pyubx2 driver for C102-F9R

[Shreyas120]

I have driver to connect to F9R (C102-F9R) over a serial port and parse incoming UBX protocol messages using pyubx2. This driver works great (setting configurations and parsing incoming data) with older F9R devices (assembled 01/23) with firmware 1.21.

I got 2 new F9Rs (C102-F9R, assembled 04, 24) and I am not able to get the driver to work with these. However, I can do all configurations and streaming in u-center, so the devices seem to work fine. The least I want to do is parse UBX messages being received on the serial port, here are the things I tried:
Make desired configurations in u-center (written to all layers) and try streaming messages using Python driver
Tried flashing them with HPS 1.21 and use unmodified Python driver
I am unable to print raw data on the correct port cat /dev/ttyUCM0

Setting configurations:
I can set some configurations from the driver but cannot set others (receive ACK-NAK). It is possible to set others via u-center. I have gone through the changelog for HPS1.3, also tried with HPS 1.4. In the code block below the comment configurations are never acknowledged and I cannot understand why (also get ACK-NAK when I try to poll those keys which I cannot set)

def configure_ublox(stream: Serial, lock: Lock, config: DriverConfigs._Ublox) -> bool:
    """
        Configure Ublox device with specified settings.
        Note: Could be specific to u-blox F9 series devices.
    """
    try:
        # Factory reset for consistent performance of the device driver
        reset_msg = UBXMessage("CFG", "CFG-CFG", SET,
                               clearMask=b"\x1f\x1f\x00\x00",
                               loadMask=b"\x1f\x1f\x00\x00",
                               devBBR=1, devFlash=1, devEEPROM=1)
        if not send_message(stream, lock, reset_msg):
            raise RuntimeError("Factory reset unsuccessful")

        # Configure device settings
        cfg_payload = [
            
            # Nominal time between GNSS measurements, min value is 25ms
            ("CFG_RATE_MEAS", 25), 
            # Ratio of number of measurements to number of navigation solutions, min val is 1 
            ("CFG_RATE_NAV", 4), 
            ("CFG_USBOUTPROT_UBX", 1),
            ("CFG_NAVSPG_DYNMODEL", 4),

            # ("CFG_NAVHPG_DGNSSMODE", 3), #Run in RTK-FIXED mode 
            # ("CFG_RATE_NAV_PRIO", 10),
            # ("CFG_MSGOUT_UBX_NAV_PVT_USB", 10), 
            # ("CFG_MSGOUT_UBX_NAV_SAT_USB", 1), 
            # ("CFG_MSGOUT_UBX_SEC_SIG_USB", 1), 

            # UART settings for RTK corrections
            # ("CFG_UART1_ENABLED", 1),
            # ("CFG_UART1_BAUDRATE", 115200),
            # ("CFG_UART1INPROT_RTCM3X", 1),
                        
            # ESF settings 
            # ("CFG_SFCORE_USE_SF", 1),

            #Aided start settings 
            # ("CFG_NAVSPG_ACKAIDING",1),
        ]

        # poll_keys = [cfg[0] for cfg in cfg_payload]
        # msg = UBXMessage.config_poll(layer=POLL_LAYER_RAM, position=0, keys=poll_keys)
        # send_message(stream, lock, msg)
    
        cfg_msg = UBXMessage.config_set(
            layers=SET_LAYER_RAM, transaction=0, cfgData=cfg_payload)
        if not send_message(stream, lock, cfg_msg):
            raise RuntimeError("Failed to set configurations")

    except Exception as err:
        rospy.logfatal(err)
        rospy.signal_shutdown("Failed to configure GPS device")

    return True

2. https://github.com/semuconsulting/pyubx2/blob/master/examples/ubxconfigdb.py

Starting read thread...


Polling UART configuration in the volatile RAM memory layer via CFG-VALGET...
(This should result in ACK-ACK and CFG-VALGET responses)
<UBX(ACK-NAK, clsID=CFG, msgID=CFG-VALGET)>
<UBX(INF-NOTICE, message=u-blox AG - www.u-blox.com)>
<UBX(INF-NOTICE, message=HW UBX 9 00190000)>
<UBX(INF-NOTICE, message=EXT CORE 1.00 (cd6322))>
<UBX(INF-NOTICE, message=ROM BASE 0x118B2060)>
<UBX(INF-NOTICE, message=FWVER=PMP 1.04)>
<UBX(INF-NOTICE, message=PROTVER=24.00)>
<UBX(INF-NOTICE, message=MOD=NEO-D9S)>
<UBX(INF-NOTICE, message=LBAND)>
<UBX(INF-NOTICE, message=PMP)>
<UBX(INF-NOTICE, message=ANTSUPERV=)>
<UBX(INF-NOTICE, message=ANTSTATUS=DONTKNOW)>
<UBX(INF-NOTICE, message=PF=FFEFF)>
<UBX(INF-NOTICE, message=UBXDBG ENABLED)>

Polling UART configuration in the BBR memory layer via CFG-VALGET... 
(This should result in an ACK-NAK response in the  absence of an existing BBR configuration setting)
<UBX(ACK-NAK, clsID=CFG, msgID=CFG-VALGET)>

Setting UART configuration in the BBR memory layer via CFG-VALSET... 
(This should result in an ACK-ACK response)
<UBX(ACK-NAK, clsID=CFG, msgID=CFG-VALSET)>

Polling UART configuration in the BBR memory layer via CFG-VALGET... 
(This should result in ACK-ACK and CFG-VALGET responses, provided the configuration is valid for your particular device)
<UBX(ACK-NAK, clsID=CFG, msgID=CFG-VALGET)>

Unsetting UART configuration in the BBR memory layer via CFG-VALDEL... 
(This should result in an ACK-ACK response)
<UBX(ACK-NAK, clsID=CFG, msgID=CFG-VALDEL)>

Polling UART configuration in the BBR memory layer via CFG-VALGET... 
(This should result in an ACK-NAK response as the BBR configuration setting has now been removed)
<UBX(CFG-VALGET, version=1, layer=1, position=0)>
<UBX(ACK-ACK, clsID=CFG, msgID=CFG-VALGET)>

Commands sent. Waiting for any final acknowledgements...


Stopping reader thread...

[semuadmin]

Hi @Shreyas120

I'm not entirely clear what the issue is here or what exactly you mean by 'driver' in this context, but I would offer the following general observations:

1. You're attempting to set CFG_RATE_MEAS to 25 ms (i.e. 40Hz) - are you sure the C102-F9R supports this? I don't have this exact model to hand, but when I try the same command on a ZED-F9R running HPS 1.30, I get an ACK-NAK - the minimum supported value is 50ms. If I run the ubxconfigdb.py example using the same 4 configuration key/value pairs you have uncommented, but with CFG_RATE_MEAS=50 [(CFG_RATE_MEAS,50), (CFG_RATE_NAV,4), (CFG_USBOUTPROT_UBX,1), (CFG_NAVSPG_DYNMODEL,4)], it appears to work OK:

Starting handler threads. Press Ctrl-C to terminate...

Polling UART configuration in the volatile RAM memory layer via CFG-VALGET...
(This should result in ACK-ACK and CFG-VALGET responses)
<UBX(CFG-VALGET, version=1, layer=0, position=0, CFG_RATE_MEAS=1000, CFG_RATE_NAV=1, CFG_USBOUTPROT_UBX=1, CFG_NAVSPG_DYNMODEL=0)>
<UBX(ACK-ACK, clsID=CFG, msgID=CFG-VALGET)>

Polling UART configuration in the BBR memory layer via CFG-VALGET... 
(This should result in an ACK-NAK response in the  absence of an existing BBR configuration setting)
<UBX(ACK-NAK, clsID=CFG, msgID=CFG-VALGET)>

Setting UART configuration in the BBR memory layer via CFG-VALSET... 
(This should result in an ACK-ACK response)
<UBX(ACK-ACK, clsID=CFG, msgID=CFG-VALSET)>

Polling UART configuration in the BBR memory layer via CFG-VALGET... 
(This should result in ACK-ACK and CFG-VALGET responses, provided the configuration is valid for your particular device)
<UBX(CFG-VALGET, version=1, layer=1, position=0, CFG_RATE_MEAS=50, CFG_RATE_NAV=4, CFG_USBOUTPROT_UBX=1, CFG_NAVSPG_DYNMODEL=4)>
<UBX(ACK-ACK, clsID=CFG, msgID=CFG-VALGET)>

Unsetting UART configuration in the BBR memory layer via CFG-VALDEL... 
(This should result in an ACK-ACK response)
<UBX(ACK-ACK, clsID=CFG, msgID=CFG-VALDEL)>

Polling UART configuration in the BBR memory layer via CFG-VALGET... 
(This should result in an ACK-NAK response as the BBR configuration setting has now been removed)
<UBX(ACK-NAK, clsID=CFG, msgID=CFG-VALGET)>

Commands sent. Waiting for any final acknowledgements...


Stop signal set. Waiting for threads to complete...

Processing complete

2. The ubxpoller, ubxconfigdb and ubxsetrate examples offer very simple illustrations of how to set and poll various UBX configuration changes, but there are circumstances in which these may require refinement...
3. If, for example, you make changes to a device which affect the configuration of the serial port to which you are connected (e.g. changing the baud rate, parity, etc.), it is generally necessary to disconnect the device and then reconnect using the modified configuration. If you fail to do this, the device may well become non-responsive (for certain config changes e.g. a 'hard' reset, you may have to physically disconnect and reconnect the device). See pseudo-code example below (which assumes the initial baud rate is 38400).

from serial import Serial
from pyubx2 import UBXMessage, SET_LAYER_BBR, TXN_NONE

# change baud rate first...
with Serial("/dev/ttyUCM0", 38400, timeout=3) as stream:
    # change baudrate to 115200...
    keys = [("CFG_UART1_BAUDRATE", 115200)]
    msg = UBXMessage.config_set(SET_LAYER_BBR, TXN_NONE, keys)
    stream.write(msg.serialize())

# then, once reconnected at new baud rate, make other changes...
with Serial("/dev/ttyUCM0", 115200, timeout=3) as stream:
    # make other config changes...
    keys = ...
    msg = UBXMessage.config_set(SET_LAYER_BBR, TXN_NONE, keys)
    stream.write(msg.serialize())

4. As I understand it, the C102-F9R has 3 available device serial ports (corresponding to ZED-F9R, NEO-D9S and MCU) - you need to ensure you're connecting to the ZED-F9R's port - see the user guide for details. Remember that pyubx2 is just a protocol parser - it doesn't in itself implement a serial stack but instead relies on standard external libraries like pyserial (Serial). If you have a problem connecting to a particular serial device/port, you need to refer to the documentation for this library in the first instance.
5. For general advice and help on configuring the C102-F9R, refer to the u-blox community support forum or the manufacturer's technical support team.

[Shreyas120]

Thanks for your response @semuadmin

My primary concern is that I am able to set certain configurations successfully only via u-center. I am referring specifically to the ones in the commented section of the code block under cfg_payload, for ex. CFG-SFCORE-USE-SF). When I use pyubx2 and send_config, I always receive ACK-NAK for them but do not understand why.

[semuadmin]

Thanks for your response @semuadmin

My primary concern is that I am able to set certain configurations successfully only via u-center. I am referring specifically to the ones in the commented section of the code block under cfg_payload, for ex. CFG-SFCORE-USE-SF). When I use pyubx2 and send_config, I always receive ACK-NAK for them but do not understand why.

I'm not seeing that behaviour at my end - I am able to successfully set and unset the CFG-SFCORE-USE-SF parameter on an F9R using either pyubx2 or PyGPSClient (which uses pyubx2 under the covers) - see screen shot below.

NB: Bear in mind that if you set a number of different configuration parameters in a single CFG-VALSET message and any one of them fails, you will get an ACK-NAK to the whole message. If you want to isolate the problem, make the changes one parameter at a time.

Also bear in mind that pyubx2 is a free open source llbrary based on publicly available u-blox documentation. I have come across instances where either a) the u-blox documentation is incorrect, or b) the documentation is incomplete - i.e. there are features in the receivers or in u-center which are not publicly documented. But I don't believe that this is the issue here.

(The green tick in PyGPSClient signifies ACK-ACK - a red exclamation mark signifies ACK-NAK)

[semuadmin]

FYI I updated the firmware on my F9R (a SparkFun GPS-RTK Dead Reckoning Breakout - ZED-F9R, SMA) to HPS 1.40 (UBX protocol 33.40) and can confirm that the minimum supported measurement rate is still 50ms (20 Hz).

Couple of observations:

1. It appears that u-blox have only just published the Release Notes for the previous firmware version HPS 1.30 - a delay of some 4 years!! There is, AFAICS, no Release Notes available for HPS 1.40 at this time.
2. It appears that, though I can successfully set the measurement rate to 50ms (20Hz) via CFG-VALSET (having set the UART1 and UART2 baud rates to 230400), I'm still only seeing NAV-PVT messages at a rate of 10Hz (and, at this rate, the CPU is pretty much maxed out). The F9R does not support High Rate Navigation message types (e.g. HNR-PVT).

[Shreyas120]

Thanks for your response @semuadmin

Yes, I agree that minimum supported measurement rate 50ms.

I am unable to find release notes for HPS 1.40 either.

The F9 HPS 1.30 manual calls out 25ms as the minimum accepted value. I have been able to set it to 25ms with the config_set method received ACK-ACK but the device seems to crash soon after that. Never been able to receive ACK-ACK when setting it via u-center.

[Shreyas120]

@semuadmin How are you seeing CPU usage? Is this u-center 2 or some other application?

[semuadmin]

@semuadmin How are you seeing CPU usage? Is this u-center 2 or some other application?

PyGPSClient's system monitor widget

[cturvey]

Some of the older model C102-F9R-0 didn't come with the NEO-D9S / D9C fitted, it could be added by just soldering on the part, as the SMA connectors and RF path components are all fitted.

The NEO-D9S will not accept most of the keys, resulting the ACK-NAK

https://www.u-blox.com/sites/default/files/u-blox-D9-PMP-1.04_InterfaceDescription_UBX-21040023.pdf
https://content.u-blox.com/sites/default/files/u-blox-D9-QZS-1.01_InterfaceDescription_UBX-21031777.pdf

The Series 9 parts don't support HNR the same way, they use CFG-RATE-NAV_PRIO to output a subset of messages, like UBX-NAV-PVT, at a higher rate (30 Hz). As I recall these will be an interpolated / synthetic mix of GNSS and IMU/SENSOR measurements, using cm level RTK solutions to constrain / gate-post the positioning. The RTK solutions typically being at much more limited rates, perhaps 2 Hz in earlier firmwares, and perhaps up to 4 Hz in later ones.

https://content.u-blox.com/sites/default/files/documents/ZED-F9R-04B_DataSheet_UBXDOC-963802114-12930.pdf#page=5

HPS 1.40 Release Notes
https://content.u-blox.com/sites/default/files/documents/ZED-F9R-04B_FW1.00HPS1.40_RN_UBXDOC-304424225-18286.pdf

[semuadmin]

👍 good to know - thanks Clive