gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gpsd-users] Driving to tunnel with UBlox M8 did not show deadreckoning


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. 



Attachment: correct-fix-quality-mapping.patch
Description: Binary data



Br,
Irko Aario


reply via email to

[Prev in Thread] Current Thread [Next in Thread]