Zu deinem Pre-FEC-Ansatz: Da bin ich nicht sicher, welches Problem du damit löst. Der Si468x macht Viterbi und Deinterleaving in Hardware und liefert die Datengruppen des Paketmodus mit CRC-Flag ab; das war mit „nur CRC-geprüft" gemeint: Was durchfällt, fliegt raus, und GEPOS SSRZ hat darunter noch eine eigene Prüfsumme. Der Datendienst läuft mit EEP 3-A, das ist deutlich robuster als die Audiodienste daneben, und eine verlorene Gruppe kostet Sekunden, nicht den Fix.
Zu Code. Naja, es geht um die letzten Zenti-Millimeter ;) Das ist doch viel komplexer als nur 2 Spec. nebeneiander legen. Sobald ich richtige fixe gibts den Code und den Strom zum testen.
Wenn du willst, kann ich dir aber einen Sketch geben, be dem GEPOS Kram gecheckt wie oben aus dem si468x bekommst mit jedem ESP32 wo der si468x per SPI dranhängt. Du musst dir nur eine FW “organsieren”. Der si468x ist außer natürlich SDR der einzige DAB+ Tuner, den ich kenne, bei dem man rankommt und der dokumentiert ist. Daher habe ich keinen 2ten untersucht, da die anderden bspw. von Frontier Sillicon zugenagelt sind.
Zu Ephemeriden: Ja, die sind jetzt seit neuestem drin im Strom, aber die liefert dir zumndest der f9p auch im Rückkanal und von daher waren die kein Problem.
Die Data Services kommen da als rohe DAB Frames raus - vor dem FEC des Data Channels.
D.h. bei einem Dual empfänger bekomme ich die Frames doppelt (theoretisch) und kann eben die SNR des Reed-Solomon verbessern wenn ich immer aus 2 frames mit unterschiedlichen Fehlern wählen kann.
Ah, dann ergibt das Sinn, ohne Si468x musst du die äußere FEC ohnehin selbst machen.
Die ist bei GEPOS auch an: Der Subkanal (8 kbit/s, Paketmodus, 24-Byte-Pakete) trägt den RS(204,188) Außenschutz, nach je 2256 Byte Nutzpaketen folgen 216 Byte FEC-Pakete. Gesehen am RTL-SDR (eti-cmdline plus eigener Paketparser): Auch bei sauberem Empfang fallen im festen Takt genau diese 216 Byte durch die Paket-CRC.
Für deine Diversity heißt das: je Paket per CRC aus beiden Empfängern wählen; wo beide Kopien durchfallen, die Bytes, in denen sie sich unterscheiden, als Auslöschung in den RS-Decoder. RS(204,188) korrigiert 16 Auslöschungen, aber nur 8 unbekannte Fehler je Codewort. Bringt natürlich nur was mit zwei getrennten Antennen; an einer Antenne sehen beide Empfänger dieselben Fehler.
Bei mir (Si468x, Dach in Hamburg) ist in 26 h kein einziger Rahmen verworfen worden, deshalb habe ich die Baustelle bisher nicht.
Hab ich ja alles fertig und das funktioniert auch - Deshalb reverse engineere ich noch an den Dual USB DAB Radios rum - Damit kann ich eben diversity hinbekommen.
Und das ich bei nicht mobilem Rover alles empfange ist schon klar. Sobald du dich bewegst sieht das ganz anders aus. Dann verlierst du permanent daten und das schlägt eben trotz RS eben bis in die RTCM frames durch die dann nicht mehr vollständig sind.
Fatal ist auch das zumindest in den letzten Test die RTCM Frame Boundaries nicht auf den DAB Boundaries respektive DAB Data Frame Boundaries liegen. Sondern beim aussenden wird das wie ein Datenstrom behandelt.
Führt dazu das du ein sync problem hast wenn mittendrin zeugs kaputt geht.
Das mit den Rahmengrenzen sehe ich auch: In meinem Mitschnitt sind die Datengruppen zwischen 100 und 1448 Byte lang, und die RTCM-Rahmen laufen quer darüber. Ein Stromparser (D3 suchen, Länge, CRC-24Q, bei Fehler ein Byte weiter) ist aber beim nächsten Rahmen wieder drin. Eine verlorene Gruppe kostet nur die Rahmen, die sie berührt.
Zum Fahren: Im Juli hatte ich einen einzelnen Si468x im Auto, Hamburg–Dagebüll, 168 km in zwei Stunden, gut ein Viertel davon über 100 km/h auf der Autobahn. Knapp 16 000 RTCM-Rahmen, kein einziger mit falscher CRC, keine Lücke (außer NATÜRLICH den kleinen Tunnel am Flughafen) über den normalen Takt hinaus. Mit dem Si468x habe ich die Baustelle also bisher nicht. Ob die C100-Sticks unterwegs mehr verlieren?
Was für eine Antenne hast du dran?
Ich hatte eine Diamond DC 100.
Ja, Xbee ist spannend, allerdings wäre mein Vorschlag der, das man den ESP32 und den Si468x auf ein Xbee Board bringt. Leider sind die mir fertigen bekannten si468x alle zu groß für Xbee und man müsste sie etwas umständlich per SPI und Jumper/Dupont Kabel anbinden.