Tim, I've spoken to NPR staff about this problem. They distribute programs to affiliates via satellite and use NTP to synchronize the station clocks. However, and you will like this, the digital link uses raw IP and stuffs the compressed program in the IP payload. I don't know if PBS video uses this scheme, but I suspect they do, as you might note their network programs start within milliseconds of UTC.
NASA has the same problem for planetary/spacecraft time synchronization, but their FEC/interleave codes are constant-length. However, the links can have highly asymmetric delays. Experiments with a Earth-Moon-Earth simulation quickly turned up the need to raise the synchronization metric threshold to allow for the 2.3-s roundtrip delay. I'm sorking to improve the audio drivers, partially to help the CHU staff in arguing for continued support. The WWV driver is now good enough to track ionospheric layer height variatioins generally within 400 microseconds. The IRIG driver on a FreeBSD Pentium is within a few microseconds relative to PPS from a GPS receiver. I'm still messing with the CHU driver and expect it to perform similar to WWV. However, the performance of serial drivers and audio codecs on a Solaris SPARC is absolutely miserable - 5/10 ms at best. Dave [EMAIL PROTECTED] wrote: > Max Power wrote: > >>http://www.cl.cam.ac.uk/~mgk25/time/lf-clocks/ >>The Digital Radio Mondiale standard for long/medium/short-wave digital audio >>broadcasts (freely available for downloading as ETSI TS 101980) includes >>time data, but like with RDS and DVB, the data format specification is not >>really optimized towards high-precision clock synchronization and the DRM >>COFDM demodulator needed is significantly more complex than the AM receivers >>that decode the time signals listed above. >> >>It is a shame that the NTP.org has not set up a working group to define >>packet formats for RDS / DVB / DRM / AMSS. > > > Digital broadcasting and studio->transmitter links, in general, present > problems for time synchronization. > > All of the digital links have some amount of delay in the > encoding/decoding process, the delay depending on details of error > correction and the amount buffered up. > > There is a delay between studio and transmitter (now almost always a > digital link esp in urban areas) and the HDTV and digital radio > standards also introduce a delay. > > The studio->transmitter delay is somewhat under control of the station > engineering, but even then they usually do not account for the delay in > their broadcasts. > > The digital transmitter->home/car receiver has other issues because > different brands and models of receivers have different delays. > > We have WWV and CHU decoders already in NTP and they're really very > good. > > Tim. > _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
