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.