| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
It seems the gpsd epc is more pessimistic than from the GPS.
|
|
|
|
|
| |
Turns out epd also came from SiRF, but never made it to TPV.
Regressions changed to show new epd data.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The start of this overly large patch was to simply move the test
for MODE_2D/3D flipping, which only affect NMEA 183, back into
driver_nmea0813.c
But that was intertwined with how gpsd_error_model() computes
derived variables, which required major changes to how NMEA 183
mode_2D/3D are set.
This ultimatly led to major regression test results. Almost all for
the better.
I tried to break it up, but moving from one paradigm to another
needed one big jump...
|
|
|
|
| |
This speeds things up a bit, while waiting ACK/NACK when needed.
|
| |
|
|
|
|
|
| |
The SiRFstar step type init will get used on other drivers
that now have similar buffer stuffing issues.
|
| |
|
|
|
|
| |
Which showed several unhandled cases...
|
|
|
|
|
| |
Try to only send one message at a time. But not really waiting
for ACK/NACK.
|
| |
|
| |
|
|
|
|
| |
ttff might be interesting...
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
unsetmidXX was getting corrupted.
|
| |
|
|
|
|
|
| |
SIRF_MSG_SSB_XO_TEMP_REC_VALUE decoded GPS time wrong. Now shows
correct temp.
|
|
|
|
|
|
| |
This reverts commit 1c7f65acffb492c45b48d5f97a9d8f9d69c74e42.
Fat fingered...
|
| |
|
|
|
|
| |
And some comments.
|
| |
|
|
|
|
|
| |
For some reason SiRFstar reports every possible sat slot, even
when it has no data. Ignore the content free slots.
|
| |
|
|
|
|
|
| |
Too bad printf() does not understand specified size integers like
uint64_t.
|
|
|
|
| |
SiRF loves to add incompatible changes to their messages....
|
|
|
|
| |
Just shows up in better logging.
|
| |
|
|
|
|
| |
Change "control type" to MID. Start to document QZSS
|
|
|
|
| |
The Fix Mode still needs to be done.
|
|
|
|
| |
More work to do. There is an off by one second thing too.
|
|
|
|
|
| |
This is initial support for SiRFstarV chipset.
Regressions updated. Skyview seems to work.
|
|
|
|
| |
Sadly no change to the regression tests as the data is just logged.
|
| |
|
|
|
|
| |
Not hard since SiRF only uses GPS and SBAS.
|
|
|
|
|
| |
This macro was wrong, and causing valid sats to not be included in
the COP calculations.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Any DOP not provided from the GPS must be reset so that the
next SATELLITE_SET will recompute it. This problem is not
only on SiRF and not only on TDOP. But I do not have the proper
fixes yet.
|
|
|
|
| |
Also two #defines for gpspipe.c
|
|
|
|
|
| |
NTPTIME is from the serial stream, it never had anything to
do with PPS and it just confused everyone.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Simon Hradecky <shradecky@nomissoft.com> writes:
I just verified a bug in the driver_sirf.c (version 3.15, I just discovered
3.16 was released a few days ago, didn't yet check this version), routine
sirf_time_offset:
Line 637:
double retval = NAN;
This sets the default offset to NAN, which later results in the real time in
ntp shared memory etc. to be set to 0 with a valid time stamp, further
causing the NTP daemon to suddenly jump to year 1970, if the SIRF last status
is not known to the driver.
I believe, this default offset would be correct to read:
double retval = 0;
The problem with the real time set to 0 as result of the NAN time offset in
the SIRF driver (while the clock time was correct) in ntp shared memory
segment occurs frequently (but not always) with GlobalSat SIRF modules, in
our case EB5531RE. This can happen at any time of operation, it is possible
that the gpsd starts out entirely correct with proper time stamps in all
fields and suddenly forces the NTP to 0 seconds since 1970 because the offset
becomes NAN.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The proximate cause was that we've been seing emission of error
messages that were randomly and disturbingly variable across different
environments - notably Raspbian and Gentoo splint gave nontrivially
different results than Ubuntu 14.10 splint. And this was *not* due to
Ubuntu patches! A pristine splint built from the 3.1.2 tarball on
Ubuntu didn't match the Raspbian and Gentoo results either.
But this has been coming for a while. Easy access to more modern
static analyzers such as coverity, scan-build and cppcheck has been
decreasing the utility of splint, which is unmaintained and somewhat
buggy and not easy to use.
Only file not cleaned is ppsthread.c, because Gary has been working
on it during this cleanup.
All regression tests pass. PPS observed live on GR601-W.
|
| |
|
| |
|
| |
|