[ntp:questions] DRM: useless for NTP like services...

David L. Mills mills at udel.edu
Thu Jan 4 19:20:47 UTC 2007


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

shoppa at trailing-edge.com 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.
> 




More information about the questions mailing list