GPS module good for timekeeping?

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

formatting link

Reply to
Vladimir Vassilevsky
Loading thread data ...

Wow.

Do they do it in synchrony, either all over the world or for the ones that are closely co-located?

--
http://www.wescottdesign.com
Reply to
Tim Wescott

Is the problem that the time is inaccurate in long run, or that the messages drift within the 1-second interval? Perhaps the message timing is tied to an internal RTC which gets corrected by the GPS timing when the error accumulates. If that is the case, you might expect the skip rate to be somewhat temperature sensitive.

Perhaps the GPS is either skipping a message, or duplicating one to get the messages back in sync with the GPS time.

I've used modules from both UBlox and Delorme, and haven't seen this problem---but that may be because I haven't really looked for it. I'll see if I can find time to do a test and will post the results if I can.

Mark Borgerson

Reply to
Mark Borgerson

Identical GPS modules, located at the desk, operating from one GPS repeater, NMEA time stamps compared to the real time clock. It is pretty certain that at least one of ten modules will jump by +/- 1 second per few hours of operation. My speculation is that the GPS timestamp is based on the internal free running RTC which is only accurate to 1 sec. When the difference between the true GPS time and the RTC exceeds 0.5 sec, the RTC is adjusted by 1 sec.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

My, that's ... interesting*.

So on the negative jumps is it really a jump, or does it just hold the time of the last second? It would seem that a jump forward/hold backward scheme would be most consistent with your RTC idea -- it would also seem that some units would always be jumping one way, and others would always be jumping the other, due to their individual RTC chips being fast or slow.

Have you checked the 1PPS output to see if it's synchronized across the units?

  • (Other adjectives have been suppressed for the sake of polite conversation).
--
http://www.wescottdesign.com
Reply to
Tim Wescott

Which sentences? And how is the time field formatted? Some receivers output only integer values for UTC (no fractional seconds portion, which is permitted by the standard) and, if their internal Kalman cycles drift a little (or one takes somewhat longer, due to whatever internal calculation), they may end up crossing a boundary.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Un bel giorno Vladimir Vassilevsky digitò:

Yep, I noticed that too, either with SiRF and Atmel chipsets. uBlox has a couple of models specifically designed for precision timing (LEA-4T and LEA-5T); I haven't used them, but maybe they've implemented some trick to avoid the leap.

--
emboliaschizoide.splinder.com
Reply to
dalai lamah

It would also be interesting to know if WAAS enabled GPS shows this problem.

Reply to
Jim Stewart

PPS looks stable and synchronous (except for the small jerks of up to about 100ns from time to time). I haven't seen the GPS reporting the same seconds twice or skipping a second; the time count is always sequential. When advancing, it spits the timestamps one after another, when going back, it makes a pause. However the time scale shifts for one second in both cases.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

I think you are seeing a sort of interference pattern between the exact GPS time and the not-so-exactly-one-second interval the RMC sentence is output. You might be able to prove this by logging the sentences with a precise time stamp.

Meindert

Reply to
Meindert Sprang

What type of device is this "data acquisition unit"? An embedded system or a PC (running Linux or Windows)?

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?

Patrick ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! ========= Patrick Klos Email: snipped-for-privacy@klos.com Klos Technologies, Inc. Web:

formatting link
============================================================================

Reply to
Patrick Klos

We've been using some variation of the Motorola M12 for years in our seismic data acquistion system. We have found that GPS timestrings, and even the pulses themselves should be treated as suspect, filtering by some sort of "jump detector and filter" is appropriate. Once we have stable 3-D lock we also update a battery backed up RTC and during power-on we verify that the GPS time is close to the RTC. If it isn't then we coldstart the GPS and see if it gets better. After 3 times we assume the GPS is correct and proceed from there.

It's sad that these sort of steps are needed, but in the seismic world, timing is everything :)

I believe our current supplier is

formatting link

Reply to
certsoft

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

formatting link

Reply to
Vladimir Vassilevsky

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!
 Click to see the full signature
Reply to
Grant Edwards

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 to
Rich Webb

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 wrote:

Reply to
dbr

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 to
Rich Webb

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 to
Tim Wescott

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 to
rickman

e
.

s.

ok

sed

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 to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.