|
From: | Irko Aario |
Subject: | [gpsd-users] Driving to tunnel with UBlox M8 did not show deadreckoning (estimated) correctly with gpspipe -r |
Date: | Thu, 3 Oct 2019 20:55:39 +0300 |
Hi, Without the gpsd running, the raw NMEA sentences from the device (/dev/ttyACM0) show valid looking NMEA sentences. GNGGA shows the fix quality as 6 Estimated (dead reckoning) as it should in the tunnel with UBlox M8. But when starting up gpsd and running gpsd -r, the gpsd switches to raw mode and the GGA sentences are now generated with pseudonmea() -function and they have different data compared to raw NMEA sentences. The GGA messages now start with $GPGGA. The field for fix quality now shows 1 or 5, although 5 should not even be possible with UBlox when NMEA v 4.0 was used (as was the case) Further investigation showed that when parsing binary messages in driver_ubx.c they will set the session->gpsdata.status to be one of the following from gps.h: STATUS_NO_FIX 0, STATUS_FIX 1, STATUS_DGPS_FIX 2, STATUS_RTK_FIX 3, STATUS_RTK_FLT 4, STATUS_DR 5, STATUS_GNSSDR 6, STATUS_TIME 7, STATUS_SIM 8 But when generating pseudonmea, the status is used to generate the fix quality value in **GGA message. But the values do not map correctly to fix quality values specified in NMEA (https://www.gpsinformation.org/dale/nmea.htm), which specifies the following values: 0=invalid, 1=gps fix, 2=dgps fix, 3=pps fix, 4=Real Time Kinematic, 5=Float RTK, 6=estimated (dead reckoning), 7=manual input mode, 8=Simulation mode The attached patch demonstrates a fix for the problem, assuming that I’ve understood the problem or actually the inner workings of gpsd. |
correct-fix-quality-mapping.patch
Description: Binary data
Br, Irko Aario |
[Prev in Thread] | Current Thread | [Next in Thread] |