Két évtizeddel ezelőtt, a digitális televíziótechnika fejlesztésének folyamatában készült egy mérés-technikai útmutató is, amit röviden TR 290-nek nevezünk. A kezdeti időszakban ez nagyon hasznos volt, mivel ez alapján terveztük az áramköröket, ebben volt leírva, hogy hány szinkron hiba után kell újbóli szinkron keresést indítani, stb.

A mai világban aki nem rendelkezik alaposabb szakismerettel, e szabványra hivatkozik, az ennek való megfelelőséget igényli, e mögé bújva rejti tájékozatlanságát.

Mivel tudjuk, hogy e szabvány nevének említése nélkül a termékek eladhatatlanok, cikkükben a szabvány sorait elemezve világítjuk meg a mögöttes tartalmat.

Az említett szabvány három csoportba sorolva javasolja a DVB rendszer jellemzőinek vizsgálatát. Az első csoportban (First priority 1.1 – 1.6) vannak a legfontosabb, folyamatosan vizsgálandó jellemzők. A második csoportban (Second priority 2.1 - 2.6) vannak a folyamatos vagy periodikus ellenőrzésre javasolt jellemzők. A harmadik csoportba (Third priority 3.1 – 3.10) kerültek az alkalmazástól függően vizsgálandó jellemzők. E három csoport nevét érdemes megjegyezni, mert alapszintű ismeretnek számít. A következőkben a szabvány számozását követve elemezzük a jellemzőket.

1.1 TS synchron loss

A régmúlt LVDS majd ASI átvitellel dolgozó világban e jellemzőnek nagy szerepe volt, de IP átvitelt használva már elő sem fordulhat. Készülékeink áramköreiben e hiba szintén nem fordulhat elő, azaz e jellemző nem számszerűsíthető, ezért a PST összesítő lapján sárga figyelemfelhívó jelzést helyezünk el, ha CC vagy TEI hiba van a TS-ben. Ezzel kívánjuk jelezni, hogy hiba lehet a korábbi jelfeldolgozó egységek valamelyikénél.

1.2 Synchron byte error

Üzemszerű működés esetén ma már elő nem fordulhat, hogy a 0x47 helyett más értékű bájt érkezzen. Példaként mindenki tudja, hogy az UDP csomag tartalmának első bájtja egy szinkron bájt, amely soha nem kerül felhasználásra, mivel az adatfeldolgozó áramkörök a 2. bájttól kezdve dolgozzák fel az adatokat. Mivel úgy kell tennünk, mintha a szabványhoz igazodva működnénk, e helyen sárga jelzést adunk, ha TEI hiba van a TS-ben.

1.3 PAT error

Üzemszerű működés elképzelhetetlen PAT nélkül, azért piros jelzést adunk, ha nincs PAT, ha kódolt, vagy az ismétlődési idő nagyobb, mint 500 ms. Ezek mellett az idegen tábla jelenlétét is jelezzük. Üzemszerű működés esetére nem jellemző hiba, e pont inkább csak útmutató a fejlesztők részére.

1.4 Continuity Counter error

A legfontosabb vizsgálandó jellemző, napjainkban ezt kellene kiemelten az első helyre tenni. Mi piros jelzést adunk, ha egyetlen CC hibát is találunk valamelyik PID értéken. A szoftverünk azzal segíti a hibakeresést, hogy a hibák száma mellett azt is jelezzük, hogy hány PID értékeken volt a hiba. A CC hibák PID érték szerinti eloszlása csak a jegyzőkönyvből olvasható ki, az összesítőben ez nem jelenik meg.

1.5 PMT error

A PAT-hoz hasonló vizsgálatot kell lefolytatni valamennyi PMT PID-en. Az összesítő azt is jelzi, hogy melyik PMT-n talált hibát.

1.6 PID error

A szabvány szerint jelezni kell, ha valamelyik PID érték nem tűnik fel az üzemeltető által megadott időn belül. Mi akkor adunk hibajelzést, ha a PMT-kben megadott PID-ek egyike nem jelenik meg a vizsgálati idő intervallunban.

2.1 Transport error vagy TEI hiba

A TEI hiba a második legfontosabb hiba. A nagyfrekvenciás demodulárorok 1-re állítják a Transport Error Indicator bitet, ha a hibajavító áramkörük nem tudta az összes hibát kijavítani. Ezt észlelve szoftverünk piros jelzést ad és jelzi, hogy hány összetevőben talált ilyen hibát. Ne feledjük, hogy a nagyfrekvenciás vevőkészülékek konfigurálásánál ezt a hibajelzést mindig be kell kapcsolni !

2.2 CRC error

Nagyon ritkán, csak hibás készülékekből származó adatfolyamoknál előforduló hiba. Mi is pirossal jelezzük, ha valamelyik táblánál CRC hibát találunk. Mintavételesen ellenőrzött jellemző.

2.3 PCR error

Széles körben vitatott, a szabványban többször módosított határértékű jellemző.

Szoftverünk sárga jelzést ad, ha az ismétlődési idő nagyobb, mint 40 ms és pirosat, ha nagyobb, mint 100 ms. Mintavételesen ellenőrzött jellemző, mivel a PCR vizsgálata komoly erőforrást igényel.

2.4 PCR accuracy error

Szoftverünk – igazodva a technika fejlődéséhez – IP átvitel esetén a gépkönyvben részletezett módon módosítja a ±500 ns-os határértéket és e szerint adja jelzéseit.

2.5 PTS error

Nagy számításigénye miatt nem vizsgált jellemző.

2.6 CAT error

A PAT-tal azonos módon vizsgált tábla. Mivel jelenléte nem kötelező, hiányát csak szürke színnel jelezzük.

3.1 NIT error

Szoftverünk a NIT-actual és a NIT-other táblákat is részletesen elemzi (lásd pdf), azonban az összesítőbe csak a NIT-actual jellemzőit vonjuk be.

3.2 SI repetition error

E jellemző hatása minimális a szolgáltatás minőségére, inkább tervezési útmutatónak számít. A hibákat az előírásokhoz igazodva jelezzük.

3.3 Buffer error

E jellemző jelentősége mára lecsökkent, tervezési útmutatónak tekinthető. Nagy erőforrásigénye miatt nem mérjük.

3.4 Unreferenced PID

A szolgáltatás minőségét nem befolyásoló jellemző, szoftverünk jelzi, ha az adatfolyamban feleslegesnek vélt PID-et talál.

3.5 SDT error

Többször módosított jellemző. Szoftverünk az SDT-actual és az SDT-other táblákat is részletesen elemzi (lásd pdf), azonban az összesítőbe csak a SDT-actual jellemzőit vonjuk be.

3.6 EIT error

Nagyon bonyolult és összetett jellemző, a szabvány inkább tervezési útmutatónak, mint folyamatosan vizsgált jellemzőnek tekinthető. Szoftverünk egyszerűsített módon vizsgálja ezt a jellemzőt.

3.7 RST error

Szoftverünk előírásszerűen vizsgálja e jellemzőt, de ilyen táblával még sohasem találkoztunk. Hiányát szürke színnel jelezzük.

3.9 Empty buffer error

Nem fontos jellemző, vizsgálata nagy erőforrás-igényű, szoftverünk nem vizsgálja.

3.10 Data delay error

Nem fontos jellemző, vizsgálata nagy erőforrás-igényű, szoftverünk nem vizsgálja.

Javasoljuk, hogy aki más cégek szoftvereit vizsgálja tegyen kísérletet a fentiekhez hasonló, a kijelzések (OK – not OK) mögött meghúzódó vizsgálatok és döntési feltételek megszerzésére.

A befejezés első lépéseként a záró felvételen látható a szoftverünk által készített összefoglaló. A befejezés második lépéseként a szabvány védelmében megemlítjük, hogy a szabvány 174 oldalán mindezek után igen fontos képletek és útmutatások találhatók, de ezek feldolgozása komoly szakismeretet igényel.

Majernik Zoltán   

A teljes újság letölthető innen...