| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This showed up a bug where rtcm3_unpack() was not clearing its
rtcm3 data, which is a union with the attitude data.
|
|
|
|
| |
A GPHDT with no heading was output as a heading of 0.00.
|
|
|
|
| |
Disabled as it breaks the cycle decoder in test/daemon/rst39.log
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that the Galileo constellation is live, the NMEA 4.1 standard
appears to have standardized on the "$GA..." prefix for
Galileo-specific messages. The lexer currently filters these out; this
patch ensures they go through to e.g. gpspipe -r. (I tore my hair out
for days trying to figure out why these were not being passed through
even though I could see them using screen etc.)
Also added logic to the GSA and GSV message parsing to account for the
Galileo messages. It probably needs more work to match up satellite
numbers between the GSA and GSV messages and to account for the GNSS
type field in NMEA 4.1, but it's a start at least.
I also fixed a couple of situations where the 'GB' prefix was being
ignored even though 'BD' was not. This leads to a regression in
test/daemon/beidou-gb.log, but the "regression" is actually incorrect
old behavior (JSON messages omitting BeiDou satellites) exposed by the
patch.
Signed-off-by: Gary E. Miller <gem@rellim.com>
|
| |
|
|
|
|
|
|
|
| |
Turns out to be a NOP. Every GPVTG with field 9 == N, also had
blank track field.
But starting point for further work.
|
|
|
|
|
|
|
| |
Co-authored-by: hkpatel <hpatel@sea-machines.com>
Co-authored-by: dwilliams <equipoise@gmail.com>
Signed-off-by: Gary E. Miller <gem@rellim.com>
|
| |
|
| |
|
|
|
|
|
|
|
| |
Ensure mask is fully set.
TESTED:
'scons build-all check' still passes
|
|
|
|
| |
regressions updated. Other rdivers prolly need similar fixes.
|
|
|
|
|
| |
Gotta clear the computed DOPs so that fill_dop() will recompute
them. I suspect this is the tipo of the iceberg.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug was intended to be fixed by commit 074499e16. The problem is
that the total satellite count in xxGSV sentences is per-talker rather
than global, but the sanity check only has the global total available
for comparison. The original change attempted to fix this by
suppressing the check whenever non-GPS talkers are detected (in the
current cycle), on the assumption that GPGSV blocks always come first.
Thus, the GPGSV total would be checked, but not the others. However,
the sense of the conditional was inverted, disabling the check for
GPGSV while causing it to produce bogus warnings in most multi-GNSS
cases. This change corrects that.
The proper fix for this would be to implement per-talker satellite
totals. There's now a FIXME to that effect.
TESTED:
All regression tests pass, and running gpsmon against a GPS/GLONASS
receiver no longer produces spurious warnings (when enabled).
|
|
|
|
|
| |
Sad, C99 did not actually standardize the defines to invoke
the standard.
|
|
|
|
| |
uint is now unsigned int.
|
|
|
|
|
|
| |
driver_nmea0183.c:1255:10: warning: taking the
absolute value of unsigned type 'unsigned int' has no effect
[-Wabsolute-value]
|
| |
|
| |
|
|
|
|
|
|
|
| |
Eric will gag at my abuse of the parser, but I'm not up to a
major resturcture today.
Not sure how to output the error in JSON.
|
| |
|
| |
|
|
|
|
|
| |
Not all doc specifies the number of PRNs in the sentence. The
doc that does usually says 12.
|
|
|
|
|
| |
NTPTIME is from the serial stream, it never had anything to
do with PPS and it just confused everyone.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change to permit the new signal ID in the GSV sentences broke the
loop end test, causing an extra "satellite" to be processed when the
signal ID is present. The signal ID itself is misinterpreted as a
satellite ID, with the other three values coming from indexing off the
end of the buffer (typically getting zeroes). For receivers
(incorrectly) reporting a signal ID of zero, this would typically get
filtered out by the zero-ID filter (but not in non-GPS cases prior to
fixing another bug), so it often didn't matter. But for receivers
reporting a value of 1 (L1 C/A), this resulted in multiple phantom
satellites with "PRN" 1. If the real PRN 1 was in use, it also
screwed up the "active" count.
The fix is just to round the field count down to a multiple of 4 prior
to using it as the loop's end test.
Also removes an incorrect comment about there being no more than three
GSV sentences in a group.
TESTED:
Ran "scons build-all check". Also verified that, with the Navika
receiver that reports the signal ID as 1, gpsmon and xgps no longer
report phantom PRN 1 satellites, and cgps no longer misbehaves in some
other (uninvestigated) way due to the confusion.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because the GSV processing invokes nmeaid_to_prn() before checking for
an apparent ID of zero, it was possible for zero (or blank) IDs for
non-GPS sentences to get offset to nonzero values and hence not
filtered out. This fix ensures that only nonzero values are adjusted.
Due to this bug, two of the regression tests had incorrect reference
results:
1) The nl2008u receiver includes the new signal ID field, though the
reported value is (incorrectly) zero. Due to another bug (to be fixed
separately), this is interpreted as an additional ID in each GSV
sentence. The zero-ID filter excluded this correctly for GPGSV, but
for GLGSV it saw phantom entries for "ID 37".
2) The sl869 receiver reports empty fields for unused satellite slots
in any GSV sentence. Again, this didn't hurt for GPGSV, and the GLGSV
test data happens to have a multiple of four satellites, but the QZGSV
sentences produced phantom "ID 193" entries.
TESTED:
Ran "scons build-all check", which passed after updating the two
regression cases noted above.
|
|
|
|
|
|
|
|
| |
What could go wrong with code that says this:
/* GLONASS GL doesn't seem to do this, but better safe than sorry */
GPGSA prn 21 was becoming prn 58
|
|
|
|
|
|
| |
Skip blanks now.
Blank in BDGSV became PRN=200
Blank in GLGSV became PRN=37
|
|
|
|
|
| |
satellites_visible is used as a counter by xxGSV. so setting
in from xxGGA beaks some regressions.
|
|
|
|
|
| |
This was messing up xxGSA which uses satellites_used as a counter
and index into sats_used.
|
|
|
|
|
| |
A normal probe fails, and is not needed since we can wait for PSTI.
Update mode detection in processGLL() to handle 'F', 'R' and 'S' modes.
|
|
|
|
|
| |
This duplicates, but improves on the accuracy of GPVTG.
Also add a bit on PSTI,001 and PSTI,032
|
|
|
|
|
| |
GNGSA's almost always come in pairs, and never with any other
flavor of xxGSA.
|
| |
|
|
|
|
| |
Fix a comment, clean up a log output.
|
|
|
|
|
| |
Decode $PSTI,030 and $PSTI,032 to log out
Not used in session_t yet.
|
|
|
|
|
|
|
| |
The time in the packet was seconds in the day. It needed to be
merged with the known date.
rergressions updated. The chk files clearly show it is better now.
|
|
|
|
|
|
|
|
| |
The combine code stolen from the GPGSV/BDGSV combining code.
Just 2 regressions changed. No surprise since Beidu rarely seen
in the USA.
I eyeballed the changes in the chk files and they look good.
|
| |
|
| |
|
| |
|
|
|
|
| |
And example of the failure in test/daemon/skytrack-fixB.log.chk
|
| |
|
| |
|