Maybe I'm missing something in my test setup or mis-understanding what's the best path forward for our platform.
I'll start at square one (or zero).
I've hooked our embedded device up to the Spectracom GPS/GNSS simulator and set the date to before the rollover. Works fine as expected.
Setting the simulator date to after the rollover date... Everything goes wrong, also as expected.
The rollover itself doesn't exist in the NMEA stream coming from the Trimble chip to GPSD but in the IS-GPS-200 stream coming from the satellite to the chip.
In our chip's case, the outgoing NMEA stream over UART / serial is not corrected to the proper date when the IS-GPS-200 stream rolls over.
The chip's NMEA stream is consumed by GPSD via UART / serial and made available for the rest of the system. We're only using the 'Generic NMEA0183' driver, nothing else is compiled in.
Would it make sense to correct this in "driver_nmea0183.c" when we process the RMC (possibly one or two other messages, our chip doesn't support many) message from the chip?
Apologies if I'm repeating myself, just trying to get this all straight in my head.
On Sat, Nov 10, 2018 at 2:27 PM Gary E. Miller <address@hidden
On Sat, 10 Nov 2018 09:33:54 -0500
Adam Heller <address@hidden> wrote:
> As far as the build, it may be oddities with our arm-linux toolchain /
> linux distro etc.
If it is sorta standard then I'd like complete patches. Usually if one
person reports a problem, there are many other silent sufferers.
> I'm not at my work computer but there was a missing
> header for fd_set <sys/select.h> in one file, i had to explicitly pass
> -std=gnu99 to get around errors being thrown for the inline asm in
> one of the headers as well. I can send you a patch on Monday if
> you're interested to see what I had to change to get this
> Ah, as far as gpsd having a hint to the current year from the clock...
> That's an interesting one.
Yes, a continuing source of irritation. Our best recommendatatio so
far, on RTC failure, is to reset the system time to the last time
of some canary file.
But that does not completely solve the week roll-over issue.
> So I'm guessing I'll have to do the week number calculation manually?
Not completely. The file timebase.c has functions for doing that.
There are also many tools available to do that job. But it does
not solve the rollover problem.
> Hopefully time isn't going to be going backwards any time soon,
You never know. Many GPS hard code the build date in their firmware,
and that, +19, becomes their rollover data.
> I can hard code in the current build year. I think that's similar to
> the solution / example code Trimble supplies.
gpsd could easily do that, but there is strong resistance to the
concept. That would break an aweful lot of the gpsd regression tests,
which would be scary.
Maybe gpsd should add a CLI option to enable forcing a minimum
year. That would not break the regression tests, and provide a knob
for people with GPS receivers that are problematic.
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
address@hidden Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin