[SBE] OK - Ohh great and wise minds

[William Whitt]

Very thorough, and quite eye opening. I have a Tanberg on my Fiber that
frequently throws fits for us. I've have audio drops and so on. This
equipment is maintained by our fiber provider, and it's given them a lot of
gray hair. I may have to tell them about this.

 

As far as the explanation of PCR - thanks - I don't analyze ASI as often as
I should to keep myself sharp on the details. I get caught up in so many
other things . well you the picture.  I take it the PCR specs are in the
white paper? I only have time enough to briefly write this note and get to
another meeting.

 

Thanks again for your response!!!!

 

Bill

 

From: sbe-bounces at sbe.org [mailto:sbe-bounces at sbe.org] On Behalf Of Gary
O'Guinn
Sent: Wednesday, July 15, 2009 10:24 AM
To: sbe member discussion mail list
Subject: Re: [SBE] OK - Ohh great and wise minds

 

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=360
65957
<http://www.broadcastpapers.com/whitepapers/PixelmetrixPCRJitter.pdf?CFID=36
065957&CFTOKEN=ab9aed43745f836f-7F558EDC-B9A5-A400-A19D92D320293AAE>
&CFTOKEN=ab9aed43745f836f-7F558EDC-B9A5-A400-A19D92D320293AAE

In short the Program Clock Reference 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

Checked by AVG - www.avg.com
Version: 8.5.375 / Virus Database: 270.13.15/2239 - Release Date: 07/15/09
06:07:00

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://seven.pairlist.net/pipermail/sbe/attachments/20090715/9ed09a24/attachment.html>