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?
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.
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.
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'.
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.
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.
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?
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?
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.
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.
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?
> 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).
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.
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.
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.
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.
> 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.
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.
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.
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.
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 :)
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
> 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.
> 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.
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?
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"?
> 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
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.
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.
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
> 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.
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