So ich habe da mal weitergeschraubt - Das mit der Forward Error Correction im DAB habe ich am laufen, der korrigiert entsprechend bytes wenn denn Bitfehler auftreten. Danach kommen halt pakete Raus.
Der DAB Standard sagt das man pakete deren CRC in Ordnung ist auch direkt konsumieren könnte, welche die da nicht passen eben durch die Reed Solomon FEC schieben. Sowohl direktes konsumieren wie auch Bitfehlerkorrektur im RS gehen jetzt. Der consumer muss entscheiden welche pakete er nimmt. Grundsätzlich kommen die pakete halt 2 mal vorbei geflogen. Einmal direct, und einmal nach dem die FEC gelaufen ist.
Das ganze funktioniert jetzt soweit. D.h. ich kriege jetzt Pakete:
Got packet - direct 1
Length 18
0x000000: 00 02 13 b1 84 09 7e 9f 6c b0 91 00 0f 2b fb cd ......~.l....+..
0x000010: c1 ae 2c bf ff fc d4 36 ..,....6
Da ist jetzt entsprechend noch der DAB header, und die 16 bit CRC am ende. Also hier Addresse 02, Länger 0x13 → 19 byte. CRC d436
Soweit so gut. Jetzt hab ich nur oberflächlich mal in die SSRZ und RTCM (Standard hinter paywall) geguckt wie das weitergeht - d.h. gibts ein framing im SSRZ, ist “in order” wichtig d.h. was mache ich mit Paketen deren CRC kaputt ist, halte ich da das prozessieren und warte auf die FEC etc etc - Vermutlich viel rumprobiererei.
Also ich hab interesse - Bisher probiere ich ja nur möglichst günstig über einen Software Defined Radio DAB receiver an die Daten zu kommen so das ich die dann weiterverarbeiten kann. welle.io ist ganz hübsch weil es einen “command line client” hat der eben keine GUI braucht. Auch das ganze Audio (mpg, aac etc) zeugs kriegt man mit wenigen handgriffen da raus. Über bleibt eben das ganze DAB OFDM zeugs als SDR. Da habe ich jetzt hinten dran einen Dekoder für Paket Streams gebaut (Den gabs bisher nicht) und eben das FEC mit Reed Solomon, was ich so halb im DAB+ aac decoder gab. Und das ganze kriegt man hoffentlich CPU mäßig auf sowas wie einem Raspberry Pi ans laufen so das das Portabel für einen Rover wird.
Jetzt irgendwann kommt halt der Punkt wo man sich das interface von Hardware DAB Receiver Chipsets wie dem Skyworks SI4688 ansehen müsste. Denn irgendwann kommt jetzt der Punkt wo man sonst code duplication hat. Ich hab keine Ahnung ob man da überhaupt an Paket Streams kommt, und wenn ja wieviel das Hardware Chipset übernimmt und was man selber “zu Fuß” machen muss. Angeblich kriegen die SI4688 auch einen Software Blob der aber komplett undokumentiert ist, wo ein Radio Hersteller aber zeugs reinpacken können.
Wenn die Skyworks Chipsets da was können wäre es durchaus Denkbar mit KiCad ein Board zu designen was eben einen DAB Receiver, einen esp32 und ein RTK Fähiges Chipset wie ublox X20 oder so beinhaltet. Vieleicht kriegt man sowas bei Ardusimple gebaut. Dann hätte man einen schicken Rover. Das Board selber kriegt man ja vermutlich für 10-20 Euro gebaut, mit den ganzen Chipsets und so reden wir dann vermutlich aber trotzdem über 250€.
ich habe mit einem Airspy auch mal schnell was aus dem Bundesmux gezogen, siehe listing unten. Das geht mit den genannten tools etitool (eti-cmdline-) und etisnoop auch super einfach vom Empfang bis zum gedemultiplexten Binärstrom. Da stehe ich derzeit und schauen auf den Datenstrom mit einem Binäranalysetool namens Hobbits und denke, dass da wohl noch was zu tun ist.
Meine Überlegung war nun mit Kaitai Struct einen Parser zu definieren und anschließend generieren zu lassen, um damit die Verarbeitung in verschiedenen Sprachen (Python, C++, etc) zu ermöglichen, ohne jeweils neu entsprechend komplexe Parser ‘per Hand’ wie in der GeoPP Referenzimplementierung bauen zu müssen.
Nachfolgend wäre natürlich weiterhin die Implementierung der Modelle und Übertragung in andere Formate nötig, ggfs. auch mit einer angepassten Referenzimplementierung.
Den fork von welle-io finde ich interessant und muss ich mir mal anschauen, wenn sich Zeit findet, die derzeit leider rar ist.
Ich kannte Kaitai bisher nicht - aber kann man dem abgewöhnen einen stream zu lesen und einen memory buffer zu akzeptieren? Also im cpp fall?
Das ganze kommt ja aus dem rtl-sdr zeugs als memory buffer 23 mal decoded schon raus - Ich kann natürlich einen stream draus machen - aber das ist dann doch ne menge, und vor allem langsamer glue code?
Ich fühle mich ja schon schmutzig da impliziete mallocs im fast packet path zu haben.
Ich hab mal aus Spaß so ein dingen auseinander genommen. Da sitzt ein wRadio C100 drin. Wenn man dann ein bisschen Google Foo auspackt kommt man drauf das das dingen wohl ein Standard Interface erfüllt mit dem Google Sicherstellen wollte das alle DAB/DAB+ Empfänger (Und anderes) unter Android supported ist. Den Hersteller oder Typ des Chips finde ich irgendwie nicht. Könnte mir auch vorstellen das das ein Si468x ist mit anderer Firmware und umgelabelt oder so.
Mit fehlt die low-level USB Steuerung des ganzen. Wenn ich da mal code durch ghidra stecke dann finde ich schön obfuscated krams soifz der da den Tuner befüttert etc.
Also - das ist kein SDR Zeugs - sondern das funktioniert eher wie eine Linux DVB Karte. Tunen und dann kommt da der Transponder/MUX raus. Man findet symbole in den libs die drauf hindeuten das da der DAB stream demuxed wird. Ausserdem ist ein mpg123 dabei - D.h. Audio wird in Software decoded.
Wäre schick wenn man das ans laufen bringen könnte. Braucht nicht so viel Strom wie die SDR varianten und ist deutlich billiger.
Oh wow, das ist ja super, dass sich so viele für das Thema interessieren. Da aktuell es wohl beim Dekodieren des Streams hakt, wäre es nicht ein guter Punkt, auf das Angebot von XYZ zurückzukommen und sich dazu in einer Onlinekonferenz einmal auszutauschen?
Mir selbst fehlt für Entwicklungsarbeit auch längerfristig leider die Zeit. Und wenn ich eure Kenntnisse hier sehe, befürchte ich, dass das meine auch deutlich übersteigt
Es hakt da gar nicht so - Es ist halt ein Hobby und bisher hab ich keinen Open Source/Free Software dekoder für DAB gefunden der eben den Packet Mode sauber kann. Das was man findet sind hacks die halt ohne FEC arbeiten. Wenn ich mir aber überlege mit dem DAB Empfänger auf dem Rad oder Roller durch die Gegend zu fahren dann kommt das ganz natürlich zu Bitfehlern, abbrüchen, packet loss etc. “Das muss das Boot abkönnen Herr Kaleu”.
Man schleppt halt keine “Dolle Antenne mit 10dB Gewinn” mit.
D.h. bei dem ganzen Dekoder schreiben ists halt wichtig das der das maximale raus holt mit Error Correction und vor allem schnell und simpel recovered wenn mal unrecovereable errors kommen, pakete weg sind etc.
Das sieht aber alles schon ganz gut aus. Ich bastel gerade eben an der Packet Pipeline die dann kaputte Pakete versucht durch die aus dem FEC zu ersetzen, das Framing aus dem Packet Mode zu aggregieren und dann müssten da SSRZ Frames rauskommen. Wobei ich mir noch nicht sicher bin ob die nicht noch RTCM encapsulated sind.
Für das SSRZ gibts ja eine Python implementierung die man ggfs verändern und befüttern könnte. Das ist halt tonnen an Mathe - hab mal oberflächlich durch die SSRZ Dokumentation und in den Python code gesehen und DAS will man nicht reimplementieren. Und WENN man das unbedingt muss dann als C++ lib die man einfach einbinden kann überall.
Dann gibts ja noch das “ssr2obs” (Was ich nicht kenne oder habe) das die SSR in OBS daten umpopelt so das man das entsprechend in die RTK GPS Chipsets schieben kann. (So jedenfalls mein bischer laienhaftes Verständnis)
Ich pfriemel mich halt von vorne da durch. Dauert halt.
Vielleicht finden sich ja noch jemand der mit basteln will/kann und auch zum Fossgis hackmeeting im Linux Hotel ende Mai kommt?
Das Linux Hotel scheint schon recht ausgebucht aber für ein Zelt ist immer noch Platz und extern im Hotel geht ja auch - also in den Konferenzräumen ist Erfahrungsmäßig reichlich Platz.
Okay - Also das ganze ist nicht RTCM encapsulated sondern ist nur nicht im EN 300 401 Packet Mode aka 5.3.2 “Packet mode - network level” sondern als 5.3.3 “Packet mode - data group level” encodiert.
Die ganze dollen features wie segments, repetition und co werden nicht genutzt aber eben 2 byte header + 2 byte CRC - CRC überprüfe ich jetzt und die ist heile - dann kommen da Frames bei raus die dann SSRZ sein sollten.
Das ist noch das DAB Frame - 0x40 ist “CRC Flag” und 0x90 ist “9” für den continuity counter. “0” für repetition.
Das eigentliche Paket geht ab der 0xd3 los und die letzten 2 byte sind eine CCITT 16 bit CRC.
Hier habe ich mal 2 Minuten frames aus dem DAB abgelegt. Leider kriege ich spontan das SSRZ Demo zeugs nicht dazu nur den SSRZ stream zu lesen und zu dekodieren. Ich will ja nur wissen ob das jetzt alles so passt.
Ist natürlich Bullshit - ERST “Packet mode - data group level” nach EN 300 401 5.3.3 und DANN RTCM - wobei das alles sehr aehm - Offensichtlich gehen RTCM frames über mehrere DAB frames:
RTCM Preamble 0xd3 - address 0x2 - dann kommen 16 bit laenge.
Und das RTCM frame overflowed dann diesen DAB Frame und geht im nächsten weiter. Das verstehe ich nicht warum man das gemacht hat und nicht jedes RTCM Frame in ein DAB Packet Data frame gepackt hat - aber gut.
Nach SSRZ Doku müsste der RTCM Message Type 4090 (Hex 0xffa) sein (Table 4.1). RTCM sind die ersten 12 Bit nach der Länge der Message type.
Das sieht also alles richtig aus.
Flo
Frame continuity 0x9
0x000000: 40 90 d3 00 08 ff a7 ee e4 e8 d9 5e 40 1b 41 cf @..........^@.A.
^^
0x000010: d3 00 27 ff a7 11 d9 e2 b5 8a 6c 55 6e 00 a1 b8 ..'.......lUn...
0x000020: 67 2f c2 08 5b 5c 8b f0 9f 38 46 06 01 42 1f 0c g/..[\...8F..B..
0x000030: 54 0e 81 08 13 41 11 a5 69 00 4c 24 68 d3 01 48 T....A..i.L$h..H
^^
0x000040: ff a7 91 d2 11 a8 7b c1 1a 15 46 e8 57 66 69 52 ......{...F.WfiR
0x000050: 02 aa aa aa 1a 83 af 53 9e fe 3d 47 9c a0 98 8d .......S..=G....
0x000060: 05 55 55 54 39 6e d0 8d .UUT9n..
Frame continuity 0xa
0x000000: 40 a0 07 8e a5 a3 0c 20 1c ea b9 aa ae 20 2a aa @...... ..... *.
0x000010: aa a1 86 71 e0 17 23 7b f7 4d 96 f8 80 67 0d 5c ...q..#{.M...g.\
0x000020: c6 d1 17 1f ab 3e 00 be c3 30 58 6b e7 ea 5a 97 .....>...0Xk..Z.
0x000030: 25 5d fc 07 68 4e 65 73 17 d0 ca 09 33 31 62 df %]..hNes....31b.
0x000040: 90 35 b4 df 9d 27 8c 41 68 da ba 40 5c 83 54 69 .5...'.Ah..@\.Ti
0x000050: 1f 33 68 a9 bc 8c 20 15 27 70 c5 14 f7 62 9d 39 .3h... .'p...b.9
0x000060: ef 08 20 84 07 10 87 c1 6f ea e6 64 81 0e 5e 41 .. .....o..d..^A
0x000070: 75 21 b8 c8 60 e2 1d 0a 1a 51 6f 4d 76 01 8c 1a u!..`....QoMv...
0x000080: 6a c6 bc 7c b1 8b cf ae 0a 0c 6d f6 e8 f0 b5 f2 j..|......m.....
0x000090: 92 d4 da 6f 41 97 5d 2e ab 10 81 b4 4a 3e 83 1f ...oA.].....J>..
0x0000a0: 4f a9 e3 1a df 9b cc 9e b8 b2 19 69 9b 9e 0f 05 O..........i....
0x0000b0: b1 43 6b 48 80 aa aa aa 86 cf 5b 5e 83 88 2e 93 .CkH......[^....
0x0000c0: c7 8b 26 81 a2 ee d0 e4 e6 d4 21 71 06 61 89 85 ..&.......!q.a..
0x0000d0: cb db 74 ef 9b e8 52 cf 1f 03 77 9c c1 ce 59 09 ..t...R...w...Y.
0x0000e0: ca 96 f7 26 fd c3 98 9f 02 b9 b5 61 21 f7 18 cb ...&.......a!...
0x0000f0: b7 90 7b 03 1c 93 cc e2 f0 f3 ba ac f0 98 86 8a ..{.............
0x000100: e0 e5 9d c2 87 96 7c f4 f7 94 cc 3b 32 7b 43 a0 ......|....;2{C.
0x000110: 49 1d 3d 26 76 aa 3d db 83 49 91 1e d4 fa 8b 5f I.=&v.=..I....._
0x000120: 9e c1 50 e5 73 ef ef d3 01 2d ff a7 91 d3 11 97 ..P.s....-......
^^
0x000130: 7c a3 0e 5b e2 cd 92 7c b7 a8 2a aa aa a1 78 64 |..[...|..*...xd
0x000140: a1 eb f6 97 4a cd 87 40 aa aa aa 86 1f da 10 67 ....J..@.......g
0x000150: b2 9f 36 ec b3 c9 a8 2a aa aa a1 8a 55 e1 04 ee ..6....*....U...
0x000160: 7e 1e 5e 28 ad 61 bb 18 4c 83 09 3a ac 51 61 34 ~.^(.a..L..:.Qa4
Ganz cool! Kannst du die Packet Data spezifischen Sachen vom welle-rtk Ordner in das ‘backend’ zügeln? Das wäre auch für andere Anwendungen noch praktisch.
Es ist alles im git tree - Coding style ist schon anders als das welle.io zeugs - Mit tabs und so - Ausserdem hab ich das ganze eher als superkleine header only Classes gebaut die man als Pipeline aneinanderreihen kann so das man je nach MSC config da unterschiedliche pipelines mit und ohne FEC, mit oder ohne Address Demux oder DataGroup aggregation machen kann.
Bin da noch nicht so zufrieden und meine C++ skills reichen da auch nicht. Ich würde es gerne als:
bauen. Das geht gerade wegen des Polymorphismus nicht so wie ich das verstanden habe. Es funktioniert - Ich befürchte es lauern noch so 5-droelf mem leaks trotz der shared_ptr<> nutzung.
Ach ja - und ich mag das irgendwie nicht im Hot-Path mallocs oder große constructors zu haben. Schön wäre für das DABPkt ein slab allocator in den die resused objects zurück gehen so das man nicht immer auf dem Heap rumbastelt. Und es gibt garantiert noch Bugs für Data Packets > 24 byte (Es sind ja auch 48 und 96 byte möglich).
Und im code sind überall noch FIXME - Error handling - was macht man mit kaputten paketen - grundsätzlich will ich die den stack hoch reichen mit dem marker das die halt kaputt sind. Dann kann der nächste halt sich überlegen das Frame zusammenzubauen und als “Hier ist eine Lücke” oder “Hier sind uncorrectable errors drin” markiert …
Keine Sorge, mach weiter solange du Lust hast. Mein Ziel ist einfach, dass deine Arbeit nicht irgendwie in deinem Fork aus Sicht des welle.io Projektes verloren geht, nur weil wir nie die Änderung ins Upstream genommen haben.
Ein Gedanke der mir noch kam, weil einige hier auf eine vollständige Implementierung auf embedded Ebene schielen: Es gibt mit rtl433 ja ein (zugegeben sehr viel einfacheres) Projekt, was 0815 Funkthermometer etc. auslesen kann. Dafür gibt es auch für den ESP32 Portierungen, etwa beim OpenMQTTGateway für RF.
Klar ein ganz anderer Grad an Komplexität, aber mal als Gedanken, dass nicht immer unbedingt ein Smartphone oder RPI / SBC dafür notwendig sein müsste
So - ein kleines Update - An dem welle.io/RTL-SDR zeugs hab ich nichts gemacht. Dafür habe ich mir mal das ganze günstige DAB(+) zeugs angesehen das es auf eBay und Amazon hinterher geschmissen gibt.
Das ganze basiert (Die beiden die ich habe) jeweils auf dem wRadio C100 Chipset der angeblich nur unter Android läuft. Ich vermute das wRadio nur ein China Clone von irgendeinem Hersteller ist. Aber ich habs nichts finden können zu dem Vendor noch zu dem Chipset. Alles sehr seltsam.
Der erste Versuch war das APK auseinanderzunehmen und mit Ghidra da mal rein zu sehen - Aaaber - Das ist a) Alles c++ und b) alles mit Java JNI dynamic callbacks. Da ist nicht viel zu sehen. Und so sehr bin ich auch nicht im Android Dynamic Call Debugging mir Frida und co.
Ich habe das ganze mir daraufhin einfach mal in einen Android Emulator gepackt und das dingen via USB reingeschliffen und dann aussen auf dem Host mitgesniffed. Nachdem ich dann die initialisierungsequenzen für das Chipset hatte habe ich nach denen mal gegoogelt und bin auf ein “omri-usb” Repository gestoßen. (https://github.com/hradio/omri-usb.git)
Das ganze enthält code das exakt so aussieht wie es sollte.
Also hab ich das ganze mal vergewaltigt - alles was Java/JNI ist rausgeworfen, noch ein paar C++ Classes hin gefakted für das USB Interface und mal großflächig code disabled der für irgendwelche Applikationsnotifications gebraucht wird.
Dann fehlte noch ein bisschen code um responses auf setRegister zu lesen und nach nur 2-3 tagen code prügeln baut es und es läuft. D.h. aus dem dingen kommen die Pakete für den Subchannel 32 raus - natürlich ohne FEC und krams - da muss man sich dann wieder selber drum kümmern - aber da habe ich ja schon code, bzw auch im OMRI-USB steckt schon fec code - da muss ich mir jetzt mal ansehen.
Und wie man sieht braucht das nur 50mA d.h. 240mW - Das ist natürlich eine andere Hausnummer als ein RTL-SDR der wenn er denn läuft bei mir 1.5W braucht und natürlich auch entsprechend die CPU Leistung das zu dekodieren.
Also ich denke man kriegt für ~20€ einen DAB+ USB Stick um an die PPP-RTK-AdV daten zu kommen. Aufwand auf dem Host ist überschaubar. Ich vermute mit der code-base wird das nichts auf einem ESP32 weil das doch einiges an Templating etc ist.
Das ganze ist eh im moment ein riesengroßer Hack auf einer Code-Base die aussieht wie halb-reverse engineered und ein paar Datenblätter gehabt.
es ist erfreulich zu sehen, dass das Interesse am PPP-RTK-Satellitenpositionierungsdienst SAPOS® | GEPOS™ weiterhin hoch ist.
Unser Vorschlag zum persönlichen Austausch scheint auf Zustimmung zu stoßen. Daher bieten wir allen Interessierten an,
am Dienstag, 06.05.2025 von 16 bis 17 Uhr
an einem Online-Info-Meeting teilzunehmen (Zugang unten).
Wir werden u.a. erklären, was PPP-RTK vom “klassischen” SAPOS® unterscheidet, wie der Dienst praktisch funktioniert und worin die Herausforderungen beim DAB+ - Korrekturdatenstrom bestehen.
Unterstützt werden wir von Kollegen der Firmen Geo++ Gmbh und RFmondial GmbH.
Also - wer Interesse und ein Stündchen Zeit hat ist herzlich eingeladen!
Mit Meeting-Kennnummer beitreten
Meeting-Kennnummer (Zugriffscode): 2792 695 6045
Meeting Passwort: MpPmKfmX332 (67765369 beim Einwählen von einem Telefon)
Hier tippen, um mit Mobilgerät beizutreten (nur für Teilnehmer) +49-619-6781-9736,27926956045#67765369# Germany Toll
Auf manchen Mobilgeräten müssen die Teilnehmer ein numerisches Passwort eingeben.
Kleines Statusupdate zum SSRoverDAB+ - Ich bin soweit das ich mit den wRadio C100 USB Empfängern alles empfange, entsprechend FEC (Forward Error Correction) mache und dann die RTCM Frames an einen local laufenden NTRIPCaster schicke. Das sind natürlich nur RTCM Frames mit Message 4090 - also Geo++ SSRZ. Das RTCM ist ja auch nur Transport Encapsulation. Die CRC24q am ende validiere ich.
Für die NTRIP variante hab ich mich entschieden weil das so die logische Schnittstelle für das ganze Thema ist. Also sollte im Rover z.b. ein RPi laufen kann man sich überlegen den NTRIP Caster auch von extern erreichbar zu machen, oder eben lokal zu arbeiten. Das NTRIP ist im moment noch ein riesen hack - hat auch einen Bug den man unten sieht. Da kommt noch ein crlf vom NTRIP Server zum NTRIP Client durch. Hätte ja gedacht das der NTRIPCaster validiert das da nur RTCM frames durchgehen. Naja.
Den kann man dann mit den klassischen tools aus dem RTKLib befragen.
flo@p5:~/projects/sapos-dab/wradio-c100/wradio-c100$ str2str -in ntrip://flo:flo@localhost:2101/ZZ-DAB-SSRZ -out file://dab.rtcm
stream server start
2025/05/06 18:38:36 [WC---] 0 B 0 bps (0) localhost
2025/05/06 18:38:41 [CC---] 2 B 0 bps (0) localhost/ZZ-DAB-SSRZ
2025/05/06 18:38:46 [CC---] 60 B 0 bps (0) localhost/ZZ-DAB-SSRZ
2025/05/06 18:38:51 [CC---] 118 B 231 bps (0) localhost/ZZ-DAB-SSRZ
2025/05/06 18:38:56 [CC---] 177 B 235 bps (0) localhost/ZZ-DAB-SSRZ
2025/05/06 18:39:01 [CC---] 177 B 0 bps (0) localhost/ZZ-DAB-SSRZ
2025/05/06 18:39:06 [CC---] 6219 B 7268 bps (0) localhost/ZZ-DAB-SSRZ
2025/05/06 18:39:11 [CC---] 6275 B 223 bps (0) localhost/ZZ-DAB-SSRZ
2025/05/06 18:39:16 [CC---] 6333 B 231 bps (0) localhost/ZZ-DAB-SSRZ
2025/05/06 18:39:21 [CC---] 6391 B 231 bps (0) localhost/ZZ-DAB-SSRZ
2025/05/06 18:39:26 [CC---] 6449 B 0 bps (0) localhost/ZZ-DAB-SSRZ
2025/05/06 18:39:31 [CC---] 6449 B 0 bps (0) localhost/ZZ-DAB-SSRZ
2025/05/06 18:39:36 [CC---] 12501 B 9238 bps (0) localhost/ZZ-DAB-SSRZ
Die harten Nüsse kommen jetzt ja erst. Vermutlich bleibt als einzige veritable Lösung das ssr2obs der Geo++. Dekodiert wird man SSRZ ja noch bekommen. Damit hab ich aber ja nur eine State Space Representation in memory. Also die kriegt man zusammengepuzzelt vermutlich.
Aus dem SSR dann aber ein entsprechendes NTRIP interface zu bauen das für die NMEA $GGA zeilen entsprechend RTCM Frames returned mit einer Observation bzw den entsprechenden MSM4/MSM7 messages für Galileo, GPS, Glonass - aeh ja - also da fehlen mir von dem 1000 Teile Puzzle noch 995.
Die Daten sind korrekt dekodiert. In Deinem Binärdatensatz sind genau 92 ungenutzte Byte und 70718 Bytes RTCM3/SSRZ-Daten drin.
P.S. Ich will Euch nicht den Spaß verderben, aber aus SSRZ eine Positionslösung zu berechnen ist nicht trivial. Die SSRZ Python Demo hilft dabei nur marginal. Das ist im wesentlichen ein Datenformatdekoder, welcher die enthaltenen Werte ausgibt. Das ist aber leider nur der allererste Schritt…
P.P.S. Die Entwicklung von rtklib lebt unter einem Fork neu auf: RTKLibExplorer Wenn sich hier jemand findet die PPP-Lösung auf SSRZ zu erweitern wäre das natürlich toll. Nur da muss man schon viel Ahnung von GNSS und PPP haben.
Da müssen noch fehler/kaputte pakete drin sein. Hab danach noch fehler im FEC/CRC zeugs gefunden. Vielleicht sind die auch im RTCM layer entschwunden.
Aber ja - mühsam ernährt sich das Eichhörnchen. Ich kriege mittlerweile den Pi5 + uBlox X20 + DAB Receiver in eine kleine Schachtel. 2 Antennen dran und eigentlich wäre das schön wenn das einfach funktionieren würde.
Es hilft ja nichts. Es wird nicht vom Himmel fallen, und keine der Firmen hat ein interesse daran eine Lösung zu bauen die open source ist und “einfach funktioniert” - Wohlmöglich als erweiterung zu RTKLib. Das wird sich vielleicht mit RTCM-SSR ändern und deren weiteren verbreitung - aber das kann ja noch 10-15 Jahre dauern. Das ist die zeit die RASANT ausgestrahlt wurde. Das BKG hat ja im Videocall deutlich gemacht das sie sich mehr Adoption vom DAB korrekturstream wünschen, und der auch gekommen ist zu bleiben. Tja - dann muss irgendwer mal eine OpenSource/Free Software Lösung bauen. Und die fängt irgendwann halt auch mit einem
int main(int argv, char **arvgc) {}
an. Ich denke auch das ICH das nicht alleine hinkriege. Ich bin der Hardware bitfummler und ich habe FEC verstanden und kann die DAB Hardware malträtieren und kriege da RTCM/SSR frames raus. Ich hab auch keinen stress damit den Parser aus dem Python Demo in c++ zu übersetzen so das wir saubere klassen und epoch handling haben, und dann wirds halt fies. Das ist dann so wie ich die Paper gelesen habe was für einige Dr. der Mathematik. Ich befürchte da werde ich sehr langsam werden. Ob meine Frustrationstoleranz da reicht?
Das nutze ich schon an anderer Stelle. Ich benutze ja mein DAB Receiver der als NTRIPServer den kram an den Caster schickt und mit str2str dumpe ich mir den stream dann. Nur SSR krams gibts da noch gar nicht so wie ich das sehe.
Ich denke das man Algorithmisch für die verschiedenen SSR implementierungen durchaus wiederverwendungsmöglichkeiten hat. In Japan scheint das ja alles schon lange genutzt zu werden - So hab ich einiges zu CLAS und compact SSR gefunden.
Und solange es halt nix in open source gibt muss ich halt gucken das ich das für meinen rover anwendungsfall mit dem ssr2obs binary hinbekommen so das meine Mapillary Bilder nicht “all over the place” sind.
Aber irgendwer muss halt den ersten schritt machen und ein code framework hinstellen an dem man weiterbauen kann.
Das Problem ist ja nur das das die Nische in der Nische ist und daher die Anzahl der Menschen die das verstehen und bock auf open source haben eher ziemlich überschaubar ist.
Mit fehlt auch gerade irgendwo die community. Wäre ja schön mehr GNSS/SSR/RTK-PPP leute zusammenzukriegen. Werde ja nicht der einzige sein der sich die Zähne ausbeist.
Vielleicht ein wenig zum Hintergrund. Die Firma in der ich arbeite, die Alberding GmbH, war am Forschungsvorhaben zur ersten Umsetzung der SSR-Verteilung über DAB+ der Konsortialführer SSRoverDAB+ Wir sind darin interessiert, dass das Verfahren genutzt wird (natürlich um Geld daran zu verdienen). Eine Open-Lösung würde helfen die Akzeptanz zu erhöhen, das liegt also im Interesse der Firma.
Da müssen noch fehler/kaputte pakete drin sein.
Ich habe es nicht geprüft, aber ich glaube die 92 defekten Bytes waren ein halbiertes Paket am Ende. Der Rest war ok. Eins der Softwarepakete die wir entwickeln ist ein Datenformatanalysator namens InspectRTCM
Bis zu einem gewissen Grad kann ich also gern helfen, wenn Du Daten analysiert haben willst oder Fragen hast. Melde Dich gerne per E-Mail bei mir. Wobei meine Expertise im Wesentlichen bei den Datenformaten, der Kommunikation und dem Drumherum endet. Für die Berechnungsalgorithmen habe ich nicht genug freie Zeit. Eine PPP/RTK-Lösung könnte ich z.B. nicht entwickeln, obwohl ich (ist schließlich mein Beruf) schon etwas mehr darüber weiß, als nur die Grundlagen
Eine PPP/RTK-Community wird schwer. Hier denke ich das eher Diplomarbeiten (Bachelor/Master/wasauchimmer) ein Weg vorwärts sein könnten.
Aktuell ist ssr2obs von Geo++ ein Weg die Daten zu nutzen. Ich denke in der Videokonferenz sollte etwas darüber gesagt worden sein wie/ob die Software verfügbar ist.
Name der Firma und die ganzen Präsentationen habe ich gelesen.
Jau - Hab da auch angefragt nach Binarys für Linux x86 und arm für den RPi5 - Also jeweils Debian/Bookworm x86_64 und Raspbian/arm - Für Android und Windows gibts ja was. Hab aber bisher nur die Antwort das sie mal reingucken.
Ich befürchte das da viel aufwand reingesteckt das inklusive GUI ans laufen zu bringen - dabei würde ja ein simpler command line client/daemon reichen - RTCM rein/RTCM raus müsste das ja sein.
So wie ich das verstehe müssten ja da auf der einen Seite die SSRZ frames rein - vermutlich via RTCM/NTRIP - Das braucht dann eben mal 30-45 Sekunden um den internen Space State aufzubauen - sobald der da ist dann auf der anderen seite NTRIPServer bzw Mischung aus Server und Caster - weil ich ja den NMEA input für die position brauche den der NTRIP client im HTTP header mit schickt um dann entsprechende virtuelle observations zu erzeugen und dem rover/client via RTCM zu füttern. Zumindest so weit mein Verständnis. Also SSRZ rein - GPS NMEA auf client seite rein und dann u.a. synthetische MSM7 für GPS, Gallileo, Glonass via RTCM auf client seite wieder raus. So mein laienhaftes Verständnis was noch sehr sparse ist.
Ich bin gespannt. Ich werde sicher jetzt am Wochenende auf dem FossGIS Hackwochenende in Essen mich mal an das dekodieren der SSRZ Pakete begeben. Bisschen c++ stubs zusammenschustern.
Ich versuche mich von vorne durch das problem langsam durchzufräsen. Es sind nur bits und bytes. Famous last words.
Mein Ziel ist einfach, dass deine Arbeit nicht irgendwie in deinem Fork aus Sicht des 
