Phil Kane wrote:
On Sun, 23 Mar 2008 22:53:54 EDT, Klystron wrote:

Wouldn't it make more sense to include WWV and WWVH along with WWVB?
Are you familiar with the Internet-based ntp system? Then, there is the
matter of GPS, which has a time capability that is incidental to its
navigation function.

Want some fun? Compare the time ticks received from WWVB, WWV,
NIST-on-line, and GPS. What, they are not all simultaneous? Welcome
to the real world. GPS time does not correlate with UTC by any means
(several seconds difference).

Each GPS sattelite has it's own on board atomic clock and the system can
easily provide UTC with accuracy on the few microseconds level with an
ultimate limit of +/- 340 nanoseconds using an appropriate receiver and
hardware.

GPS is the basis for most of the current NTP time servers.

http://www.ntp-time-server.com/gps-t...ime-server.htm


--
Jim Pennino

Remove .spam.sux to reply.

On Mon, 24 Mar 2008 00:10:13 EDT, wrote:

Each GPS sattelite has it's own on board atomic clock and the system can
easily provide UTC with accuracy on the few microseconds level with an
ultimate limit of +/- 340 nanoseconds using an appropriate receiver and
hardware.

Something must have changed (or been fixed) then - we made
measurements about three years ago and there was about six seconds
offset - an eternity for accurate time measurements. 340 nanoseconds
we can tolerate. Six seconds we can't.
--

73 de K2ASP - Phil Kane

From a Clearing in the Silicon Forest
Beaverton (Washington County) Oregon

e-mail: k2asp [at] arrl [dot] net

Phil Kane wrote:

Something must have changed (or been fixed) then - we made
measurements about three years ago and there was about six seconds
offset - an eternity for accurate time measurements. 340 nanoseconds
we can tolerate. Six seconds we can't.



Could "selective availability" have anything to do with that?

--
Klystron

In article ,
Klystron wrote:
Phil Kane wrote:

Something must have changed (or been fixed) then - we made
measurements about three years ago and there was about six seconds
offset - an eternity for accurate time measurements. 340 nanoseconds
we can tolerate. Six seconds we can't.



Could "selective availability" have anything to do with that?

No.

Klystron wrote:
Phil Kane wrote:

Something must have changed (or been fixed) then - we made
measurements about three years ago and there was about six seconds
offset - an eternity for accurate time measurements. 340 nanoseconds
we can tolerate. Six seconds we can't.

Could "selective availability" have anything to do with that?

It was turned off about 7 years ago and even then just put the ultimate
accuracy in the low microsecond range.

GPS has never been off by six seconds.

--
Jim Pennino

Remove .spam.sux to reply.

In article ,
Phil Kane wrote:
Something must have changed (or been fixed) then - we made
measurements about three years ago and there was about six seconds
offset - an eternity for accurate time measurements. 340 nanoseconds
we can tolerate. Six seconds we can't.

It's changed. GPS and UTC now differ by 14 seconds, according to
http://tycho.usno.navy.mil/gpstt.html. This is because GPS time does
not include leap seconds.

This 14 second difference is part of the GPS broadcast, so can easily
be backed out of the GPS time data to produce UTC. Once corrected,
the UTC values have the stated accuracy.

Don't be confused by the latency of some GPS units in producing time/fix
products. I've seen them produce fixes several seconds later. That's why
the time is included in postition data, so you know when you were there.
If you want time from your GPS, you need either the 1PPS pulse output or
a unit with a known and predictable period from real time to character
output. For many uses, simply assuming that the first character of the
output string (NMEA) occurs at the time in the message is adequate,
but that's not going to get you your 340ns accuracy.

For example, I am using a Trimble Acutime to feed an home-brew time
demon. Tests comparing system time from this demon to ntp stratum 1
servers gave a few millisecond difference. Good enough for me.

Mark Kramer wrote:
In article ,
Phil Kane wrote:
Something must have changed (or been fixed) then - we made
measurements about three years ago and there was about six seconds
offset - an eternity for accurate time measurements. 340 nanoseconds
we can tolerate. Six seconds we can't.

It's changed. GPS and UTC now differ by 14 seconds, according to
http://tycho.usno.navy.mil/gpstt.html. This is because GPS time does
not include leap seconds.

If you read the whole thing, you find there are several differences
betweeen the raw time and UTC.

This 14 second difference is part of the GPS broadcast, so can easily
be backed out of the GPS time data to produce UTC. Once corrected,
the UTC values have the stated accuracy.

All the offsets from UTC and their values are in the NAV message. Most
receivers do that adjustment automaticaly as UTC is what most end users
want.

Now, if you have some receiver that outputs the raw uncorrected stuff
or a home brew receiver without the corrections...

That would be a case of RTFM.

Don't be confused by the latency of some GPS units in producing time/fix
products. I've seen them produce fixes several seconds later. That's why
the time is included in postition data, so you know when you were there.
If you want time from your GPS, you need either the 1PPS pulse output or
a unit with a known and predictable period from real time to character
output. For many uses, simply assuming that the first character of the
output string (NMEA) occurs at the time in the message is adequate,
but that's not going to get you your 340ns accuracy.

Most cheap receivers are either optimized for position or time, not
both, so it pays to read the spec sheet carefully.

For example, I am using a Trimble Acutime to feed an home-brew time
demon. Tests comparing system time from this demon to ntp stratum 1
servers gave a few millisecond difference. Good enough for me.

That's one that has been optimized for time, so a good choice for your
application. A bit of attention to details could get you into the
microsecond range, but for the majority of people not necessary.

--
Jim Pennino

Remove .spam.sux to reply.

Phil Kane wrote:
On Mon, 24 Mar 2008 00:10:13 EDT, wrote:

Each GPS sattelite has it's own on board atomic clock and the system can
easily provide UTC with accuracy on the few microseconds level with an
ultimate limit of +/- 340 nanoseconds using an appropriate receiver and
hardware.

Something must have changed (or been fixed) then - we made
measurements about three years ago and there was about six seconds
offset - an eternity for accurate time measurements. 340 nanoseconds
we can tolerate. Six seconds we can't.
--

The only thing that has changed since the first sattelite launched is
that the accuracy degrading dither for civilian use was removed about
7 years ago. With the dither the time accuracy was in the range of tens
of microseconds.

Whereever you were getting your six seconds of error from, it wasn't
from the GPS system.



--
Jim Pennino

Remove .spam.sux to reply.