Re: accuracy in NMEA, F9P data point, UBX library and GUI

[Gary E. Miller]

Yo Greg!

On Mon, 08 Nov 2021 20:37:00 -0500
Greg Troxel <gdt@lexort.com> wrote:

> I have just been dealing with making my ardusimple F9P work again
> after a firmware upgrade and getting u-center (via wine) to configure
> NMEA output on the UART going to the wifi interface.   That has led
> me to look at the NMEA messages it is sending to see if there is some
> kind of accuracy, so that I could parse it for Vespucci to get an
> error circle, even if it's useful only as status rather than real
> accuracy.

Cool.

> Looking at the standard NMEA messages, I see
>   - counts of SVs and CNR
>   - HDOP and other DOPs
>   - mode, including 2d/3d, DGNSS, RTK/fixed and RTK/float

Yeah.

> but I do not see any EPE, URA, UERE and so on.

Yup.

But check out $GPGST:

GNSS pseudorange error statistics

$GPGST,082356.00,1.8,,,,1.7,1.3,2.2*7E

Or $PUBX:

Lat/Long position data

$PUBX,00,081350.00,4717.113210,N,00833.915187,E,546.589,G3,2.1,2.0,0.007,77.52,0.007
 ↲ ,,0.92,1.19,0.77,9,0,0*5F

> I gather there is some proprietary UBX NMEA message "UBX,00" with some
> kind of horizontal accuracy, but I'm not super inclined to go there
> for a Vespucci patch.  I also don't want to add UBX parsing.

Not much point to the F9P unless you parse the UBX.  Feel free to
grab the gpsd driver_ubx.c code.

> Am I correct that with standard NMEA, there is no way to get an
> expected error (other than making it up from CNR, #sats, HDOP)?  This
> seems to be how it is, but it strikes me as an odd thing to leave out.

Other than $GPGST, none that I know of.

> I am contempating generating a faux accuracy:
> 
>   10m * HDOP (non-differential)
>   5m * HDOP (differential)
>   1m (RTK/float)
>   0.1m (RTK/fixed)

Ugh.

> I am relaively confident in the RTK values, and I suspect the answer
> about the other ones is to go observe a known mark a bunch and see how
> it is, but I am curious if anyone thinks that the above is off more
> than 3 dB.

Works fine, until you move.

> random datapoint:
>   I know others have not been able to get good results with the F9P.

The F9P is designed for RTK with a nearby base station.  If you do
not have that, then it is not a huge improvement ove the 8 series.
But it does well with bad skyview due to the extra constellations.

>   Just now I have seen both 4 and 5 for fixed/float, matching the RTK
>   status blinkenlight on the board.  Using an ardusimple L1/L2
> antenna, it is actually operating in RTK/fixed, inside on the top
> floor, via network RTK from MassDOT (MSM4 IMAX), with reference data
> on L1/L2 x {GPS, GLONASS, Galileo, BeiDou}, and holding position to
> better than 10 cm.  (Yes, I know it's ridiculous to try to do RTK
> indoors and the position is probably not entirely right, but with 4
> constellations there are an impressive number of satellites.)

The F9P is impressive indoors.  I would say 10 cm sounds good.

> Also, when looking, I came across this code, which seems perhaps
> useful. So far I have only skimmed the README.
> 
>   https://github.com/semuconsulting/PyGPSClient

Interesting.  Using tkinter will be a problem for some.

And that uses this:

https://github.com/semuconsulting/pyubx2/tree/master/pyubx2

Not as complete as gps/ubx.py, but pretty good.  Maybe better than
ubx.py as a standalone library.  Not as good on the decoding.  I did not
see support for the newer ubx configuration items.  Maybe I missed it.

Using Python could be too slow.  The few gpsd Python utilities like
gpsplot are really too slow for production use.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgp3ffycYD2fJ.pgp
Description: OpenPGP digital signature