[opendtv] Re: XDS and ATSC

  • From: John Willkie <johnwillkie@xxxxxxxxxxxxx>
  • To: opendtv@xxxxxxxxxxxxx
  • Date: Mon, 21 May 2007 17:18:48 -0400 (EDT)

One can do all sorts of things with time that are outside A/65. and indeed one 
seems to answer your need for accurate time. I think that DVB-SI TDT (time and 
date table) is a component of UpdateTV over ATSC networks.  The tdt just gives 
the date and time: no conversion.

I've come up with this strange kind of timing hybrid: ATSC_seconds for values 
greater than one second, and a 27mhz/90khz clock for sub-second values.  It's 
still a bit dicey where they overlap, but I'll get it right, I figure.

As for the prize money, not particularly close.  There are all sorts of ways to 
violate A/65.  I was addressing what's inside A/65 -- having lived with the 
document for 6 years now -- not what's outside it.  How about sending a TDT and 
a SCTE-54 STT?

The lagest STT-related fine I've seen was for the ABC o&o (WPVI) in 
Philadelphia:  their time didn't vary over several months or years.  Just 
stayed the same; I can't remember if it was zero, or a higher value.

John Willkie


-----Original Message-----
>From: Kon Wilms <kon@xxxxxxxxxxxx>
>Sent: May 21, 2007 5:03 PM
>To: opendtv@xxxxxxxxxxxxx
>Subject: [opendtv] Re: XDS and ATSC
>
>On 5/21/07, John Willkie <johnwillkie@xxxxxxxxxxxxx> wrote:
>> BTW, stattions get fined for not having accurate time in their STT.  ATSC 
>> A/65 requires an accuracy within one second.  I should also note that time 
>> of day from the phone company is not an accurate time reference: it can be 
>> up to 10 seconds off, in my experience.  I've checked hundreds, if not 
>> thousands of times.
>
>I remember back to iBlast days where every station in LA we tested had
>bogus STT. The station blamed the manufacturer who blamed us,
>eventually resulting in one of those 'see here, here is your packet,
>and your time is always midnight' pie-in-the-face responses.
>
>For datacasting clock sync between transmission and local PC time is
>required so that a socket can be opened at the correct time to receive
>content (depending on how the system works, usually the end PC is
>offset from UTC and the clock modified by the receiver application). I
>ended up writing an app that pulled NTP time from nist and converted
>it to a multicast stream. So much for relying on STT. In fact we still
>use such a system for datacasting since when you're jumping over
>disparate networks it is easier to forward a PID or IP multicast
>stream than it is to do time conversion all over the place. What a
>joke that was...
>
>BTW you are aware our multiplexer can restamp STT using an add-in GPS
>module? Does that get me the $100? Maybe $50 for effort? (make check
>payable to Steve Jones) :-)
>
>Cheers
>Kon
> 
> 
>----------------------------------------------------------------------
>You can UNSUBSCRIBE from the OpenDTV list in two ways:
>
>- Using the UNSUBSCRIBE command in your user configuration settings at 
>FreeLists.org 
>
>- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word 
>unsubscribe in the subject line.
>

 
 
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:

- Using the UNSUBSCRIBE command in your user configuration settings at 
FreeLists.org 

- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word 
unsubscribe in the subject line.

Other related posts: