On 11/10/2018 2:33 PM, Adam Heller
wrote:
Gary,
As far as the build, it may be oddities with our arm-linux
toolchain / linux distro etc. 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 building.
... All that being said the only things I really needed to
compile in were NMEA183 support, I'm wondering if my scons
config was off....
Ah, as far as gpsd having a hint to the current year from
the clock... That's an interesting one. Obviously we have a
clock on the boards, however it's all pinned to a tiny watch
cell RTC battery which likes to die if the units aren't hooked
up to a power supply very often (they get trickle charged when
the units powered). And these are all units that last saw
production between 2010 and 2013. Even my 3 development units
all had bad RTC batteries (and therefore system time showed as
unix epoch on boot).
So I'm guessing I'll have to do the week number calculation
manually? Hopefully time isn't going to be going backwards any
time soon, maybe I can hard code in the current build year. I
think that's similar to the solution / example code Trimble
supplies.
Adam,
We have similar problems with our products (also ARM based, also
with a battery backup that cannot wholly be relied upon).
Firstly, the air-interface documetn ICD-GPS-200 specifies GPS time
in the form Week Number (0-1024), Seconds into Week (0-604799) and
UTC Offset.
Most modern GPS receivers fix the 1024 week number roll-over
internally. For those that don't the problem arises every 1024
weeks (19.69 years). The hack which I used in my code and the
Trimble TSIP clock driver works once - for the first roll-over - a
different solution is needed for subsequent roll-overs which
includes some sort of state or memory.
Depending on how long your products need to last an alternative hack
can be in the form:
#define GPS_START_YEAR 1986
unsigned short sw_build_year;
unsigned short min_weeks;
unsigned short week_no;
sw_build_year = get_year_from_compile_date(); // fetch the
year from your software compile time - you provide this
min_weeks = (sw_build_year - GPS_START_YEAR) * 52;
week_no = get_week_number_from_gps(); // get GPS week
number - you provide this
for (; week_no <= min_weeks; week_no += 1024); // fix up
week number - convert to extended week number
our newer software to run on old products does this and it fixes the
problem for around 18-19 years on from when we release a drop of
software.
Mike
Adam
Yo Adam!
On Fri, 9 Nov 2018 20:50:16 -0500
Adam Heller <address@hidden> wrote:
> Yeah, I managed to reproduce the rollover today. Not
sure what I was
> doing wrong yesterday but today the date jumped back
as expected.
Ouch.
> Spent the other half of the day getting the latest
gpsd release
> compiling for our platform.
Ouch again. Anything we could do to make that easier?
> Am I correct in assuming that gpsd handles the
rollover in the newer
> relases?
Yeah, we assume that...
The code to handle week rollover is in timebase.c. It
needs your system
clock to be close before starting gpsd.
We look forward to the results of your tests.
RGDS
GARY
---------------------------------------------------------------------------
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
--
|