Announcement: there is an English version of this forum on 
Vorbemerkung: Hier wird kein fertiges Gerät beschrieben, sondern es soll (mit Eurer Hilfe) erst eines entstehen. Die Hardware besteht aus einer Baugruppe namens "PSoC5 First Touch Starter Kit", hergestellt von der Firma CYPRESS (USA). Da dieses Modul nicht mehr produziert wird, kommen statt dessen das "Schmartboard PSoC5LP" oder auch das CY8CKIT-042 (Völkner, Conrad) in Frage. PSOC4 scheidet wahrscheinlich aus, da hier keine Filterbaugruppe verfügbar ist. (Allerdings könnte man versuchen, die Filter als FIR selbst zu programmieren, auf Kosten von CPU- Zeit.) Die von mir verwendete Baugruppe wurde ergänzt durch - eine Lochrasterplatine 10 cm x 16 cm mit passenden Steckleisten - Drehgeber - LCD- Anzeige 4 x 20 Zeichen - NF- Übertrager 1:1 für den Audio- Eingang (ehemals Treibertrafo in einem Transistorradio). Den ersten Entwurf der "inneren Verdrahtung" zeigt das linke Bild. Links oben sieht man den (Trafo getrennten) NF- Eingang, gekoppelt mit dem 16- Bit A/D- Wandler (ADC). Der Takt ist auf 8 kHz festgelegt. Er soll vom Programm variiert werden, um eine Frequenznachführung zu ermöglichen. Außerdem ist eine Handeinstellung per Drehencoder vorgesehen. Das erzeugte Digitalsignal wird in den Filter geschickt, der aus einem Tiefpass, Hochpass und Bandpass besteht. Die Filtercharakteristik ist im rechten Bild zu sehen. Das Ausgangssignal der Filterbaugruppe soll einem Monitor über den D/A- Wandler (VDAC) und OPAMP_1 zugeführt werden, (NF- Output). Zur weiteren Frequenzselektion sind drei Goertzel- Filter vorgesehen, die auf benachbarte Frequenzen (abstimmbar) eingestellt werden. Die Taktung dieser Filter erfolgt durch drei getrennte Interrupts, erzeugt von Counter 1..3. Die decodierten Morsezeichen sollen auf dem LCD- Display angezeigt werden. Soviel zur Hardware.
Angehängte Dateien:
-
Plan1.jpg
70 KB -
Filter.jpg
68 KB
Die Taktfrequenz irgendwie mit der Filterfrequenz zu korrelieren, finde ich erst mal sekundär. Chipmaessig gibts das fertig und ist nur eine Preisfrage. Warum keine eigene Platine? Postkarte oder Briefmarke ist doch ein Unterschied. Die digitale Frequenzfilterung mit mcu braucht eine höhere Frequenz und das wurde ich vorziehen ,falls ich den passenden Code dafuer finde. Kleiner gehts nicht. Ohne jetzt genau prüfen zu können, wie gut "Deins" funktioniert, wuerde ich evtl. auch noch einen anderen Weg versuchen. Es gibt tone decoder IC's, oder es sollte bei CW auch mit Quarzen ein wirksamer Filter möglich sein. Mochte man eine Frequenznachfuehrung, aehnlich dem AFC bei Radios, kann man 2 Filter oder tone Decoder geringfügig ausser Mitte gegeneinander stimmen, um eine Regelspannung für auf/abwärts zu erzeugen. Wenn das erst mal funktioniert, kommt das decodieren fürs LCD. Da geht ein 8051 controller für 50 cent schon für. MFG und frohes neues Matthias
Erst einmal alles Gute im Neuen Jahr, an alle Mitleser! Matthias K. schrieb: > Warum keine eigene Platine? > Postkarte oder Briefmarke ist doch ein Unterschied. Für einen Prototypen ist doch der Platzbedarf nicht entscheidend... Mich reizt eben die Herausforderung, mit der "eingebauten" Hardware plus ein wenig Programm die Aufgabe zufriedenstellend zu lösen. Im vorausgehenden Thread gab es ja sehr gute Hinweise, die ich aber mit dem Arduino nicht so recht umsetzen konnte. Ein starkes Motiv ist auch das bei mir gesammelte Material. Sowohl "Schmartboard PSoC5LP" als auch das CY8CKIT-042 sind vorhanden und warten auf sinnvollen Einsatz. Das CY8CKIT-042 enthält übrigens einen PSoC5LP (als Programmer/ Debugger), der mit dieser Aufgabe allein ziemlich unterfordert ist... Im Übrigen gebe ich zu, dass ich etwas gegen die Unbekanntheit der PSoC- Schaltkreise in Deutschland tun möchte. Demnächst wird ein Artikel von mir zu diesem Thema im Funkamateur erscheinen.
:
Bearbeitet durch User
Matthias K. schrieb: > oder es sollte bei CW auch mit Quarzen ein > wirksamer Filter möglich sein. Moin, der TE schickt NF in seinen Decoder, da gibts keine Quarzfilter. Auch sollte der Filter so schmal wie moeglich sein, damit auf dicht belegten Freuquenzbereichen nicht mehrere CW Signale gleichzeitig durchkommem und den Decoder aus dem Tritt bringen. 73
DH1AKF K. schrieb: > Im Übrigen gebe ich zu, dass ich etwas gegen die Unbekanntheit der PSoC- > Schaltkreise in Deutschland tun möchte. Demnächst wird ein Artikel von > mir zu diesem Thema im Funkamateur erscheinen. Mach doch mal hier ein Wiki dazu!
F. Fo schrieb: > Mach doch mal hier ein Wiki dazu! Einen Übersichtsartikel, den ich vor einiger Zeit aktualisiert habe, kann man hier finden: http://www.mikrocontroller.net/articles/PSoC
Ja das kannte ich schon. Ich will auch mal (wenn ich denn mal die anderen Dinge abgehakt habe) mit PSoC5 Filteranwendungen bauen. Deshalb ist das besonders interessant für mich.
Angehängte Dateien:
-
Plan2.jpg
73 KB
Plan geändert (konkretisiert): - Nur ein Goertzel- Takt, dieser entsteht bei der A/D- Wandlung -8 kHz- - Die Arduino- Funktion "millis()" wurde nachgebildet durch einen Timer, der die Millisekunden zählt und alle 30s überläuft (Interrupt) - Synchronisation mit einem externen 24 MHz Quarztakt - Button zur Menüsteuerung - LED blinkt im Rhythmus der Morsezeichen F. Fo schrieb: > Ich will auch mal ... mit PSoC5 Filteranwendungen bauen. Dann schau mal hier: (Ich habe daraus sehr viel gelernt, sogar VERILOG- Programmierung.) http://www.simplecircuits.com/SimpleSDR.html
Neue Erkenntnisse: Ein A/D Wandler- Interrupt steuert drei Goertzel- Filter. So soll es ablaufen: Der A/D- Wandler arbeitet mit 8000 Hz. Dann gibt es bei 3,5 kHz NF- Bandbreite keine Aliasing- Probleme. Nach dem Passieren des digitalen Bandpassfilters (800 Hz, B = 80 Hz) folgen die drei Goertzel- Filter. - Goertzel L arbeitet mit 52 Schritten, ergibt 769 Hz Mittenfrequenz - Goertzel M mit 50 Schritten -> 800 Hz --> weiter zum Morse- Decoder - Goertzel H mit 48 Schritten -> 833 Hz Die Ausgänge der beiden zusätzlichen Goertzel- Filter sollen zur Frequenznachführung verwendet werden. Einen Ausschnitt aus der Interruptroutine habe ich beigefügt. Vielleicht von Interesse...
Wieviel RAM braucht man ca. für einen controller, also Goertzelfiter, und CW oder PSK und 3 Frequenzen, zB. 300,350, 400 Hz.? Geht auch phasenerkennung mit Goetzel-filerung?
300+350+400 und daraus die Wurzel ergibt die benötigte Speichermenge in kB. Nachzulesen in Grundlagen der digitalen Signalverarbeitung von Horst Walter Gödelau.
Matthias K. schrieb: > Wieviel RAM braucht man ca. für einen controller, also Goertzelfiter, > und CW oder PSK und 3 Frequenzen, zB. 300,350, 400 Hz.? Man braucht je Frequenz nur 2 Speicher (z.B. je 4 Byte), und eine Zählzelle. Dazu einen Akku (4 Byte) und die Variablen Input, Output, cosinus_alfa und sinus_alfa. Je nach Implementation also recht wenig. Aber: Vor dem Goertzel sollte unbedingt ein Tiefpass liegen, und der benötigt z.B. 2 x 64 x 3 Byte (bei 24 Bit Genauigkeit) - falls man es digital macht. 64 Koeffizienten, 64 Zwischenwerte Matthias K. schrieb: > Geht auch Phasenerkennung mit Goetzel-Filterung? Ja, (man braucht dazu Google), siehe hier: Beitrag "Goertzel Phasenbestimmung" Ein JAVA- Programm steht hier: Beitrag "Goertzel Algorithmus" Anderes Beispiel in C: http://stackoverflow.com/questions/13489519/goertzel-algorithm-to-get-the-phase double rR;// Zur Weiterverarbeitung global vereinbart double rI; double AlgorithmGoertzel( int16_t *sample,int sampleRate, double Freq, int len ) { double realW = 2.0 x cos(2.0 x M_PI x Freq / sampleRate); double imagW = 2.0 x sin(2.0 x M_PI x Freq / sampleRate); double d1 = 0; double d2 = 0; double y; for (int i = 0; i < len; i++) { y=(double)(signed short)sample[i] +realW x d1 - d2; d2 = d1; d1 = y; } rR = 0.5 x realW x d1-d2;// ** Realteil des Resultats rI = 0.5 x imagW x d1-d2;// ** Das ist der Imaginärteil. return (sqrt(pow(rR, 2)+pow(rI,2)))/len; } // Dann noch : alfa = arctan(rI/rR);// Phasenwinkel im Bogenmaß Alles klar? In diesem Beispiel geht man von einem Array mit (len) Abtastwerten aus. Das lässt sich aber vermeiden, wenn man jeden Abtastwert einzeln verarbeitet, so wie in meinem Programm vom 02.01. 17:43
:
Bearbeitet durch User
DH1AKF K. schrieb: > Den ersten Entwurf der "inneren Verdrahtung" zeigt das linke Bild Das mag ja alles sehr schön in deinem Kopfe sich darstellen, aber vielleicht wäre es deutlich besser gewesen, anstelle diverser Screenshots aus dem Psoc-Creator zu allererst einmal das Funktionsprinzip des angedachten Dekoders darzustellen. Also wie das Teil denn den Morsecode dekodieren soll, kurzum was für eine Funktionalität dir denn eigentlich vorschwebt. Wie anschließend die diversen Teile des Ganzen realisiert werden können, ist doch etwas, das erst NACH dem ganzen Systementwurf kommen sollte. Kurzum, mir kommt das Vorhaben ein bissel planlos vor. Sowas liest man hier häufiger: "Ich will mit einem ATmega und einem PT100 ein GIZMO bauen" - wo man lar sehen kann, daß es dem TO nicht um die Realisierung eines konkreten Vorhabens, sondern vorrangig um die Benutzung einer bestimmten Zutat zu irgend einem Vorhaben geht. Also, mach dein Vorhaben mal etwas konkreter, dann kann man auch besser miteinander drüber reden. W.S.
W.S. schrieb: > aber vielleicht wäre es deutlich besser gewesen, anstelle diverser > Screenshots aus dem Psoc-Creator zu allererst einmal das > Funktionsprinzip des angedachten Dekoders darzustellen. Ein berechtigter Einwand, W.S.! Im vorausgegangenen Thread Beitrag "Morse-Decoder" ist das eigentlich schon ausführlich erörtert worden. Ich benutze experimentell den Decoder von OZ1JHM sowie einen eigenen, der "mit Gleichstrom", also angeschlossener Morsetaste bzw. Squeeze- Taste bereits erprobt ist. Deshalb habe ich hier mehr Wert auf die Signalaufbereitung gelegt. Mein Transceiver ist ein IC706 ohne CW- Filter, er bietet dem Prozessor also den gesamten NF- Kanal (bis 3,5 kHz) an. Deshalb geht es hier erst einmal um die Filterung des NF- Signals.
> Man braucht je Frequenz nur 2 Speicher (z.B. je 4 Byte), und eine > Zählzelle. > Dazu einen Akku (4 Byte) und die Variablen Input, Output, cosinus_alfa > und sinus_alfa. > Je nach Implementation also recht wenig. Erst mal vielen Dank. Das ist ja erheblich weniger als die voherige Angabe von diaroe in kB Ich kann danach eine einzelne Welle mit z.B. genau 2 oder 5 Abtastungen bestimmen. Aber z.B. bei einem 10 bit a/d Wandler komm ich auf deutlich mehr als 4 Byte als Einlesepeicher. Bist Du sicher? Bei Reichelt gibt es controller mit a/d Wandler für 1 bis 2 € mit wenig ram, oder das andere sind arm controller mit größerem oder externem RAM ab ca. 7 €. Für interessierte, ich faende es cool, auf einer Selbstbaufunke duchlaufende cw und psk31 Texte ablesen zu koennen. Ist psk eigentlich auch als normales cw codiert? Einen Tiefpassfilter kann man leicht mit Quarzen im ZF-Filter realisieren. Dessen Vorteile kann man sicher nicht mit simulierten Filtern ersetzen. MFG Matthias
Matthias K. schrieb: > Ich kann danach eine einzelne Welle mit z.B. genau 2 oder 5 Abtastungen > bestimmen. Das wäre schön, aber dann hast Du eine Riesen- Bandbreite!! Ab ca. 48 Abtastungen wird es schmalbandig nenug für unsere Zwecke. Die zwei Speicher pro Spektralfrequenz reichen beim Goertzel- Filter trotzdem aus. Matthias K. schrieb: > Ist psk eigentlich auch als normales cw codiert? Kennst Du Google?? Schönen Abend noch!
OK, du willst also zu allererst einen schmalbandigen NF-Bandpaß bauen und einen darauf folgenden Demodulator nebst CW-Dekoder sparst du dir für später auf. Nun ja. Ich schätze mal, den ADC und den nachfolgenden NF-Bandpaß ordnet man am besten in einem Cortex M4 an, wegen des Gleitkomma-Rechenwerkes. Bei 3.5 kHz Bandbreite braucht es auch nur 10 kHz Samplerate - und bei rund 100 MHz Takt (wenn du nen LPC4xxx nimmst) hat dieser µC noch genug Zeit, um nebenher eine kleine FFT zwecks Anzeige zu machen. Um dein ankommendes Signal auf einem kleinen TFT oder einem monochromen Grafik-LCD darzustellen, sollte eine FFT mit 64..128 Samples dicke ausreichen. Eine Filter-Nachführung würde ich mir verkneifen, da bekommst du es mit zu häßlichen Regel-Problemen zu tun. So. Damit hättest du erstmal folgendes: - Digitalisierung im NF-Bereich - einstellbares digitales NF-Filter - Visualisierung (NF-Spektrum und Filter-Bereich) - NF-Ausgabe bei Bedarf Was danach noch fehlt, ist der Demodulator (NF da oder nicht da) und der darauf folgende eigentliche Morse-Dekoder. Ich hatte mir vor ein paar Wochen mal ein Programm (per Delphi) geschrieben, um mal etwas mit FIR-Filtern herumspielen zu können. Aber du kannst das alles auch bei "http://www.dspguide.com/editions.htm"; direkt nachlesen. Da gibt's auch Formeln, mit denen man berechnen kann, wieviele Taps man für welche Flankensteilheit bei FIR-Filtern benötigt. Und die Filterkoeffizienten kann man sich dann direkt im µC je nach Gusto selber berechnen. Aber das alles ist ja nur das Vorspiel, nicht der eigentliche Akt (laut Überschrift des Threads). Wozu du allerdings auf einen PSOC orientierst, solltest du mal näher erklären. Ich halte auch die PSOC4 und 5 für weniger geeignet, wegen der geringen Taktfrequenz. W.S.
Hallo Wolfgang, eine Anmerkung zu deinem Filterdesign Beitrag "Re: Morse- Decoder mit PSoC" Dein Görtzelfilter hat bei einer Mittenfrequenz von 800Hz eine Bandbreite von 160Hz und nicht 80Hz. Die beiden anderen Filter haben die gleiche (!) Mittenfrequenz, jedoch jeweils eine andere Bandbreite. Wenn du die Mittenfrequenz ändern möchtest, dann mußt du also die Stützstellenzahl gleich lassen und den Filterkoeffizienten neu bestimmen.
W.S. schrieb: > den ADC und den nachfolgenden NF-Bandpaß ordnet man am > besten in einem Cortex M4 an Ja, das klingt gut, und zwei STM32F4- Boards liegen hier auch herum. Aber ich werde nicht wegen jeder klugen Idee das ganze Konzept umschmeißen. Man könnte es ja ganz leicht mit PC und CWGet machen!! Soundkarte + Programm genügt. Ich sehe es eben sportlich: Die Herausforderung ist Cortex M3. Speziell PSoC5LP. Trotzdem danke ich für Deine Hinweise, W.S.
Tschuldigung, aber was soll die wilde Filterei und Signalverarbeitung? Nur weil der PSoC das eventuell kann? Die schmalbandige Filterung macht doch bereits der CW-Empfänger. Raus kommt ein schmalbandig gefiltertes Audiosignal. Dann: Gleichrichten, ein bisschren Glätten (auf die Zeitkonstante achten), auf einen Komparator, und ab mit dem Komparator-Ausgang in einen digitalen Eingang eines Mikrocontrollers. Die Software ist dann schon fast trivial: - Kontinuierlich An- und Auszeiten messen - Laufend einen Mittelwert der gemessenen Zeiten bilden. Der Mittelwert dient als Referenzzeit. Dadurch stellt sich das System selbst ein. - Ausgehend vom Mittelwert mit Zeitfenstern Punkt (M/2 +/- x), Strich (M*1.5 +/- y), kurze und lange Pausen detektieren (Zeiten habe ich jetzt nicht im Kopf). - Umwandeln der detektierten Punkte und Strich in ASCII-Zeichen ist danach trivial - Mit den An- und Auszeiten der detektierten Punkte, Striche und Pausen den Mittelwert nachstellen. So habe ich bereits in den 80ern einen funktionierenden Dekoder mit einem Z80 gebaut. Heute könnte man sicher separate Mittelwerte für Punkte, Striche und den Pausen mitführen, um besser auf individuelle Handschriften einzugehen. Ebenso könnte man einen Puffer für gemessene Zeiten verwenden. Aus Platzmangel habe ich damals die paar Zeichen die reinkommen bis sich die Dekodierung eingeschwungen hat nicht gespeichert. Die wurden prinzipbedingt häufig falsch dekodiert. Mit einem Puffer könnte man warten bis man eine stabile Referenz hat, und dann die alten Daten dekodieren und ausgeben. Nachstellen: Ich würde eine Statistik über erfolgreich und nicht erfolgreich dekodierbaren Symbole und Zeichen mitfuhren. Dann würde ich den Empfänger um ein Delta verstellen. Wird die Statistik besser, dann weiter in dieser Richtung verstellen. Wird die Statistik schlechter, dann in die andere Richtung verstellen.
Joe G. schrieb: > Dein Görtzelfilter hat bei einer Mittenfrequenz von 800Hz eine > Bandbreite von 160Hz und nicht 80Hz. > Die beiden anderen Filter haben die gleiche (!) Mittenfrequenz, jedoch > jeweils eine andere Bandbreite. Wenn du die Mittenfrequenz ändern > möchtest, dann mußt du also die Stützstellenzahl gleich lassen und den > Filterkoeffizienten neu bestimmen. Hey Joe, Danke für die Richtigstellung. Ich werde es sobald wie möglich testen. Eine verdoppelte Stützstellenzahl, also 100, bedeutet ja nur 1/80 Sek. Verzögerung. Dann hätte man 80 Hz Bandbreite. Für die beiden Seitenband- Filter müsste ich die Koeffizienten anpassen. Sind dort auch Faktoren wie cos( 2 x Pi x 4.8/100) erlaubt? Hallo Hannes, Danke für Deine kurze Zusammenfassung der Decoder- Probleme! So oder fast genauso will ich es machen. Auch der Hinweis auf die Statistik ist bemerkenswert. Hannes Jaeger schrieb: > was soll die wilde Filterei und Signalverarbeitung? ...weil mein Transceiver eben leider kein CW- Quarzfilter enthält, muss es der Prozessor machen.
:
Bearbeitet durch User
Hannes Jaeger schrieb: > Die schmalbandige Filterung macht doch bereits der CW-Empfänger. Und den Rest macht das Ohr und Gehirn. :-) Eine technische Herausforderung ist es natürlich allemal, ein absolut nicht für die Decodierung durch Maschinen konzipiertes Signal dennoch durch sie verarbeiten zu lassen.
Eine Frage war noch offen: Matthias K. schrieb: > Ist psk eigentlich auch als normales cw codiert? Siehe hier, die Codetabelle für PSK31: Beitrag "Re: PSK 31 Modlulation im Mikrocontroller" Das ist übrigens ein sehr interessanter Thread! Er würde auch in unsere Rubrik passen..
:
Bearbeitet durch User
DH1AKF K. schrieb: > Sind dort auch Faktoren wie cos( 2 x Pi x 4.8/100) erlaubt? Ja, die Koeffizienten werden immer gleich berechnet. Du benötigst lediglich die Filtermittenfrequenz und die Samplefrequenz. Die ganze Nachführerei mit drei Goertzelfiltern würde ich jedoch anders realisieren. Ein Filter auf der Durchlassfrequenz mit fester Bandbreite. Die Mittenfrequenz dieses Filters wird über eine PLL mitgezogen, d.h. der Filterkoeffizient des Goertzels wird nach jedem vollständigen Filterdurchlauf neu berechnet. Für das Gortzelfilter ist noch folgendes zu beachten. Für eine vollständige Filterberechnung mit N Stützstellen (N+1 Schleifendurchläufe) ist der letzte ADC-Wert, also der N+1 Wert NULL zu setzten! Macht man das nicht, so tritt eine Amplituden und Phasenfehler auf. Der Amplitudenfehler ist sehr klein, der Phasenfehler jedoch erheblich.
Angehängte Dateien:
-
Filter1.jpg
65 KB
Hallo miteinander! Nach etlichen Versuchen habe ich für die A/D- Wandlung mit 16 000 sps und für das Frequenzfilter eine brauchbare Lösung gefunden. Die Abbildung zeigt ein Vorfilter, Bandbreite 100 Hz. Dessen Ausgangssignal - liefert den Mithörton, - wird von einem Görtzel- Filter mit 200 Schritten gefolgt. Das Vorfilter ist ein IIR- Filter vom Bessel- Typ, also nicht extrem steilflankig, aber dafür werden die Morsezeichen nur wenig "verrundet". Im Vergleich zu den FIR- Filtern hat es eine bessere Weitab- Selektion. Für die Tests hat sich mein Signalgenerator bewährt: Beitrag "Sinusgenerator mit PSoC 4" Auch die Aussage, dass beim Görtzel- Filter beliebige Zwischenwerte einstellbar sind, hat sich bestätigt. Danke, Joe G.! Es gilt also tatsächlich realW = 2.0 x cos(2.0 x M_PI x Freq / sampleRate); wobei Freq die Mittenfrequenz und sampleRate die Samplefrequenz sind. Im nächsten Schritt werden zwei verschiedene Verfahren zur Decodierung der Morsezeichen getestet.
:
Bearbeitet durch User
Hallo Wolfgang, das Goertzelfilter ist doch schon ein IIR-Filter. Wenn es auf eine Bandbreite von 80Hz ausgelegt ist, warum nochmals ein 100Hz IIR-Vorfilter?
Für den Decoder: Bei meinen Versuchen für einen Decoder hat ein Medianfilter (etwa halbes did) vor dem Signal(schwellen)detektor die Erkennung verbessert.
Hallo Joe! Joe G. schrieb: > warum nochmals ein 100Hz IIR-Vorfilter? 1. Das Vorfilter soll Aliasing- Effekte und QRM mindern (QRM = Störungen durch fremde Sender). Mein Transceiver liefert 300 .. 3500 Hz. 2. Es liefert einen sauberen Mithörton auf der Originalfrequenz. 3. Durch einen Vollwellengleichrichter mit anschließender LED- Anzeige habe ich eine manuelle Grob- Abstimmung. 4. kann ich hiermit die von Dir vorgeschlagene PLL verwirklichen. Das Goertzel- Filter liefert dagegen nur eine summierte Amplitude mit der Frequenz F_Sample/n, (die Phase habe ich noch nicht berücksichtigt.) Es ist für die Sendersuche viel zu spitz!! Eine PLL +- 50 Hz könnte das auswertende Görtzel- Filter nachsteuern. @Henrik: Danke für Deinen Hinweis, werd ich probieren.
Hallo Wolfgang, QRM zu filtern sowie einen sauberen Mithörton auszufiltern ist ja OK, das ist ja der Sinn eines Filters. Ich vermute, Du interpretierst ein Goertzelfilter falsch. Ein Goerzelfilter ist ein IIR-Filter, d.h. es filtert natürlich genauso wie jedes andere Filter. Der Filterkoeffizient wird halt nur anders berechnet. Du kannst es natürlich auch dafür verwenden die Amplitude und die Phase auf genau der Filterfrequenz (Goerzelfrequenz)zu bestimmen. Normiert man das Eingangssignal im Maximum auf Eins, so lässt sich damit also ein Frequenzkomperator aufbauen. So spitz sieht der Filterfrequenzgang des Goertzels doch gar nicht aus [1], lege doch mal dein Bessel darüber. Für die PLL benötigst du einen Phasenkomperator damit du die Frequenzrichtung richtig nachsteuern kannst. Das lässt sich jedoch auch prima digital realisieren. 73, Joe (DL3AKB) [1] Beitrag "Re: Morse- Decoder mit PSoC"
Hallo Joe, Joe G. schrieb: > Ein Goerzelfilter ist ein IIR-Filter, d.h. es filtert natürlich genauso wie > jedes andere Filter. ... vielleicht geht es so: Man nimmt einen Ringpuffer aus n=200 Gleitkommazahlen, den man "am Anfang" mit der Görtzel- Formel füttert, an dessen "Ende" entnimmt man dann das NF- Signal. Das ist zwar speicherfressend, aber bei 64 kByte spielt das keine Rolle. Interessant wäre noch die Frage, ob dieses Signal zu runden oder klingelnden Morsezeichen führt. (Stichwort Impulsantwort) Aber mit der Normierung tue ich mich noch schwer. Ohne Normierung muss ich das Ergebnis durch 1 000 000 000 teilen, um in den Bereich 100..1000 zu kommen. Eingangswerte sind 16 Bit Integer. Ich komme für den Ringpuffer a[k] auf die Formel a[k] = sample[k] + faktor x a[k-1] - a[k-2]; k = k + 1; wobei alle Indexoperationen modulo n zu rechnen sind. Ist das so richtig??
Hallo Wolfgang, mein Vorschlag war natürlich Unsinn :-( Du möchtest ja die gefilterten ADC-Werte rekusiv in Echtzeit berechnen. Somit ist eine blockweise Berechnung natürlich Quatsch. Zur Normierung. Du musst natürlich nicht auf Eins normieren sondern kannst einen beliebigen anderen Wert nehmen. Normiert werden sollte jedoch trotzdem, da sich ja sonst die Komperatorschwelle verschiebt.
Da es häufig vorkommt, dass die Gegenstation(en) in einem CW- QSO etwas neben der Frequenz liegen, bastele ich an einer digitalen Frequenznachführung statt einer PLL. Ich habe zwei Görtzel- Filter jeweils auf die obere und untere Flanke des Durchlassbereichs meines Hauptfilters gesetzt. Deren Ausgangssignale werden verglichen und steuern das schmalbandige Auswertefilter hin und her, (wenn es denn so klappt.) Das Auswertefilter ist nur 25 Hz breit. (Ein Görtzel- Filter mit auswertendem Trigger.) Mit Dauerträgern sieht das schon ganz gut aus...
Angehängte Dateien:
-
Magn.jpg
13 KB
Nun klappt es endlich mit der Frequenznachführung im Bereich 750 bis 850 Hz. Das Bild zeigt den Amplituden- Verlauf des nachgeführten Görtzel- Filters. Auch die Decodierung nach der Methode von OZ1JHM funktioniert einigermaßen. Doch es gibt noch Probleme: 1. Zu Beginn einer Aussendung steht dem Empfänger noch kein vernünftiges Zeitmaß zur Verfügung, man weiß also nicht, ob a) Strich oder Punkt, b) ob Pause im Zeichen, zwischen den Zeichen oder ein Wortende übertragen wurde. Die Synchronisation ergibt sich erst durch Bewertung und Mittelwertbildung nach mehreren gesendeten Zeichen. Abhilfe könnte die Aufzeichnung der ersten 20 Signal- und Pausenzeiten mit nachträglicher Auswertung bringen. Das werde ich jedenfalls so probieren. 2. Behandlung von Pegelunterschieden: Es müsste eine intelligente Pegelregelung geschaffen werden, die zwischen Signal und Rauschen unterscheiden kann. In der gemeinsamen Auswertung aller drei Görtzel- Filter sehe ich hierfür einen Ansatzpunkt. 3. (Baustelle): Die Ankopplung an den Empfänger. Denkbar ist ein Mikrofon samt Vorverstärker, bisher realisiert die direkte Anzapfung der Lautsprecherleitung.
Für den PSoC gab wohl mal ein Morse-Dekoder. Vielleicht findest du dort Anregungen.
Abdul K. schrieb: > Für den PSoC gab wohl mal ein Morse-Dekoder. ja, hier: http://www.ea4frb.eu/psoc-projects/morse-decoder
Angehängte Dateien:
-
IMG_1185.jpg
88 KB
Hallo Mitleser, nachdem ich dieses Testprogramm gefunden und angewendet habe, geht es wieder voran. Das Programm generiert aus eingegebenem Text eine Audio- Datei mit den Morsezeichen. Frequenz und Wpm sind einstellbar: http://www.meridianoutpost.com/resources/etools/calculators/calculator-morse-code.php Da die Pausen zwischen 2 Zeichen nicht der Norm entsprechen, sie sind viel zu lang, habe ich die Parameter meines Programms angepasst. Nun schreibt es bis 300 Wpm (Dit- Länge 19 ms) mit. Das Goertzel- Filter hatte die maximale Länge 150, bedeutet ca 106 Hz Bandbreite. Noch schmalere Einstellung führte zu einigen falsch erkannten Zeichen. Es gibt noch einiges zu tun, aber der jetzige Stand ist ermutigend...
:
Bearbeitet durch User
DH1AKF K. schrieb: > Nun schreibt es bis 300 Wpm (Dit- Länge 19 ms) mit. Entschuldigung - Schreibfehler! Es sollte 30 Wpm heißen. Aber das ist auch falsch, ich hatte mich auf die Angabe des Testprogramms verlassen... Man kann leicht nachrechnen, dass einer Dit- Länge von 19 ms eine Geschwindigkeit von 330 Bpm entspricht. (Zugrunde gelegt wird das Wort "PARIS", welches laut Norm 48 Dit's lang ist, die eine Pause eingerechnet.) Und weil Paris aus 5 Buchstaben besteht, erhält man als korrekten Wert 330/5 = 66 Wpm.
Läuft das nun auf einen 5LP oder ein anderer? Ich hab mir mal die Entwicklungsumgebung runtergeladen. Leider werde ich nicht schlau draus, wie man die Ressourcenverteilung intern abrufen kann. Wieviele z.B. D-FF passen denn in den Chip und kann ich die frei verdrahten? Bei PSoC1 war das alles extrem eingeschränkt. Nun wollte ich schauen, ob es beim 5LP wirklich freizügiger zugeht. Ich bräuchte öfter Subsysteme wie in einem FGPA. Und außer dem 5LP andere Varianten verwenden macht auch keinen Sinn mehr, oder? Was ist das für ein abgebildetes Board? Taugt das was?
Angehängte Dateien:
-
IMG_1188.jpg
74 KB -
IMG_1186.jpg
120 KB
Abdul K. schrieb: > Läuft das nun auf einem 5LP oder einem anderen? Hallo Henry! Nein, hier läuft ein PSoC5 ES1, also ein Testmuster. Diese Boards gab es vor 2 Jahren für ca. 50 Dollar plus Versand. Haben den Vorteil, dass Debugger und Programmer eingebaut sind. Ferner hat man Cap-Sense, einen Neigungs- und Beschleunigungsdetektor sowie einen Quarztakt an Bord. Gibt es leider nicht mehr. Alternativen sind auf den Fotos zu sehen: Links das Schmartboard von der gleichnamigen Firma. PSoC5LP Breakout- Board mit Bootloader, ohne Programmer, ohne Quarz. Trotzdem für den Morse- Decoder gut geeignet. Rechts das in D (z.B. bei C oder Völkner) erhältliche CY8CKIT-042 mit PSoC4 plus PSoC5LP. Ich müsste mal versuchen mein Programm (falls es denn "fertig" ist) auf diese Boards anzupassen. Abdul K. schrieb: > Wieviele z.B. D-FF > passen denn in den Chip und kann ich die frei verdrahten? Frei verdrahten: JA! "Resources: The D Flip Flop uses one macrocell." In meinem PSoC5LP gibt es insgesamt 192 Macrozellen. Aber die teilen sich auf die sonst noch benötigten Module auf... Ich hoffe, Du bist mit meiner Antwort zufrieden. Tschüß, Wolfgang P.S. (Werbung in eigener Sache): Der Funkamateur bringt im März meinen Artikel über die PSoC- Technologie.
:
Bearbeitet durch User
Aha, danke! Also 192 Zellen insgesamt für alle programmierbaren Funktionen. Scheint mir nicht sonderlich viel. Ich werde wohl mal das TRM erstürmen müssen. Und im März die Uni-Biblio.
Abdul K. schrieb: > Also 192 Zellen insgesamt für alle programmierbaren Funktionen. Scheint > mir nicht sonderlich viel. JEIN. Mit nem XC95er mit ca 140 Zellen (soweit ich mich erinnere) kann man ne ganze Menge anstellen. Aber hier? Es kommt wohl drauf an, was vor den FF ist, also wie groß die AND/OR-Gatter ausgelegt sind. W.S.
Hallo Leute, nachdem die Erkennung synthetischer Signale, (die vom PC erzeugt werden) recht gut funktioniert, habe ich versucht, echte KW- Signale vom WEB-SDR Twente zu decodieren. Wer es nicht weiß: http://websdr.ewi.utwente.nl:8901/ Dabei gibt es stets das Problem, dass in längeren Sendepausen irgendwelche Rauschsignale als Morsezeichen interpretiert und angezeigt werden. Problem: Wie unterscheidet man Rauschen und Nutzsignale ?? Ideen sind gefragt! P.S. Ich könnte die Signale vor und hinter den Filtern auswerten...
:
Bearbeitet durch User
DH1AKF K. schrieb: > Ideen sind gefragt! Bilde mal den gleitenden Mittelwert. Ich habe mal für einen Satz aus 5x Paris den arithetischen Mittelwert und die Varianz berechnet. Vergleicht man das mit weißem Rauschen oder der Gaußverteilung, so unterscheidet sich der Mittelwert signifikant (siehe Anhang). Die Varianz ist weniger geignet.
Hallo Joe, Danke für den Tip. Ich habe es mal mit dem Befehl if(out > 0) out= ((128 x out - out)+ in) / 128; probiert, und erhalte eine stabile Triggerschwelle zur Unterscheidung von Rauschen und Morsezeichen. Darin enthalten ist eine "Einweg- Gleichrichtung", ohne diese geht es nicht. Nochmals Danke!
:
Bearbeitet durch User
Nach etlichen Versuchen fand ich diese Methode: 1. Abgetastetes Signal gleichrichten, so dass es der Hüllkurve folgt (Das heißt Signalzuwachs sofort verarbeiten, Signalabfall über eine Treppenkurve schrittweise linear, gegebenenfalls bis Null.) 2. Bildung eines gleitenden Mittelwertes aus z.B. 32 Eingangswerten 3. Bestimmung des Maximums und des Minimums dieser Mittelwerte 4. Division Maximum : Minimum Der erhaltene Wert ist bei vorhandenen Morsezeichen größer als 10, falls jedoch ein Rauschsignal anliegt, ist der Wert deutlich kleiner. Damit läßt sich die Zeichenauswertung (nach einer gewissen Karenzzeit) abschalten und es wird kein "Müll" decodiert. Schönen Gruß an alle geduldigen Mitleser. Wolfgang Kiefer
Angehängte Dateien:
-
Plan3.jpg
69 KB
Neuer Zwischenstand: Rauschsperre und AGC eingebaut. die Görtzel- Filter wieder entfernt. (Sie sind nicht erforderlich, weil schon ein ausreichend scharfer Bandpass für Selektion sorgt.) Die Demodulation verläuft jetzt phasensynchron: Nulldurchgänge des gleichgerichteten Signals werden erkannt, und im passenden Zeitpunkt wird das Signal des A/D- Wandlers an das Hauptprogramm weitergeleitet. Eine Tatsache kann ich mir nicht erklären: Wenn lediglich ein Rauschsignal anliegt, wird ein höherer Maximalwert der Amplitude erkannt als bei vorhandenen Morsezeichen. Hat jemand eine Idee?
Hallo! Endlich kann man leidlich QSO's auf den Bändern 80 - 20m bei WebSDR mitschneiden. Eure Hinweise, z.B. Ermittlung des Median anstelle von gleitenden Mittelwerten, habe ich eingearbeitet. Trotzdem wurden in das Programm ein paar "Krücken" eingebaut: - wenn mehr als 12 Dit's nacheinander erkannt werden, dann ist offenbar die Synchronisation falsch, und es werden die Zeitkriterien auf das 3-fache erhöht, (also das erwartete Tempo gedrosselt.) - Umgekehrt, wenn mehr als 15 Daa's nacheinander eingingen, wird das Tempo auf das 3- fache erhöht. - Werden 6-mal nacheinander nur T bzw. E erkannt, dann wird die Pausenlänge angepasst, (auf das Doppelte erhöht). In einem QSO geben halt nicht beide Partner mit dem gleichen Tempo... Schließlich wurde die Interruptroutine des AD- Wandlers von Multiplikationen und Divisionen befreit. Diese führten vorher zu häufigen Fehlern. Als nächstes kommt eine per Hand einstellbare Rauschsperre dran. Schöne Grüße, Wolfgang
DH1AKF K. schrieb: > In einem QSO geben halt nicht beide Partner mit dem gleichen Tempo... Und auch nicht in der gleichen Tonhöhe. Gerade das macht es für einen menschlichen Zuhörer einfacher, als wenn beide auf exakt gleicher Frequenz und in exakt gleichem Tempo geben.
Jörg Wunsch schrieb: > Und auch nicht in der gleichen Tonhöhe. Ja, das ist ein weiteres heikles Problem. Das bisher verwendete Filter ist mit 100 Hz vielleicht doch zu schmal, um immer beide Partner aufzunehmen. Ein hin- und herspringendes Filter ist zwar ohne großen Aufwand realisierbar, aber ohne "Handsteuerung" wird das wohl nicht funktionieren. hw?
DH1AKF K. schrieb: > aber ohne "Handsteuerung" wird das wohl nicht funktionieren Naja, es könnte sich ja den Versatz zwischen beiden merken, dann müsstest du nur noch sehen, wie du die Umschaltung schnell genug erkennst. Ich bevorzuge hier Humanfilter und -dekoder. ;-) Aber das ist natürlich keine technische Herausforderung, ich weiß. :)
Jörg Wunsch schrieb: > den Versatz zwischen beiden merken ... oder einfach breit genug sein, um beide Partner aufzunehmen. Dazu wird man aber um ein kleines Frequenzdisplay nicht herumkommen...
Jörg Wunsch schrieb: > Ich bevorzuge hier Humanfilter und -dekoder. ;-) Ja, das ist gut so- man kommt nicht aus der Übung! Aber: Bei Tempo 200 höre ich nur noch ein "Rattern", mein Programm kann dagegen fast fehlerfrei mitlesen, jedenfalls synthetische Texte z.B. von diesem Programm: http://morsecode.scphillips.com/translator.html Bis 40 Wpm klappt es sehr gut. Vor die Decodierung der Morsezeichen habe ich eine reine Zeiterfassung geschaltet, die also Punkte, Striche, kurze und lange Pausen messen und voneinander unterscheiden kann. Erst dann, wenn Dit und Daa sowie die Pausen häufig genug aufgetreten sind und eindeutig erkannt wurden, beginnt die Decodierung der aufgezeichneten Signale. Nächstes Ziel ist, diese Zeitbewertung auch in das laufende Programm einzubauen. Ich habe übrigens das CW- Skimmer- Programm parallel laufen lassen, und war ziemlich enttäuscht von dessen Ergebnissen: http://www.dxatlas.com/CwSkimmer/
DH1AKF K. schrieb: > > Ja, das ist gut so- man kommt nicht aus der Übung! > > Aber: Bei Tempo 200 höre ich nur noch ein "Rattern" Hatte mal eine Weile versucht das zu lernen, aber die tackern so schnell, so schnell kann ich nicht denken.
F. Fo schrieb: > die tackern so > schnell, so schnell kann ich nicht denken. Ja, so geht es mir auch... Zur Zeit denke ich gaanz langsam, wie ich die im Ringpuffer gesammelten Signal- und Pausenzeiten vernünftig bewerten soll- z.B. bei einem Tempowechsel.
Hallo allerseits, angeregt von diesen Beiträgen: http://www.4x4ham.com/showthread.php?3981-Arduino-based-PSK31-RTTY-APRS-RadioModem und Beitrag "PSK 31 Modlulation im Mikrocontroller" habe ich versucht, den Morsedecoder zu erweitern. Herausgekommen ist ein Programm, welches (bisher) auf genau 1360 Hz fast fehlerfrei decodiert, was fldigi ihm per Soundkarte anbietet. Es beruht im Wesentlichen auf der Arbeit von KF7IJB, musste aber ziemlich stark abgeändert werden für den PSoC. Mit dem anderen Programm von Bernd (prof7bit) https://gist.github.com/prof7bit/ea9b272c80182eeaccba hatte ich leider kein Glück. Habe vielleicht die falsche Frequenz eingespeist.? Jedenfalls muss man bei dem gegenwärtig laufenden PSK- Programm die Frequenz sehr genau einhalten, sonst wird nur Müll decodiert...
DH1AKF K. schrieb: > Bei Tempo 200 höre ich nur noch ein "Rattern" Ist aber auch nicht unbedingt eine übliche Geschwindigkeit. Ich war übrigens selbst überrascht, habe mal gelegentlich mit Fabian Kurz' Programm „qrq“ (das Unix-Pendant zu „RufzXP“) getestet, und habe teilweise in der Tat 230 oder 240 noch gehört. Kurze Sequenzen halt.
Ich weiß nicht, ob es für dein Decoder noch aktuell ist. Ich habe mal mit nur zwei Goertzelfiltern eine schnelle AFC aufgebaut. Das läßt sich bestimmt auch sehr einfach in deinem PSoC realisieren.
Hallo Jörg, das ist ja ein toller Vorschlag! Ich hatte Ähnliches bereits mit 2 FIR- Filtern (PSoC- intern) und einem Interpolationsmechanismus versucht, bin aber wieder davon abgekommen. Dagegen ist eine echte AFC eine wirkliche Bereicherung! Auch das Berechnungsverfahren ist einleuchtend. Momentan stecke ich etwas fest beim Versuch, das Programm NUE-PSK von PIC auf PSoC zu portieren. Die FFT zur Frequenzanzeige will noch nicht wie sie soll.
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.