Radio Data System

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von RDS CT)
RDS-Logo

Das Radio Data System (RDS; englisch, wörtlich übersetzt Radiodatensystem) ermöglicht die Übermittlung von digitalen Zusatzinformationen beim analogen UKW-Rundfunk. Die amerikanische Version ist das Radio Broadcast Data System (RBDS).

Geschichte

Das Institut für Rundfunktechnik (IRT) war im Rahmen der Arbeiten der Europäischen Rundfunkunion (EBU) an der Entwicklung des Radio Data Systems (RDS) maßgebend beteiligt. Erste Ausstrahlungsversuche fanden 1983 über UKW-Sender des Bayerischen Rundfunks statt. Dessen Technischer Direktor, Frank Müller-Römer, unterstützte die Systementwicklung und die Ausstrahlungsversuche maßgeblich. Der RDS-Versuchsbetrieb wurde ab 1984 aufgenommen, offizielle Einführung war der 1. April 1988.

Das Radiodatensystem ist in der DIN EN 62106 standardisiert. Aktuell gültige Version ist die EN 62106:2010-07 (dt. Version), welche die Version von 2002 ersetzt.[1] Seit 1993 pflegt das RDS-Forum (Genf) die RDS-Standards, unabhängig von der EBU.[2]

Das erste Autoradio mit RDS war das im Volvo 760 gegen Aufpreis erhältliche Volvo-Radio vom Typ SR-701. Die RDS-Erkennung wurde anfangs hauptsächlich in Autoradios verwendet, da es durch die Übertragung der Alternativfrequenzen (alternative frequencies) möglich ist, ohne Benutzereingriff automatisch die Frequenz zu wechseln und somit einem einmal eingestellten Programm zu folgen. Dies erspart das manuelle Suchen nach der neuen Frequenz, wenn das Fahrzeug auf der Fahrt den Sendebereich eines Senders verlässt. Das RDS-Signal wird in der Regel spezifisch für jeden Senderstandort erzeugt, meistens direkt am Sender.

Das RDS-Forum hat am 9. Juni 2015 an seiner jährlichen Sitzung in Glion beschlossen, den neuen Standard RDS2 auf dem Weg zu bringen. Der Standard wird in enger Zusammenarbeit mit den US-Kollegen von NRSC RBDS Subcommittee erstellt und soll eine einheitliche Plattform für FM-Rundfunk und weltweite Datendienste bieten. RDS2 wurde 2017 als IEC 62106 Edition 4 als neuer Standard eingereicht.

Datei:Rds2 1.png
RDS2 Logo

Unter RDS wird nun das Protokoll von 1984 bis 2016 verstanden. RDS und RDS2 werden die neuen Versionen genannt, wobei RDS der rückwärtskompatible Teil mit den üblichen 1187,5 Bit pro Sekunde ist und mit konventionellen Empfängern funktioniert. RDS2 benötigt neue Chips bzw. Chipsätze und hat eine Datenrate von bis zu 4750 Bit pro Sekunde.

Neue Struktur des IEC 62106 Edition 4 2017

RADIO DATA SYSTEM (RDS)–VHF/FM SOUND BROADCASTING IN THE FREQUENCY RANGE FROM 64,0 MHz TO 108,0 MHz

  • Part 1: RDS system: Modulation characteristics and baseband coding
  • Part 2: RDS message format, coding and definition of RDS features
  • Part 3: Coding and registration of Open Data Applications ODAs
  • Part 4: Registered code tables
  • Part 5: Marking of RDS and RDS2 devices
  • Part 6: Compilation of technical specifications for Open Data Applications in the public domain
  • Part 7: RBDS
  • Part 8: Universal Encoder Communication Protocol UECP

Anmerkung zu

  • P7: RBDS wird nur die Differenzen zwischen RDS und RBDS beschreiben. Es geht vor allem um die PI-Code Generierung.
  • P8: UECP war früher ein eigener Standard, nun ist es mit erfasst von IEC 62106. RDS2 startet mit Version 8.0

Versionen bis 7.x bleiben gültig für den alten bzw. 1 Träger RDS. (57kHz – Stream 0))

Dienste des RDS

Die Dienste des RDS sind bestimmte Arten von Daten, die gesendet und entsprechend der Datenart von den Radioempfangsgeräten ausgewertet werden. Bei der Sendung der Daten in Sendeblöcken (s. u. für das Format) wird der Dienst teilweise durch den Gruppentyp ("group type", GT) definiert. Hierbei stehen 16 Gruppentypen in je zwei Versionen, A und B, also insgesamt 32, zur Verfügung.[3]

RDS bietet neben den verbreitet genutzten Funktionen für Programmkennung, Verkehrsfunk und Alternativfrequenzen weitere Möglichkeiten für Zusatzinformationen und -Dienste, die aber von den Sendern nur vereinzelt genutzt und von vielen Geräten nur teilweise unterstützt werden.

Programme Service Name

Programme Service Name (PS, GT 0A/0B) ist der wohl bekannteste Dienst im RDS. Er ermöglicht die Übertragung des Sendernamens in bis zu acht alphanumerischen Zeichen. Ältere Autoradios konnten nur Großbuchstaben und Ziffern sowie eingeschränkt Sonderzeichen darstellen, wodurch manchmal wenig Spielraum für sinnvollen PS-Text bestand. Neuere RDS-Empfänger, allen voran radiotexttaugliche Geräte, müssen umfangreiche Code-Tabellen beinhalten, u. a. den lateinischen Standardschriftsatz und weitere europäische Sonderzeichen (siehe DIN EN 62106).

In jüngerer Zeit ist es in Mode gekommen, durch wechselnde PS-Anzeigen einen längeren Sendernamen, Zusatzinformationen wie den aktuell gespielten Musiktitel oder gar Werbung zu übertragen. Diese Anwendung verstößt jedoch gegen die RDS-Spezifikation und behindert oftmals die Senderspeicherverwaltung in den Autoradios, worauf manche Radio-Hersteller versuchen, mit intelligenter Software den Programmnamen herauszufiltern, um somit den Nutzen des PS wiederzuerlangen.

Long Programme Service Name

Long Programme Service Name (LPS, GT 15A) ist die neue Version des PS mit Berücksichtigung beliebiger Zeichensätze durch UTF-8-Kodierung. Obwohl im ASCII-Zeichensatz alle 32 Bytes nutzbar wären, beschränkt man sich auf maximal 16 Zeichen in der Anzeige. Europäische Umlaute benötigen in der Regel 2 Bytes, so kann man beliebige Namen richtig anzeigen. Chinesisch, Arabisch, Koreanisch und alles, was mit UTF-8 darstellbar ist, kann gesendet werden. RDS2 setzt generell auf UTF-8, lediglich aus Kompatibilitätsgründen wird im 2A-/2B-Radiotext und im 0A-/0B-PS-Namen der originale EBU-Zeichensatz verwendet. Dieser ist jedoch nicht mehr uneingeschränkt kompatibel zum DAB-/DAB+-Zeichensatz, seit 2016 im DAB-Standard Änderungen vorgenommen wurden.

Programme Type

Programme Type (PTY, in allen ausgestrahlten GT) bezeichnet die Einteilung der Sender nach Sparten, zum Beispiel Pop-Musik, Nachrichten, Klassik oder Jazz. Die PTY-Auswahl gehört zu den Standardfunktionen üblicher RDS-Empfänger. PTY kann auch während des Programms umgeschaltet werden, sodass z. B. eine Pop-Welle während der Nachrichten "Nachrichten" als PTY überträgt und danach wieder "Pop".

PTY-31

PTY-31 (GT 9A) bietet (theoretisch) eine automatische Ein- und Umschaltlösung für Notfall- und Katastrophenmeldungen. Das PTY-31-Signal besitzt höchste Priorität und die RDS-Empfänger schalten automatisch den "warnenden" Rundfunksender ein. In neueren Empfängern wird PTY-31 jedoch teilweise nicht mehr implementiert, da es zumindest in Europa nie oder nur missbräuchlich genutzt wurde. Die öffentlich-rechtliche Sendeanstalt Italiens RAI sprach diesbezüglich einige Verwarnungen gegen Privatsender wegen „Station Kidnapping“ aus. Die verwarnten Radiosender hatten Radiogeräte zwangsweise mittels des PTY-31-Signals auf ihr Programm umgeschaltet. Diese Umschaltung kann vom Hörer nicht mehr rückgängig gemacht werden, es sei denn, er verlässt den Empfangsbereich des (illegalen) Rundfunksenders.

Traffic Programme

Ein Traffic-Programme-Signal (TP, in allen ausgestrahlten GT) wird gesendet, wenn ein Sender den sogenannten Verkehrsfunk anbietet, das heißt, wenn Informationen über Staus und Gefahren durch ein spezielles Signal angekündigt werden. Die TP-Kennung existiert seit Anbeginn von RDS und hat die bisherige ARI-Funktion zum 1. April 2005 vollständig ersetzt, welche aus Kompatibilitätsgründen für nicht-RDS-fähige Empfänger bis dahin parallel ausgestrahlt worden war.

Traffic Announcement

Falls TP aktiviert ist, bewirkt ein Traffic Announcement (deutsch: Verkehrsdurchsage, abgekürzt (TA, GT 0A/0B, auch 14B, 15B)) für die Zeit der Durchsage beispielsweise eine Erhöhung der Lautstärke (geräteabhängig) oder den Wechsel der Wiedergabe von CD zum Radio und danach wieder zurück.

Enhanced Other Networks

Enhanced Other Networks (EON, GT 14A, 14B) ermöglicht den Empfang von Verkehrsfunk (TA), auch wenn der gewählte Sender kein eigenes TA-Programm anbietet. Diese Funktion wird maßgeblich von den öffentlich-rechtlichen Hörfunksendern genutzt, die damit zum Beispiel Hörern der Kulturwellen (zum Beispiel MDR Figaro) die Verkehrsnachrichten der Pop- und Jugendwellen (beispielsweise MDR Jump) zugänglich machen. Deutschlandradio Kultur nutzt EON, um auf regionalen bzw. bundeslandspezifischen Verkehrsfunk (etwa von MDR Sachsen) zu verweisen.

Wird vom Verkehrsfunksender eine Verkehrsnachricht ausgesendet, wird dies über RDS-Gruppe 14 signalisiert, was den EON-Empfänger veranlasst, für die Dauer dieser Verkehrsnachricht auf das andere Programm mit der Nachricht umzuschalten (typischerweise aus derselben Senderfamilie) und nach der Nachricht wieder zurück auf das TP-lose Ausgangsprogramm. Mit der Signalisierung einer Durchsage werden sogleich einige linkbezogene Informationen mit ausgestrahlt, wie z. B. PI des betreffenden Verkehrsfunksenders, sowie mögliche Frequenzen (AFs) zur schnellen Abstimmung des EON-Empfängers.

EON ist theoretisch auch dafür geeignet, für andere Programmtypen (PTY) wie etwa Nachrichten auf einen verbundenen Sender umzuschalten, wenn dort eine Sendung mit dem betreffenden PTY beginnt. Diese Funktion wird aber von den Sendern und Empfängern nicht genutzt.

Falls EON unterstützt wird, findet sich zumeist ein EON-Symbol auf der Gerätefront. RDS2 : EON unterstützt unter RDS2 9-bit AF

Traffic Message Channel

Der Traffic Message Channel (TMC, GT 8A) enthält kodierte Verkehrsmeldungen, die von einem Navigationssystem angezeigt und direkt zur Routenplanung genutzt werden können. Im fremdsprachigen Ausland kann der Empfänger daraus Meldungen in der eigenen Sprache generieren. TMC wurde als ODA (Open Data Application) realisiert und wird von TISA gepflegt. Das bedeutet, TMC könnte unter einer beliebigen Gruppe laufen. Aus Kompatibilitätsgründen wird er aber weiterhin unter 8A ausgestrahlt.

Alternative Frequency

Die Funktion Alternative Frequency (AF, GT 0A/0B) ermöglicht das automatische Wechseln der Empfangsfrequenz beim Verlassen des Empfangsbereiches eines Senders. In der AF-Tabelle im RDS werden ständig Alternativfrequenzen umliegender Sender ausgestrahlt, die ebenfalls das eingestellte Programm übertragen. Im Normalfall sollte der Empfänger laufend die Qualität des empfangenen Signals überprüfen und gegebenenfalls auf eine andere in der AF-Tabelle angegebene Frequenz wechseln. Der Wechsel ist nur dann erfolgreich, wenn auch der Programme-Identification-Code (PI, s. u.) übereinstimmt. So vermeidet man, dass ein Radio auf eine Frequenz wechselt, die an diesem Punkt von einem anderen Programm belegt ist.

9-bit AF

RDS2 unterstützt Trägerfrequenzen von 64 MHz bis 108 MHz. Damit reichen die 8 bit AF nicht mehr aus. Als System-ODA wurde die 9-bit AF (Sys-ODA) eingeführt. Beschrieben wird sie unter IEC 62106-6 Annex D

Program Identification

Der Program-Identification-Code (PI, in allen ausgestrahlten GT) ist ein senderinterner Identifikationscode, der unter anderem bei der Suche nach AFs (Alternativfrequenzen) eingesetzt wird. Er besteht aus einer 16-Bit-Zahl, die eine eindeutige Kennung des Senders ermöglicht. In der vierstelligen Identifikationsnummer sind ein Ländercode enthalten, eine Regionskennung (Reg-Bit) sowie eine der Senderkette zugehörige, individuelle Nummerierung.

Extended Country Code

Die PI-Codes sind nicht eindeutig. Bereits in Europa kann es vorkommen, dass sie mehrfach verwendet werden.

Beispiel: Deutschland, Serbien und Libyen beginnen alle mit hex "D".

Der Extended Country Code (ECC) mit dem CI-Code zusammen bezeichnet das Land eindeutig. Einige Länder, wie USA oder China haben mehrere ECC+CI-Kombinationen. Benutzt wird er hauptsächlich für TMC (Location Code Tables) und RadioDNS.

Radio Text

Radio Text (RT, GT 2A, 2B) übermittelt Zusatzinformationen, wie den aktuellen Musiktitel und Interpreten oder Kontaktdaten des Senders. Die Textübertragung erfolgt zeilenweise, eine Zeile enthält maximal 64 Zeichen. Bei den meisten Autoradios wird jedoch aus Sicherheitsgründen bewusst auf diese Funktion verzichtet, um nicht die Aufmerksamkeit des Fahrers auf den eingeblendeten Text zu lenken. In der aktuellen RDS-Spezifikation EN 62106 wurde nun auch Radiotext bzw. Radiotext plus (RT+) integriert. Parallel dazu mehren sich nun auch die Implementierungen, u. a. sogar bereits bei "Original-Radios" (sogenannte OEMs), die in moderneren Fahrzeugen fest integriert sind.

Enhanced Radio Text

Enhanced Radio Text (eRT, GT = ODA) übermittelt Zusatzinformationen ähnlich wie Radiotext. Die Textübertragung erfolgt zeilenweise, eine Zeile enthält maximal 128 Bytes, aber maximal 64 Zeichen. Die Kodierung erfolgt wahlweise in UCS-2 oder UTF-8, somit sind alle Zeichen weltweit abgedeckt, inklusive chinesische, japanische, arabische etc. Die Schreibrichtung (z. B. Arabisch r-l – Latein l-r) wird in der Übertragung signalisiert. Moderne Autoradios können zwischen RT und eRT umschalten, die Übertragung der beiden Radiotexte darf aber nicht parallel erfolgen. In der aktuellen RDS-Spezifikation EN 62106 wurden nun auch Radiotext und Radiotext plus (RT+) integriert, der je nach Implementation auch auf eRT angewendet werden kann.

Music/Speech

Mit Music/Speech (MS, GT 0A/0B, 15B) wird in einem Bit zwischen Musik- und Sprachübertragung unterschieden, so dass ein Radio beispielsweise zwischen zwei Klangprofilen umschalten kann.

Clock Time

Das Clock-Time-Signal (CT, GT 4A) dient der Zeitsynchronisation. Wenn das Signal ausgestrahlt wird, können Ungenauigkeiten der Uhr im Empfänger mit diesem Signal korrigiert werden. Diese Funktion wird vor allem von den öffentlich-rechtlichen Sendern verwendet.

Open Data Applications

Open Data Applications (ODA, GT 5A,6A,7A,8A,9A,11A,12A,13A + 1B,3B,4B,5B,6B,7B,8B,9B,10B,11B,12B,13B) wurde eingeführt, um das RDS System einfach erweiterbar zu machen und somit schnell zusätzliche Datendienste implementieren zu können, ohne den Standard explizit dafür anpassen zu müssen. Beispiele für ODAs sind (neben dem oben erwähnten TMC) die Übertragung von DGPS-Korrekturdaten; RT+ (Radiotext plus), eine maschinenlesbare Weiterentwicklung des Radiotext; oder "iTunes-Tagging", das eine Identifizierung eines gesendeten Musikstücks im iTunes Music Store ermöglicht (derzeit nur HD Radio).[4]

Weitere 64 ODA Kanäle bietet RDS2 auf drei höheren Trägern. Diese werden mit C-type Gruppen verwendet.

Technische Grundlagen RDS

[[Hilfe:Cache|Fehler beim Thumbnail-Erstellen]]:
RDS-Dekoder-iC von Sanyo

Die Datenbits werden mit einer Datenrate von 1187,5 Bit pro Sekunde übertragen. Als Modulationsverfahren wird ein digitales Zweiseitenbandverfahren (2-PSK) eingesetzt, wobei als Träger der um 90° gedrehte ARI-Pilotton von 57 kHz verwendet wird. Durch die 90°-Phasendrehung sind das ARI-Signal und das RDS-Signal unabhängig voneinander zu empfangen, da diese beiden Signale orthogonal zueinander stehen. Zusätzlich wird der Träger unterdrückt. Träger und Übertragungsrate stehen in der Beziehung: Trägerfrequenz (57 kHz) / 48. Voraussetzung für den unabhängigen Empfang ist die kohärente Demodulation. Die dazu notwendige Phaseninformation wird aus der Phasenlage des Stereo-Pilottons mit 19 kHz (⅓ der RDS-Trägerfrequenz) im Empfänger abgeleitet.

Technische Grundlagen RDS2

RDS2 kennt bis zu drei weitere Träger auf den Frequenzen 66,5 kHz, 71,25 kHz und 76 kHz.

[[Hilfe:Cache|Fehler beim Thumbnail-Erstellen]]:
UKW-Basisbandsignal mit RDS2 Trägerfrequenzen

Modulation und Übertragungsraten sind identisch für alle Streams. Die Gruppen sind auf allen vier Trägern synchron zueinander.

Bei RDS bilden je 26 Bits einen Block, der wiederum aus 16 Datenbits und 10 Prüfbits besteht. Hier kommt ein linearer Code zur Anwendung, der einen minimalen Hamming-Abstand von 5 besitzt, das heißt, es lassen sich zwei zufällige Fehler innerhalb eines Blocks korrigieren. Der Code ist so ausgelegt, dass sich bis zu elf weitere Fehler korrigieren lassen, wenn sie als Bündelstörung, also direkt nebeneinander, vorliegen. Mit Hilfe der Prüfbits können auch die Blockgrenzen und die Art des Blocks detektiert werden. Jeweils vier Blöcke (ABCD bzw. ABC'D) bilden eine RDS-Gruppe. RDS2 C-type Gruppen kennen nur ABCD Blöcke.

Wichtig ist noch die Synchronisation der Blöcke. Datenübertragungen werden normalerweise immer mit Hilfe eines speziellen Datenworts, welches eine hohe Erkennungswahrscheinlichkeit in einem verrauschten Signal hat, synchronisiert. Dieses Verfahren kann aber hier nicht angewendet werden, da ein kontinuierlicher Datenstrom vorliegt. Dazu wird ein anderes Verfahren genutzt: Betrachtet man das oben angegebene Fehlerkorrekturverfahren genauer, stellt man fest, dass es neben den angegebenen Fehlerkorrekturen noch weitere Fehlermöglichkeiten gibt, die nicht zur Anwendung kommen können, da sie in kein Schema passen. Aus diesen nicht nutzbaren Fehlerworten werden 5 ausgewählt und den Blöcken zugeordnet. Blöcke sind A, B, C, D und C'. Diese Fehler werden entsprechend den Blöcken auf der Sendeseite hinzugefügt. Da die Art der Fehler auf der Empfängerseite erkannt werden kann, sucht ein Empfänger nach diesen Fehlern. Können 3 Fehler in der richtigen Gruppenreihenfolge erkannt werden, geht man von einer richtigen Synchronisation aus und kann danach die Daten auswerten. Es sind allerdings noch auf der Empfängerseite entsprechende Strategien für positiven und negativen Bitschlupf zu entwickeln.

Datei:RDS de Gruppe Bloecke.svg
Eine RDS-Gruppe aus vier Blöcken

Die Spezifikationen findet man in der DIN-Norm DIN EN 62106.[5]

In Block A wird immer die 16-Bit-Sender-ID (Programme Identification, PI) übertragen. In Block B findet man den Programmtyp (PTY), einen Indikator für Verkehrsfunk (TP) und die RDS-Gruppennummer (Group Type GT). Diese gibt Auskunft über die Verwendung der restlichen fünf Bits des Blocks B und der 32 Bits von Block C und D. Es existiert eine Reihe von RDS-Gruppen, die für verschiedene zusätzliche Datendienste verwendet werden, zum Beispiel Gruppe 11A (siehe Beispielbitmuster) oder Gruppe 3A für Open Data Applications (ODA).

Beispielbitmuster für die Gruppe 11A

RDS2 C-Type Gruppen tragen keinen PI-Code. Sie bestehen aus 1 Byte Header und 7 Byte Data. Ist der Header 0x0000, sind die restlichen 7 bit A- oder B-Type Gruppen (Tunnelling), der PI-Code dazu wird aus Stream-0 entnommen.

RDS2 C-Type Gruppe; 1 Byte Header- 7 Bytes Daten

Steuerung der RDS-Aussendung

Solange sich die Benutzung von RDS weitgehend auf die Übermittlung statischer Daten wie TP/TA beziehungsweise AF beschränkt, ist eine Steuerung über akustische Signale (Töne, etwa Hinz-Triller) möglich. Dafür wurde von der deutschen Telekom das Verfahren „Steuerung des RDS/VRF-Systems mittels Hinz-Triller“ mit dem Schreiben FTZ 175 AB 33 vorgegeben. Es waren nur wenige Geräte zur Steuerung zugelassen (unter anderem Rudolph HT090). Sollen darüber hinaus weitere Dienste genutzt werden, ist eine Übermittlung auf anderen Wegen an den RDS-Encoder erforderlich (etwa eine separate Datenleitung). Ein geeignetes Verfahren ist unter UECP zu finden.

Externe RDS-Decoder

Prinzipiell kann dem Audio-Signal eines UKW-Radios die RDS-Information entnommen werden. Allerdings werden bei vielen Geräten, die nur für den Monobetrieb ausgelegt sind, mit einem Tiefpass alle Signale oberhalb des Hörbereichs unterdrückt, weil diese den Tonfrequenzverstärker ungünstig beeinflussen können, sodass am Audioausgang dieser Geräte ein RDS-Decoder nicht funktioniert.

Radiodatensysteme

Das RDS-Verfahren kann in der beschriebenen Form nur für Rundfunk im UKW-Bereich verwendet werden. Durch Phasenmodulation des Trägers können aber auch Rundfunksender im Lang-, Mittel- und Kurzwellenbereich für den Hörer nicht wahrnehmbare Zusatzinformationen übermitteln (Amplitudenmoduliertes Datensystem, AMDS).

Siehe auch

Weblinks

Einzelnachweise

  1. ↑ DIN EN 62106 Berichtigung 1. Website des Beuth Verlags. Abgerufen am 5. Februar 2011.
  2. ↑ RDS-Forum
  3. ↑ RDS groups list (engl.)
  4. ↑ Dietmar Kopitz: Progress on theRadioTextPlus (RT+) implementation. (PDF 491,8 KB) RDS Forum Office, abgerufen am 26. Februar 2011 (englisch).
  5. ↑ DIN EN 62106: Spezifikation des Radio-Daten-Systems (RDS), Deutsche Fassung 2002, Beuth Verlag GmbH, Berlin
Abgerufen von „https://de.wikiup.org/index.php?title=Radio_Data_System&oldid=223632084#Clock_Time“