[SBE] OK - Ohh great and wise minds

[Mike Armatta]

We have 4 paths to our transmitter. 3 are SMPTE310 via microwave and a 
fiber path. The fiber path is converted to ASI in the flexicoder, run 
thorough an AT&T 270MB digital video link and reconverted to SMPTE310 at 
the transmitter by a Tandberg TT6120. The jitter on the fiber is about 3 
times what it is on any of the microwave paths. We see this jitter on 
the ASI output of the fiber receiver as well.

All are well within specs so we haven't looked much further.

Mike Armatta
KTRK Houston

Gary O'Guinn wrote:

> Hi William:

>

> Tektronix has a really good White Paper on PCR jitter that explains 

> what PCR is and the effect of PCR jitter. Here is a link to a paper 

> (not the one from Tektronix) on PCR Jitter. 

> http://www.broadcastpapers.com/whitepapers/PixelmetrixPCRJitter.pdf?CFID=36065957&CFTOKEN=ab9aed43745f836f-7F558EDC-B9A5-A400-A19D92D320293AAE

>

> In short the *P*rogram *C*lock *R*eference signal is the "master" data 

> clock for the MPEG packets. When the packets are created a PCR signal 

> is included in the header. This contains a time when the packet was 

> created (similar to time code in an analog frame). Since the data is 

> transmitted asynchronously the receiver has to have some method of 

> re-clocking the packets to it knows where the beginning of a packet 

> is. The PCR provides this clock reference to the receiver. It is 

> similar to Horizontal and Vertical Sync signals in a analog video 

> frame. The need for re-stamping occurs when the packets are messed 

> with. Such as if two data streams are multiplexed together. Since 

> there are time delays associated with multiplexing, the MUX generates 

> a new PCR and re-stamps it into the packet header. This is supposed to 

> guarantee packet synchronization for the decoder. Since the 

> transmitter's modulator is the last device in the broadcast chain, it 

> needs to re-clock the MPEG stream (because of the 8VSB specification) 

> since it has manipulated the stream it needs to re time stamp the PCR.

>

> PCR jitter can be a major factor. If the jitter is too severe the 

> clock reference cannot be obtained by the decoder and thus no packets 

> will be decoded properly. You probably should measure PCR jitter at 

> the transmitter site. We transmit the data to our transmitter site via 

> microwave: as an ASI stream. At the transmitter we trans code ASI to 

> SMPTE-310 for the 8VSB modulator; with a Tandberg device. We noticed 

> that with the Tandberg transcoder we have out of spec PCR jitter. We 

> suspect the microwave gear is causing the jitter. We had to remove the 

> Tandberg and are now using a K-Tech transcoder. The K-Tech seems to be 

> more forgiving and the PCR jitter is within specification using the 

> K-Tech. The Tandberg device is working properly, and I don't know why 

> it is less stable at the transmitter than the K-Tech.

>

> Also check the PSIP Tables for proper timings. We use a Sencore 

> Investigator and we also noticed that the PSIP tables were not being 

> updated quite fast enough. So I changed the encoder settings slightly 

> to increase the PSIP table update times to make sure they were being 

> updated more frequently in order to maintain ATSC specs.

>

> I hope this was what you were looking for.

> Gary O'Guinn

> KTUU-TV

>

> William Whitt wrote:

>>

>> I have a couple of questions – What is the point of PCR re-stamping? 

>> If I was told I can’t remember.

>>

>> I have a digital transmitter that we use as a STL/intercity relay – 

>> Digital CH23. On the mountain top I have a Drake unit that converts 

>> CH 23 to an ASI stream that I feed to my Full Power transmitter on a 

>> different channel. I feed my STL/intercity relay with a steady stream 

>> at 19.392Mbs from my multiplexer.

>>

>> At least once a month I lose my PSIP data on some manufactures 

>> digital convertor boxes. I also get weird video and audio issues … I 

>> go up to the mountain top, reset the Drake(unplug and plug back in) 

>> and poof everything is back in order.

>>

>> Well – I thought there may be a problem with the STL/intercity relay, 

>> maybe it was causing a drift by doing something to my ASI stream that 

>> eventually screws up the Drake on the mountain. I called the 

>> manufacture and they said – the only thing that might cause that is 

>> if the PCR re-stamping was turned on … ???

>>

>> I drilled into the menu of the modulator on my transmitter and sure 

>> enough the PCR re-stamping was selected. Would that cause this issue? 

>> It also had “Del Null Padding” which by its default was disabled. I 

>> left that one alone.

>>

>> Any ideas? Or is this a direct result of the digital world, and I’m 

>> going to have to come up with some kind of remote reset for the Drake?

>>

>> Thanks in advance,

>>

>> Bill

>>

>> ------------------------------------------------------------------------

>>

>> _______________________________________________

>> The SBE Roundtable, SBE at sbe.org

>> To unsubscribe, go to http://seven.pairlist.net/mailman/options/sbe

>>

>> http://seven.pairlist.net/mailman/listinfo/sbe

> ------------------------------------------------------------------------

>

> _______________________________________________

> The SBE Roundtable, SBE at sbe.org

> To unsubscribe, go to http://seven.pairlist.net/mailman/options/sbe

>

> http://seven.pairlist.net/mailman/listinfo/sbe