| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
A GPHDT with no heading was output as a heading of 0.00.
|
|
|
|
|
|
|
|
| |
This could create unparseable JSON messages.
Including regression tests.
Signed-off-by: Gary E. Miller <gem@rellim.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
All functional changes inside "#ifdef GREIS_ENABLE"
Includes new regression tests. All regressions tests
pass.
Developed by Gregory Fong, with help and support from
Virgin Orbit.
Signed-off-by: Gary E. Miller <gem@rellim.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
At one point, the check for MODE_SET made sense in
gpsd_binary_quality_dump(). But since then, the calling code was
refactored to only invoke nmea_tpv_dump() when REPORT_IS is set,
eliminating the dupes.
Remove the MODE_SET check and update the affected binary regression
check files to contain the expected GSA sentences.
Signed-off-by: Gary E. Miller <gem@rellim.com>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Co-authored-by: hkpatel <hpatel@sea-machines.com>
Co-authored-by: dwilliams <equipoise@gmail.com>
Signed-off-by: Gary E. Miller <gem@rellim.com>
|
|
|
|
|
|
|
|
|
|
| |
2 steps forward, one step back.
Changing cycle end for UBX broke old UBX samples. Reverting that
change breaks the new ECEF, that will need more work.
Fixing when a UBX cycle is cleared broke the UBX regression tests, but
the old way was wrong. So update the regression tests.
|
|
|
|
|
| |
The chk file is empty, not sure how to get 'scons check' to do the
right thing with it. New bug #52678 to add regression on this flie.
|
| |
|
|
|
|
|
| |
Interesting because it has no altitude in TPV, which used to crash
gegps.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 71a487d8, "Support UBX NAV-PVT", added a new regression test
case, but the .chk data didn't actually match. All mismatches were
a difference of 0.01 in the 'epc' value. Whether the difference
is due to an actual code difference or excessive numeric sensitivity
remains to be seen, but in the meantime this gets rid of the failure
which seems to be consistent.
TESTED:
Ran "scons build-all check", which now succeeds.
|
|
|
|
|
|
|
| |
NAV-SOL has only been retained for backwards compatibility;
users are recommended to use the UBX-NAV-PVT message in preference.
A regression test case using ublox-neo-m8n is also added.
|
|
|
|
|
|
|
|
|
| |
This reverts commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c.
This commit broke PPS on uBlox. PPS would flip from offset
0 to offset -1, and back, every few minutes.
Also stray characters (^M) in the log files.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NAV-SOL has only been retained for backwards compatibility; users are
recommended to use the UBX-NAV-PVT message in preference.
A regression test case using ublox-neo-m8n is also added.
Also fix the checking on valid flags of iTOW and fTOW and process fTOW whose
range is +-500us. Update test/dae/ublox-aek-4t.log.chk accordingly.
Signed-off-by: Clark Li <clark.li@cohdawireless.com>
Signed-off-by: Fred Wright <fw@fwright.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This one instance of the 63 character-pushback changes in commit
fbaaaa76 broke the packet-regress test, though that was masked due to
another bug's causing that test to be disabled. With this instance
reverted, the test passes again.
It's not entirely clear why a change within Zodiac-specific code broke
one SiRF test and two Evermore tests, but that's empirically the case.
This change affects one daemon regression test. The ublox-8 test
begins with a $GPRMC sentence preceded by a bunch of garbage. The
broken version of packet.c skips this sentence, while the fixed
version recognizes it. The test data has been updated accordingly.
TESTED:
Manually ran the packet-regress test successfully.
Ran "scons build-all www check".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This updates the test data to reflect the two new tests that were
added in commit 58a35243. This was neglected before due to a bug
(commit 40c40cc4) that causes the packet-regress test to be
inaccessible. This test still doesn't pass due to a bug introduced in
commit fbaaaa76, but this update makes the current failure equivalent
to the previous failure. In particular, it avoids gratuitous
miscompares due to mismatches in the line numbers.
TESTED:
Running the test manually now gets the same errors as it did prior to
the addition of the new tests.
|
| |
|
|
|
|
| |
regressions updated. Other rdivers prolly need similar fixes.
|
|
|
|
|
|
| |
The broken tests are the ones where we have to do our own conversion from
week/second to UTC because the device either doesn't supply UTC or its
reporting is broken.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
GPGSA is commonly taken to be 12 sats. Prevent ublox and TSIP drivers
from outputting more. No regressions had more than 12 anyway.
DOPs that were NaNs were output as 0.0. Now output as blanks.
Too easy for a user to take 0.0 as a real number.
|
|
|
|
| |
Signed-off-by: Gary E. Miller <gem@rellim.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This is a "with fix" case for the Navika-100 chip, and includes GSV
data for the real PRN 1. A previously fixed bug caused a phantom PRN
1 instance to appear for each GSV sentence, due to misinterpreting the
signal ID as a satellite ID.
TESTED:
Verified that this test illustrates the "phantom satellite 1" bug
prior to that bug's being fixed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was causing problems in sign extension.
On amd64/Gentoo sign was extended:
(unsigned int)(char 0x80) became: 0xfffffff80
But on Pi2/Wheezy the same thing became: 0x80.
The obvious fix is to make it unsigned, as god intended.
All regression tests pass on pi2/wheezzy and amd64/gentoo.
|
| |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an entire 4K buffer of packet data contains no newlines, it's
simply retained for future use. But the code was failing to clear the
previous response in that case, causing the caller to see duplicate
data.
Since this bug only mattered with lines longer than 4K bytes, and
since even then it varied as a function of the alignment of lines
vs. 4K boundaries, it was never seen on previous regression tests.
TESTED:
Ran "scons build-all check" with the updated code and the corrected
test data for RTCM3.2.
Signed-off-by: Gary E. Miller <gem@rellim.com>
|
|
|
|
| |
All regressions pass.
|
| |
|
|
|
|
|
| |
Also update the affected regression files. gpsd had been
throwing away the DGPS status.
|
| |
|
|
|
|
| |
I have seen up to about 490 in RTCM3.
|
|
|
|
|
| |
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.
|
|
|
|
| |
2d and 3d modes.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Notice that the chk file shows the sats are not properly marked.
Sat 214 is the only one marked used in a 3D fix!
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Useful reference set of sentences but not as useful as
part of regression data
Took over 45 minutes on one architecture.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moved some sample entries from ais-nmea-sample.log
to sample.aivdm and commented them out.
these were generating warning/errors in gpsd
Likely malformed but would like to stash them away
to be looked into more when someone with specs
or other sample data can look for similar types of
data
|