Hi All, 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. 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) │ │ 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 │ └─ ┘ 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 numSV 25 lon <REDACTED> lat <REDACTED> height 122280 hMSL 75828 hAcc 14 vAcc 12 velN 12 velE -19 velD -5 gSpeed 23 headMot 31364002 sAcc 64 headAcc 14548972 pDOP 135 reserved1 4 52888 10343 headVeh 2648014 magDec 0 magAcc 0 Basically, what I want to ask is: Is this expected behavior or is this something that'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. 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. Thanks for your advice Chris
