Hlavní stránka Nabídka Schémata Software Diskuze Kontakt Zpět   

Vysílání znaků národní abecedy v systému RDS

Tento článek si klade za cíl shrnout všechny významné aspekty vysílání znaků národních abeced v systému RDS (Radio Data System). Pokud se provozovatel vysílání rozhodne zobrazovat v rámci RDS textové zprávy včetně nabodeníček, háčků a čárek, znaky arabské, azbuku, řeckou abecedu a jiné, je to teoreticky možné, prakticky jej však čeká několik velmi nepříjemných omezení a překážek, z nichž některé bohužel nelze nijak obejít.

1. Omezení systému RDS

Konzumní uživatelé se na současných výrobcích spotřební elektroniky obvykle nesetkávají s jakýmkoli významným problémem při zobrazení vícejazyčných textů obsahujících různé znaky národních abeced. Je to především zásluha kódování znaků Unicode. Bohužel systém RDS nezná Unicode, neboť pochází ještě z doby, kdy se používalo výlučně 8bitové kódování, které neumožňuje nadefinovat více než 256 znaků (v praxi o něco méně). Ve snaze přizpůsobit se co nejvíce konkrétní aplikaci provozované v konkrétní oblasti si kdekdo nadefinoval svou vlastní sadu znaků, tzv. kódovou stránku. Těch vzniklo několik desítek (počítáme-li jen ty významné), a převody textů mezi různými kódovými stránkami byly neskutečný opruz a noční můra všech, kteří častěji pracovali s textem.

V systému RDS jsou nadefinovány tři kódové stránky, standardní G0 a dvě doplňkové G1 a G2. V případě, že pro právě vysílaný text platí některá z doplňkových kódových stránek, je nezbytné tuto skutečnost nějakým způsobem indikovat, aby přijímač k zobrazení použil odpovídající znakovou sadu. Dle normy se výběr kódové stránky realizuje prostřednictvím těchto speciálních znaků:

  • 0/15, 0/15 (0x0F, 0x0F): kódová stránka G0
  • 0/14, 0/14 (0x0E, 0x0E): kódová stránka G1
  • 1/11, 6/14 (0x1B, 0x6E): kódová stránka G2

Tyto speciální řídicí znaky jsou vysílány v rámci textu, ač nejsou určeny k přímému zobrazení. Tam, kde v textu potřebujeme přepnout kódovou stránku, se odvysílají výše uvedené speciální znaky. Všechny znaky od této pozice (včetně) potom užívají zvolené kódování.

Text je standardně kódován podle kódové stránky G0, takže při použití pouze této kódové stránky není potřeba speciální znaky přepínající kódování vůbec vysílat. To je ostatně v praxi běžný, a (jak si dále ukážeme) také bohužel jediný možný případ.

e1.gif (49352 bytes)
Standardní kódová stránka RDS (G0).
RDS norma uvádí, že "levné" přijímače mohou být schopné zobrazit pouze zvýrazněné znaky.
To nicméně neznamená, že "drahé" přijímače na tom nutně musí být lépe. Cena v tomto ohledu často nehraje roli.

e2.gif (43972 bytes)
Kódová stránka G1.

e3.gif (44385 bytes)
Kódová stránka G2.

2. Omezení na straně kodérů RDS

Kodéry RDS obvykle nepředstavují omezení v otázce vysílání znaků národních abeced. Na svém ovládacím portu předpokládají některé z běžných 8bitových kódování a vnitřně se provede překódování do kódové stránky RDS, nebo se překódování neprovádí vůbec a kodér tedy pracuje zcela transparentně. Za správný převod znaků je potom zodpovědný ovládací software kodéru běžící na PC. Například v programu Magic RDS lze příslušné nastavení najít v menu Options – Preferences – Local settings. Druhý zmíněný způsob je samozřejmě výhodnější, protože zdrojové texty jsou dnes většinou v kódování Unicode a mohou být do kódové stránky RDS převáděny přímo, bez mezikonverze do jiné 8bitové kódové stránky a tedy bez výpadku znaků, které v této kódové stránce nejsou obsaženy.

RDS kodéry obvykle nemají implementovánu přímou podporu pro přepínání kódových stránek mezi G0, G1 a G2. To lze u některých kodérů RDS obejít tím, že se příslušné speciální znaky vloží jako uživatelsky definovaná skupina *.

Například u RDS kodéru PIRA32 by příslušné konfigurační příkazy vypadaly takto:

UDG1=0000E0CD0E0E
GRPSEQ=X0

s následujícím obsahem na výstupu RDS kodéru **:

rdsspy.gif (27869 bytes)

Jako zajímavost je třeba uvést, že starší verze UECP (Universal Encoder Communication Protocol) obsahovaly příkaz pro přepínání kódových stránek mezi G0, G1 a G2. Ve verzi 7 specifikace tohoto protokolu však byl tento příkaz vypuštěn. V důsledku to neznamená nic jiného než že doplňkové kódové stránky se tímto oficiálně a definitivně odebraly na smetiště dějin. Některé důvody si popíšeme vzápětí.

Poznámky:
* V některých případech může tento způsob použití kolidovat s kódováním AF.
** Obrázek získán z RDS dekodéru RDS Spy.

3. Omezení na straně přijímačů

Spolu s absencí kódování Unicode v systému RDS jsou to samy přijímače, kde spočívá velká část omezení při zobrazení znaků národních abeced. Je bohužel smutnou skutečností, že způsob i kvalita implementace RDS je značně závislá na konkrétním výrobci i typu přijímače. Provozovatel vysílání však nemá jinou možnost než pro všechny vysílat pouze jednu jedinou podobu textu.

3.1 Přijímače se 14segmentovým LCD displejem

Přestože zastoupení přijímačů s tímto typem displeje se postupně snižuje, stále se jedná o velmi častý případ, zejména u stolních přijímačů a autorádií.

14seg.gif (11648 bytes)

Tento typ displeje může zobrazit jen omezený počet znaků ze základního rozsahu. Pro ostatní znaky nastává několik různých situací v závislosti na typu přijímače:

  • Znaky, které nemohou být přímo zobrazeny, jsou uvnitř přijímače převedeny na nejbližší zobrazitelné znaky, pokud je to možné a smysluplné. Text tak obvykle zůstává bez problému čitelný.
  • Znaky, které nemohou být přímo zobrazeny nebo nejsou příliš časté, nemají v přijímači vůbec definovanou svou grafickou podobu, na displeji se tedy zobrazí jen jako prázdná mezera. Text přestává být čitelný.

3.2 Speciální znaky k přepínání kódových stránek nejsou podporovány

Při vysíláni speciálních znaků pro přepínání kódové stránky přijímače reagují různým způsobem, v rozporu s normou RDS. Objevují se tyto problémy:

  • Blikání prvního segmentu textu (segment = 2 znaky u PS, 4 znaky u RT). Problém je způsoben tím, že přijímač chybně interpretuje speciální znaky jako znaky sloužící k přímému zobrazení. Protože těmto znakům není přiřazena žádná grafická podoba, jsou na displeji zobrazeny jako prázdná mezera. Bezprostředně poté jsou přepsány přijatými korektními znaky příslušného segmentu. To se neustále opakuje.
  • Text není vůbec zobrazen. Tento problém souvisí s předchozím. Přijímač čeká na stabilní příjem celého textu, tato situace však nikdy nenastane.
  • Text je zobrazen správně, ale speciální znaky jsou zcela ignorovány, takže text je vždy zobrazen s použitím standardního kódování G0, a to i v tehdy, kdy je použito jiné kódování (G1, G2). V takovém případě je text nečitelný. Toto je vůbec nejčastější případ. Prakticky to znamená, že doplňkové kódové stránky (G1, G2) pro běžné textové funkce RDS nelze vůbec použít. Je možné, že v některých zemích se vyskytují přijímače s podporou těchto kódových stránek, ale na globalizovaném trhu je takový argument beztak irelevantní.

3.3 Chybějící podpora pro standardní kódovou stránku G0

Typický dnešní přijímač je obvykle zařízení kombinované s mnoha dalšími funkcemi. Takové zařízení implementuje běžné kódové stránky pro zobrazení textu, které se samozřejmě odlišují od kódové stránky RDS. Bohužel některé přijímače neprovádějí potřebnou konverzi (edukativní zkratka: výrobce se na to prostě vys*). Výsledkem je, že znaky z dodatečného rozsahu (128-255) jsou zobrazeny ve špatném kódování a tedy nečitelné, stejně jako když si v PC otevřeme textový soubor s odlišným kódováním.

4. Praktický test přijímačů

Pro praktický test bylo vybráno pět různých přijímačů RDS, různého stáří a pro různé cílové skupiny. Jsou to Apple iPod A1320, Sony XR-C6220R, Nokia HS-12W, Panasonic SA-AK320 a Conrad RDS Manager.

Referenční RDS data byla vysílána pomocí kodéru PIRA32 a vf generátoru.

4.1 Test přepínání kódových stránek RDS

V tomto testu bylo PS (Program Service name) vysíláno jako sekvence následujících znaků z dodatečné sady:

0x80 0x81 0xA0 0xA1 0xC0 0xC1 0xE0 0xE1

Této sekvenci znaků vždy předcházela RDS skupina přepínající postupně na kódové stránky G0, G1 a G2.

Očekávaný výsledek:

 G0  aa-e1.gif (1948 bytes)
 G1  aa-e2.gif (1867 bytes)
 G2  aa-e3.gif (1850 bytes)

Výsledek testu:

Přijímač G0 G1 G2 Zobrazení na displeji * Poznámka
iPod Správně Chybně Chybně ipod1.jpg (9520 bytes)  
Sony Správně Chybně Chybně sony1.jpg (23250 bytes) Znaky G0 převedeny na nejbližší zobrazitelné znaky.
Nokia Chybně Chybně Chybně nokia1.jpg (11113 bytes) PS vůbec nenaskočilo.
Jako by stanice nevysílala RDS.
Panasonic Chybně Chybně Chybně panas1.jpg (14105 bytes) Wtf?
Conrad Chybně Chybně Chybně conrad1.jpg (7673 bytes) Národní znaky zobrazeny jako mezera.
V případě vysílání zobrazitelných znaků první dva z nich blikaly.

* Poznámka:
Žádný z testovaných přijímačů nepodporoval doplňkové kódové stránky. Zobrazení proto bylo stejné pro všechna vysílaná kódování.

4.2 Test standardní kódové stránky G0

V tomto testu bylo PS vysíláno jako kombinace základních a dodatečných znaků ve standardním kódování G0. Speciální znaky pro přepínání kódových stránek nebyly vysílány.

Výsledek testu:

Přijímač G0 Zobrazení na displeji Poznámka
iPod Správně ipod2.jpg (9520 bytes)  
Sony Správně sony2.jpg (23250 bytes) Znaky převedeny na nejbližší zobrazitelné znaky.
Nokia Chybně nokia2.jpg (11113 bytes) Přijímač vůbec neprovádí konverzi mezi G0 a vnitřní kódovou stránkou.
Panasonic Chybně panas2.jpg (14105 bytes) Národní znaky zobrazeny jako mezera.
Conrad Chybně conrad2.jpg (7673 bytes) Národní znaky zobrazeny jako mezera.

5. Závěr

Abychom to shrnuli do nějakého praktického závěru, provozovatel vysílání má dnes dvě možnosti:

  • Zachovat vysílaný text v původní ideální podobě, včetně specifických znaků národní abecedy, ovšem s tím, že na velké části přijímačů bude text nečitelný,
  • nebo zachovat přijatelnou čitelnost textu na všech přijímačích, přestože na žádném přijímači nebude zobrazen v původní, ideální podobě.

Pravděpodobně vůbec neexistuje masově dostupný přijímač, který by v otázce kódování znaků zcela odpovídal RDS normě. Nelze přijmout ani platnost předpokladu, že novější přijímače jsou na tom lépe než ty starší.

Doplňkové kódové stránky G1 a G2, přestože jsou definovány RDS normou, nejsou v přijímačích podporovány. Provozovatelé vysílání jsou prakticky omezeni pouze na užívání standardní kódové stránky G0 (což zrovna v našich končinách není problém). V rámci použití této kódové stránky si mohou provozovatelé zajistit vlastní šetření mezi posluchači, zda je smysluplné vysílat znaky z dodatečného rozsahu nebo veškeré znaky konvertovat na znaky základního rozsahu. S ohledem na poměry v ČR bych stanicím orientovaným na mladou generaci doporučil zvážit první variantu, tedy zahrnout háčky a čárky do vysílaných textů. Přijímače používané touto cílovou skupinou jsou dnes až na výjimky schopné tyto znaky korektně zobrazit.

Bude-li snad někdy systém RDS revidován, měla by být přijata taková úprava, která zajistí definitivní vyřešení problému se znaky národních abeced, s ohledem na plnou kompatibilitu se stávajícími i staršími přijímači. Je zjevné, že tomuto požadavku by vyhověla pouze taková úprava, která by umožnila vysílat textové funkce (tedy alespoň PS a RT) dvojím způsobem, jednak v současné podobě a nově v kódování Unicode, patrně v rámci nově přiřazeného typu skupiny nebo jako ODA aplikace. Pro starší nebo jednoduché přijímače by se nic nezměnilo, novým přijímačům by však bylo umožněno zobrazit text v kódování Unicode v případě, že v této podobě je text vysílán.

 

 

 

(C) 1999-2017 Pira.cz