[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