[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


Max,

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, ...

Dave

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 
>>>time
>>>signal is rather immoral when TV transmitters (and radio too, remember 
>>>RDS)
>>>pump out many megawatts of signal each day (globally).
>>
>>/////////////////////////////////////////////////
>>Immoral?  That's a bit strong, innit?  You don't NEED to rely on 
>>satellites for
>>time signals.  There are many LF radio time signals, such as WWV, WWVB, 
>>WWVH,
>>CHU, MSF, DCF77, and others.  CDMA cell phone towers broadcast a time 
>>signal. 
> 
> 
> 




More information about the questions mailing list