Clock accuracy & auto setting ?

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.

lid wrote:
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, ...

I just started reading that paper, and I've found a bug/typo:

The era number is the integer quotient 2^32 / s and the timstamp is
the integer s mod 2^32.

The first operations should of course be s / 2^32, not the reciprocal!

BTW, it is only when working with unsigned integers that the C standard
guarantees that subtraction of two values will behave as required by
NTP, in your paper you implicitly acknowledge this by stating the need
for twos-complement arithmetic. :-)

It seems to me that for absolute maximum portability, the subtractions
could be done on unsigned values, then the result inspected:

If the high (sign) bit is set, negate the 64-bit result manually (using
twos-complement rules) and remember the sign bit. Next convert the
(small) positive value to double, then re-apply the correct sign bit:

double ntp_diff(uint32_t ah, uint32_t al, uint32_t bh, uint32_t bl)
/* Calculate A-B and return the result as a double: */
{
uint32_t dl, dh;
double d, sign;

dl = al - bl;
dh = ah - bh;
if (dl al) { /* Wrap-around, so borrow: */
dh--;
}

sign = 1.0;
if (dh & 0x80000000) { /* Negative difference? */
sign = -1.0;
/* Negate by inverting all bits... */
dl = ~dl;
dh = ~dh;
/* ... and increment the result, taking care of any carries: */
if (++dl == 0) {
dh++;
if (dh == 0x80000000) { /* Maximal negative value: -2^31 */
return -65536.0*32768.0;
}
}
}
d = (double) dl;
d *= 1.0/(65536.0*65536.0); /* Shift the fractional bits down */
d += (double) dh;

d *= sign;

return d;
}

(I believe that this is probably one of the smaller problems you'd have
if/when porting NTP to something like a 60-bit sign-magnitude machine. :-)

Terje
--
-
"almost all programming can be viewed as an exercise in caching"

On Mon, 01 May 2006 05:42:07 -0700, Max Power wrote:

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.
================================
OK? What other technology can provide such accurate signals at such a low
cost? The simple amplitude modulated nature of the LW signals makes for
such low cost implementations. A PSK or QAM modulation is going to put the
cost of hardware to decode the signal up to much to be useful.

For consumer purposes (save cellular telephony) GNSS technology is too
costly.
NTP is OK for computers, but has a learning curve.

But the consumer does not need any better accuracy than LW, and if they do
then GPS is dirt cheap these days. The point is that the SW signals have
very few users. Consider the number of say CHU users to MSF or DCF77.


I am unaware of WWVB doing this.
If WWVB does this, its signalling must be very quaint.
Typical 1983 signalling medthods (bitfields transmitted) would probably not
pass modern muster.

The point was that the LW signals can provide better accuracy than the
normal AM pulses used.



BCD is the universal flaw of LW time stations.
NTP could fix the problem, but NTP is not perfect for this [without
tweaking].
BCD could be said to use odd signalling in not using {seconds} within a day,
albeit seconds are not suitable for LW signalling rates.

All LW signals implicitly signal the second...

I assume both NTP
and BCD signalling medthods are aimiable to 'bit averaging' for LW time
service's slow signal rate and error correction condtions.

Not really a 64bit signal cannot be transmitted within one minute for
starters. Secondly a NTP style time signal would be overly complicated for
the simple wall clocks to cheaply decode. I just described a simple binary
coded signal with the year/day/time as separate fields with loads of bits
left over for error correction, which could be taken or left depending on
the power of the decoding device. It is good for a 1000 years. What more
do you need?


DRM on MW and SW only sends the Julian date and time.
There is some BCD coding similar to WWVB and DCF77 -- for time and date.
However, there is no [univeral] NTP or UNIX time packet in DRM.

Probably because it is not suitable for simple decoding.

SW signals do cover areas LW cannot reach (like Antartica) -- and with
adiquate frequency diversity provide a higher time resolution vs LW.

If you need something better than LW then GPS is a better solution than SW
and probably just as cheap, and has global reach. I imagine that a good
view of the sky is not hard in Antartica.

DRM can
cope with ionspheric delay via indicating TX (and at the reciver RX) coords.
LW time stations are trapped in late 1960s style signalling.

But are simple enough to provide a millisecond accuracy at the receiver
for 20USD.

I personally cannot think of anything dafter than an additional SW
transmitter signal for CHU. Another LW station somewhere in north America
would be infinitely more useful.

JAB.

--
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
Northumberland, United Kingdom. Tel: +44 1661-832195

Alan,

The 128-bit NTP date spans 584 billion years with a resolution of .05
attosecond. The 64-bit NTP timestamp spans 136 years with a resolution
of 232 picoseconds. Is there something that needs better than 232
picoseconds? A 4-GHz CPU comes close.

As for broadcasters chiming good time, I do know that PBS/NPR
distributes progams via digital satellite and IP network with NTP.
However, I am told the gadgetry that actually brands the signal doesn't
use NTP, is often banished to the bottom of the rack and nobody knows
how to adjust it. As for the broadcast program start time, so far as I
can tell it's withing 30 ms of UTC. That's the best I can do with
eyeball and ear.

When I worked for an NBC affiliate in Detroit we had two clocks, one
synchronized to the power grid and the other a Western Union gadget that
synchronized via wire. The WU clock was purposely set to run slow by a
second or two per hour. Once per hour WU sent a pulse over the wire
causing the clock to do a hands-up jerk. I quickly learned to use that
clock only to calibrate the few seconds offset of the grid at the
hands-up signal. Broadcast networks once sent an audible ping at
hands-up to do the same tning, but that was (ahem) 50 yuears ago..

Dave

Dave

Alan Larson wrote:
In article "Max Power" writes:

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.


128 bits? What do you want - to specify the time of the heat death of the
universe (long after our sun dies) to nanosecond resolution, then be able to
tell the time of the death of the next universe (if there is one)?

64 bit NTP is probably quite adequate, and definitely enough bits if
one doesn't insist on the NTP nanosecond precision.

However, the time information doesn't need to be NTP, or IP based.
By the way, NTP is not a part of unix.


Presently, the analog TV stations transmitting time don't even seem
to consider it worth keeping the clocks set accurately -- some use a
PC's clock, with no external source to deal with its drift.

The time sent with ATSC seems to be random as well. Some stations
seem to have gone ahead with DST, but the only way to get the program
data to be correct is to manually force (and set) the receiver to use
local standard time.

Of course, not using UTC is astoundingly stupid -- folks who live next
to a time zone boundary are out of luck if some stations are on each side.


However, counting on broadcasters to get the time right is a fantasy.
They cannot even get their program guide information correct in the data
stream.


Alan

Hi Dave,

Since the application for ATSC broadcasting seems to be mostly setting
the clocks in the receiver's equipment, the 232 picoseconds of NTP seems to
rather far beyond what is needed. After all, 232 picoseconds is just under
7 centimeters at light speed. Thus, broadcasting the time of day (to set
the clock in your TV recorder) to that resolution seems a bit excessive.

0.01 second seems adequate to me to not miss the program.

The problem as I see it is that the sources are way bad (as you note).

Clearly, NTP would be a useful and available way of keeping a machine
transmitting time on a broadcast signal in good sync.

With ATSC, there seems to be some difficulty with daylight saving time --
when the time advanced this spring, I noticed that the electronic program
guides apparently did not advance. Attempts to set the clock on my ATSC
receiver from over the air signals got various times which did not match
local time. I eventually gave up and went back to the recommendation in
the addendum to the manual to manually set it to local non-DST time, with
the timezone set. That gets the program guide to match, but the clock of
course reads an hour slow.

It is unclear whether the Asians who programmed the thing didn't
understand time, or whether the standard is that completely flawed that it
doesn't account for properly dealing with transferred times in UTC and
converting for display. (Though, transmitting daylight saving time info in
the WWVB style seems a good idea, given the government's willingness to
fiddle with it and almost certainly break lots of things with built in
advance/fallback calculations.)


Precision is not a solution for lack of accuracy.

Neither precision nor accuracy will make up for implementation errors.


Alan


p.s. Doesn't CBS news still do the ping at the top of the hour? I think
they are still coming out from KCBS here. (I don't know what they do about
satellite delay of the feed (signal travel time, and any digital coding/decode
times). I have no idea how they will deal with the variable time delays of
IBOC digital processing.




In article "David L. Mills" writes:
Alan,

The 128-bit NTP date spans 584 billion years with a resolution of .05
attosecond. The 64-bit NTP timestamp spans 136 years with a resolution
of 232 picoseconds. Is there something that needs better than 232
picoseconds? A 4-GHz CPU comes close.

As for broadcasters chiming good time, I do know that PBS/NPR
distributes progams via digital satellite and IP network with NTP.
However, I am told the gadgetry that actually brands the signal doesn't
use NTP, is often banished to the bottom of the rack and nobody knows
how to adjust it. As for the broadcast program start time, so far as I
can tell it's withing 30 ms of UTC. That's the best I can do with
eyeball and ear.

When I worked for an NBC affiliate in Detroit we had two clocks, one
synchronized to the power grid and the other a Western Union gadget that
synchronized via wire. The WU clock was purposely set to run slow by a
second or two per hour. Once per hour WU sent a pulse over the wire
causing the clock to do a hands-up jerk. I quickly learned to use that
clock only to calibrate the few seconds offset of the grid at the
hands-up signal. Broadcast networks once sent an audible ping at
hands-up to do the same tning, but that was (ahem) 50 yuears ago..

Dave

Dave

Alan Larson wrote:
In article "Max Power" writes:

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.


128 bits? What do you want - to specify the time of the heat death of the
universe (long after our sun dies) to nanosecond resolution, then be able to
tell the time of the death of the next universe (if there is one)?

64 bit NTP is probably quite adequate, and definitely enough bits if
one doesn't insist on the NTP nanosecond precision.

However, the time information doesn't need to be NTP, or IP based.
By the way, NTP is not a part of unix.


Presently, the analog TV stations transmitting time don't even seem
to consider it worth keeping the clocks set accurately -- some use a
PC's clock, with no external source to deal with its drift.

The time sent with ATSC seems to be random as well. Some stations
seem to have gone ahead with DST, but the only way to get the program
data to be correct is to manually force (and set) the receiver to use
local standard time.

Of course, not using UTC is astoundingly stupid -- folks who live next
to a time zone boundary are out of luck if some stations are on each side.


However, counting on broadcasters to get the time right is a fantasy.
They cannot even get their program guide information correct in the data
stream.


Alan

Alan Larson wrote:
Hi Dave,

Since the application for ATSC broadcasting seems to be mostly
setting
the clocks in the receiver's equipment, the 232 picoseconds of NTP
seems to
rather far beyond what is needed. After all, 232 picoseconds is
just under
7 centimeters at light speed. Thus, broadcasting the time of day
(to set
the clock in your TV recorder) to that resolution seems a bit
excessive.

0.01 second seems adequate to me to not miss the program.

The problem as I see it is that the sources are way bad (as you
note).

Clearly, NTP would be a useful and available way of keeping a
machine
transmitting time on a broadcast signal in good sync.

With ATSC, there seems to be some difficulty with daylight saving
time --
when the time advanced this spring, I noticed that the electronic
program
guides apparently did not advance. Attempts to set the clock on my
ATSC
receiver from over the air signals got various times which did not
match
local time. I eventually gave up and went back to the
recommendation in
the addendum to the manual to manually set it to local non-DST time,
with
the timezone set. That gets the program guide to match, but the
clock of
course reads an hour slow.

It is unclear whether the Asians who programmed the thing didn't
understand time, or whether the standard is that completely flawed
that it
doesn't account for properly dealing with transferred times in UTC
and
converting for display. (Though, transmitting daylight saving time
info in
the WWVB style seems a good idea, given the government's willingness
to
fiddle with it and almost certainly break lots of things with built
in
advance/fallback calculations.)


Precision is not a solution for lack of accuracy.

Neither precision nor accuracy will make up for implementation
errors.


Alan


p.s. Doesn't CBS news still do the ping at the top of the hour? I
think
they are still coming out from KCBS here. (I don't know what they
do about
satellite delay of the feed (signal travel time, and any digital
coding/decode
times). I have no idea how they will deal with the variable time
delays of
IBOC digital processing.

Alan

Be aware that, at least in LA, some stations put the 'ping' ahead of an
8-10 second delay. Realistically, do you even need to be more accurate
than a frame of video?

I think 0.01 seconds is 10-100 times better than it needs to be. We're
not trying to pinpoint the position of the news helicopter, just start
your DVR without missing the head of the show. The phone company time
is sufficient for that.

I suspect the times are 'way bad' because it isn't automatically loaded
yet and the stations aren't getting any complaints and those guys have
plenty to do withouit setting a clock almost nobody checks.

Personally, I set the times and record times manually with no problems.


GG