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. 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?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: patrick@klos.com Klos Technologies, Inc. Web: http://www.klos.com/ ============================================================================
GPS module good for timekeeping?
Started by ●February 10, 2009
Reply by ●February 11, 20092009-02-11
Reply by ●February 11, 20092009-02-11
On Feb 10, 3:20 pm, Vladimir Vassilevsky <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. 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 Consultanthttp://www.abvolt.comWe'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 http://www.synergy-gps.com/content/view/17/31/
Reply by ●February 11, 20092009-02-11
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
Reply by ●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
Reply by ●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 ●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 ●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
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.comIt 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 ●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 ●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
