Hallo Leute,
es gibt viel Lektüre über RDS. Ich tue mich aber ziemlich schwer, etwas für mich passendes zu finden. Ich hab den Dekoder angezapft und bekomme kleine Datenpakete geliefert. Die kann ich einsammeln. Aber wie und in welcher Reihenfolge man die dann verarbeitet, ist schwer zu finden. Jedenfalls ist nach dem Ablegeen im Speicher kein Muster erkennbar. Obwohl sich das ja ständig wiederholen müsste. Weiß da jemand was?
MfG hjs
Am 09.10.2024 um 11:59 schrieb Hans-Juergen Schneider:
Selber nie etwas damit gemacht, aber vielleicht hilft das hier:
Domnule Mihailescu belieben sich zu verzetteln. Er hat genauso im Trüben gefischt, wie ich das wohl machen muss. Aber irgendwo sollte doch geschrieben stehen, nach welcher Ordnung diese ganzen Bits dort gepurzelt kommen.
MfG hjs
Für Gnu Radio gibt es auch einen RDS-Decoder, eventuell hilft der etwas?
Hallo!
Am 09.10.2024 um 11:59 schrieb Hans-Juergen Schneider:
Ähm, da suche ich gelegentlich auch noch nach. Modernere Chip-Radios wie der RDA5807 tun die Rohdaten Vorverarbeiten.Bei den Rohdaten handelt es sich um ein Rahmen von 104bit, bestehend aus
4 Blöcken zu 16Bit + 10Bit Prüfbits. Die ganzen Prüfbits werden heute in solchen Chipradios intern verarbeitet und bieten extern nur die Nutzdaten an.Also immer vier Blöcke (16Bit)
Ein anderes Bit irgendwo im Statusbyte gibt an. ob die aktuellen vier Blöcke die Blöcke A, B, C, oder D sind, oder um es sich um einen Block E handelt. Und genau da wird es dann mürbe: Standardblöcke A, B, C und D haben definierte Bedeutungen. So enthält Block A immer die PI, während im Block B GT/GTA, TP-Kennung und PTY stecken. Blöcke C&D haben eine Bedeutung die von der GT/GTA-Nummer im Block B abhängen. Ein Block E ist eine andere Geschichte zu der ich noch nix fand. Block E umfasst einen ganzen Rahmen, also 64Bit.
Wenn du allerdings den rohen Datenstrom aus einem alten Tuner vom MPX-Signal ziehst, hast du noch die Prüfbits mit drin, also 26Bit je Block. Nach vier Blöcken zu dann 104 Bit müsstest du eine Wiederholung sehen, da Block A bei einem Sender immer identisch ist (PI).
Jürgen Hüser
Der sieht zumindest erstmal plausibel aus.
Eine wichtige Information ist: es steht an jedem Datagramm ein Typ dran, der bestimmt, wie weiter dekodiert wird:
group_type = ((group[1] >> 12) & 0xf);
Pro Datagramm bekommt man dann auch nur eine bestimmte Menge Bits. Bei bestimmten Informationen muss man halt eine Weile warten, bis man alle Teile hat. Da gibt's dann auch keine bestimmte Reihenfolge. Und wenn der Vogelschwarm vorm Fenster ungünstig kam, fehlt halt auch mal ein Datagramm in der Mitte, und dann muss man auf die nächste Runde warten.
Stefan
Ja, erstmal klein anfangen. Also: Ich taste group A ab und weiß nicht einmal, wie ich das einordnen soll. Es sollten acht Zeichen im UTF-8 kommen. Das wären dann 16 Bytes, die in Telgrammeen von jeweils zwei Bytes enthalten sind. Da wird es wohl kein start und kein stop geben, weil die durchaus ungordnet eintreffen könnten. Die sind vermutlich nummeriert. Aber wie das gemacht ist, lässt sich nicht ergründen.
MfG hjs
Irgendwie müsssen die jeweils (durchaus ungordnet) eintreffenden Doppelbytes ja nummeriert sein.
Muss mich da mal durchwursteln. 608 Zeilen sind 'ne Hausnummer.
MfG hjs
Ich meine in der Elrad gab es mal einen ausführlichen Artikel wie man das ganze decodiert - aus der Erinnerung ein ziemliches Bit-geschubse. Ich habe mir damals - Anfang 90er? - nach der Anleitung ein Layout für den Decoder am Atari Druckerport gemacht und konnte damit den Text darstellen. Vielleicht hat ja jemand Archiv-Zugriff auf den Artikel? Für 24 Euro kann man die kompletten Ausgaben auf USB-Stick kaufen.
Gerald
Ich hätte die beiden Artikel aus den Heften 1 und 2 1992, versende sie aber nur privat, es sei denn Heise stellt sie selbst öffentlich.
Aber ich bin doch gar kein Spammer.
MfG hjs
Have something to add? Share your thoughts — no account required.
Ask the community — no account required