Ist es mit dem -b soviel schlechter? Bei mir ist es umgekehrt. (Es sei denn, die Sampling-Rate ist niedrig (22k oder weniger), dann wird's mit dem -b nicht so gut. Aber 48k ist eigentlich gut.) Denn dann muessten auch die dm/dm_dft-Versionen Probleme haben. Das Lesen der weiteren Bits ist da eigentlich wie mit -b, nur das Erkennen des Frame-Beginns ist anders. Da kommt der Gewinn bei schlechtem S/N, da erkennt die alte Methode nicht immer den Header.asg hat geschrieben: Norderney3.wav Aufnahmedauer: 3334 Sekunden, sample_rate: 48000, bits: 16, channels: 1
./rs41ecc -v --crc --ecc --res Norderney3.wav | grep lat | wc -l (Die Version mit ka9q-fec)
Anzahl: 1479 in 8 Sekunden
./rs41ecc -v --crc --ecc -b Norderney3.wav | grep lat | wc -l (Die Version mit ka9q-fec)
Anzahl: 506 in 8 Sekunden
Wenn das Signal schlecht ist und die neue Version den Frame dennoch erkennt (die alte jedoch nicht), dann kann es aber durchaus sein, dass das Rauschen zu gross ist fuer eine Fehlerkorrektur, aber dennoch einzelne Bloecke noch einen korrekten CRC-Wert liefern und ausgegeben werden.
Ach, was sein kann, wenn du noch die alte Variante mit dem Reed-Solomon von ka9q verwendest, dass da die kurzen Standardframes mit 320 byte bei -b nicht richtig erkannt werden, und dann ist die Fehlerkorrektur oft nicht viel wert. Hab das zumindest in der rs41ptu.c umgebaut, das sollte da unabhaengig von Sampling-Rate oder aehnlichem zuverlaessiger erkannt werden. Probier es vielleicht auch mal mit der rs41ptu (ist wie rs41ecc nur mit Temperatur (--ptu)).
Das Problem bei der rs41 ist nun aber, dass zwischen den Frames recht viel Pause ist. Und die grosse Rechenlast kommt in der Zeit, wo er den naechsten Frame sucht. Hab bei der rs41 am Ende des Frames erstmal soweit vorgespult, dass er noch weiter bits liest bis zur maximal moeglichen Framelaenge von 518 bytes. Man koennte auch genauer bis zum vermuteten naechsten Frame-Beginn springen oder nach der Sync-Preambel Ausschau halten (wo sich die Varianz des Signals deutlich verbessert/verkleinert), die es jedoch bei den alten rs41 noch nicht gab. Und wenn man die Frequenz zu einer anderen rs41 wechselt, verpasst man vielleicht was.
Schlimm wird es halt, wenn man gerade kein Signal empfaengt und der Decoder nach einer rs41 sucht...
Also das war so der erste Entwurf, da kann man vieles feiner abstimmen. Merke das gerade bei der M10. Im Prinzip kann ich das ganz aehnlich machen wie bei den anderen Sonden. Da ist der Frame nur etwa 1/4 sek lang, allerdings alle 10 sek gibt es einen Doppelframe (den man nicht unbedingt braucht). Ziemlich viel Leerlauf, wo der Correlator heisslaeuft... Die Bitrate ist dort hoeher, da war dann sehr hilfreich, den dc-Offset zu korrigieren, die Daten dazu werden ja eh berechnet. Da koennte vielleicht aber auch noch helfen, dass man aehnlich wie mit der --res Option die Startposition auch zwischen zwei Samples festlegen kann, vielleicht mindert das den Quantisierungsfehler bei kleiner Sampling-Rate. Hab das noch nicht ausprobiert.
Einerseits haette ich gerne fuer alle 4 Sonden moeglichst das gleiche Verfahren, andererseits hilft es dann doch manchmal, spezielle Eigenschaften der einzelnen Sonden zu beruecksichtigen.
asg hat geschrieben: bufs = (float *)calloc( M+1, sizeof(float)); if (bufs == NULL) return -100;
usw.
Warum immer einen mehr?
//Warum, hat doch calloc aufgerufen for (i = 0; i < M; i++) bufs = 0.0;
Weiss, das calloc sollte eigentlich alles auf Null setzen. Und eigentlich sollte das bei nem float/double auch 0.0 bedeuten. Die Initialisierung wird aber nur einmal vorgenommen, da ist es eigentlich egal. ob man nochmal Werte zuweisst. Weiss auch nicht, ob ich konsequent alles initalisiert habe.
Ach, das +1 ist einfach nur ein minimaler Zusatzschutz, bei N=600 oder mehr spielt das dann keine Rolle. Eigentlich sollte ueberall mod N bzw. M zugewiesen oder gelesen werden. Hab mir auch noch nicht ueberlegt, wieviel von dem "delay" ich eigentlich wirklich brauche, dachte da erst an etwas anderes.
Bei der Dimensionierung von N, K und M kann man im Einzelfall, wenn man die Bitrate vorher kennt, auch optimalere Werte finden. Am besten, man braucht pro Frame nur einen FFT-Durchlauf, d.h. man ist schon ziemlich genau am Frame-Beginn und das K-Fenster ist gross genug, um den Peak zu finden, der den Header anzeigt.
Bei guter Signalqualitaet und langsamen Computer ist die Nulldurchgangsmethode wohl am einfachsten. Wenn man die Signalqualitaet zuverlaessig messen kann, koennte man zwischen den verschiedenen Methoden hin- und herschalten. Oder wenn die Decodierung ausbleibt, das ganze nochmal mit der aufwendigeren Methoden.. Am besten hat man dann Samples fuer mehrere Sekunden im Buffer. Wird dann natuerlich ein ziemlich grosses All-In-One-Paket. Das Paket, das in jeder Situation optimal funktioniert, ist wahrscheinlich auch nicht so einfach zu bauen. Deshalb stell ich erstmal die verschiedenen Varianten nebeneinander, auch wenn die Auswahl dann etwas unuebersichtlich wird. Dann kann erstmal vergleichen. Nicht bei jeder Sonde hat man immer den gleichen Gewinn. Z.B. bei Sonden ohne Fehlerkorrektur (oder nur geringer wie bei der DFM) hat man bei schlechtem Signal selten vollstaendig korrekte Frames, insbesondere wenn der Frame gerade noch mit Correlation erkannt wird. Da gefaellt mir die rs41 doch am besten.
NACHTRAG:
Wenn man das Fenster K von N/2 auf z.B. 2N erhoeht und einen etwas groesseren Buffer in Kauf nimmt, halbiert sich die Rechenzeit beinahe. (So sollte es auch sein, da kommt der Vorteil der schnellen Fouriertrafo zur Geltung.) Eigentlich muesste man diese Parameter fuer jede Bitrate/Sampling-Rate/Sonde bestimmen, um den FFT-Buffer vernuenftig auszunutzen. Haengt aber auch davon ab, wieviel Speicher man zur Verfuegung stellen will.
Die Zeit, die fuer die Verarbeitung von einer festen Anzahl Frames gebraucht wird, haengt natuerlich auch davon ab, wie oft er Fehler korrigieren muss und dadurch mehr Arbeit hat. Gerade wenn man dann noch mehrere Fehlerkorrekturrunden einbaut. Grob gesagt, wenn man mehr aus einem schlechtem Signal rausholen will, muss man meist auch mehr Aufwand treiben.
Um die verschiedenen Methoden zu vergleichen, muesste man eigentlich eine konstante S/N haben und Statistik treiben, wieiviel Fehler jeweils die Dekoder machen. Grob kriegt man mit der Anzeige in sdrsharp zum Beispiel einen Eindruck. Mit der alten Methode bekomme ich bei der rs41 Frames (wenn auch mit Fehlern) etwa bei 12dB ueberm Rauschen, mit der neuen etwa mit 10dB. Ist aber sehr grob. Bei der dfm mit der niedrigen Bitrate geht es oft schon bei 6dB los, dann haeufiger mit Fehlern, frueher waren so 9dB noetig, Das Verhaeltnis korrekte/fehlerhafte Frames ist dann jedoch schlechter. Besser waere es, einem sauberen, halbwegs konstantem Signal kuenstlich Rauschen hinzuzufuegen und dann die Fehler zu zaehlen. Dann koennte man parallel auch das saubere Signal ohne Fehler korrigieren und weiss, wo tatsaechlich Fehler auftreten.
Bei der rs41 bekommt man immerhin schon einen Eindruck, wenn man sich die Anzahl korrigierter Fehler ausgeben laesst.
asg hat geschrieben: Zeitmessung:
a=$(expr $(date "+%s"))
./rs41...
e=$(expr $(date "+%s"))
d=$((e-a))
In Linux gibt es auch "time", einfach vor das Kommando schreiben, das man messen will: time ./rs41...