Seit ich den folgenden Beitrag gefunden habe, beschäftige ich mich wieder einmal mit dem Problem, Morsezeichen aus dem Kurzwellenempfänger zu decodieren. http://www.youtube.com/watch?v=zbQFlzbDb8w Ich habe das Programm auf einem Arduino erprobt, aber ich bin damit nicht so recht zufrieden, denn es hat: - keine Rauschsperre, d.h. es kommen ständig Zeichen, auch in Sendepausen - unzureichende Selektivität bezüglich der Nachbarkanäle Wer von Euch hat sich erfolgreich mit dem Problem beschäftigt?? Wünschenswert wären Eigenschaften wie - Frequenzselektivität, - Schwundausregelung, - Störaustaster (gegen Gewitterstörungen), - Temponachregelung, - Toleranz gegenüber per Hand gegebenen Zeichen. Das Goertzel- Filter, wie im o.g. Beitrag lässt sich leicht programmieren, aber seine Bandbreite erscheint mir zu hoch. Anregungen und Ideen sind gefragt!! (Aber bitte keine Vorschläge wie "CW-Get", es soll auf einem µC laufen!!)
Du schreibst da "Kurzwellenempfaenger". Und da liegt nach meiner Meinung schon das Problem. Meinst Du einen gewöhnlichen Kurzwellen-Rundfunkempfaenger? Da brauchst Du schon einen SSB Empfaenger oder ein Gerät mit noch schmalbandigerem Filter. Andernfalls hörst Du nur zufälliges Gepiepe, welches auch nur zufällig lesbare Signale abgibt. Geraete, die breitbandig empfangen und daraus mit cpu bzw. controller filtern, gibt es auch, das ist dann aber eine andere Technik. Auf jeden Fall ist eine Frequenzbestimmung mittels Quarz zu empfehlen. Programme um CW/Morsecode zu decodieren, gibt es schon für Pc und Soundkarte glaub ich. Aber das zu lernen ist auch ganz gut wegen der ganzen Abkürzungen usw.. Wenn Du Amateurfunker bist, solltest Du das doch wissen, oder was?
DH1AKF K. schrieb: > Ich habe das Programm auf einem Arduino erprobt, aber ich bin damit > nicht so recht zufrieden, Ein gutes Beispiel dafür, das für die meisten Probleme eine gute Hardware wesentlich wichtiger ist, als ein gutes Programm.
Harald Wilhelms schrieb: > Ein gutes Beispiel dafür, das für die meisten Probleme eine gute > Hardware wesentlich wichtiger ist, als ein gutes Programm. Ach, Morsedekoder habe ich schon vor knapp 30 Jahren auf dem Z80 gesehen. Aber das ist natürlich etwas tricky, keine FFTs oder sowas.
Auch als Laie wird man unschwer erkennen, dass es sich bei "DH1AKF" wohl um ein Rufzeichen handeln könnte... Ja, sogar mit amtlicher Bestätigung von Morsekenntnissen, die allerdings nach über 20 Jahren SSB etwas nachgelassen haben. Aber darum geht es mir nicht, sondern um die technische Herausforderung, mit einem µC eine saubere Decodierung hinzubekommen. Mein Stationsgerät ist ein IC706 MKIIG, leider ohne das optionale CW- Filter, so dass die Banbreite in Stellung CW ca. 2,8 kHz beträgt. Ich habe schon überlegt, ob ein zusätzliches NF- Filter am Lautsprecherausgang das ganze Problem entschärfen würde. Natürlich könnte man auch ein fertiges Gerät kaufen, aber dann wäre die Freude am Selbermachen dahin! Übrigens habe ich bereits einen fertigen Morsedecoder (Marke Eigenbau,) an den man Morsetaste oder Elbug anschließen kann, der aber nur einen Gleichstromeingang hat. Mein Problem ist also in erster Linie die Filterung und Umsetzung der NF.
Warum schlägst du dich mit Krücken durch das CW_Leben? Das was deine Ohren und dein Gehirn leisten können bei entsprechendem Training, das kannst nie im Leben mit Hardware lösen.
Die bisherigen Kommentare vergleiche ich mal mit dem Vorschlag, doch gefälligst Fahren oder Fliegen zu lernen, wenn jemand einen Autopiloten entwickeln will... Nein: nicht mit PC, nicht mit Raspi, Beaglebone Black oder Smartphone, sondern mit einem µC. Und dessen Möglichkeiten weitestgehend ausreizen.
DH1AKF K. schrieb: > Mein Stationsgerät ist ein IC706 MKIIG, leider ohne das optionale CW- > Filter, so dass die Banbreite in Stellung CW ca. 2,8 kHz beträgt. Damit wirst du es in realen QSOs schwer haben. Ich hatte in meinem TS-50 auch lange Zeit kein CW-Filter drin. Selbst mit der vergleichsweise guten Filterung durch Ohren und Gehirn hat das keinen Spaß gemacht (obwohl ich es auch mal für ein Mini-Pileup als V5/DL8DTL benutzt habe ;). Seit ich mir ein 270-Hz-Filter (eigentlich für den TS-480 bestimmt) da reingenagelt habe, ist das ein Unterschied wie Tag und Nacht. Aus dem 2,8-kHz-Gemisch wirst du wohl schon eine FFT benötigen, um da sinnvoll eine CW-Frequenz zu extrahieren. Selbst dann darf sich kein pegelmäßig viel stärkerer Störer im Durchlassbereich des Filters befinden (der Hauptvorteil eines schmalen ZF- oder Roofing-Filters liegt ja darin, dass die Regelung nicht durch Störer zugedrückt wird). Beim Signal hinter dem schmalen CW-Filter ist es wahrscheinlicher, dass man auch mit einfacheren Mitteln da was elektronisch dekodieren kann, denn im Allgemeinen hat man dort wirklich nur noch das Signal einer Station anliegen.
:
Bearbeitet durch Moderator
DH1AKF K. schrieb: > Die bisherigen Kommentare vergleiche ich mal mit dem Vorschlag, doch > gefälligst Fahren oder Fliegen zu lernen, wenn jemand einen Autopiloten > entwickeln will... Das wäre wohl auch wirklich mehr als zweckmäßig!
die Bandbreite kann man offensichtlich auf Kosten der Rechenzeit ueber die Anzahl der Samples (N rauf -> Bandbreite runter; im Code werden N = 128 mit Bandbreite 70Hz angegeben) reduzieren. Evtl. koenntest Du ja auch mal mit einer diskreten Hartley Transformation spielen: http://forum.arduino.cc/index.php?PHPSESSID=tveps22topa8929j5epptse101&topic=126978.msg955285#msg955285
DH1AKF K. schrieb: > sondern mit einem µC. Und dessen Möglichkeiten weitestgehend ausreizen. Ist nur die Frage was fuer ein uC? Man sollte da schon etwas schnelleres nehmen wie ein einen ARM oder DSP. http://www.nue-psk.com/ Auf der Webseite gibt es auch den Sourcecode fuer einen CW Decoder.
Hallo Wolfgang Da würde ich zuerst an Elm Chans FFT denken: http://elm-chan.org/works/akilcd/report_e.html Zuerst muss irgendwie das richtige Signal ausgewählt werden. Das kann evtl. über ein Grafikdisplay und Rotary-Encoder geschehen. Dann wird eine Driftkompensation benötigt. Die Frequenz kann langsm wandern oder als Cirp. Was passiert, wenn es mehrere Stationen nebeneinander gibt? Falls dann die Frequenz bekannt ist, kommt die Maximalwerterkennung. Der halbe oder 1/3 des Maximalwertes der Spektrallinie ergibt die Schwelle ob Ton an oder Ton aus. Die Maximalwerterkennung muss ähnlich einer AGC entsprechend schnell dem Fading folgen können. Gruß, Bernd
Mein Stand meiner Forschung ist zur Zeit der Folgende: Man kann sich ein schmalbandiges ZF-Filter mit Quarzen selbst bauen, besser als wie für SSB, weil man da nicht so viele Quarze braucht, evtl. nur einen oder zwei. Das wär auch technisch die beste Lösung. Man muss u.a. eine geeignete Frequenz wählen und mischen u.s.w., um die Bandbreite zu bestimmen. Man kann mit PC-Leistung das NF Spektrum analysieren(fast fourier...), da gibt es vor allem schon fertige Programme. Ein SSB Empfänger ist da anscheinend schon mäßig brauchbar. Wenn es darum geht, einen bestimmten Ton aus einem Frequenzgemisch zu filtern, das geht auch. Nur wie. Die passiven Filter mit Widerständen und Kondensatoren, Hochpass, Tiefpass usw. mit Verstärker benötigen eine Unzahl von Bauteilen. Man kann einen Wien-Brücken-Oszillator bauen, der jedoch nur eine zu kleine Rückkopplung zum Schwingen hat. Das kann man dann nur einstellen und testen durch auf- und wieder zurückdrehen der Rückkopplung. Man findet 2 Punkte zum Einspeisen und Abnehmen. Das entsprechende Hochfrequenzprinzip heisst glaub ich "Audion". Den Morsecode zu decodieren geht dann mit µC genauso, wie es "manuell" geschehen soll. Es gibt ein zeitliches Fenster(für Toleranzen) in dem Ereignisse interpretiert werden können, bzw. ein Fenster für kurz lang und Pause muss evtl. erst durch hören bzw, analysieren erstellt werden. Dann können während des Betriebes die Größen des Fensters nachgeführt werden. Jetzt kann man am besten helfen, wenn man weiss, was Du vor hast.
Hallo, Hmm, CW war doch die Betriebsart, wo nur der HF-Träger getastet wurde. Das entspricht einer NF im Bereich der Morse-Impulse. Wie kann man da eine NF filtern ? Oder liege ich daneben ? Gruß, Michael
@Michael Appelt Die NF wird durch Mischen mit der BFO Frequenz erzeugt. Liegen aber mehrere HF-Träger im ZF-Filterbereich, so ist das Ohr-Hirn als NF-filter gefordert die vescheidenen Mischfrequenzen zu trennen. Das funktioniert aber eben nur wie Jörg schon schrieb solange kein starker Träger die AGC des ZF verstärkers erdrosselt. Deshalb ist ein Schmalbandiges ZF-Filter so wichtig wie bei SSB eine Steilflankiges Seitenbandfilter. Für eine technische Decodierung ist es geradezu unabdingbar, sind es doch keine stabilen klaren und sauberen Signalbilder, welche da einschweben. Neben Schwund, Cirp und Drift treten noch Störungen durch aktive Störquellen auf ..... Das alles kann das Gehör gut und schnell bewerten und ausblenden, anders ein automatisches System. Das kann nur, was der Programierer ihm beibringt.
DH1AKF K. schrieb: > Das Goertzel- Filter, wie im o.g. Beitrag lässt sich leicht > programmieren, aber seine Bandbreite erscheint mir zu hoch. > Anregungen und Ideen sind gefragt!! Hallo Wolfgang, tatsächlich ist die Filterbandbreite unnötig groß. Auch meine Rechnung kommt auf eine Bandbreite von 186Hz bei einer Abtastfrequenz von 8928Hz und einer Stützstellenanzahl von 48. Soweit also alles korrekt mit der Software. Doch das Görtzel „lebt“ ja gerade von der Unterabtastung bzw. der Abtastung nahe der Nyquistfrequenz. Bei einer Abtastfrequenz von 1674Hz kommst du schon auf eine Bandbreite von 34.8Hz. Es steckt also noch Potential in der Software. 73, Joe (DL3AKB)
Matthias K. schrieb: > Man kann sich ein schmalbandiges ZF-Filter mit Quarzen selbst bauen, > besser als wie für SSB, weil man da nicht so viele Quarze braucht, evtl. > nur einen oder zwei. Naja, habe ich seinerzeit für den TS-50 probiert und aufgegeben. Insbesondere die Weitabselektion habe ich nicht in irgendein sinnvolles Maß bekommen dabei. Außerdem hat der IC706 MKII eine zweite ZF von stolzen 9,0106 MHz, dafür muss man auch erstmal Quarze bekommen.
Interessant wäre eventuell die Morse-Muster mittels Korrelation auszufiltern Störungen welche nicht ins Morseschema passen könnten so vor der Dekodierung ausgeblendet werden?
Vielleicht gehst Du die Sache falsch an. Nimm erst mal ein Soundfile mit deiner gewählten Samplerate auf und dekodier das mit deinem Algo auf dem PC. Wenn das zufriedenstellend klappt, kannst Du das dann in deine CPU übersetzen.
Vielen Dank, besonders an Joe, Jörg, Matthias und Michael für Eure interessanten Beiträge, die das Problem von ganz verschiedenen Seiten her angehen! Als einfachsten Schritt hin zur Schmalbandigkeit werde ich es mit der Unterabtastung (siehe Joe's Beitrag von 19:47) versuchen. Ganz einfach zu programmieren, indem man z.B. nur jeden 5. A/D- gewandelten Wert weiterverwendet. Natürlich muss dann ein Tiefpassfilter an den Eingang, (zwischen Transceiver und µC), um Aliasing zu vermeiden. Und gleichzeitig steigt die Messzeit für einen Satz Messwerte auf das 5- fache. Es sei denn, man packt die AD-Wandlung in einen Timer- Interrupt und puffert getrennt vom Hauptprogramm. Aber Probieren geht (manchmal) über Studieren... Schönen Abend noch! Wolfgang
Hallo, hat jemand Lust auf ein kleines Rätsel?
Im Originalprogramm von OZ1JHM hat mir folgendes nicht gefallen:
void docode(){
if (strcmp(code,".-") == 0) printascii(65);//'a'
if (strcmp(code,"-...") == 0) printascii(66);//'b'
if (strcmp(code,"-.-.") == 0) printascii(67); //'c' usw...
Warum? Die Codetabelle wird mit strcmp() durchsucht. Meistens sind
mehrere Bytes zu vergleichen.
Mir ist dazu folgendes eingefallen:
char codetab[59]={5,0x18,0x1a,0x0c,2,0x12,0x0e,0x10,4,0x17,0x0d,//....
nebst
char chartab[60]={'A','B','C','D','E','F','G','H','I','J','K',//....
(endet mit 0)
Sinn der Sache ist eine möglichst kompakte Codierung und dadurch eine
schnellere Suche. Aber wie funktioniert das??
Manche werden das Rätsel sofort lösen...
DH1AKF K. schrieb: > Sinn der Sache ist eine möglichst kompakte Codierung und dadurch eine > schnellere Suche. Aber wie funktioniert das? Ich verstehe deine Frage jetzt nicht. Du hast einen Code, der funktioniert, aber du weißt nicht, warum? Oder hast du eine coole Idee, und wüsstest sie gern umgesetzt?
> Aber wie funktioniert das??
Ein Bit um anzugeben wie lang das Zeichen ist, dann einfach Punkt und
Strich in 0 und 1 übersetzt.
Kann man machen, aber die wahren Probleme beim Dekodieren von Morsecode
liegen woanders ;-)
73
Statt > char codetab[59]={5,0x18,0x1a,0x0c,2,0x12,0x0e,0x10,4,0x17,0x0d,... und > char chartab[60]={'A','B','C','D','E','F','G','H','I','J','K',... steht jeder Buchstabe an der korrekten Postion in der Tabelle. Beispiel: char chartab[]={' ', ' ', 'E', 'T ', 'I'..,
Rabeleus schrieb: > Statt .... > steht jeder Buchstabe an der korrekten Postion in der Tabelle. > > char chartab[]={' ', ' ', 'E', 'T ', 'I'.., Das ist natürlich noch cooler! Glückwunsch! Da braucht man gar nichts mehr suchen...
Ich bin mal auf die fertige Lösung gespannt. Hab mir 1982 ein Programm geschrieben, um mit VC20 und LM567 zu decodieren. Ging mit 150BPM auf KW fehlerfrei. Gruß Mani
Manfred H. schrieb: > mit VC20 und LM567 Oha! Hatte damals für 45-50 Baud RTTY ein Programm auf einem TI-99/4A und an dessen Datenrekorder-Port einen Filterkonverter nach DJ6HP: http://elektronikbasteln.pl7.de/rtty-filterkonverter-nach-dj6hp.html Dekodieren von Morsecode stelle ich mir weit schwieriger vor, nicht nur weil Punkte, Striche und Pausen zu analysieren sind, sondern auch wg. der individuellen Gebegeschwindigkeit der Gegenstation.
Manfred H. schrieb: > Hab mir 1982 ein Programm geschrieben, um mit VC20 und LM567 zu > decodieren. > Ging mit 150BPM auf KW fehlerfrei. Nicht schlecht, mit 1MHz Takt und vielleicht in BASIC? - Alle Achtung! Für uns waren 1982 nur schreibtischgroße "Mikrorechner" mit U880, allenfalls Z80 greifbar, und diese auch niemals zu Hause, sondern auf Arbeit. Kostenpunkt damals im 10000er Bereich. Damit habe ich dann "Datenfernübertragung" per Telefonmodem programmiert... In Assembler natürlich. Der LM567 hat mit seiner PLL- Technik ein großes Plus bezüglich Frequenzselektivität und Amplitudentoleranz. Das wäre natürlich eine einfache, wirksame Lösung für mein A/D- Problem... Aber: könnte man das nicht auch digital, im µC nachbauen? Den A/D- Wandler haben wir bereits im Arduino. Aber wie weiter? Mir fällt im Moment nichts besseres ein, als einen PSoC3 oder 5LP (der hier herumliegt) mit seinen Analogbaugruppen zu verwenden. Da hätte man zumindest den Analogmischer, dazu eine schnelle Gleitkomma- Arithmetik und bei Bedarf noch umschaltbare (Digital)Filter. Übrigens spielt das Programm von OZ1JHM mit kleinen Änderungen schon recht ordentlich, falls kein QRM (Störungen durch benachbarte Sender) auftritt, und der Schwund nicht zu hoch ist. Das Gehör ist in diesen Fällen (noch) besser als der µC. Meine Devise: Der Weg ist das Ziel.
:
Bearbeitet durch User
DH1AKF K. schrieb: > Im Originalprogramm von OZ1JHM hat mir folgendes nicht gefallen: > void docode(){ > if (strcmp(code,".-") == 0) printascii(65);//'a' > if (strcmp(code,"-...") == 0) printascii(66);//'b' > if (strcmp(code,"-.-.") == 0) printascii(67); //'c' usw... Nur als Anmerkung, da Du das ja sowieso anders machen willst: An dem obigen Code ist schon mal gaaaaanz schlecht, dass da keine Else-Statements stehen. So muss der arme µC den Code mit sämtlichen Möglichkeiten vergleichen - auch wenn er das Zeichen längst erkannt hat. Ein if (strcmp(code,".-") == 0) printascii(65);//'a' else if (strcmp(code,"-...") == 0) printascii(66);//'b' else if (strcmp(code,"-.-.") == 0) printascii(67); //'c' usw... wäre da wesentlich resourcen-schonender. Sortiert man die Zeilen anschließend noch nach Häufigkeiten (z.B. Vergleich auf 'e' nach oben) - also nach Kürze der Morsecodes, wirds nochmal schneller.
DH1AKF K. schrieb: > Aber: könnte man das nicht auch digital, im µC nachbauen? Den A/D- > Wandler haben wir bereits im Arduino. Aber wie weiter? Digitales Filter (IIR) dahinter oder den Goertzel Algorithmus verwenden. Wenn es FSK ist kann man auch einen digitalen Phasenschieber und eine Multiplikation verwenden. Also quasi einen Koizedenzdetektor digital nachbauen.
Frank M. schrieb: > An dem obigen Code ist schon mal gaaaaanz schlecht, dass da keine > Else-Statements stehen. So muss der arme µC den Code mit sämtlichen > Möglichkeiten vergleichen - auch wenn er das Zeichen längst erkannt hat. Nur, wenn man dem Compiler per -ffreestanding das Wissen über die C-Standard-Bibliothek abgewöhnt hat. Ansonsten könnte er durchaus erkennen, dass, nachdem ein strcmp() zugeschlagen hat, ein weiteres mit einem anderen konstanten String nicht mehr zuschlagen kann. (Allerdings macht er es in der Praxis doch nicht, insofern ist dein Einwand nicht ganz von der Hand zu weisen.)
DH1AKF K. schrieb: > Aber: könnte man das nicht auch digital, im µC nachbauen? Den A/D- > Wandler haben wir bereits im Arduino. Aber wie weiter? Wie oben schon beschrieben. Der Goertzel-Algorithmus bekommt das prima hin. Anbei mal ein Vergleich des ursprünglichen Filters und meines Vorschlages mit verringerter Samplefrequenz. Weiterhin der komplette Algotithmus [1] wenn es jemanden interessiert. Übrigens Mathcad Express [2] ist kostenlos :-) [1] http://amesys.de/?Download___Mathcad [2] http://de.ptc.com/product/mathcad/download-free-trial
Danke für die Hinweise!
Zuerst habe ich mal den Vorschlag zur Codetabelle von Rabeleus
aufgegriffen. die Tabelle sieht nun so aus:
/*
'ii','*','E','T','I','A','N','M','S','U','R','W','D','K','G','O','H','V'
,'F','Ü',
'L','Ä','P','J','B','X','C','Y','Z','Q','Ö','CH','5','4','VE','3','*','*
','*','2',
'*','*','+','*','*','*','*','1','6','=','/','*','*','K','(','*','7','*',
'*','*',
'8','*','9','0','*','*','*','*','*','SK','*','*','*','*','*','*','?','_'
,'*','*',
'*','*','*','*','*','.','*','*','*','*','@','*','*','*',''','*','*','-',
'*','*',
'*','*','*','*','*','*',';','*','*',')','*','*','*','*','*',',','*','*',
'*','*',
':','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*',
'*','*',
'SS,'*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*',
'*','*',
'*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*',
'*','*',
'*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*',
'*','*',
'*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*',
'*','*',
'*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*',
'*','*',
'*','*','*','*','*','*','*','*','*','*','*','*','*','*','*','*'
*/
Wobei ich Sonderzeichen wie "SK" lieber getrennt auswerten würde, damit
jeweils nur 1 Byte der Tabelle belegt wird.
Das zu decodierende Zeichen beginnt immer mit einem Startbit,
anschließend werden Nullen oder Einsen von rechts her eingeschoben. Das
war das Rätsel...
Wenn das so klappt, werde ich mal die Abtastfrequenz variieren. Bin
gespannt.
Helmut Lenzen schrieb: > Digitales Filter (IIR) dahinter oder den Goertzel Algorithmus verwenden. Das könnte helfen! Habe eben mal den Goertzel_ Algorithmus mit geringerer Abtastrate ausprobiert. --> enorme Trennschärfe, wie vorausgesagt. Habe einfach jeden 4. A/D- Wert weiterverarbeitet, dazwischen jeweils eine kleine Pause. Ein Ausschnitt mit dem Goertzel- Algorithmus: for (char index = 0; index < n; index++){//n=48 QQ=analogRead(audioInPin); delayMicroseconds(50); QQ=analogRead(audioInPin); delayMicroseconds(50); QQ=analogRead(audioInPin); delayMicroseconds(50); QQ=analogRead(audioInPin)-511; // if((QQ>475)&&(QQ<525))QQ=512;//Rauschsperre 470...537 Q0 = coeff * Q1 - Q2 + (float) QQ;//coeff=2*cos(2*pi*k/n) Q2 = Q1; Q1 = Q0; } Aber:Im Arduino werden Signale auf der 3. 5. und 7. Harmonischen fast nicht unterdrückt. (Sie fallen noch in das Durchlaßband des Empfängers.) Joe, das müsste in der Simulation ebenfalls zu sehen sein.
:
Bearbeitet durch User
DH1AKF K. schrieb: > Habe einfach jeden 4. A/D- Wert weiterverarbeitet, > dazwischen jeweils eine kleine Pause. Du must die Daten dezimieren. Dazu brauchst du ein Dezimierungsfilter. Da nimmt man zwar jeden 4. Wert aber erst nach einer Tiefpassfilterung mit einem FIR Filter. Du programmierst erst ein FIR Tiefpass mit der geforderten Abtastrate und Grenzfrequenz erst dann nimmt jedes 4. Sample
DH1AKF K. schrieb: > Habe einfach jeden 4. A/D- Wert weiterverarbeitet, > dazwischen jeweils eine kleine Pause. Das ist zu Test ja noch gerade so erlaubt ;-) doch tatsächlich ist erst Überabtasten und dann wieder Dezimieren ziemlicher Unsinn. Du solltest die Abtastfrequenz einfach generell reduzieren. Wenn das nicht möglich ist, kannst du ja bei der gegebenen Abtastfrequenz auch die Datenvektorlänge erhöhen. Bei einer Abtastrate von 8928Hz ergibt eine Datenvektorlänge von N=256 die gleiche Bandbreite von 34.8Hz.
Ronny Mobile schrieb: > schau Dir den doch mal an. > > http://elf-land.de/doc/Pollin-Spiel-RTTY-CW/decoder/decoder Eine tolle Fleißarbeit, alles in 8- Bit- Assembler geschrieben. Es hat auch 1 1/2 Jahre gedauert... Sehr mühsam, da nehme ich lieber C, damit kann man das Programm relativ leicht auf andere Controller portieren und hat gute Entwicklungswerkzeuge (z.B. Debugger). Helmut Lenzen schrieb: > Du programmierst erst ein FIR Tiefpass mit der > geforderten Abtastrate und Grenzfrequenz erst dann nimmt man jedes 4. > Sample So werde ich es machen. Man wird mit verschieden großen FIR- Blöcken (Anzahl taps) experimentieren müssen, um einen Kompromiss zwischen Filtergüte und Signalverzögerung zu finden. Wenn man jetzt noch die A/D- Wandlung in einen Timer- Interrupt einschleift, kann man sogar die Resonanzfrequenz des Görtzel- Filters verschieben (variabler Timer).
DH1AKF K. schrieb: > Wenn man jetzt noch die A/D- > Wandlung in einen Timer- Interrupt einschleift, kann man sogar die > Resonanzfrequenz des Görtzel- Filters verschieben (variabler Timer). Kann man. Bisschen Code falls du den brauchen kannst.
Hallo in die Runde, nachdem ich mich vorübergehend anderen Themen zugewandt habe, soll hier noch mal mein letzter Stand mit Arduino gezeigt werden. Die Morse- Decodierung klappt schon einigermaßen, nur mein Transceiver hat halt keine CW- Filter. Wer möchte, kann das Projekt gern weiterführen. Als nächsten Schritt werde ich das Projekt auf einen PSoC5 übertragen. Warum? - bessere Filtermöglichkeiten (eingebauter Filterblock, der weder CPU- Zeit noch Speicher frißt) - Analoge und digitale Baugruppen stehen zur Verfügung, sie brauchen intern nur "verdrahtet" zu werden. - Mit diesem System habe ich seit drei Jahren Erfahrung.
Hi Sorry of my german ;o) Thank you for your interest in my decoder. The purpose was to make a code which everybody could read and which could fullfill the need for a simpel decoder. Please when some of you have a code which are better send me a copy on hjh@skovholm.com, so i can learn from that ;o) Best regards and cu on the bands.. Hjalmar OZ1JHM
Helmut Lenzen schrieb: > Du must die Daten dezimieren. Dazu brauchst du ein Dezimierungsfilter. > Da nimmt man zwar jeden 4. Wert aber erst nach einer Tiefpassfilterung > mit einem FIR Filter. Du programmierst erst ein FIR Tiefpass mit der > geforderten Abtastrate und Grenzfrequenz erst dann nimmt jedes 4. Sample Hmm.. eigentlich sollte man das m.W. ein bissel anders machen. Mir würde z.B. vorschweben, aus je 2 Samples den Mittelwert zu machen, das halbiert die Samplerate. Anschließend das Gleiche nochmal. Damit hast du auf sehr einfache Weise die gleiche Reduzierung der Taktrate um Faktor 4 - und es rechnet sich sehr einfach. Der Grund dafür ist, daß der gleitende Mittelwert als so ziemlich einziges Filter kurvengetreu ist. Alle "schärferen" Filter versauen nämlich die Phase mehr oder weniger heftig - und sie sind aufwendiger zu rechnen, brauchen also mehr an Resourcen. Und genau DAS beides kan man bei einem Morsedekoder am allerwenigsten gebrauchen. W.S.
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.