| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Required a regression-test rebuild.
The immediate reason for this was Savannah bug bug #37810:
satellites_used always zero via gpsd socket with multi nmea GSA/GSV. As the
user reporting said:
The "satellites_used" field in a "struct gps_data_t" filled in by
"gps_read" is always returning zero.
This module emits GNGSA messages in a group of three. My information
is that the first GNGSA pertains to GPS, second to GLONASS, third to
QZSS. It also emits GSV messages using talker id's GL,GP,QZ.
The larger point is that DOPs are likely to be valid for longer than
a GSV reporting cycle; they change only slowly as the actual sat
configuration does. So it makes sense to retain them.
|
|
|
|
| |
Required a regression-test rebuild.
|
| |
|
|
|
|
|
|
|
|
| |
Protocol version number is bumped. Python and C test clients are known
to work; interfaces of the C and Python client bindings are
unchanged. Third-party client-side bindings which rely on naively
copying JSON members will break (implementers have been repeatedly
warned not to do this).
|
|
|
|
|
| |
Copes better with the Placer 450. Exposes some dodgy reporting on various
unusual NMEA devices.
|
|
|
|
| |
It suppresses some previously emitted but contentless sentences.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This solves the disappearing epx/epy bug on SiRFs, but it was actually a
systemic problem that affected several drivers. Navigation solution messages
were clearing DOPs, making it impossible for the error modeller to compute
estimates. New logic: Clear DOPs only when we get a skyview report. They'll
be regenerated by our visibility-matrix calculation when the skyview sentence
is analyzed.
If a sentence from the device supplies a DOP between the time the visibility
calculation is done and when the next fix is reported, it will override
our computed value. This might change later!
This change required a regression-test rebuild.
|
|
|
|
|
|
| |
The guard controllong DOP computation wasn't right. The result was
that x/y error estimates were computed much less often than they
should have been.
|
|
|
|
|
| |
Also, include some additions of copyrights on the test logs that somehow
wint missing from the last commit (probably git operator error).
|
|
|
|
|
|
|
|
|
|
|
| |
These were causing port problems on systems with 32-bit time. It turns
out the problem was with the assumption that these devices always
deliver a valid time in $GPRMC. They don't when the navigation
warning bit (second field 'V') is on! The NMEA driver now knows.
Also, the code now contains a sanity check - it will log a complaint
if it sees a date moere than a year in the future. This invariably
indicates some driver-level problem with time extraction.
|
|
...to something more descriptive.
|