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. �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.
>
>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
Reply by rickman●February 12, 20092009-02-12
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
Reply by Rich Webb●February 12, 20092009-02-12
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
Reply by rickman●February 11, 20092009-02-11
On Feb 11, 5:08=A0pm, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
> On Wed, 11 Feb 2009 15:21:52 -0600, Vladimir Vassilevsky
>
>
>
> <antispam_bo...@hotmail.com> wrote:
>
> >Patrick Klos wrote:
>
> >> In article <UVgkl.10235$hc1.6...@flpi150.ffdc.sbc.com>,
> >> Vladimir Vassilevsky =A0<antispam_bo...@hotmail.com> wrote:
>
> >>>There is a data acquisition network of many units. Each unit is
> >>>synchronized to the GPS. It turns out that the common OEM GPS modules
> >>>have a nasty problem: the GPS time can suddenly jump by +/- 1 second
> >>>once in a while.
>
> >> We ran into this problem when developing our TimeStamper product. =A0W=
e
> >> ended up having to detect and compensate for the problem in our driver=
.
>
> >> We saw the NMEA strings were being delayed for a second or two at time=
s.
> >> This would make the casual observer attribute old data to a new PPS.
> >> The PPS pulses were fairly consistant and continuous, so we take some
> >> time to synchronize our system's clock to the PPS. =A0Then we would lo=
ok
> >> for wierd behavior from the NMEA strings and ignore the ones that cros=
sed
> >> a PPS and/or didn't make sense. >
> >> Hope that helps?
>
> >Thanks, Patrick. I am trying to define the valid time windows as well,
> >and it helps to the certain extent. However the whole thing about GPS
> >timing does not seem right; it shouldn't be that way.
>
> GPS time, per se, is as accurate as the GPS position because, pretty
> much, time and position have to fall out of the calculations together.
>
> A 10 m position uncertainty is (more or less, wave hands in air)
> equivalent to about a 30 nsec timing uncertainty. *BUT* how well that
> internal clock gets out to the user is subject to all of the usual
> firmware errors. Add to that the latency in constructing and
> transmitting the NMEA string and suddenly life isn't so good.
>
> If your GPS has one, you really want to watch the PPS as a timing source
> and, as Patrick and certsoft noted, run a long enough correlation to be
> able to stick the proper label on the active edge.
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.
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.
Rick
Reply by rickman●February 11, 20092009-02-11
On Feb 11, 4:33 pm, Grant Edwards <gra...@visi.com> wrote:
> On 2009-02-11, Vladimir Vassilevsky <antispam_bo...@hotmail.com> wrote:
>
> > Thanks, Patrick. I am trying to define the valid time windows
> > as well, and it helps to the certain extent. However the whole
> > thing about GPS timing does not seem right; it shouldn't be
> > that way.
>
> Probably not, but there are a lot of people writing firmware
> who just aren't very good.
>
> A friend of mine had a Garmin GPS, and the time it displayed on
> the LCD screen was often wrong by several minutes. It was a
> bug in the firmware, and it never got fixed. People who used
> that line of GPS units learned not to rely on the displayed
> time being accurate.
Good point. The Meridian line of Magellan GPS receivers have a
similar problem. The time display is correct for potentially a long
time and then one day it is off by seconds or even minutes. The only
way to correct the problem is by a total master reset which also
looses a lot of other data, including the local WAAS sat numbers.
When that happens, because the firmware only looks for the sat numbers
stored in the ROM or RAM, it can no longer receive a valid WAAS DGPS
signal. Someone figured out where the sat number data was stored so
we now have a fix, but this shows two examples of the poor firmware
development you mentioned; the clock loosing sync and the firmware
assuming the then current WAAS sats would be up there forever.
I don't, however, blame this on the programmers/developers.
Management often controls the goals and length of the product
development cycle which limits what the developer can do. Then again,
I am a hardware person, so software people suck, right? ;^)
Actually there is at least *ONE* excellent software guy, the one who
figured out how to fix the WAAS problem. I have not heard how he did
it, but I find that to be an impressive accomplishment. If I were him
I would put that on my resume.
Rick
Reply by Tim Wescott●February 11, 20092009-02-11
On Wed, 11 Feb 2009 15:21:52 -0600, Vladimir Vassilevsky wrote:
> Patrick Klos wrote:
>
>> In article <UVgkl.10235$hc1.6908@flpi150.ffdc.sbc.com>, Vladimir
>> Vassilevsky <antispam_bogus@hotmail.com> wrote:
>>
>>>There is a data acquisition network of many units. Each unit is
>>>synchronized to the GPS. It turns out that the common OEM GPS modules
>>>have a nasty problem: the GPS time can suddenly jump by +/- 1 second
>>>once in a while.
>
>
>> We ran into this problem when developing our TimeStamper product. We
>> ended up having to detect and compensate for the problem in our driver.
>>
>> We saw the NMEA strings were being delayed for a second or two at
>> times. This would make the casual observer attribute old data to a new
>> PPS. The PPS pulses were fairly consistant and continuous, so we take
>> some time to synchronize our system's clock to the PPS. Then we would
>> look for wierd behavior from the NMEA strings and ignore the ones that
>> crossed a PPS and/or didn't make sense. >
>> Hope that helps?
>
> Thanks, Patrick. I am trying to define the valid time windows as well,
> and it helps to the certain extent. However the whole thing about GPS
> timing does not seem right; it shouldn't be that way.
>
>
> Vladimir Vassilevsky
> DSP and Mixed Signal Design Consultant http://www.abvolt.com
It might be helpful to look at the serial port and the 1PPS pin at the
same time -- if the NMEA packets don't line up well with the 1PPS, it
would indicate that the problem has to do with the firmware using an RTC,
as suggested.
I don't know what you can _do_ about it short of getting hardware
involved, but at least you'll know more.
--
http://www.wescottdesign.com
Reply by Rich Webb●February 11, 20092009-02-11
On Thu, 12 Feb 2009 00:10:17 +0000 (UTC), dbr@kbrx.com wrote:
> Two or three weeks ago our calender, ie time (there is a proper title,
>perhaps UTC), changed by one second. The shifting you are seeing may be
>related to that.
Actually, GPS time itself is not corrected for leap seconds (neither is
Loran time, FWIW). However, the periodic nav message broadcast by the
satellites contains the necessary correction, currently 15 seconds, to
allow user equipment to derive UTC(USNO).
Since the nav message is only sent every 12.5 minutes, it's possible
that a given receiver may be off by quite a lot on startup if that
receiver failed to cache the correction when it was last received.
--
Rich Webb Norfolk, VA
Reply by ●February 11, 20092009-02-11
Two or three weeks ago our calender, ie time (there is a proper title,
perhaps UTC), changed by one second. The shifting you are seeing may be
related to that.
Hul
Vladimir Vassilevsky <antispam_bogus@hotmail.com> wrote:
> There is a data acquisition network of many units. Each unit is
> synchronized to the GPS. It turns out that the common OEM GPS modules
> have a nasty problem: the GPS time can suddenly jump by +/- 1 second
> once in a while. There is no indication if the time is stable or not. I
> tried several different brands and makes; all of them did that. The
> event looks random; I can't see any correlation with time or from unit
> to unit.
> Can you suggest a GPS module with the good timekeeping properties?
> Vladimir Vassilevsky
> DSP and Mixed Signal Design Consultant
> http://www.abvolt.com
Reply by Rich Webb●February 11, 20092009-02-11
On Wed, 11 Feb 2009 15:21:52 -0600, Vladimir Vassilevsky
<antispam_bogus@hotmail.com> wrote:
>
>
>Patrick Klos wrote:
>
>> In article <UVgkl.10235$hc1.6908@flpi150.ffdc.sbc.com>,
>> Vladimir Vassilevsky <antispam_bogus@hotmail.com> wrote:
>>
>>>There is a data acquisition network of many units. Each unit is
>>>synchronized to the GPS. It turns out that the common OEM GPS modules
>>>have a nasty problem: the GPS time can suddenly jump by +/- 1 second
>>>once in a while.
>
>
>> We ran into this problem when developing our TimeStamper product. We
>> ended up having to detect and compensate for the problem in our driver.
>>
>> We saw the NMEA strings were being delayed for a second or two at times.
>> This would make the casual observer attribute old data to a new PPS.
>> The PPS pulses were fairly consistant and continuous, so we take some
>> time to synchronize our system's clock to the PPS. Then we would look
>> for wierd behavior from the NMEA strings and ignore the ones that crossed
>> a PPS and/or didn't make sense. >
>> Hope that helps?
>
>Thanks, Patrick. I am trying to define the valid time windows as well,
>and it helps to the certain extent. However the whole thing about GPS
>timing does not seem right; it shouldn't be that way.
GPS time, per se, is as accurate as the GPS position because, pretty
much, time and position have to fall out of the calculations together.
A 10 m position uncertainty is (more or less, wave hands in air)
equivalent to about a 30 nsec timing uncertainty. *BUT* how well that
internal clock gets out to the user is subject to all of the usual
firmware errors. Add to that the latency in constructing and
transmitting the NMEA string and suddenly life isn't so good.
If your GPS has one, you really want to watch the PPS as a timing source
and, as Patrick and certsoft noted, run a long enough correlation to be
able to stick the proper label on the active edge.
--
Rich Webb Norfolk, VA
Reply by Grant Edwards●February 11, 20092009-02-11
On 2009-02-11, Vladimir Vassilevsky <antispam_bogus@hotmail.com> wrote:
> Thanks, Patrick. I am trying to define the valid time windows
> as well, and it helps to the certain extent. However the whole
> thing about GPS timing does not seem right; it shouldn't be
> that way.
Probably not, but there are a lot of people writing firmware
who just aren't very good.
A friend of mine had a Garmin GPS, and the time it displayed on
the LCD screen was often wrong by several minutes. It was a
bug in the firmware, and it never got fixed. People who used
that line of GPS units learned not to rely on the displayed
time being accurate.
--
Grant Edwards grante Yow! My haircut is totally
at traditional!
visi.com