Es gibt etwas Interessantes zum Thema "Sync" zu berichten. Bemerkt habe ich das Ganze am Wochenende, nachdem ich die rtltcp-Source auf meinem Rechner mit der Fähigkeit zum Ändern der Samplefrequenz des SDR-Sticks mit 1/100 ppm Genauigkeit versehen habe.
Einen einfachen Algo zur Auffinden des Nullsymbols in den Puffern vom Stick hatte ich ja schon drin, denn Anfang des Jahres hatten wir ja noch mit Sampleverlusten zu kämpfen, die QIRX, je nach Anzahl der verlorenen Samples, mächtig aus dem Tritt brachten. Im Prinzip habe ich am Ende eines Nullsymbols die fehlenden Samples duch Nullbytes ersetzt, damit der folgende Frame zeitlich wieder "passt". Das hat schon viel geholfen, damit QIRX nicht den Sync verliert. Zum Glück brauchen wir das heute nicht mehr.
Aber wenn das ganze Zeug schon drin ist, dann kann man den Drift des Nullsymbols in den Puffern auch in ppm umrechnen und anzeigen. Gesagt getan. Damit man auch was sieht, habe ich die ppm Anzeige oben im Konsolenfester mit etwas grösserer Schrift angeheftet. Das sieht nach dem Start und der Aufwärmphase des Sticks so aus:
Mein Stick ist schon sehr gut, liegt weit unter den 0,5 ppm laut Datenblatt. Früher bestand also kein Grund, den Stick von QIRX kalibrieren zu lassen. Das ging auch nicht, da ja nur 1 ppm Schritte möglich waren.
Der zweite Wert ist übrigens der ppm-Wert nach 300 Nullsymbolen, also nach einer Messzeit von genau 57,6 Sekunden. Trotzdem ist es sehr "mutig", nach dieser Zeit drei Stellen nach dem Komma anzuzeigen. Man müsste noch länger messen (1000), damit sich Messfehler entsprechend wegmitteln. In "Real-World-Nullsymbolen" ist ja immer etwas Rauschen, letzte Signale weiter entfernter SFN-Sender am Anfang des Nullsymbols oder irgendwelche Störungen drin, was sich in Jitter äussert.
An dieser Stelle möchte ich Dana zu Wort kommen lassen. Sie schrieb (etwas gekürzt):
Dana Diezemann hat geschrieben: ↑Mi 24. Nov 2021, 18:21
Auch das extreme schwanken beim Sync. ... Auch unter Windows tritt das auf ab 3.x. Nicht mit 2.x.
Ich hab 5 Systeme, die hier monitoren können.
Und es tritt nur auf:
-
wenn ich live abspiele, also keine Record Datei wiedergebe
-
unabhängig ob ich QIRX oder selbst mit Buffern die rtl Lib starten lasse
-
wird besser bei leistungsfähigeren Rechnern
Ich fange mal mit dem ersten Punkt an, denn der erscheint mir sehr wichtig für die Fehlersuche. Wenn QIRX ein File abspielt, wird das Timing intern generiert. Die "Abspielgeschwindigkeit" ist also völlig unabhängig vom SDR-Stick. Den kann man ja notfalls auch abziehen. Ich gehe jetzt davon aus, dass man ein IQ-File nur aufzeichnet, wenn der Sync auch "steht". Ein solches File wäre dann beim Replay auch erstmal in Ordnung...
Der zweite Punkt deutet darauf hin, dass Dana die rtltcp mitunter auch über eine Batchdatei startet. Das könnte darauf hindeuten, dass evt. nicht die rtltcp im QIRX-Programmverzeichnis gestartet wird. An dieser Stelle komme ich wieder ins Spiel, denn meine rtltcp lag ja zunächst im Release-Verzeichnis vom VisualStudio und dort lag noch eine rtlsdr.dll vom Juli rum. Mal sehen, ob das Programm funktioniert. Ich lasse also meinen Stick von QIRX "kalibrieren"...
0,14 ppm sagt QIRX und zeigt das auch an. In Wahrheit sind es aber 100x soviel. Und da hab ich noch Glück mit meinem Stick. Es gibt auch Sticks mit einem grösseren Frequenzfehler. Sagen wir "läppische" 1,5 ppm. Dann wird es schnell kritisch mit dem Sync:
Das Problem entsteht also nur dadurch, weil ich zunächst die falsche (ältere) rtlsdr.dll benutzt habe und auch nur, wenn die Korrektur !0 ist. Es riecht mir verdammt danach, dass das bei Dana ebenso ist. Wie soll Dana später auch erkennen, dass der Stick völlig "verstimmt" ist? Klar, im "Sync-Tab" spielen die Zahlen verrückt, und das kann bekanntlich mehrere Gründe haben.
Ein bekannter "Held" in dieser Beziehung ist bekanntlich "Firefox". Beim Aufruf einer "schweren" Webseite kann man darauf wetten, dass der Sync flöten geht. Und es hilft auch nichts QIRX und die rtltcp mit High-Priority laufen zu lassen. Firefox würgt kurzzeitig alles ab. Da ist wohl ein CPU-Hog drin. Dieser Zirkus gibt sich nur, wenn man im Taskmanager die beiden Firefox-Tasks mit dem höchsten Speicherverbrauch (gut sichtbar über 100MB, die anderen sind unwichtig) auf niedrigste Priorität setzt. Normalerweise nimmt man diese Prio für Bildschirmschoner.
Aber zurück zu den ppm-Werten mit der richtigen rtlsdr.dll aus dem aktuellen QIRX-Verzeichnis. Ich hätte ja gedacht, dass die gesamte Frequenz-Mover-Geschichte am Anfang der DAB-Dekodierung gegen Null strebt, wenn der SDR-Stick mit möglichst exakt 2,048 MHz sampled. Das scheint aber nicht der Fall zu sein. Mein Stick läuft nach der Kalibrierung definitiv langsamer. Das zeigt nicht nur meine rtltcp an, man sieht es auch im IQ-Data Fenster. Das Nullsymbol wandert ganz langsam nach links aus dem Fenster.
Langer Text- wenig Inhalt.
für Eure Aufmerksamkeit!