[ntp:questions] NTP over DRM: http://hireme.geek.nz/NTP.html .2

Kristoff Bonne compaqnet.be at kristoff.bonne
Wed Mar 21 07:48:11 UTC 2007


David L. Mills schreef:
> NPR currently uses NTP to synchronize the local broadcast time to the
> satellite feed. The crucial issue is to encapsulate the compressed audio
> in IP packets, not the other way around. I suspect PBS might do the same
> thing as well, as their programs start time deltas are be in the low
> milliseconds relative to UTC. The DRM page cited is riddled with errors.
> Somebody (me?) should send a comprehensive bug report.

My guess, the problem is that any time-system needs some way to
determine the time-delay between the transmittor and the receiver. Over
a bidirectional IP-network the NTP protocol does work very well, but
over a broadcasting-network -which is unidirectional by nature- it's a
different story.

I see three different possibilities:

- either the delay is known and fixed and configured in the device.

E.g. the satellite link you mentioned, you can messure the delay once
and -except for the variation due to the satellite moving around in its
100x100x200 km box- that would be fixed.

- either you try to calculate it based on the position of the receiver
(how does it know this?) and the transmittor (OK, but what about
transmittors in SFN-configuration?)

- either you ignore this all and live with (say) 10 ms of error.
("if you need greater precision, get yourself a GPS").

Further on, I see two other problems:

- Even if you knew the exact location of the receiver and the
transmittor, you do not always know the exact distance the radio-signal
has traveled.
For groundwave transmissions (e.g. LW and daytime MW), it's pretty easy
to calculate but for multiple hop long-distance SW, the distance the
radio-signal has traveled is much more difficult to predict and will not
be the same for all listeners.

- In the time-broadcasts on LW and SW, there is a link between the
application (the time-information) and the OSI layer 1 characteristics.

"The next minutes begins exactly at the beginning of the first burst".

Using NTP, the time-information is inside an IP-stream which is
encapsulated inside some transport-protocol. There is no direct link
anymore between the layer 7 information (time) and the layer 1 markers.

I don't know about DRM, but for DAB, the time-information as found in
the FIC (i.e. the "system part" of the DAB system) does refer to the
beginning of a the first "symbol" of each DAB-packet. (so it is related
to a OSI layer 1 frame-marker).

To be honest.

The only advantage I see for encapsulating time information inside NTP
for DAB or DRM, is the possibility to "export" it natively on a local
LAN network.

For the rest, as sending time-information is part of the DRM and DAB
specs itself, I do not see any real advantage in using NTP for that.
Just make sure the chipsets support that part of the specs, and that's it.

> Dave
Cheerio! Kr. Bonne.

More information about the questions mailing list