Announcement: there is an English version of this forum on 
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?
Angehängte Dateien:
-
cw_sig_01.png
3 KB
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.
Warum sollte man sich durch das Rechteck etwas ersparen? Sinus ist doch einfach zu erzeugen?
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.
Wozu wird denn eigentlich bei DEM Anwendungsfall IQ betrieben? Ist da eine Frequenzmodulation drin?
Angehängte Dateien:
-
cw_decoder_hi06.png
1,3 KB
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?
Angehängte Dateien:
> 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.
Wieso braucht es noch einen TP, wenn die FFT doch filtert? Was ändert der im Vergleich zum Wegdenken der Höhen?
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.
Angehängte Dateien:
-
waterfall_01.png
67 KB -
cw1_noise.png
3,6 KB
> 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
Angehängte Dateien:
-
wfall_20161228.png
33 KB
> 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.