Előző cikkünkben bemutattuk az új PCR Analyzer modulunkat és általános ismereteket adtunk a PCR mérésével kapcsolatban. Ebben a cikkben azok számára kívánunk további ismereteket adni, akik mélyebben érdeklődnek a téma iránt, és komolyabb szakmai ismereteket kívánnak szerezni.

1. A pontosság kérdése a PCR vizsgálatánál

Az előző cikkben láttuk, hogy például 30 ms-os ismétlődési idő esetén a mérőkészülékbe épített órának 30 000 000 ns elteltét kell jeleznie. A PCR 27 MHz-es vezéroszcillátora a professzionális stúdiókban 1×10-6, azaz 1 ppm körüli pontosságú. A középkategóriás készülékekben, mint például a PST, a 20...50 ppm-nél pontosabb kristályok alkalmazása az ár és a méret miatt nem jöhet szóba. A PST kristálya 25 ppm-es. A fenti 30 ms-os tartománynál maradva könnyen kiszámítható, hogy már 10 ppm eltérés esetén is 300 ns lesz az eltérés a PCR óra és a mi óránk között.

A korábbi MPEG-2 és -4 encodereknél a PCR beültetése egyenletes időközökkel történt, így a fenti hiba korrigálható konstansként jelentkezett, mondhatjuk, észre sem vettük.

Tapasztaltuk, hogy napjaink bonyolult, statisztikus remultiplexerrel vezérelt HD encodereinél a PCR beültetési idő széles tartományban változik. Ennek következtében a korábbi konstans érték hol kisebb, hol nagyobb zavaró értékként jelentkezik a mérésben. Az 1. ábra montirozott képén ezt a jelenséget szemléltetjük.

1. ábra

A változó ismétlődési idő okozta kiugrások a PCR hibák között

A fejlesztés során kiderült, hogy ezt a „PCR álhibát” csak úgy tudjuk korrigálni, ha a mérőmű frekvenciáját nagy pontossággal ráhúzzuk a PCR óragenerátorára. Megoldásként került a kezelőfelületre a 2. ábrán látható, idő kompenzációt kapcsoló elem, amelyet bekapcsolva a PCR adatcsomag első eleménél a szoftver igyekszik nullára csökkenteni ezt a hibát. A korrekció mértéke a grafikonról leolvasható.

2. ábra

Az idő kompenzáció ki- és bekapcsolását biztosító lenyíló lista.

Kapcsoljuk be az időkompenzációt, ha professzionális rendszerekben nagy pontosságú vizsgálatot kívánunk végezni igen kis PCR hibák környezetében.

Kapcsoljuk ki az időkompenzációt, ha nagyok a PCR hibák, mivel a hibás PCR-hez történő kompenzálás hol fel, hol lefelé húzza a rajzolt görbét.

2. Az átlagos PCR hiba

Mint azt előző cikkünkben jeleztük az eredeti PCR-től való eltérés abszolútértéke semmilyen módon nem határozható meg. Annak érdekében, hogy a hibák koordináta rendszerbe rajzolhatók legyenek, elsőként a számtani középértéket kell meghatározni, és ezzel a konstans részt nullára kell csökkenteni. Fejlesztők számára az átlagértékképző modult kikapcsolhatóvá tettük, így a szoftver lehetőséget nyújt a szabályozókörök stabilitásának, lengéseinek stb. vizsgálatára is.

A Time Correction modul bekapcsolása az átlagérték képzést és levonást más úton pótolja, hatása kis PCR hibák esetében azonos.

3. A PCR vizsgálata IP környezetben

Az előző és a mostani cikkünkben is olyan felvételeket mutattunk, amelyeknél a TS packet akadályoztatás, azaz késleltetés nélkül jut a PCR mérő áramkör bemenetére. Az IP átvitel esetében az 1 TS packet/UDP formátum beállításával küldhető a TS packet azonnal a mérő áramkör bemenetére. Fogadjuk el, hogy ilyen esetben a bemutatottakhoz hasonló eredményt kapunk és vizsgáljuk meg a 2 TS packet/UDP formátum esetén előálló helyzetet.

A 3. ábra felül azt szemlélteti, hogy a TS packetek egyenletes ütemben érkeznek az UDP csomagokat előállító modul bemenetére. Az „A” esetben az UDP csomag fejlécének elkészítése után a kettes számú TS packet kerül az UDP fejlécét követő első helyre.

3. ábra

A TS packetek kiküldése az IP hálózatra 2 TS packet/UDP formátum esetén

A PCR adatot hordozó hármas számú packet „jókor” érkezik, mivel annak beültetése után kész az UDP, ami így azonnal kiküldésre kerül. A „B” esetben a PCR-t hordozó hatos packet azonnal beültetésre kerül az UDP-be, de „nincs szerencséje”, mivel az UDP-ben még van egy szabad hely, így meg kell várnia a következő packet beérkezését és csak ezután kerül az IP hálózatra. Könnyen belátható, hogy várakozási, vagy szakszerűbben késleltetési idő éppen 1 TS packet továbbítási idejével azonos. A cikk készítésénél a DVB-T adás 22,4 Mbit/s sebességű adatfolyamát használtuk, így elsőként számítsuk ki azt, hogy ennél mennyi lesz a várakozási idő. A packet idő nagysága:

Tpacket = (188×8) / 22,4×106 = 67,1 μs

Első ránézésre meglepő, hogy a korábban emlegetett 500 ns alatti értékekhez képest ez több mint, két nagyságrenddel nagyobb. Bizonyítsuk elképzelésünk helyességét azzal, hogy megvizsgáljuk a jelenséget a PCR analizátorunkkal is. A kedvezőbb ábraméret érdekében a 4. ábrán a grafikon számunkra érdekes részeit egymás mellé ollóztuk.

4. ábra

A PCR görbe 2 TS packet/UDP formátum esetén

Lehet, hogy többen a késett/nem késett állapotokból két szint megjelenését várták, de mint azt korábban láttuk a hibákat átlagolni kell és így korábban, és később érkezők is lesznek. Az eloszlásfüggvény jól szemlélteti, hogy ebben az esetben a hibák három jellemző érték körül csomósodnak. Mielőtt a cikk olvasását folytatnánk, tegyünk kísérletet a számszerű értékek értelmezésére!

4. A PCR mérő hitelesítése

Egy pillanatra sem térünk el a témától, de a vizsgált jelenség kiváló lehetőséget ad egy másik fontos kérdés, a hitelesítés megvilágítására. A PCR Analyzer modul valójában egy újnak számító jellemző mérőműszere, így nagyon fontos kérdés annak eldöntése, hogy valójában jól mér-e, hiteles-e. Mivel a kérdés eldöntésére kalibráló berendezések nincsenek, különböző módszereket kell kitalálni arra, hogy a fejlesztők munkáját ellenőrizzük. Visszatérve a 4. ábrához, számítsuk ki a min és max értékekből meghatározható késleltetési időt.

Tkésleltetés = 33,21 + 33,72 = 66,93 μs

Az eredmény azt mutatja, hogy a számított és a mért érték a hibahatárokon belül azonos, tehát a PCR analizátor helyes értéket mutat.

5. A 7 TS packet/UDP formátum vizsgálata

Az IP technológia a gazdaságosság érdekében nem az előbb bemutatott, hanem a 7 TS packet/UDP formátumot használja. Az eddigi jelnél maradva átállítottuk a formátumot és az 5. ábrán megmutatjuk olvasóinknak e formátum jellegzetes képét.

5. ábra

A PCR görbe 7 TS packet/UDP formátum esetén

Vegyük észre, hogy az automata 100 μs-ról 400 μs-ra emelte a méréshatárt. A vízszintes tengely felett és alatt megjelenő 6-6 szintet vízszintes vonalak berajzolásával igyekeztünk kiemelni. A közvetlen összehasonlításra a 6. ábra nagyított képe ad lehetőséget.

6. ábra

7 TS packet/UDP görbéje nagyított változatban

6. A null packetek eltávolításának hatása

Az IP átvitelnél az adatmennyiség csökkentése érdekében eltávolítjuk a null packeteket, és csak a hasznos packeteket építjük az UDP-be. Bizonyítás nélkül is belátható, hogy 1 TS packet/UDP formátum esetén a null packetek vagy egyéb packetek eltávolításának nincs hatása a PCR menetére. A szemléletesség érdekében most is a 2 TS packet/UDP formátummal kezdjük a jelenség vizsgálatát. A 3. ábránál arról beszéltünk, hogy a PCR-t tartalmazó TS packetnak időnként várakoznia kell az UDP csomagot lezáró packetre. A null packetek eltávolítása esetén ezt úgy kell módosítani, hogy az is előfordulhat, hogy egynél több packet idejéig kell várakozni a kiküldésre, mivel az időközben érkezett packet null packet volt, és beépítés helyett eltávolításra került. Mint azt már sejtjük is, a várakozási idő egy, vagy több packet idejével történő megnövelése újabb szinteket fog megjeleníteni a PCR görbén (lásd 8. ábra).

8. ábra

A null packetek eltávolításának hatása a PCR hibákra 2 TS packet/UDP formátum esetén

A 8. ábra felvételén nyíllal jelöltük azokat a helyeket, ahol a null packet eltávolítása új szintet jelenített meg a PCR hibagörbéjén. 7 TS packet/UDP formátumnál a 2×6 szint mellett megjelenő új szinteket már nagyon nehéz észrevenni, azért erről nem mutatunk be felvételt. Természetesen egészen más a helyzet, ha egy streamben valamilyen okból nagyon sok null packet van és ezek eltávolítása kiemelkedően nagy szinteket hoz létre.

7. További hatások elemzése

Az eddigi vizsgálatainkban jól reprodukálható, és számítható eseményekkel foglalkoztunk. A befejező részben a véletlenszerű és nehezen számszerűsíthető eseményeket vesszük szemügyre. Induljunk ki abból, hogy visszatérünk az 1 TS packet/UDP formátumú IP átvitelre, és az 500 ns-os tartományban gyönyörködünk a PCR menetében. A Single Application módról az Expert View módra váltva lehetőségünk nyílik arra, hogy a PST IP bemenetére más streamet is bekérjünk. Egy másik készülékből ugyanezt a DVB-T adást bekérve nem látunk változást, mivel szinkronban fut a két csatorna. A T adás helyett egy 38 Mbit/s sebességű műholdas adást bekérve (7TS packet/UDP) azonban a 9. ábra szerinti kép jelenik meg.

9. ábra

Az UDP packetek ütközésének hatása a PCR-re

A megjelenő hibák okát keresve először határozzuk meg a nagyméretű zavaró UDP packet továbbításának idejét a gigabites hálózaton:

TUDP/1G ~ 1400 bájt × 8 bit × 1 ns = 11,2 μs

Vélhetően már magyarázni sem kell, hogy amikor a PCR-t tartalmazó packetünk egy hajszállal később érkezik az IP bemenetre, mint a 11,2 μs továbbítási idejű UDP, akkor a PCR-t tartalmazó packetnek ennyi ideig várakoznia kell a switch-ben. Egyéb ütközéseknél ez a várakozási idő a 0 és a 11,2 μs között bármennyi lehet, tehát nem szintek, hanem mindenféle értékű hibák alakulnak ki. A jobb oldali képen a 100 Mbites switch-csel készített felvétel látható. Itt az értékek tízszereződtek!

Visszatérve a Personal Stream Tool belső felépítésére elmondjuk, hogy a DVB-T vevő, a sat vevő és az ASI bemenet egy 430 Mbit/s sebességű belső buszra dolgoznak. A buszon egyesével kerülnek továbbításra a packetek, így kisebb mértékben, de itt is fellép a packetek ütközése, mint az a 10. ábrán is látható.

10. ábra

A TS packetek ütközése a PST belső buszán

Bízunk benne, hogy cikkünkben sikerült megmutatni, hogy a PCR mérése milyen bonyolult és összetett téma, és sikerült rávilágítani arra, hogy milyen körültekintően kell eljárnia annak, aki megbízható, a valóságot tükröző méréseket kíván végezni.

Zigó József    

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