gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-users] possible week rollover problem


From: Paul Fox
Subject: Re: [gpsd-users] possible week rollover problem
Date: Tue, 25 Aug 2015 14:23:49 -0400

gary e. miller wrote:
 > Yo Paul!
 > 
 > On Tue, 25 Aug 2015 13:44:04 -0400
 > Paul Fox <address@hidden> wrote:
 > 
 > > i've been seeing bad dates from gpsd which seem to indicate a week
 > > rollover issue.  i've been running gpsd 3.9, which i realize is out of
 > > date, but which i think is more recent than most "week
 > > rollover"-related commits i could see in the git log.  (i've now
 > > upgraded to gpsd 3.15, so i'll see if the problem described below
 > > reappears.)
 > 
 > Likely no change.
 > 
 > > i have two BU-353 usb dongles:  one older (sirfstar 3?), the other a
 > > newer S4 with a sirfstar 4.  (yes, i've read the FAQ, and it's slow
 > > to acquire sometimes, but i needed something in a hurry at the
 > > time.)  they both exhibit similar date issues with gpsd. 
 > > unfortunately, it's hard (because of the binary protocol) for me to
 > > trivially check them against something other than gpsd.
 > 
 > So just put them in NMEA mode.
 >  
 > > what i've observed:
 > What we really need is gpsd raw logs, or raw GPS output that we can look at.

okay.  i'll figure out how to enbale that, so i can quickly turn it on
if/when the problem occurs.  can gpsd raw logging can be enabled on
the fly?  or do i have to change systemd's gpsd conf file to add the -D
option?

 > 
 > > if this is a known issue with the sirf chipsets,
 > 
 > Pretty much all GPS can lose the GPS epoch.  Usually when the internal GPS
 > battery is dead, but your units sound to new or that.  But most GPS
 > can report bad time until they have had a good sky view for 30 minutes.

in the "weekend trip" scenario i reported, the 2035 date persisted
over the course of two days of clear sky and good fixes.  i believe
i was using the S4 device.

 > 
 > So only worth looking at if the bad time persisted after 30 mins of
 > valid fixes.
 > 
 > > then i'll probably
 > > put a bandaid into my application and call it a day.  but i'm also
 > > happy to do more debugging/logging, or add instrumentation, if that
 > > would be helpful.
 > 
 > Yup, that would be helpful.  Also, when reporting gpsmon results, you
 > need to say whether it was in standalone or slave mode.  In standalone
 > mode gpsmon talks directly to the GPS, in slave mode it just reports
 > what gpsd is seeing.

i didn't realize gpsmon could run standalone -- it was definitely talking
to gpsd in this case.  i'll try connecting directly next time it
happens.  (the usage message skips that case, btw.)

is the "Time:" reported by gpsmon the gps time?  i'd have assumed so,
except that it definitely didn't match the results gpsd was giving
via gpspipe, or to my application.

paul
=----------------------
 paul fox, address@hidden (arlington, ma, where it's 72.1 degrees)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]