GPS module good for timekeeping?

On Wed, 11 Feb 2009 18:34:01 -0800 (PST), rickman <gnuarm@gmail.com>
wrote:

>This is a very interesting discussion to me.  I recently developed an
>IRIG-B time code product and none of those problems occurred.  In
>fact, I had originally put a several frame (1 per second) sync time in
>the hardware taking a queue from what I have seen in comms protocols.
>The customer wanted it to sync faster so on the network side of the
>card it now syncs on the first detection of a frame marker and on the
>IRIG-B side I it syncs on two complete frames.  The customer has
>tested this for 72 hours with no sync slips.  Of course a time code is
>a single stream of data combined with the detail timing reference.
>The GPS signal seems to have two signals which are not well
>correlated.

Neither the PPS signal nor the NMEA data streams are in any way part of
the GPS signal itself. A GPS receiver may choose to emit NMEA messages,
or Rockwell binary, or a military IDS, or a PPS but all of those are
generated by the receiver itself.

The time stamp on a NMEA message should reflect the time at which its
data fields were valid and will only be loosely correlated with UTC by
the time it gets queued and then sent out the serial port. Time of
receipt of, say, a $GPZDA sentence was never intended to be precisely
synchronized to UTC.

>I think when using time code signals of any type, it is important to
>design the receiver as a PLL rather than as just a decoder.  So any
>one message does not disrupt the timing.  Of course this requires more
>complex design, but as Vladimir has found, simpler solutions have
>problems.

Yup, absolutely true.

-- 
Rich Webb     Norfolk, VA

On Feb 12, 8:35=A0am, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
> On Wed, 11 Feb 2009 18:34:01 -0800 (PST), rickman <gnu...@gmail.com>
> wrote:
>
> >This is a very interesting discussion to me. =A0I recently developed an
> >IRIG-B time code product and none of those problems occurred. =A0In
> >fact, I had originally put a several frame (1 per second) sync time in
> >the hardware taking a queue from what I have seen in comms protocols.
> >The customer wanted it to sync faster so on the network side of the
> >card it now syncs on the first detection of a frame marker and on the
> >IRIG-B side I it syncs on two complete frames. =A0The customer has
> >tested this for 72 hours with no sync slips. =A0Of course a time code is
> >a single stream of data combined with the detail timing reference.
> >The GPS signal seems to have two signals which are not well
> >correlated.
>
> Neither the PPS signal nor the NMEA data streams are in any way part of
> the GPS signal itself. A GPS receiver may choose to emit NMEA messages,
> or Rockwell binary, or a military IDS, or a PPS but all of those are
> generated by the receiver itself.

Yes, of course.  I should have said "the signal from the GPS
module".

I also worked with a similar time code used in Military radios and it
also was a single stream combining the data (time value) with the 1
pps marker.  We built a GPS unit to give the radio location info.  I
don't know if they ever used the GPS module to provide time data.  I
guess if they did they would have found this issue.


> The time stamp on a NMEA message should reflect the time at which its
> data fields were valid and will only be loosely correlated with UTC by
> the time it gets queued and then sent out the serial port. Time of
> receipt of, say, a $GPZDA sentence was never intended to be precisely
> synchronized to UTC.

That sounds a lot like weasel wording.  A GPS receiver does not have
the same sort of time and priority problems that a PC will have.  If
they can't provide a few ms of messages in a timely manner, then the
product is defective.  So I don't buy the idea that I should not
expect the messages to be sent in a timely manner.  If there are other
issues involved... no, I don't think anyone has pointed out any issues
that are not *design* issues in the receiver.  There is a 1 PPS signal
that is recovered from the GPS signal.  This is coordinated to "real"
time to within microseconds according to all the docs I have read on
GPS receivers.  The calculations are typically done on a 1 sec
interval.  The receiver should be keeping a PLL for updating the time
data.  Then the time output by the receiver can be closely correlated
to the 1 PPS signal.  If they don't do this, then it is a design
issue, not an inherent flaw.

The timing of the sentences reporting time should be closely
correlated to the 1 PPS signal (which *IS* correlated to UTM) that it
can be matched to the correct 1 PPS pulse.  Otherwise, what is the
point of the sentence?


> >I think when using time code signals of any type, it is important to
> >design the receiver as a PLL rather than as just a decoder. =A0So any
> >one message does not disrupt the timing. =A0Of course this requires more
> >complex design, but as Vladimir has found, simpler solutions have
> >problems.
>
> Yup, absolutely true.

I just don't know how the GPS module makers implement their time
sentences.  I know that my work with retail units show they have any
number of issues, but I guess that is to be expected.  I bet the
$10,000 mil units don't have *any* of these problems.  I don't know
how much the surveying units cost, but they are accurate enough to
locate a point to within a few cm.  That's pretty durn amazing!

Rick

On Thu, 12 Feb 2009 10:45:00 -0800 (PST), rickman <gnuarm@gmail.com>
wrote:

>The timing of the sentences reporting time should be closely
>correlated to the 1 PPS signal (which *IS* correlated to UTM) that it
>can be matched to the correct 1 PPS pulse.  Otherwise, what is the
>point of the sentence?

In a general purpose GPS one should be able to rely on the time stamp as
pretty darn accurate with respect to "data good", and most of the time
I'd expect the sentences to appear at regular, periodic intervals and at
their proper place between PPS events. However, unless otherwise spec'd
by the manufacturer, there's no guaranteed relationship between the
leading start bit (or trailing stop bit) of any particular sentence to
the PPS. The NMEA spec does not require one (or even mention a pulse per
second).

Indeed, unless the device *specifies* bounding values for delta-T from
UTC along with jitter, rise time, etc. I'd not count on the PPS pulse
itself to have any particular relationship to UTC or even to have a
periodicity that's well defined.

There absolutely are receivers that are well-behaved in this regard, but
if it ain't in the datasheet ...

>> >I think when using time code signals of any type, it is important to
>> >design the receiver as a PLL rather than as just a decoder. &#4294967295;So any
>> >one message does not disrupt the timing. &#4294967295;Of course this requires more
>> >complex design, but as Vladimir has found, simpler solutions have
>> >problems.
>>
>> Yup, absolutely true.
>
>I just don't know how the GPS module makers implement their time
>sentences.  I know that my work with retail units show they have any
>number of issues, but I guess that is to be expected.  I bet the
>$10,000 mil units don't have *any* of these problems.

They put it in the specs.  ;-)  For example, "When 1PPS UTC is selected,
the leading edge of the PPS output will be within a period of time from
the UTC 1 second rollover that is RCVR specific, but shall not exceed
[redacted] ns ([redacted]%), when the Time Figure of Merit (TFOM) is
[redacted] or less." which goes with "Message xxxx is associated with
the 1PPS UTC output pulse.  It is automatically output whenever the 1PPS
output mode is set to 1PPS UTC. ... Message xxxx shall be output after
its associated 1PPS UTC pulse is output, and before the next 1PPS UTC
pulse." If it ain't in the datasheet ...

>  I don't know
>how much the surveying units cost, but they are accurate enough to
>locate a point to within a few cm.  That's pretty durn amazing!

It's one of those where if you have to ask, you can't afford it.  ;-)
But yeah, you get what you pay for -- usually. At the least, it's rare
to get $10K performance from a $100 receiver. On the other, other hand,
what $100 buys nowadays is pretty amazing.

-- 
Rich Webb     Norfolk, VA