[ntp:questions] NTP over DRM: http://hireme.geek.nz/NTP.html .2
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
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
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
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.
Cheerio! Kr. Bonne.
More information about the questions