Forum: Digitale Signalverarbeitung / DSP / Machine Learning Mischer mit Rechteck Oszillator?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Manfred M. (bittbeisser)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin gerade dabei für meinen Morsedecoder eine neue Methode der 
Signalaufbereitung auszuprobieren. Nach diesem Vorbild (Zweites Bild):
https://wwwhome.ewi.utwente.nl/~ptdeboer/ham/rscw/algorithm.html

Nachdem ich in anderen Veröffentlichung gesehen hatte, das für den 
Oszillator auch Rechteck Generatoren eingesetzt werden, habe ich 
versucht, die Sinus und Cosinus Funktionen durch entsprechende Rechteck 
Funktionen zu ersetzen. Ziel war die Prozessorlast zu verringern.

Aber das Ergebnis finde ich nicht wirklich überzeugend. Bei dem Bild im 
Anhang ist der untere Teil mit sin/cos entstanden und der obere Teil mit 
Rechteck. Im Gegensatz zum Vorbild wurden dabei hinter dem Mischer 
jeweils ein 4 poliger Tschebyscheff Tiefpass (fg=0.0125 SR =100Hz) 
eingesetzt. Die Eingangsdaten sind in beiden Fällen exakt identisch, da 
es sich um eine .WAV Datei handelt.

Wodurch entstehen diese Abweichungen? Sind die Filter nicht gut genug?

von Possetitjel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Manfred M. schrieb:

> Nachdem ich in anderen Veröffentlichung gesehen hatte, das
> für den Oszillator auch Rechteck Generatoren eingesetzt
> werden, habe ich versucht, die Sinus und Cosinus Funktionen
> durch entsprechende Rechteck Funktionen zu ersetzen.

Kann man natürlich machen, ist aber eine etwas grobe
Methode.

> Ziel war die Prozessorlast zu verringern.

Naja. Warum immer gleich der Holzhammer?

Man könnte ja auch mathematisch etwas feinfühliger zu Werke
gehen -- Tabelle für die Winkelfunktionen, zu Beispiel, oder
Polygonzug als Näherung (Trapez, also Dreieck ohne Spitze),
oder Treppenfunktion, oder Parabelnäherung.

> Aber das Ergebnis finde ich nicht wirklich überzeugend. [...]
>
> Wodurch entstehen diese Abweichungen?

Naja, der Pythagoras (sin^2 + cos^2 = 1) gilt halt nicht für
Rechtecke.
Darüberhinaus findet beim Multiplizieren mit Rechtecken statt
mit Sinus auch Oberwellenmischung statt.

> Sind die Filter nicht gut genug?

Das mag auch eine Rolle spielen.

von IUnknown (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ein Rechteck als LO einzusetzen und mit einem Filter zu erschlagen ist 
durchaus üblich. Wichtig ist nur dass die ersten paar Oberwellen 
ausreichend gedämpft werden (vielleicht noch einen Bandstopfilter auf 
die dritte Harmonische legen).

Was auch relevant ist ist die Phase der LOs, weicht diese von 90° ab 
wirst du das sofort in den Ausgangsdaten merken. Ein Sinus kommt durch 
seine analogen Werte eher mit Ungenauigkeiten klar, beim Rechteck wirkt 
sich jede leichte Veränderung aus.

Was du machen könntest wäre die LOs durch einen gesteuerten IIR-Filter 
zu erzeugen, was sehr sparsam für die CPU ist.

Alternativ kannst du auch sowas:
https://ccrma.stanford.edu/~juhan/pubs/jnam-emile05.pdf
implementieren. Kostet fast keine Rechenleistung und gibt dir deutlich 
reduzierte Oberwellen.

von Digitaler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Warum sollte man sich durch das Rechteck etwas ersparen? Sinus ist doch 
einfach zu erzeugen?

von Opper (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was hast du für ein Eingangssignal? Audio? Dann sollte der klassische 
8051 bereits ausreichen. Prozessorlast ließt sich im Zusammenhang mit 
der Kodierung von Morsesignalen 'witzig'.

von Manfred M. (bittbeisser)


Bewertung
0 lesenswert
nicht lesenswert
Also auf diese Idee bin ich heute Morgen gekommen, als eine bekannte 
Suchmaschine mir eine PDF Datei von der TFH-Berlin vermittelt hatte. Da 
wurde die Phasenbeziehung sichergestellt durch Erzeugung aus einem 
Oszillator mittels Frequenzteilung. Filter wurden da auf der 
Oszillatorseite nicht erwähnt.

> Ein Sinus kommt durch seine analogen Werte eher mit Ungenauigkeiten
> klar, beim Rechteck wirkt sich jede leichte Veränderung aus.
Das könnte natürlich der springende Punkt sein.

Bei den echten Winkelfunktionen gehe ich von der Phase (0 bis 2π) aus. 
Da kann es schonmal sein, dass der Phasenwechsel etwas zu spät kommt. 
Aber er sollte eigentlich immer zu den Samples passen, da das ja der 
gleiche Arbeitstakt ist.

> Naja. Warum immer gleich der Holzhammer?
Ok, dann packe ich den wieder ein ;-)

> Was hast du für ein Eingangssignal? Audio?
300 bis 2700 Hz mit 8000Hz abgetastet.

> Prozessorlast ließt sich im Zusammenhang mit der Kodierung
> von Morsesignalen 'witzig'.
Tatsächlich bereitet mir die Signal Aufbereitung mehr Kopfzerbrechen. 
Die eigentliche Decodierung schafft auch ein Arduino und hat dabei noch 
Luft. Wichtig ist allerdings, das er saubere Rechtecksignale bekommt.

Momentan untersuche ich das am PC, da ich dort auch eine vollständige 
FFT des Eingangssignals machen kann. Auch den zeitlichen Signalverlauf 
werde ich später weglassen.

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wozu wird denn eigentlich bei DEM Anwendungsfall IQ betrieben? Ist da 
eine Frequenzmodulation drin?

von Manfred M. (bittbeisser)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nein, bei Morsetelegrafie nicht. Aber es wird ja auf 0 Hz herunter 
gemischt. Dazu müsste eigentlich der LO phasengenau der Sendefrequenz 
entsprechen, was er nicht tut. Daher tritt auch normalerweise eine 
langsame Schwebung auf, die das Nutzsignal zeitweise verschwinden lässt. 
Aber durch die Aufspaltung in I und Q Anteil und anschliessende 
Vectoraddition (sqrt( i*i + q*q)) wird das vermieden. Wird irgendwo in 
der verlinkten Seite auch erwähnt.

Ich hatte das bei einer meiner früheren Versuche missachtet. Das 
Ergebniss ist im Anhang zu bewundern. Dabei ist zu beachten, dass durch 
die "Gleichrichtung" die negativen Halbwellen "hochgeklappt" sind. Es 
ist zwar kein Zeitmassstab angegeben, aber jedes horizontale Pixel 
repräsentiert 5 ms.

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ach so, Ich dachte, dass Du Dich schon auf die Sendefrequenz synchst - 
zumindest wird das in dem Diagram das gelinkt ist, angedeutet.

Aber warum wird überhaupt gemischt? Kann man die 1/0 nicht diskret 
erkennen und verarbeiten?

von Possetitjel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Manfred M. schrieb:

> Ich hatte das bei einer meiner früheren Versuche missachtet.
> Das Ergebniss ist im Anhang zu bewundern.

Sind das dieselben Quelldaten wie in Deinem ersten Beitrag?

Das hier sieht ja - bis auf die Schwebung - schon richtig gut
aus.

> Dabei ist zu beachten, dass durch die "Gleichrichtung" die
> negativen Halbwellen "hochgeklappt" sind.

Naja, logisch. Die Mischung ist ja ein Synchrongleichrichter.

> Es ist zwar kein Zeitmassstab angegeben, aber jedes horizontale
> Pixel repräsentiert 5 ms.

Wenn Du die Schwebung durch richtige I/Q-Mischung und Betrags-
bildung eliminierst, müsste das doch super aussehen. Wieso tut
es das nicht?

von Possetitjel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:

> Aber warum wird überhaupt gemischt? Kann man die 1/0 nicht
> diskret erkennen und verarbeiten?

Naja - wie denn?

Der Empfänger spuckt eine (gestörte) NF aus, z.B. 800Hz.

Die sauberste Methode "Ton da / Ton nicht da" zu unterscheiden,
ist halt die Kreuzkorrelation. Im Prinzip ist da ja nix weiter
als ein Synchrongleichrichter.
Und da die Phasenlage der NF unbekannt ist, muss man mit Sinus
und Cosinus separat korrelieren (=mischen und tiefpassfiltern)
und dann den Betrag bilden.

Anschließend hat man eine "Gleichspannung", auf die man mit
einem Schwellwertschalter losgehen kann.

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Mir ist immer noch nicht klar, wie der übertragene Datenstrom jetzt 
aussieht. Ist das frequenzmoduliert? Wenn da doch nur 0/1 kommt geht das 
doch klassisch.

von Possetitjel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:

> Mir ist immer noch nicht klar, wie der übertragene Datenstrom
> jetzt aussieht.

Morsezeichen werden üblicherweise über einen Funkkanal übertragen.

> Ist das frequenzmoduliert?

Vermutlich nicht. On/Off-Keying, nehme ich an. Modulationsart
A1A ist das wohl.

> Wenn da doch nur 0/1 kommt

Nein, kommt nicht!
Funkkanäle sind gleichstomfrei!

> geht das doch klassisch.

Wie denn?

von Manfred M. (bittbeisser)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Ach so, Ich dachte, dass Du Dich schon auf die Sendefrequenz synchst -
> zumindest wird das in dem Diagram das gelinkt ist, angedeutet.
Nicht ganz. Ich benutze nur den linken Teil des Diagramms, auch ohne den 
"moving average" Anteil und ohne weitere Dezimierung.

Das Vorbild setzt eine kontinuierliche Aussendung mit konstanter, bzw. 
nur langsam Frequenz veränderlicher Aussendung voraus, da es für die 
Erfassung von Telemetrie Daten von Satelliten gedacht ist. Das 
entspricht aber nicht den Bedingungen wie sie im Amateurfunk 
vorherrschen. Da dominieren kurze Aussendungen. Da kann man dann auch 
schlecht eine Frequenznachführung Aufgrund einer FFT durchführen. Die 
Zeiten sind einfach zu kurz.

> Aber warum wird überhaupt gemischt? Kann man die 1/0 nicht diskret
> erkennen und verarbeiten?
Ich hatte zuvor zur Erkennung des Signale den Goertzel Algorithmus 
verwendet, was mich aber nicht wirklich überzeugt hat. Der Grund ist, 
das dieser nur bedingt an leicht veränderliche Frequenzen angepasst 
werden kann (unter Missachtung einiger Design Vorgaben). Dazu kommt dann 
noch die nicht gerade berauschende Dämpfung der ersten Nebenzipfel und 
der nicht flache Durchlassbereich (siehe Anhang).

> Sind das dieselben Quelldaten wie in Deinem ersten Beitrag?
Keine Ahnung, mein (wirklich) erster Beitrag liegt schon etwas zurück.

> Der Empfänger spuckt eine (gestörte) NF aus, z.B. 800Hz.
Ja, was der Empfänger ausspuckt hängt natürlich vom Verhalten des 
Operators ab. 800Hz ist natürlich die Wunschfrequenz, zumal da alle 
Parameter zusammenpassen. Aber in der Realität sieht das natürlich 
anders aus. Der Empfänger spuckt das aus, was der Operator eingestellt 
hat und das Programm muss irgendwie damit fertig werden, also auch mit 
Frequenzen die um +/- 200 Hz davon abweichen.

> Die sauberste Methode "Ton da / Ton nicht da" zu unterscheiden,
> ist halt die Kreuzkorrelation.
Das habe ich schon öfters gehört, aber nicht wirklich verstanden. Das 
Hauptproblem hierbei scheint darin zu bestehen, das manuell eingegebene 
Morsezeichen nicht mit konstanter Geschwindigkeit erzeugt wurden und 
einem erheblichen "Phasenjitter" ausgesetzt sein können.

Das verlinkte Beispiel geht von kontinuierlicher Aussendung und von 
einer exakten Einhaltung des Punkt-Strich Verhältnisses von 1:3 aus, was 
bei "human input" nicht garantiert werden kann.

> Wenn Du die Schwebung durch richtige I/Q-Mischung und Betrags-
> bildung eliminierst, müsste das doch super aussehen. Wieso tut
> es das nicht?
Keine Ahnung. Aber das sind die Ergebnisse verschiedener 
Programmversionen und das letzte Beispiel ist nicht von der selben 
Quelldatei wie die ersten (konservierter Screenshot).

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Manfred M. schrieb:
> Das habe ich schon öfters gehört, aber nicht wirklich verstanden. Das
> Hauptproblem hierbei scheint darin zu bestehen, das manuell eingegebene
> Morsezeichen nicht mit konstanter Geschwindigkeit erzeugt wurden und
> einem erheblichen "Phasenjitter" ausgesetzt sein können.

Die KK liefert Dir eigentlich genau diese Info "DA und NICHT-DA" - die 
Jitterbehandlung wäre nochmal ein weiteres Thema. Das ist aber leicht 
lösbar.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ach so - Dies noch: Wie konstant ist die Sendefrequenz? Kann die nicht 
jeweils permanent grob ermittelt werden und für die KK verwendet werden? 
Wenn die Pulse lang genug sind, könnte man auch einen sweep mit 
Pulskompression benutzen.

von Manfred M. (bittbeisser)


Bewertung
0 lesenswert
nicht lesenswert
Also für die KK habe ich bisher noch keinen Denkansatz für die 
Realisierung, aber das kommt vielleicht irgendwann.

> Ach so - Dies noch: Wie konstant ist die Sendefrequenz?
Also die Sendefrequenzen sind im Prinzip ausreichend konstant. Aber das 
hilft nicht, da es sich um unmodulierte Träger handelt. Was man zu hören 
kriegt, hängt von der Empfänger Einstellung ab. Und was noch schlimmer 
ist, ist dass die Gegenstelle, die man ja vielleicht auch mitschreiben 
will, auch mal locker 50Hz daneben antworten kann.

Die Zeitdauer für einen Punkt kann zwischen 30 und 80 ms variieren, aber 
nicht innerhalb einer Sendung. Was aber passieren kann ist, dass die 
Gegenstation mit einer anderen Geschwindigkeit antwortet.

Übrigens, ich habe heute den "Rohbau" einer FFT (als Wasserfalldiagramm) 
fertig gestellt und mir damit mal angesehen was der Mischer so 
produziert. Es sieht in beiden Fällen fürchterlich aus, also zumindest 
wenn mehrere Signale vorhanden sind. Hinter dem Tiefpass ist davon aber 
meist nichts mehr zu sehen.

von Martin K. (mkmannheim) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wieso braucht es noch einen TP, wenn die FFT doch filtert? Was ändert 
der im Vergleich zum Wegdenken der Höhen?

von Günter Lenz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Warum so kompliziert? Die NF kann man doch einfach
mit Dioden gleichrichten, glätten und dann folgt
noch ein Schmitt-Trigger, und hat dann einen sauberen
Rechteck. Dieses Rechtecksignal bekommt dann der
Mikrocontroller und der kann sich dann um die
dekodierung kümmern.

von Manfred M. (bittbeisser)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Wieso braucht es noch einen TP, wenn die FFT doch filtert?
Wenn ich nur über die FFT gehe, benötige ich eine höhere Abtastrate, um 
sowohl eine ausreichende Frequenzauflösung als auch eine hohe 
Zeitauflösung zu bekommen. Tatsächlich gibt es ein Programm, das so 
arbeitet.
http://www.dxatlas.com/cwskimmer/
Die erforderliche Abtastrate ist dann 48kHz oder mehr. Ausserdem bekomme 
ich mit der FFT ein festes Kanalraster.
Da hätte ich dann auch beim Goertzel Algorithmus bleiben können.

> Warum so kompliziert? Die NF kann man doch einfach mit Dioden
> gleichrichten, glätten und dann folgt noch ein Schmitt-Trigger, ...
Das kann man so machen, wenn in dem NF Signal nichts weiteres enthalten 
ist. Die Realität bei Kurzwellenempfang sieht aber anders aus. Dazu 
braucht es dann noch eine einstellbare Schwelle, um das Signal vom 
Hintergrundrauschen zu trennen.

Anhang 1 zeigt neben einem Morsesignal (800Hz) noch ein RTTY Signal 
(Funkfernschreiben, 1275 und 1445 Hz). Mit der Filtermethode können 
diese Signale sauber getrennt werden, ohne Zeitauflösung zu verschenken.

Anhang 2 zeigt, wie ein stark verrauschtes Signal aussehen kann. Die 
rosa Linie ist die Entscheidungsschwelle (gleitender Mittelwert) und die 
obere Impulslinie ist das Ergebnis davon. Ich glaube nicht, dass da eine 
einfache Gleichrichtung gereicht hätte. Die senkrechten Linien oben 
rechts geben übrigens die gemessenen Zeitintervalle an (bezogen auf die 
unterste Impulsreiche). Man sieht, das diese etwas variieren.

von Possetitjel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Günter Lenz schrieb:

> Die NF kann man doch einfach mit Dioden gleichrichten,
> glätten und dann folgt noch ein Schmitt-Trigger, und
> hat dann einen sauberen Rechteck.

Nee, das klappt nur bei sehr gutem Störabstand.

Sobald Rauschen und/oder Störsignale mit im Kanal sind,
kommt nur noch Schotter heraus.

von Possetitjel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Manfred M. schrieb:

>> Sind das dieselben Quelldaten wie in Deinem ersten
>> Beitrag?
> Keine Ahnung, mein (wirklich) erster Beitrag liegt
> schon etwas zurück.

Hmpf!

Ich meinte natürlich den ersten Beitrag dieses Threads,
also den vom 21.11.2016.

Zum Vergleich von Verfahrensvarianten kann es sich lohnen,
einen Zoo von realen oder synthetischen Testdaten anzulegen,
auf den man gezielt zurückgreifen kann.

>> Die sauberste Methode "Ton da / Ton nicht da" zu unter-
>> scheiden, ist halt die Kreuzkorrelation.
> Das habe ich schon öfters gehört, aber nicht wirklich
> verstanden.

Das verstehe ich wiederum nicht - denn mit der Mischung auf
DC (=Synchrongleichrichtung) und Tiefpassfilterung bestimmst
Du ja die Korrelation!

Das Problem besteht darin, dass Du einen brauchbaren
Schätzwert für die Tonhöhe brauchst, denn ohne lokale
Referenzfrequenz kein Synchrongleichrichter.

> Das verlinkte Beispiel geht von kontinuierlicher Aussendung
> und von einer exakten Einhaltung des Punkt-Strich Verhältnisses
> von 1:3 aus, was bei "human input" nicht garantiert werden
> kann.

Nee, die Pause/Punkt/Strich-Unterscheidung ist schon die
nächste Stufe der Dekodierung.

von Possetitjel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:

> Ach so - Dies noch: Wie konstant ist die Sendefrequenz?
> Kann die nicht jeweils permanent grob ermittelt werden
> und für die KK verwendet werden?

Die Driftgeschwindigkeit der Frequenz wird ja hoffentlich
beschränkt und nicht allzu hoch sein.
Da Manfred - wie ich es verstanden habe - offline arbeitet,
könnte man eine Art Mehrpassverfahren anwenden: Im ersten
Durchgang "irgendwie" (FFT, Filterbank, ...) die Frequenz
schätzen und nachführen; im zweiten Durchgang dann mischen
und das Nutzsignal weiterverarbeiten.

> Wenn die Pulse lang genug sind, könnte man auch einen
> sweep mit Pulskompression benutzen.

Hmm. Sweep. - Vielleicht kann man Anleihen bei der Wavelet-
Transformation machen. Durch die kurzen Bursts kommt ja
auch eine gewisse spektrale Breite ins Spiel.

von Possetitjel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Manfred M. schrieb:

>> Wieso braucht es noch einen TP, wenn die FFT doch filtert?
>
> Wenn ich nur über die FFT gehe, [...]

Aber das verlangt doch niemand. Warum immer nur schwarz oder
weiss?

Im Funkkanal können zahlreiche unterschiedliche Störungen
auftreten: Rauschen, Schwund, Frequenzdrift, Störsignale,
ungleichmäßig gegebene Zeichen.

Es ist doch klar, dass es nicht DEN EINEN EINZIGEN Wunder-
algorithmus gibt, der gegen sämtliche Störungen immun ist.

Also wird man mehrere ganz unterschiedliche Verfahrensschritte
kombinieren müssen, deren jeder genau eine Schwierigkeit
bekämpft.
Nicht alle dieser Schritte müssen direkt die Nutzdaten
bearbeiten, manche können auch der Parameterschätzung dienen,
damit andere Verarbeitungsschritte korrekt funktionieren.

FFT und Wasserfalldiagramm könnten doch ein guter Anfang
sein: Man erhält für jedes Zeitintervall einen Block von
Frequenzeimern, die mehr oder weniger mit Signal gefüllt
sind.
Jetzt gehst Du mit einem Klassifizierungsalgorithmus, der
gleitend n aufeinanderfolgende Spektren betrachtet, in
Richtung der Zeitachse durch das Wasserfalldiagramm und
verfolgst, durch welche Frequenzzellen Dein Signal driftet.

Als Ergebnis erhältst Du einen zeitabhängigen Schätzwert
für die Frequenz Deines Nutzsignales.
Den kannst Du verwenden, um im zweiten Durchgang mit anderen
Verfahren (z.B. einem adaptiven Filter, oder einem I/Q-Mischer)
auf Deine gesampelten Daten loszugehen.

Irgendwie so ähnlich würde ich es zumindest versuchen :)

von Manfred H. (manfredbochum)


Bewertung
0 lesenswert
nicht lesenswert
Interessantes Thema.
Ich hab früher mit LM567 gearbeitet. Mein Programm hat bis 150Bpm auf 
VC20 dekodiert.  Natürlich mit automatischer Geschwindigkeit. 
Anpassung.
Alles in SW ist einfacher.
Viel Erfolg

von Manfred M. (bittbeisser)


Bewertung
0 lesenswert
nicht lesenswert
> Zum Vergleich von Verfahrensvarianten kann es sich lohnen,
> einen Zoo von realen oder synthetischen Testdaten anzulegen,
> auf den man gezielt zurückgreifen kann.
Genau das habe ich gemacht um die Ergebnisse verschiedener Strategien 
vergleichen zu können. Also mit verschiedenen Pegeln für Rauschen und 
Signal sowie gezielt unsauberen Timing. Aber "echte" Aufnahmen sind auch 
dabei.
An dem eigentlichen Decoder habe ich aber schon fast 1 Jahr nichts mehr 
gemacht, weil ich erkannt habe, das ich meine Signal Aufbereitung 
verbessern muss. Deshalb habe ich mir auch den DSP-Guide als Hardcopy 
besorgt. Die meisten deutschen Bücher bestehen ja fast nur aus Formeln 
und geben wenig Hinweise zur Realisierung.

> Das Problem besteht darin, dass Du einen brauchbaren
> Schätzwert für die Tonhöhe brauchst,...
Am Computer ist das relativ einfach. Das könnte man durch einen Klick 
auf das Wasserfalldiagramm erledigen. Für eine automatische 
Feinabstimmung habe ich allerdings noch keine Idee.

> Nee, die Pause/Punkt/Strich-Unterscheidung ist schon die
> nächste Stufe der Dekodierung.
Eigentlich fängt damit die Decodierung an. Ich nenne das 
Synchronisation.
Das in dem verlinken Beispiel exakt ein 1:3 Verhältniss vorausgesetzt 
wird, hängt damit zusammen, das dort die erkannten Bitzellen in 
Zweiergruppen (Dibits) aufgeteilt werden.

> Ich hab früher mit LM567 gearbeitet. Mein Programm hat bis 150Bpm auf
> VC20 dekodiert.  Natürlich mit automatischer Geschwindigkeit.
> Anpassung.
Ich komme etwa bis 300Bpm. Allerdings muss ich dann die Filterbandbreite 
ab ca. 180Bpm erhöhen und schwache Signale gehen dann nicht mehr. Aber 
ich denke alles über 180 ist praxisfremd oder Leistungssport.
Geschwindigkeitsanpassung ist klar. Bei Sprüngen ab ca. 45% gibts aber 
Probleme.

von Manfred M. (bittbeisser)


Bewertung
0 lesenswert
nicht lesenswert
> FFT und Wasserfalldiagramm könnten doch ein guter Anfang
> sein: Man erhält für jedes Zeitintervall einen Block von
> Frequenzeimern, die mehr oder weniger mit Signal gefüllt
> sind.
Ansatzweise hatte ich das schon probiert. Also ich habe die Frequenzen 
mit einen gleitenden Mittelwert gemittelt und in eine Datei schreiben 
lassen. Aber in dem Moment, wo eine längere Pause entsteht, driftet die 
Frequenz zur nächsten Störung weg. Da bräuchte ich dann so etwas wie 
eine Rauschsperre. Die habe ich zwar, funktioniert bei schwachen 
Signalen aber nicht wirklich.

von Possetitjel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Manfred M. schrieb:

>> FFT und Wasserfalldiagramm könnten doch ein guter Anfang
>> sein: Man erhält für jedes Zeitintervall einen Block von
>> Frequenzeimern, die mehr oder weniger mit Signal gefüllt
>> sind.
>
> Ansatzweise hatte ich das schon probiert.

Ahh okay. Um so besser.

> Also ich habe die Frequenzen mit einen gleitenden
> Mittelwert gemittelt und in eine Datei schreiben
> lassen.

Nach welchem Kriterium hast Du die "neue" Frequenz
ausgewählt? Einfach den Bin mit dem stärksten Signal?

> Aber in dem Moment, wo eine längere Pause entsteht,
> driftet die Frequenz zur nächsten Störung weg.

Ja. - Gleitendes Mittel kann gefährlich sein, denn es
wirft Bins, die tatsächlich Nutzsignal enthalten,
gnadenlos mit der relativ stärksten Rauschkomponente
in einen Topf und mittelt darüber.
Das ist natürlich sachlich falsch. Zum einen brauchst
Du also, wie Du selbst weiter unten sagst, einen
Diskriminator, der Bins mit Nutzsignal von solchen mit
Rauschen unterscheidet. Nur bestätigte Nutzsignalbins
dürfen zur Frequenznachführung verwendet werden.

Dadurch wird aber die Folge der "gültigen" Frequenzpunkte
lückenhaft, so dass es sich anbietet, das gleitende Mittel
durch eine lineare Regression zu ersetzen. Das kann man
sogar dreidimensional machen.

Als Gewinn erhältst Du extrapolierte Schätzwerte für
die Amplitude und die Frequenz des Nutzsignales sowie
eine Kennzahl für die bisher aufgetretenen Frequenz-
schwankungen.

> Da bräuchte ich dann so etwas wie eine Rauschsperre.

Genau.

> Die habe ich zwar, funktioniert bei schwachen Signalen
> aber nicht wirklich.

Wie arbeitet die? Bzw. warum funktioniert die nicht
wirklich?

von Possetitjel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Manfred M. schrieb:

>> Zum Vergleich von Verfahrensvarianten kann es sich
>> lohnen, einen Zoo von realen oder synthetischen
>> Testdaten anzulegen, auf den man gezielt zurückgreifen
>> kann.
>
> Genau das habe ich gemacht

Okay. - Ich kenne ja nur Deine Beiträge in diesem Thread
und wusste nicht, dass Du schon länger an diesem Thema
dran bist.

> An dem eigentlichen Decoder habe ich aber schon fast 1 Jahr
> nichts mehr gemacht, weil ich erkannt habe, das ich meine
> Signal Aufbereitung verbessern muss.

Ich bin seit einer Weile an einem verwandten Thema (OCR).

Das Problem ist halt, dass das menschliche Gehirn viele
unterschiedliche Teilverfahren iterativ kombiniert.
Die einzelnen Verarbeitungsebenen beeinflussen sich
teilweise recht stark, so dass es schwierig ist, das
einer sequenziell arbeitenden Maschine beizubringen.

> Die meisten deutschen Bücher bestehen ja fast nur aus
> Formeln und geben wenig Hinweise zur Realisierung.

Schwieriger Punkt.
Häufig kann man mit ziemlich hemdsärmeligen Methoden schon
gute Resultate erzielen; andererseits sollte man von der
mathematischen/numerischen Seite schon grob verstehen, was
man da tut.

>> Das Problem besteht darin, dass Du einen brauchbaren
>> Schätzwert für die Tonhöhe brauchst,...
> Am Computer ist das relativ einfach. Das könnte man durch
> einen Klick auf das Wasserfalldiagramm erledigen. Für eine
> automatische Feinabstimmung habe ich allerdings noch keine
> Idee.

Nee - Du willst zuviel auf einmal.

Der eine Schritt ist das Tracking, also die reine Nachführung,
wenn ein garantiert korrekter Startwert bekannt ist.
Das andere Thema ist dann, ob dieser Startwert gegebenenfalls
auch automatisch von der Maschine gefunden werden kann.

Das sind aber zwei Entwicklungsschritte. Alles andere ist
meiner Meinung nach methodischer Wahnsinn.

>> Nee, die Pause/Punkt/Strich-Unterscheidung ist schon die
>> nächste Stufe der Dekodierung.
> Eigentlich fängt damit die Decodierung an. Ich nenne das
> Synchronisation.

Okay... Begriffsverwirrung.

Ich zähle, auch wenn das theoretisch vielleicht nicht 100%ig
korrekt ist, die ganze Signalvorverarbeitung (also die
Frequenznachführung, Puls-Pause-Unterscheidung usw.) zum
Themenkreis "Kanal(de)codierung", die finale Morsezeichen-
erkennung fiele demnach unter "Quellencodierung".

> Das in dem verlinken Beispiel exakt ein 1:3 Verhältniss
> vorausgesetzt wird, hängt damit zusammen, das dort die
> erkannten Bitzellen in Zweiergruppen (Dibits) aufgeteilt
> werden.

Entschuldigung - welches "verlinkte Beispiel"?

von Manfred M. (bittbeisser)


Bewertung
0 lesenswert
nicht lesenswert
> Nach welchem Kriterium hast Du die "neue" Frequenz
> ausgewählt? Einfach den Bin mit dem stärksten Signal?
Ja, allerdings nur zwischen ca. 600 bis 900 Hz (hatte ich variiert). Als 
ich meinen letzten Beitrag schrieb, kam mit der Gedanke nur wenige 
Nachbar Bins zu beobachten.

> Wie arbeitet die? Bzw. warum funktioniert die nicht wirklich?
Das kann man ansatzweise im Anhang "cw1_noise.png" erkennen, wo die 
beiden hellblauen Linien in etwa dem Spitzenwert und dem Rauschteppich 
folgen. Der Mittelwert (rosa) wird mit der Differenz dieser beiden 
Linien verglichen. Wenn die Differenz groß genug ist, funktioniert das. 
Bei der roten Linie hatte ich so etwas ähnliches, wie die 
Standardabweichung versucht. Aber da hatte ich die Literatur wohl falsch 
interpretiert.

> Okay. - Ich kenne ja nur Deine Beiträge in diesem Thread ...
Ich hatte einige Tage zuvor einige Fragen zur Hilbert Transformation, 
die ich in diesem Zusammenhang auch schon mal auf dem Zettel hatte. 
Deswegen die Frage.

> Nee - Du willst zuviel auf einmal.
Irgendeinen Ansporn bracht man doch. Und jetzt, wo ich im Ruhestand bin, 
habe ich Zeit dafür.

> ...die finale Morsezeichen-erkennung fiele demnach
> unter"Quellencodierung".
Ich bin gerade dabei das bewusst zu trennen, damit die einzelnen Module 
ausgetauscht werden können.
Beispiel: Ich habe mit einem Arduino eine Morsetaste programmiert, die 
mit getrennten Kontakten für Punkte und Striche arbeitet. Z.B. so etwas:
https://blog.radioartisan.com/arduino-cw-keyer/
Dabei wird der Text dann auch in einem Display angezeigt, was noch ohne 
Decoder möglich ist. Aber wenn man dann nur eine einfache Taste 
anschliesst, ist schon ein einfacher Decoder notwendig, weil die Punkt 
und Strich Folgen nicht mehr von den Kontakten kommen. Da habe ich dann 
versuchsweise den Decoderteil auf den Arduino übertragen.

> Entschuldigung - welches "verlinkte Beispiel"?
Das zum RSCW Programm, wo es um den Empfang von Telemetriedaten von 
Satelliten geht:
https://wwwhome.ewi.utwente.nl/~ptdeboer/ham/rscw/algorithm.html

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Possetitjel schrieb:
> Markus W. schrieb:
Das stand ich wohl sehr auf dem Schlauch. Ich hatte da irgendwie ständig 
den Morsetaster vor Augen und dacht an eine Drahtverbindung.

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich hätte nochmals eine kleine Verständnisfrage:

Bei dem digitalen Mischer sind I und Q immer um 90 Grad verschoben. Wie 
möchte man das erreichen, wenn ein Rechteck verwendet werden soll?

Die Phase von 90 Grad ist nur für die Grundwelle gegeben, schon für die 
erste Oberwelle wären es 180 und damit Auslöschung. So setzt sich das 
fort.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Markus W. schrieb:
> schon für die
> erste Oberwelle wären es 180 und damit Auslöschung. So setzt sich das
> fort.

Bei einem Rechteck gibt es diese Oberwellen nicht. Das waere eher ein 
Problem, wenn du mit Saegezaehnen mischen wuerdest. Aber wer macht das 
schon ;-)
Auch mit Rechteck als LO mischen ist, eher shice - aber es spart nunmal 
die Multiplizierer ein, was schon ein Ansporn sein kann, eine Kroete zu 
schlucken.

Gruss
WK

von Manfred M. (bittbeisser)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Bei dem digitalen Mischer sind I und Q immer um 90 Grad verschoben. Wie
> möchte man das erreichen, wenn ein Rechteck verwendet werden soll?
Also um einen I und Q Zweig zu erzeugen multipliziere ich einmal mit cos 
und dann mit sin. Bei einem Rechteck nimmt man dann 2 entsprechend 
gegeneinander verschobene Rechtecksignale.

Der Diskussion um die Oberwellen kann ich jetzt nicht ganz folgen. 
jedenfalls gibt es sie. Ich füge mal ein Diagramm an, welches unter 
Weglassung der Tiefpassfilter entstanden ist. Das Eingangssignal ist ein 
Sweep von 300 - 1200 Hz und ca. 1.5 Sec Dauer.

> Auch mit Rechteck als LO mischen ist, eher shice - aber es spart nunmal
> die Multiplizierer ein, ...
Aber bei meiner Softwarelösung bringt das nicht wirklich etwas. Ich habe 
da mal einige Zeitmessungen gemacht und dabei festgestellt, das der PC 
seine Zeit ganz woanders vertrödelt.

Die reine FFT (1024 Samples) dauert ca. 0.4ms
Die Aufbereitung der Pixeldaten ca. 1.4 ms (incl. 1 Pixelzeile 
scrollen).
Die GUI braucht dann nochmal 2 bis 14 ms um das dann auch auf den 
Bildschirm zu zaubern.
Alles gemessen auf einem alten Athlon XP.

Da fallen dann 2 zusätzliche Multiplikationen nicht weiter auf. Ich habe 
mich deshalb von der Rechteck Lösung erstmal verabschiedet.

Ich finde, es ist sehr schön zu sehen, wie sich die unerwünschten 
Aliasse wieder einschleichen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.