[ntp:questions] Re: Clock accuracy & auto setting : digital television does a crap job of providing time services...
user at domain.invalid
user at domain.invalid
Wed May 3 19:32:12 UTC 2006
Have you seen the white paper "The NTP Era and Era Numbering" on the NTP
project page at www.ntp.org http://www.eecis.udel.edu/~mills/y2k.html?
It includes a 128-bit date format, which has enough seconds bits to
measure the age of the Universe until the Sun grows dim and enough
fraction bits to measure the time a photon crosses an atomic nucleus.
The mapping to and from this format and NTP timestamps is transparent,
even when the NTP era rolls in 2036, 2172, ...
Max Power wrote:
> In North America, the FM RDS time service is of very low quality.
> In Europe (I understand) this is not the case with RDS.
> Stations running RDS should be mandated by law to provide a quality
> service -- based on transmitter power and coverage area.
> Over time RDS's time service should be uniform.
> DRM (on MW and SW) time service is of a lower quality than RDS -- but could
> be upgraded with a specialized "80 bit" NTP-UNIX time packet.
> ATSC and DVB-T (& DVB-H/M) need a uniform ~"80 bit"...~"128 bit" time packet
> service that is well thought out.
> Futureproofing is important, so probably 128 bits or more is preferable.
> LF time services are OK, and are necessary over large transnational
> regions -- like Sub Saharan Africa, Australasia and South America ... but
> any new LF service needs to be more technologically advanced than WWVB, MSF
> or DCF77 and its Swiss twin. In these regions 10 LF frequencies need to be
> allocated, but the signal to be transmitted needs to be more modern than
> WWVB or DCF77 -- maybe using some form of low complexity PSK or low
> complexity QAM and 240 hz to 480 hz of bandwidth. The signal must be
> futureproofed -- as above.
> I wish I had all of the email addresses of the Canadian National Research
> Council -- so that I could email them my CHU upgrade proposal at
> * http://CBC.am/CHU.htm
> * This proposal probably, if implemented -- would require a signal upgrade
> to account for 2 transmitters on all of the frequencies used.
> * A properly designed signal upgrade could make CHU a more powerful
> [technological design] than WWV[H] -- but this would probably require 2 or 3
> years of experimentation. I would love to see support for high speed ECC
> polytone and MD63 (MD?) with its Walsh coding.
>>>>ATSC time is always late ?
>>>ATSC and DVB-T (DVB in general) are devoid of a 64 bit (or 80 bit) clock
>>>packet (based on NTP and 'Unix Time').
>>>For people to be forced to rely upon GNSS (Glonass, GPS, Galileo) for a
>>>signal is rather immoral when TV transmitters (and radio too, remember
>>>pump out many megawatts of signal each day (globally).
>>Immoral? That's a bit strong, innit? You don't NEED to rely on
>>time signals. There are many LF radio time signals, such as WWV, WWVB,
>>CHU, MSF, DCF77, and others. CDMA cell phone towers broadcast a time
More information about the questions