[Top][All Lists]

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

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

From: Gary E. Miller
Subject: Re: accuracy in NMEA, F9P data point, UBX library and GUI
Date: Mon, 8 Nov 2021 18:07:13 -0800

Yo Greg!

On Mon, 08 Nov 2021 20:37:00 -0500
Greg Troxel <> 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.


> 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


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


But check out $GPGST:

GNSS pseudorange error statistics



Lat/Long position data

 ↲ ,,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)


> 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.

Interesting.  Using tkinter will be a problem for some.

And that uses this:

Not as complete as gps/, but pretty good.  Maybe better than 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.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  Tel:+1 541 382 8588

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

Attachment: pgp3ffycYD2fJ.pgp
Description: OpenPGP digital signature

reply via email to

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