Chris Blackburn <[email protected]> writes: > I'm using a U-blox X20P GPS chipset connected to gpsd to provide location > information to a local network. I'm noticing some strange behaviour when > I'm using NTRIP data to get a high accuracy lock. I notice that the > estimated error is much higher than I expected. It's also much higher than > the value I'm getting out of the official U-center software form u-blox.
To be pendantic, NTRIP is a method for transporting RTCM, so how good you get with it depends on which RTCM, from who and how good it is. But I understand from below that you are doing RTK and it looks like FIX, so indeed you should get very good accuracy, assuming an accurate reference data source. As a semi-related data point, I have an F9P that I use with MaCORS, an RTK network run by MassDOT, using Leica equipment with many of the reference stations also in national CORS. I suspect the results are good to about a cm. > This is what I see from cgps > > ┌─888888888888888888888888888888888888888888┐ > │ Time 2025-10-12T17:00:55.920Z ( 0)│ > │ Latitude <REDACTED> N │ > │ Longitude <REDACTED> W │ > │ Alt (HAE, MSL) 123.400, 76.900 m │ > │ Speed 0.06 km/h │ > │ Track (true, var) n/a, n/a deg │ > │ Climb 0.00 m/min │ > │ Status 3D RTKFLT FIX (33 secs) │ Status is odd; "3D RTKFLT FIX" seems to be a mix of things. > │ Long Err (XDOP, EPX) 0.38, +/- 5.7 m │ > │ Lat Err (YDOP, EPY) 0.53, +/- 7.9 m │ > │ Alt Err (VDOP, EPV) 1.06, +/- 24.4 m │ > │ 2D Err (HDOP, CEP) 0.66, +/- 12.5 m │ > │ 3D Err (PDOP, SEP) 1.25, +/- 23.8 m │ > │ Time Err (TDOP) 0.61 │ > │ Geo Err (GDOP) 1.29 │ > │ Speed Err (EPS) +/- 1424 km/h │ > │ Track Err (EPD) n/a │ > │ Time offset 0.041108807 s │ > │ Grid Square <REDACTED> │ > │ ECEF X, VX n/a n/a │ > │ ECEF Y, VY n/a n/a │ > │ ECEF Z, VZ n/a n/a │ > └─ ┘ That looks odd; those are huge errors. > However, the output below shows that the actual error being reported by the > GPS is 14mm horizontal and 12mm vertical. > > $ ubxtool -p NAV-PVT localhost:2947:/dev/ttyACM0 > UBX-NAV-PVT: > iTOW 61471560 time 2025/10/12 17:04:13 valid x37 > tAcc 21 nano 559727634 fixType 3 flags x43 flags2 xea fixType is 3. Assuming the same encoding as NMEA GGA that doesn't make sense. > numSV 25 lon <REDACTED> lat <REDACTED> height 122280 > hMSL 75828 hAcc 14 vAcc 12 I find it strange that hAcc is larger than vAcc. On the F9P the typical lowest values are 10mm for hAcc and higher for Vacc and I think 14mm for overall, but I'm a bit fuzzy on that. It is near universal for vertical error to be about double horizontal error. > velN 12 velE -19 velD -5 gSpeed 23 headMot 31364002 > sAcc 64 headAcc 14548972 pDOP 135 reserved1 4 52888 10343 headAcc is really high; hard to grasp what that means. pDop 135 if 1.35, is similar to 3D ERR rom NMEA. > headVeh 2648014 magDec 0 magAcc 0 > > Basically, what I want to ask is: Is this expected behavior or is this > something that's broken? I'd say 99% it's broken. > What I mean is that, if there's a good reason that the wrong number is > being reported. Such as, "we don't trust the numbers u-blox is giving as > they are known to be wrong" etc then I understand and that's just the way > of things. I totally don't trust the numbers, but that's about whether 10mm should be 20mm kind of not trust. > Or, is it that this is just something that's missing and the > fields from the UBX message are just not used by the gpsd code, but they > should be. If so, then I'm happy to have a rummage around in the code and > see if I can get it to use the correct figures. There are error fields in NMEA. Programs that just read NMEA display, like QField and Vespucci, display them (with the F9P). So just reading NMEA is not really the problem. I would capture NMEA and try to decode it by hand. There is GPGST that should give 1-sigma errors in meters.
