Checksum error and then a string of unknown headers

[gos-h]

I have been experiencing an elusive problem recently that I am looking for advice on. I am connecting to a u-blox ZED-F9P receiver over USB with PyGPSClient. I am sending the default NMEA messages, as well as RXM-RAWX and RXM-SFRBX messages with a 10Hz observation rate and 1Hz NAV rate.

When I first connect, everything seems alright. However, at some point I will start getting errors where one message will fail the checksum, followed by a string of messages with unknown headers (I'm guessing the software is parsing the incoming bytes wrong and gets out of sync somehow). This is creating big gaps in my data. I have been having difficulty troubleshooting this as it is intermittent and usually takes 30+ minutes to start showing up.

Has anyone experienced this before? I am using a baud rate of 115200 and decent quality USB cables. There shouldn't be anything else attempting to access the COM port.

[semuadmin]

Hi @gos-h

I'm unable to reproduce your specific issue but at a measurement interval of 100ms (10Hz), you're almost certainly exceeding the capacity of the ZED-F9P's internal and/or external TX output buffers. If you enable the System Monitor widget you can see how much stress the device's transmission buffers are under. Here's a ZED-F9P (HPG 1.51) running at 10Hz and 115200 baud with a full cohort of NMEA, RXM-RAWX and RXM-SFRBX output messages:

You can see the I/O buffer is completely maxed out after approximately 30 seconds of running, and you're starting to see GNTXT txbuf alloc (buffer overflow) error messages. u-blox receivers often exhibit indeterminate behaviour when the TX buffers are under stress.

You can try the following...

1. Increasing the baud rate still further (F9P can go up to 921600, but bear in mind not all hosts can support that).
2. Reduce the output message cohort - for example, disable (or reduce the output rate of) all the GSV and GSA messages.
3. Disable NMEA output and enable minimal UBX instead (e.g. NAV-POS, NAV-SAT, NAV-DOP).
4. Increasing the measurement interval to, say, 250ms (4 Hz).

... but in general terms there may be little point in running RAW output at a rate higher than 1 Hz as most GNSS constellations simply don't output raw data that quickly. There are numerous posts on this in the u-blox support forum e.g. https://portal.u-blox.com/s/question/0D52p00008HKCS1CAP/how-to-get-10hz-refresh-rate-on-rawx-message-in-ucenter-windows.

What specifically are you looking to achieve here?

[semuadmin]

@gos-h

semuconsulting/pygnssutils#143

As a general observation, if you're looking to record extended GNSS data logs (say, 30 mins or more) and data continuity is key, you may be better off with an unattended (i.e. CLI) rather than attended (i.e. GUI) data logger.

You can always replay the logs in a GUI at a later date if you have a specific need to eyeball the data.

Check out the gnssstreamer CLI utility.

Here, for example, is a CLI gnsstreamer command which I regularly use to a) configure an F9P to output the requisite UBX RAW & NAV message cohort, and b) record the binary data output to a file:

gnssstreamer -C gnssstreamer_zedf9p_raw.conf

The gnssstreamer_zedf9praw.conf text file contains a series of command line arguments:

port=/dev/ttyACM0
baudrate=115200
timeout=3
verbosity=2
format=2
cliinput=5
input=/home/semuadmin/Downloads/pygpsconfig_zedf9p_raw.ubx
clioutput=1
output=/home/semuadmin/Downloads/pygpsdata_zedf9p_rawlog.ubx

The pygpsconfig_zedf9p_raw.ubx binary file contains a series of UBX CFG-VALSET configuration commands previously recorded using PyGPSClient's 'Configuration Command Recorder' facility.

If you wanted to start the above command under Linux as a unattended 'daemon' and just leave it running in the background, you could use something like this (to terminate, use the Linux kill command):

setsid gnssstreamer -C gnssstreamer_zedf9p_raw.conf >gnssstreamer.log 2>&1 < /dev/null &

(I have this set up as an alias in my .zshrc profile)