On Sat, 19 Jan 2008 05:35:32 -0800, David wrote:

They could put the new station on 60 kHz as well. If they can't get
them adequately synchronized they could alternate every 30 minutes or
whatever. This would avoid everyone having to buy new watches. Any
commercial entity who really needs accurate time switched over to GPS a
decade ago.

Joke's on them. GPS time is implemented by the atomic clocks in the
GPS ground control stations and the GPS satellites themselves. Since
it is not updated with leap seconds, GPS is currently ahead of UTC by
14 seconds.

FWIW, the time obtainable from LORAN-C transmitter sites is an
additional 9 seconds ahead of that (23 seconds total), and the
international atomic time scale, called TAI for Temps Atomique
International and which is a statistical timescale based on a large
number of atomic clocks, is currently ahead of UTC by 33 seconds.

73 de John, KC2HMZ

John Kasupski wrote:

Joke's on them. GPS time is implemented by the atomic clocks in the
GPS ground control stations and the GPS satellites themselves. Since
it is not updated with leap seconds, GPS is currently ahead of UTC by
14 seconds.

That's a software bug. For location purposes, a leap second is a
very bad thing when it happens. So it's better for GPS to ignore
it, and if you really need accurate time, compenstate for the extra
seconds in the routine that takes the GPS data and converts it to
whatever you are using it for.

It would not take much, a simple calculation of missed leap seconds
subtracted from the current GPS time would do it perfectly.

I wonder if the NTP (network time protocol) GPS drivers do it
already?

Geoff.

--
Geoffrey S. Mendelson, Jerusalem, Israel N3OWJ/4X1GM
IL Voice: (07)-7424-1667 U.S. Voice: 1-215-821-1838
Visit my 'blog at http://geoffstechno.livejournal.com/

John Kasupski wrote:

Joke's on them. GPS time is implemented by the atomic clocks in the
GPS ground control stations and the GPS satellites themselves. Since
it is not updated with leap seconds, GPS is currently ahead of UTC by
14 seconds.

I answered that with:

That's a software bug. For location purposes, a leap second is a
very bad thing when it happens. So it's better for GPS to ignore
it, and if you really need accurate time, compenstate for the extra
seconds in the routine that takes the GPS data and converts it to
whatever you are using it for.

According to:
http://www.eecis.udel.edu/~mills/leap.html

The NTP network automaticly deals with the difference between NTP and
GPS times. The web page also states:

While of less use to the computer timekeeper, the Global Positioning
System (GPS), which is widely used to disseminate standard time, has its
own timescale. The GPS timescale is syntonic with TAI, but at a fixed
time offset of -19 s from that timescale, apparently because the final
system design review was in 1980. GPS clocks typically convert from GPS
to UTC for external readings.

So someone already thought of it, and it is no longer, and may never
have been an issue.

Geoff.

--
Geoffrey S. Mendelson, Jerusalem, Israel N3OWJ/4X1GM
IL Voice: (07)-7424-1667 U.S. Voice: 1-215-821-1838
Visit my 'blog at http://geoffstechno.livejournal.com/

On Sun, 20 Jan 2008 11:44:11 +0000 (UTC), (Geoffrey
S. Mendelson) wrote:

According to:
http://www.eecis.udel.edu/~mills/leap.html

The NTP network automaticly deals with the difference between NTP and
GPS times. The web page also states:

While of less use to the computer timekeeper, the Global Positioning
System (GPS), which is widely used to disseminate standard time, has its
own timescale. The GPS timescale is syntonic with TAI, but at a fixed
time offset of -19 s from that timescale, apparently because the final
system design review was in 1980.

OK, I see where you're coming from. A better explanation appears to be
in order. But before I do that, I will comment that your information
is essentially correct to the best of my knowledge. The GPS time was
zero at zero hours on January 6, 1980 (That is to say, the start of
the GPS time scale occurred at UTC instant 1980-01-06T00:00:00.0), but
that occurred at TAI instant 1980-01-06T00:00:19.0, hence the
19-second difference between the two. The GPS is now 14 seconds ahead
of UTC because of the leap seconds, which are not inserted into GPS
but are inserted into UTC.

OK, now, on to the problem of using GPS as a time standard.

GPS *satellites* reference an atomic clock (actually several of them)
and produce a time standard that is continuously monitored, not only
by the U.S. Naval Observatory (which is responsible for providing the
time and frequency references for GPS) but also by the National
Institute of Standards and Technology, which maintains the official
time standard here in the U.S. The time on the GPS birds themselves is
not the problem. The problem is with the GPS *receivers*.

GPS receivers use an internal clock that is set by accessing the time
broadcast by as many GPS birds as the receiver can "see" and coming up
with an average that the receiver then sets its internal clock to.
That average is based on the time contained in the birds'
transmissions and the distance between the bird and the receiver -
which the receiver calculates based on the time it took the signal
from the bird to reach the receiver (which is also how it accomplishes
trilateration, the process by which the receiver determines its
position).

Now, since it bases this calculation on its own internal clock, the
distances will all be proportionally incorrect, and thus so will the
receivers subsequent calculations, including those of its own time
errors! The calculation is also based in part on the receiver's
understanding of where the bird is located. It determines this from an
internally-stored almanac that tells it where every satellite should
be at any given time. Things like the gravity of the moon and the sun
do change the satellites' orbits slightly. The USNO and NIST
constantly monitor their exact positions and USNO transmits any
adjustments to all GPS receivers as part of the satellites' signals.

In any event, the accuracy of this process varies from one GPS
receiver to the next, depending on the quality of the algorithms that
the receiver is using to process the data received from the birds.

Furthermore, while some receivers use a quartz (or maybe rubidium in
some models) crystal oscillator to control their internal clocks,
others simply let a temperature controlled crystal oscillator (TCXO)
free run, divide its output to 1 pps, and then synchronize that to the
GPS signal. The receiver then accumulates time errors until the total
time error approaches a certain level, at which point the receiver
inserts a phase step to reduce (notice I did not say "correct") the
time error. This actually works pretty well over the long term in
comparison to the models that use a quartz controlled oscillator, but
its short-term stability is questionable.

There are also other differences in the internal programming of GPS
receivers. Some have routines to toss out bad data when a bird is
broadcasting bad data (as happened with one of the GPS birds in 1997),
others do not. The point is that with a receiver having a poor quality
oscillator and/or poor quality algorithms, the time it displays at any
given instant may not be as accurate as its user might hope.

Note that we're probably talking errors in the amount of nanoseconds
(per second) here, certainly not errors that are going to cause
somebody to be ten minutes late for work, but for commercial or
scientific applications requiring a time reference that is related
directly to a national or international reference, GPS may not
necessarily cut the mustard.

73 DE John, KC2HMZ

John Kasupski wrote:
On Sat, 19 Jan 2008 05:35:32 -0800, David wrote:

They could put the new station on 60 kHz as well. If they can't get
them adequately synchronized they could alternate every 30 minutes or
whatever. This would avoid everyone having to buy new watches. Any
commercial entity who really needs accurate time switched over to GPS a
decade ago.

Joke's on them. GPS time is implemented by the atomic clocks in the
GPS ground control stations and the GPS satellites themselves. Since
it is not updated with leap seconds, GPS is currently ahead of UTC by
14 seconds.

Easily compensated for in the software.

http://www.ese-web.com/

On Sun, 20 Jan 2008 05:51:02 -0800, David wrote:

John Kasupski wrote:
On Sat, 19 Jan 2008 05:35:32 -0800, David wrote:

They could put the new station on 60 kHz as well. If they can't get
them adequately synchronized they could alternate every 30 minutes or
whatever. This would avoid everyone having to buy new watches. Any
commercial entity who really needs accurate time switched over to GPS a
decade ago.

Joke's on them. GPS time is implemented by the atomic clocks in the
GPS ground control stations and the GPS satellites themselves. Since
it is not updated with leap seconds, GPS is currently ahead of UTC by
14 seconds.

Easily compensated for in the software.

Well, that part of it is, but see my reply to Geoffrey's posts on the
subject. There are other issues with using GPS as a time standard,
which are related to the quality of the algorithms GPS receivers use
to process data received from the satellites, as well as variations in
the circuitry used to control receivers' internal clocks.

73 DE John, KC2HMZ

John Kasupski wrote:
On Sun, 20 Jan 2008 05:51:02 -0800, David wrote:

John Kasupski wrote:
On Sat, 19 Jan 2008 05:35:32 -0800, David wrote:

They could put the new station on 60 kHz as well. If they can't get
them adequately synchronized they could alternate every 30 minutes or
whatever. This would avoid everyone having to buy new watches. Any
commercial entity who really needs accurate time switched over to GPS a
decade ago.
Joke's on them. GPS time is implemented by the atomic clocks in the
GPS ground control stations and the GPS satellites themselves. Since
it is not updated with leap seconds, GPS is currently ahead of UTC by
14 seconds.

Easily compensated for in the software.

Well, that part of it is, but see my reply to Geoffrey's posts on the
subject. There are other issues with using GPS as a time standard,
which are related to the quality of the algorithms GPS receivers use
to process data received from the satellites, as well as variations in
the circuitry used to control receivers' internal clocks.

73 DE John, KC2HMZ

Did you visit the ESE web site? They make the master clocks used in
broadcasting (and a lot of public service and labs) and they have very
well thought-out innards.

Is GPS like NTP in as they just give a raw number of seconds since a
certain date and that the receiver computes the real time from that,
based on its firmware?