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
GPS module good for timekeeping?
Started by ●February 10, 2009
Reply by ●February 10, 20092009-02-10
On Tue, 10 Feb 2009 09:20:25 -0600, Vladimir Vassilevsky 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.comWow. 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 by ●February 10, 20092009-02-10
In article <UVgkl.10235$hc1.6908@flpi150.ffdc.sbc.com>, antispam_bogus@hotmail.com says...> > 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.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.> > Can you suggest a GPS module with the good timekeeping properties?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 by ●February 10, 20092009-02-10
Tim Wescott wrote:> On Tue, 10 Feb 2009 09:20:25 -0600, Vladimir Vassilevsky 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? >> > Wow. > > Do they do it in synchrony, either all over the world or for the ones > that are closely co-located?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 http://www.abvolt.com
Reply by ●February 10, 20092009-02-10
On Tue, 10 Feb 2009 10:13:48 -0600, Vladimir Vassilevsky wrote:> Tim Wescott wrote: > >> On Tue, 10 Feb 2009 09:20:25 -0600, Vladimir Vassilevsky 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? >>> >> Wow. >> >> Do they do it in synchrony, either all over the world or for the ones >> that are closely co-located? > > 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 http://www.abvolt.comMy, 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 by ●February 10, 20092009-02-10
On Tue, 10 Feb 2009 10:13:48 -0600, Vladimir Vassilevsky <antispam_bogus@hotmail.com> wrote:> > >Tim Wescott wrote: > >> On Tue, 10 Feb 2009 09:20:25 -0600, Vladimir Vassilevsky 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? >>> >> Wow. >> >> Do they do it in synchrony, either all over the world or for the ones >> that are closely co-located? > >Identical GPS modules, located at the desk, operating from one GPS >repeater, NMEA time stamps compared to the real time clock.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 by ●February 10, 20092009-02-10
Un bel giorno Vladimir Vassilevsky digit�:> 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.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 by ●February 10, 20092009-02-10
dalai lamah wrote:> Un bel giorno Vladimir Vassilevsky digit�: > >> 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. > > 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.It would also be interesting to know if WAAS enabled GPS shows this problem.
Reply by ●February 10, 20092009-02-10
Tim Wescott wrote:> On Tue, 10 Feb 2009 10:13:48 -0600, Vladimir Vassilevsky wrote: >>Tim Wescott wrote: >>>On Tue, 10 Feb 2009 09:20:25 -0600, Vladimir Vassilevsky 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? >>>> >>> >>>Wow. >>> >>>Do they do it in synchrony, either all over the world or for the ones >>>that are closely co-located? >> >>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. >> > > 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).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 http://www.abvolt.com
Reply by ●February 11, 20092009-02-11
"Vladimir Vassilevsky" <antispam_bogus@hotmail.com> wrote in message news:UVgkl.10235$hc1.6908@flpi150.ffdc.sbc.com...> > 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. >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
