Die Option -b soll nach anfaenglicher Synchronisation anders als bei der Nulldurchgangsmethode in festen Abstaenden bis zum Frameende fuer jedes bit durch Aufsummieren der samples entscheiden, ob es 0 oder 1 ist. Hier ist natuerlich wichtig, dass man zu Beginn den Startpunkt richtig trifft und dass das Timing bis zum Ende des Frames stimmt, weil zwischendurch nicht neu synchronisiert wird. Erwaehne das nur, weil das nicht mit allen Sonden gleich gut funktioniert, bei DFM und Vaisala ganz gut, bei iMet-1-AB schlecht und bei der M10 muss die baudrate recht genau eingestellt werden. Was ich auch nicht weiss, wie gut das auf unterschiedlichen Systemen funktioniert oder mit anderen Empfaengern.
Jedenfalls ist das bei schlechtem SNR bei mir deutlich besser als mit den Nulldurchgaengen, wenn man dann Fehlerkorrektur anwenden will. Gerade bei RS41/92 kann man dann mit der Reed-Solomon-Fehlerkorrektur noch einiges reparieren. Allerdings ist bei der RS41 dann das Problem, dass die Framelaenge entweder 320 byte oder die maximal moeglichen 518 byte betragen kann, wenn Aux-Daten gesendet werden. An Werte dazwischen kann ich mich nicht erinnern, die Frames werden mit 00-Bloecken aufgefuellt, wie mir scheint. Fuer die Fehlerkorrektur waere es auch gut, wenn man wenigstens mit einer der zwei Framelaengen rechnen kann, sonst versucht man teilweise, zu viel zu korrigieren.
Wenn nun die byte-Position jenseits der 320 ist, kann man anfangen darauf zu achten, ob die gelesenen bit in einem byte haeufiger fehlerhaft oder von schlechter Qualitaet sind, um dann zu entscheiden, ob das eigentlich nur noch Rauschen ist. Wie man ermittelt, ob da noch bits kommen oder ob das Rauschen ist, da gibt es wohl mehrere Moeglichkeiten, z.B. die Varianz oder eben die Anzahl Nulldurchgaenge pro bit und das ganze pro byte. Dachte, hier kann die Schwaeche der Nulldurchgangsmethode auch genutzt werden. Ob 0.7 fuer diese kurze Ueberlegung der optimale Wert ist und ob man das nicht besser normieren kann, kann ich nicht sagen, lange habe ich das nicht getestet. Wenn gleich zu Beginn die Synchronisation nicht ganz stimmt (bei schlechtem SNR kann das natuerlich schnell passieren), koennte das schneller zum Abbruch fuehren als noetig, denn zwischen 320 und 518 ist eigentlich genug Zeit, um sich fuer die eine oder andere Grenze zu entscheiden. Ein etwas hoeherer Wert reicht wahrscheinlich, gerade bei geringerer Samplerate. (In der ersten Version war mir wichtig, genau das Ende des Frames zu erkennen, was glaube ich nicht noetig ist, s.o.) Hatte auch ausprobiert, fuer jedes bit nur den inneren Teil der samples, die zu einem bit gehoeren, zu zaehlen, das koennte etwas Spielraum schaffen, hat aber auch nicht immer Vorteile gebracht.
Bei der RS92 und den DFMs hat man mit der Manchestercodierung den Vorteil, dass man zwei bit zusammen betrachten kann als eine Schwingung, man kann also das Zaehlen der samples, die zu einem bit gehoeren, genauer gewichten.
asg hat geschrieben:
if (byte_count > NDATA_LEN) {
if (ratioQ > 0.7 && ratioQ0 > 0.7)
Musste auch erst nochmal ueberlegen, was ich mir genau gedacht habe, das ging damals recht schnell und irgendwann hatte ich die Ueberlegung auch nochmal geaendert, weil mir auffiel, dass entweder 320 oder 518 die Framelaenge ist, nichts dazwischen.
Die Funktion, die die samples pro bit auswertet, gibt die Anzahl Nulldurchgaenge zurueck. Sollte pro bit nicht mehr als 1-2 sein, im Schnitt weniger. Die Anzahl wird pro byte aufsummiert. Ausgewertet wird erst ab byte 320, ob das byte als fehlerhaft gewertet wird. Anfangs hatte ich glaube nur gezaehlt, wenn zwei aufeinanderfolgende bit fehlerhaft sind (zu viele Nulldurchgaenge), jetzt hat ratioQ0 eigentlich nur noch fuer das erste bit eine Relevanz. Werde mir das nochmal anschauen und etwas aufraeumen, eigentlich geht das jetzt einfacher. Mit dem auskommentierten printf sieht das auch noch etwas unfertig aus... Danke fuer den Hinweis.
asg hat geschrieben:
Hast du dich schon mit dem dekodieren der Kalibrierungsdaten beschäftigt?
Bei der 92er ist ein System von Marker/Daten schnell zu identifizieren. Anders
bei der 41er, dort finde ich zwar Marker(wenn es denn welche sind) aber nicht
in der (meistens) ansteigenden Folge wie bei der 92er.
Fuer die rs92 hab ich fuer mich PTU-Daten programmiert mit den Infos, die man im Internet findet. Weiss nicht genau, was du mit "Marker" meinst. In den Calib-Daten ab subframe 0x04 sind immer Bloecke zu je 5 byte (Zaehler + 4byte float32). Meinst du den Zaehler als "Marker"?
So richtig begeistern konnte ich mich fuer die PTU-Daten bisher leider noch nicht. Dachte, bei der rs41 wird das aehnlich sein, hatte auch was gehoert, bin dem aber bisher nicht weiter nachgegangen.
einergehtnochrein hat geschrieben:
Über die Blocklänge weiß man also immer wo der nächste Block beginnt. Damit kann man sich von Block zu Block hangeln bis zum Ende. Blocks mit einer Typkennung die man nicht kennt kann man einfach überspringen. So ist man auch gegen unbekannte Blocktypen und beliebige Reihenfolge der Blöcke gewappnet. Am Ende eines Frames scheint immer ein Block des Typs 0x76 mit variabler Länge und allen Nutzdatenbytes=null zu liegen (Auffüller).
Im Prinzip kann man mit den Bloecken auch die Bitgrenzen in den Samples justieren. Allerdings wenn man eigentlich erst die Fehlerkorrektur anwenden will, muss man ueberlegen, was macht man zuerst, bevor man den "Inhalt" der bytes ernst nimmt...
. Also Vorsicht bei den Daten die von mir getrackt werden 
.
->zoom