EVK-F9P Support

[juncheng-dd]

Hi, I purchased a EVK-F9P unit(https://www.u-blox.com/en/product/evk-f9p) to evaluate ZED-F9P device. Is this evaluation kit expected to work with this library? My current set up is to connect the evaluation kit with a linux laptop(ubuntu 20.04) using a USB cable. I realized that the linux platform was supported, but I didn't see USB as an option for serial connection(I2C, SPI, UART).

I tried to run the gnss example as suggested in https://github.com/u-blox/ubxlib/tree/41349f324ed52de37ade97f8de638b4ab1549f9a/example/gnss, and below is the error messages:

U_APP: running functions that begin with "exampleGnss".

U_APP: Running preambleHeapDefence...
U_PREAMBLE_TEST: at start(ish) of day main task stack had a minimum of -4 byte(s) free.
U_PREAMBLE_TEST: at start(ish) of day heap had a minimum of -4 byte(s) free.
U_PREAMBLE_TEST: calling platform APIs that might allocate memory when first called...
U_PREAMBLE_TEST: 0 byte(s) of heap were lost to the platform.
/home/ddlabs/Projects/ubxlib/port/platform/common/test/u_preamble_test.c:115:preambleHeapDefence:PASS

U_APP: Running preambleCleanUp...
U_PREAMBLE_TEST: 1 outstanding call(s) to pUPortMalloc().
/home/ddlabs/Projects/ubxlib/port/platform/common/test/u_preamble_test.c:266:preambleCleanUp:PASS

U_APP: Running exampleGnssCfgVal...
Opened device with return code -8.
Unable to open GNSS!
Done.
/home/ddlabs/Projects/ubxlib/example/gnss/cfg_val_main.c:333:exampleGnssCfgVal:FAIL: Expression Evaluated To FALSE

U_APP: Running exampleGnssDec...
Opened device with return code -8.
Unable to open GNSS!
Done.
/home/ddlabs/Projects/ubxlib/example/gnss/dec_main.c:341:exampleGnssDec:FAIL: Expression Evaluated To FALSE

U_APP: Running exampleGnssGeofence...
Opened device with return code -8.
Unable to open GNSS!
Done.
/home/ddlabs/Projects/ubxlib/example/gnss/geofence_main.c:300:exampleGnssGeofence:PASS

U_APP: Running exampleGnssMsg...
Opened device with return code -8.
Unable to open GNSS!
Done.
/home/ddlabs/Projects/ubxlib/example/gnss/msg_main.c:359:exampleGnssMsg:FAIL: Expression Evaluated To FALSE

U_APP: Running exampleGnssPos...
Opened device with return code -8.
Unable to open GNSS!
Done.
/home/ddlabs/Projects/ubxlib/example/gnss/pos_main.c:327:exampleGnssPos:FAIL: Expression Evaluated To FALSE

U_APP: Running postambleResourceCheck...
U_POSTAMBLE_TEST: *** ERROR *** 1 outstanding call(s) to pUPortMalloc().
U_POSTAMBLE_TEST: too many resources outstanding.
/home/ddlabs/Projects/ubxlib/port/platform/common/test/u_postamble_test.c:88:postambleResourceCheck:FAIL: Expression Evaluated To FALSE

-----------------------
8 Tests 5 Failures 0 Ignored 
FAIL

U_APP: application task ended.

I assumed the above error might be caused by the unsupported USB connection, but I would like to confirm that the EVK-F9P is indeed supported by the library and I wonder whether there are any workarounds so that the software works with the USB connection? Thanks for the help in advance

[RobMeades]

Hi there, and thanks for posting. For ubxlib on Linux USB or UART are equivalent, so that should be fine.

Error code -8, from u_error_common.h, is U_ERROR_COMMON_PLATFORM, and if uDeviceOpen() is returning that value it is highly likely to be because the contents of uDeviceCfg_t don't end up at a GNSS module.

Can you indicate what values you are putting in the various fields of that structure?

In particular, for a Linux connection over USB, if you don't specify a value for pPrefix then it will default to /dev/ttyUSB, on the end of which will be added the number you assigned to the field uart; for instance, if you had a GNSS device on /dev/ttyUSB0 then, with pPrefix left as NULL that should work if the uart field of the structure were set to 0.

[RobMeades]

The other thing to watch out for (this may not be the problem right now but could be later) is, for protocol/control reasons the GNSS device and ubxlib need to know whether the connection is, in fact, over UART or USB (because the control of message exchanges inside the GNSS chip is per port number, and the GNSS chip's internal port numbers are different for USB and UART).

For Linux, the ubxlib code assumes that you are using a Raspberry Pi and actually using a UART connection, see here:

https://github.com/u-blox/ubxlib/blob/41349f324ed52de37ade97f8de638b4ab1549f9a/gnss/src/u_gnss.c#L335-L338

Should this turn out to be an issue then the fix is to pass the conditional compilation flag U_CFG_GNSS_PORT_NUMBER into the build of ubxlib, set to 3 (U_CFG_GNSS_PORT_NUMBER=3), then the ubxlib code will know that the internal GNSS port number is 3 (USB), rather than 1 (UART 1) or 2 (UART 2).

But I think this is likely a second step, I don't think it is going to be the cause of your initial problem.

EDIT: I've just updated the master branch so that you can specify the transportType field to be U_DEVICE_TRANSPORT_TYPE_UART_USB. This is exactly the same as U_DEVICE_TRANSPORT_TYPE_UART except that it will give the GNSS part of the ubxlib code the hint that it is connected to the USB port of the GNSS device rather than the UART port.

[juncheng-dd]

Hi @RobMeades , thanks for the quick response. I tried to follow both of your suggestions, and the dec_main example worked now! Here is the output:

U_APP: Running exampleGnssDec...
U_GNSS: initialising with ENABLE_POWER pin not connected, transport type UART.
Opened device with return code 0.
U_GNSS: sent command b5 62 06 01 08 00 01 07 00 00 00 01 00 00 18 df.
U_GNSS: decoded UBX response 0x05 0x01: 06 01 [body 2 byte(s)].
UTC time 1705971260000059312 nanoseconds.
UTC time 1705971261000059062 nanoseconds.
UTC time 1705971262000058811 nanoseconds.
UTC time 1705971263000058560 nanoseconds.
UTC time 1705971264000058309 nanoseconds.
5 UBX-NAV-PVT message(s) decoded.
Done.
/home/ddlabs/Projects/ubxlib/example/gnss/dec_main.c:233:exampleGnssDec:PASS

For reference, the fields of the structure look like below:

    .transportType = U_DEVICE_TRANSPORT_TYPE_UART,
    .transportCfg = {
        .cfgUart = {
            .uart = 0,
            .baudRate = U_GNSS_UART_BAUD_RATE, /* Use 0 to try all possible baud rates
                                                  and find the correct one. */
            .pinTxd = U_CFG_APP_PIN_GNSS_TXD,
            .pinRxd = U_CFG_APP_PIN_GNSS_RXD,
            .pinCts = U_CFG_APP_PIN_GNSS_CTS,
            .pinRts = U_CFG_APP_PIN_GNSS_RTS,
            .pPrefix = "/dev/ttyACM"
        },
    },

Note that the port for the evaluation kit is "/dev/ttyACM0". In addition, the U_FLAGs settings are: -DU_CFG_APP_FILTER=exampleGnss -DU_CFG_TEST_GNSS_MODULE_TYPE=U_GNSS_MODULE_TYPE_M9 -DU_CFG_APP_GNSS_UART=1 -DU_CFG_GNSS_PORT_NUMBER=3

Please let me know if you noticed any problems in the above set up

[juncheng-dd]

Hi @RobMeades , I had a follow up question: is there a way to get the GPS time in addition to the UTC time in the dec_main example?

One thing I noticed was that in the NAV-PVT struct, it only had the gps iTOW data. I am wondering where I can also grab the GPS week information so that I can compute the GPS time from it. Looking forward to your reply, thanks

[RobMeades]

Please let me know if you noticed any problems in the above set up

No problems there, looks excellent to me, glad it is working for you.

For GPS time, I guess it might be easiest to add the UBX-NAV-TIMEGPS (0x01 0x20) (see section 3.15.25 of the F9P manual) message to the set of messages you are interested in. Using the dec_main example as a basis, probably the easiest way to do this is to modify the lines:

messageId.type = U_GNSS_PROTOCOL_UBX;
messageId.id.ubx = 0x0107; // The message class/ID of a UBX-NAV-PVT message

...to be:

messageId.type = U_GNSS_PROTOCOL_UBX;
messageId.id.ubx = 0x01FF; // The message class UBX-NAV, all of the messages

...so that you will receive all messages of the UBX-NAV message class, and add:

 U_GNSS_CFG_SET_VAL_RAM(devHandle, MSGOUT_UBX_NAV_TIMEGPS_USB_U1, 1)

...to your list of "SET_VAL"s (noticing that this is switching on the UBX-NAV-TIMEGPS message for the USB port of the GNSS device).

Then, in the callback() function, you will need to check pMessageId and only bother passing the UBX-NAV-PVT messages to pUGnssDecAlloc(), so something like this:

uGnssDec_t pDec = NULL;

...

if (pMessageId->id.ubx == U_GNSS_UBX_MESSAGE(0x01, 0x07)) {
    pDec = pUGnssDecAlloc(pBuffer, length);
}
if (pDec != NULL) {
    if (pDec->errorCode == 0) {
        // Do stuff with UBX-NAV-PVT
    }
} else {
    if (pMessageId->id.ubx == U_GNSS_UBX_MESSAGE(0x01, 0x20)) {
        // Do stuff with UBX-NAV-TIMEGPS
    }
}

In the "do stuff with UBX-NAV-TIMEGPS" bit, you could take a look at the kinds of patterns we use for the decoding of the UBX-NAV-PVT message to make sure you deal with any endianness issues you may have.

[RobMeades]

EDIT: should be MSGOUT_UBX_NAV_TIMEGPS_USB_U1 above, not MSGOUT_UBX_NAV2_TIMEGPS_USB_U1; I've modified the line to be correct, just posting this update in case you have copied the code already.

[juncheng-dd]

Hi @RobMeades , thanks for your detailed instructions! Really appreciate your help here.

I was able to receive the NAV-TIMEGPS message and parse some of its fields following your suggestions. Below are some loggings from my test:

id: 7 
fix: 3, horizontal accuracy: 1758, vertical accuracy: 3167, valid: 7, flag: 3, flag2: 234, flag3: 0
NavPvt tow: 368136000
UTC time 1706163318000165949 nanoseconds.
id: 32 
Time GPS data 
TIMEGPS tow: 368136000, ftow: 165950, gps week: 2298
id: 7 
fix: 3, horizontal accuracy: 1759, vertical accuracy: 3166, valid: 7, flag: 3, flag2: 234, flag3: 0
NavPvt tow: 368137000
UTC time 1706163319000165699 nanoseconds.
id: 32 
Time GPS data 
TIMEGPS tow: 368137000, ftow: 165700, gps week: 2298

However, I encountered one interesting issue: When I tried to increase the navigation rate to 5Hz by calling: uGnssCfgSetRate(devHandle, 200, 1, U_GNSS_TIME_SYSTEM_NONE), somehow I only received the NAV-PVT messages as shown by below outputs:

fix: 3, horizontal accuracy: 832, vertical accuracy: 1571, valid: 7, flag: 3, flag2: 234, flag3: 0
NavPvt tow: 368203800
UTC time 1706163385800148990 nanoseconds.
id: 7 
fix: 3, horizontal accuracy: 830, vertical accuracy: 1568, valid: 7, flag: 3, flag2: 234, flag3: 0
NavPvt tow: 368204000
UTC time 1706163386000148940 nanoseconds.

Updating the rate back to 1Hz will fix the above the problem. Do you happen to know what might be the reason and how to keep all the messages at 5Hz? I am wondering whether it is relevant to some kind of throttling mechanism. Looking forward to your reply, thanks!

[RobMeades]

I confirm that I can see the same thing on M9 sometimes myself. Running the same test on an M10 I see no such problem, so my guess is that this is due to throttling within the M9.

As an aside, you should also remove this line:

https://github.com/u-blox/ubxlib/blob/bb93cdb2cfea08f6752e5aabe77a1733ebf5bbcf/example/gnss/dec_main.c#L292

...so that you just have the U_GNSS_CFG_SET_VAL_RAM macros you need for USB and the two message types; on the F9P modules the uGnssCfgSetMsgRate() function works _as_wellas the U_GNSS_CFG_SET_VAL_RAM macros so, with the message ID set to 0x01FF, I'm not entirely sure what that will be doing.

That said, I don't believe that this is the problem in this case since the M10 does not show the same issue.

As an experiment, I printed out the view of the communications links that the GNSS chip has by adding this before I close the device:

        uGnssCommunicationStats_t communicationStats;
        if (uGnssInfoGetCommunicationStats(devHandle, -1, &communicationStats) == 0) {
            // Print the communication stats as seen by the GNSS chip
            uPortLog("communications from the GNSS chip's perspective:\n");
            uPortLog(" %d transmit byte(s) currently pending.\n", communicationStats.txPendingBytes);
            uPortLog(" %d byte(s) ever transmitted.\n", communicationStats.txBytes);
            uPortLog(" %d%% transmit buffer currently used.\n", communicationStats.txPercentageUsage);
            uPortLog(" %d%% peak transmit buffer usage.\n", communicationStats.txPeakPercentageUsage);
            uPortLog(" %d receive byte(s) currently pending.\n", communicationStats.rxPendingBytes);
            uPortLog(" %d byte(s) ever received.\n", communicationStats.rxBytes);
            uPortLog(" %d%% receive buffer currently used.\n", communicationStats.rxPercentageUsage);
            uPortLog(" %d%% peak receive buffer usage.\n", communicationStats.rxPeakPercentageUsage);
            uPortLog(" %d 100 ms interval(s) with receive overrun errors.\n",
                              communicationStats.rxOverrunErrors);
            for (size_t x = 0; x < sizeof(communicationStats.rxNumMessages) /
                 sizeof(communicationStats.rxNumMessages[0]); x++) {
                if (communicationStats.rxNumMessages[x] >= 0) {
                    uPortLog(" %d protocol %d message(s) decoded.\n", communicationStats.rxNumMessages[x], x);
                }
            }
            uPortLog(" %d receive byte(s) skipped.\n", communicationStats.rxSkippedBytes);
        }

...and I have attached an M9 success case, an M10 case and an M9 fail case log of what is returned.

You will see that in the M10 case the peak transmit buffer usage inside the GNSS chip is 56% while in the M9 success case the peak transmit buffer usage got up to 96% and in the fail case the response to the communications stats query from the GNSS chip never even arrives (we hit the 10 second reply timeout). But I also had quite a few M9 runs where, for instance, 25, UBX-NAV-PVT messages arrive within 5 seconds but only one UBX-NAV-TIMEGPS message arrives and the peak transmit buffer usage is only 50%, so I'm not sure we can blame that entirely either.

Since my tests are running over I2C rather than USB I tried increasing the I2C clock rate from 100 kHz to 400 kHz, which is the fastest the [ESP32] MCU in question can support, but that made no difference.

I guess that the UBX-NAV-PVT messages, when messages are to be emitted at a high rate, are being prioritised, in terms of the GNSS chip's processing power, over the UBX-NAV-TIMEGPS messages, so I tried setting the UBX-NAV-TIMEGPS to be 5, i.e. so that the GNSS chip only tries to emit UBX-NAV-TIMEGPS every 5 navigation periods, i.e. once a second, but that did not help; fewer than one UBX-NAV-TIMEGPS every second arrived.

I will carry on experimenting.

[cturvey]

Throttling from a horse-power sense usually results in dropping individual epochs. The one immediately following top-of-second being the most prone, ie +0.200 for 5 Hz 5 Hz should be manageable on the M9/F9 Where you will have data loss is overwhelming the slowest interface with too much data volume. Usually the UARTs. The buffers for output data messages is pooled and finite, when too much data is generated you'll see a "$GNTXT txbuf,alloc" failure as it chokes. Reduce message load on slow interfaces, or turn OFF interfaces you're not using. Watch UART2, usually outputting NMEA, shed loads of GSV at 5 Hz, not helpful/useful

[RobMeades]

Thanks Clive, very useful.

Watch UART2, usually outputting NMEA, shed loads of GSV at 5 Hz, not helpful/useful

That's a good point actually: @juncheng-dd: if you happen not to need them you can switch off NMEA message output (which will be present by default) on the USB port of the ZED-F9P with:

U_GNSS_CFG_SET_VAL_RAM(devHandle, USBOUTPROT_NMEA_L, 0);

[cturvey]

A good course of action would be to disable all unused interface so there aren't unintended consequences to rate change.

UART+I2C vs SPI tends to be an either one or other depending on DSEL pin state or eFuse, acting at a CFG-UART1-ENABLED, CFG-I2C-ENABLED, CFG-SPI-ENABLED level

I2C will stall if not attended too, and turn off.

The UART1 / UART2 will always try to fire hose data as they are just blind outputs, the host is not involved. Generally it's a disparity in inflow vs outflow volumes here that consumes all the buffer resources. Compounded here when the rate of generation increase. The rate change itself looks innocent, but the receiver doesn't do anything to manage or check the message volume or balance.

The USB will understand if it is connected to a host, or not

[RobMeades]

FYI, I've put in some debug prints at the lowest possible point in the communications path from the GNSS device within the ubxlib code and there is no sign of data loss; in other words, in the case where the UBX-NAV-TIMEGPS messages are not received they really have not left the GNSS device (this is true with NMEA messages from the GNSS device switched off on that port also).

[RobMeades]

A clue: I usually have all of the satellite systems enabled in the GNSS device. If, instead, I enable only GPS, as follows:

        U_GNSS_CFG_SET_VAL_RAM(devHandle, SIGNAL_GPS_ENA_L, 1);
        U_GNSS_CFG_SET_VAL_RAM(devHandle, SIGNAL_SBAS_ENA_L, 0);
        U_GNSS_CFG_SET_VAL_RAM(devHandle, SIGNAL_GAL_ENA_L, 0);
        U_GNSS_CFG_SET_VAL_RAM(devHandle, SIGNAL_BDS_ENA_L, 0);
        U_GNSS_CFG_SET_VAL_RAM(devHandle, SIGNAL_QZSS_ENA_L, 0);
        U_GNSS_CFG_SET_VAL_RAM(devHandle, SIGNAL_GLO_ENA_L, 0);

...then I get UBX-NAV-TIMEGPS at the same rate as UBX-NAV-PVT, five times per second.

@juncheng-dd: can you try this?

[RobMeades]

Find attached the log output of only having GPS switched on, 200 ms epoch, NMEA disabled, running for 30 seconds: 150 of each message type as expected. This is over I2C @ 100 kHz.

The observed peak transmit buffer usage inside the GNSS device is between 6% and 13%; if I leave NMEA enabled then the peak transmit buffer usage shoots up to 99% and only about 130 of each message type arrive, so switching NMEA off, if you don't need it, is a good idea.

Also find attached the modified dec_main.c, bearing in mind of course that this is set up for I2C.

[juncheng-dd]

Hi @RobMeades @cturvey , thanks both for the help! I think the problem has been fixed :tada:

Without any changes, the peak transmit buffer usage is around 70% and there is no NAV-TIMEGPS message at 5Hz:

24 UBX-NAV-PVT message(s) decoded.
0 UBX-NAV-TIMEGPS message(s) decoded.
U_GNSS: sent command b5 62 0a 36 00 00 40 ca.
U_GNSS: decoded UBX response 0x0a 0x36: 00 04 03 00 00 01 05 06 00 01 c1 31 6e ed 2e 00 63 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 0a f2 65 00 00 00 00 00 3a c8 8e 01 05 05 00 00 93 ea 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 03 00 00 45 79 06 00 01 46 00 00 1b 08 00 00 00 00 00 00 85 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 00 00 5f 9a 8e 01 00 01 00 00 ee ab 5c 00 03 05 00 00 b4 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [body 168 byte(s)].
communications from the GNSS chip's perspective:
 0 transmit byte(s) currently pending.
 424261 byte(s) ever transmitted.
 1% transmit buffer currently used.
 70% peak transmit buffer usage.
 0 receive byte(s) currently pending.
 2075 byte(s) ever received.
 0% receive buffer currently used.
 0% peak receive buffer usage.
 0 100 ms interval(s) with receive overrun errors.
 133 protocol 0 message(s) decoded.
 0 protocol 1 message(s) decoded.
 0 receive byte(s) skipped.

After enabling only GPS, I was able to see the NAV-TIMEGPS messages and the peak transmit buffer is around 37%:

24 UBX-NAV-PVT message(s) decoded.
24 UBX-NAV-TIMEGPS message(s) decoded.
U_GNSS: sent command b5 62 0a 36 00 00 40 ca.
U_GNSS: decoded UBX response 0x0a 0x36: 00 04 00 00 00 01 05 06 00 01 d8 00 77 ad 0a 00 04 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 0b 72 24 00 00 00 00 00 34 32 77 00 04 04 00 00 5f 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 03 00 00 a7 d6 01 00 01 25 00 00 79 04 00 00 00 00 00 00 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 00 00 59 04 77 00 00 01 00 00 ef 2b 1b 00 02 04 00 00 32 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [body 168 byte(s)].
communications from the GNSS chip's perspective:
 0 transmit byte(s) currently pending.
 120487 byte(s) ever transmitted.
 1% transmit buffer currently used.
 37% peak transmit buffer usage.
 0 receive byte(s) currently pending.
 1145 byte(s) ever received.
 0% receive buffer currently used.
 0% peak receive buffer usage.
 0 100 ms interval(s) with receive overrun errors.
 73 protocol 0 message(s) decoded.
 0 protocol 1 message(s) decoded.
 0 receive byte(s) skipped.
Done.

Finally after also disabling the NEMA, the peak transmit buffer reduces to 19%:

25 UBX-NAV-PVT message(s) decoded.
25 UBX-NAV-TIMEGPS message(s) decoded.
U_GNSS: sent command b5 62 0a 36 00 00 40 ca.
U_GNSS: decoded UBX response 0x0a 0x36: 00 04 00 00 00 01 05 06 00 01 34 00 b5 24 e9 00 04 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 a1 95 ce 01 00 00 00 00 02 ed df 07 03 04 00 00 93 8d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 03 00 00 13 5d 00 00 00 13 00 00 4b 02 00 00 00 00 00 00 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 00 00 27 bf df 07 00 01 00 00 85 4f c5 01 03 06 00 00 31 4c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [body 168 byte(s)].
communications from the GNSS chip's perspective:
 0 transmit byte(s) currently pending.
 23827 byte(s) ever transmitted.
 0% transmit buffer currently used.
 19% peak transmit buffer usage.
 0 receive byte(s) currently pending.
 587 byte(s) ever received.
 0% receive buffer currently used.
 0% peak receive buffer usage.
 0 100 ms interval(s) with receive overrun errors.
 37 protocol 0 message(s) decoded.
 0 protocol 1 message(s) decoded.
 0 receive byte(s) skipped.
Done.

Note that the above testing runs on my linux laptop and the EVK-F9P is connected via USB ports. Somehow the peak transmit buffer(19%) is higher than your linked result(6%) @RobMeades , but at least all the messages are received. Thanks a lot for the supports!

[juncheng-dd]

@RobMeades Also just to confirm that If I only enable GPS signals via the below command, the computed position, velocity solution won't be comprised?

        U_GNSS_CFG_SET_VAL_RAM(devHandle, SIGNAL_GPS_ENA_L, 1);
        U_GNSS_CFG_SET_VAL_RAM(devHandle, SIGNAL_SBAS_ENA_L, 0);
        U_GNSS_CFG_SET_VAL_RAM(devHandle, SIGNAL_GAL_ENA_L, 0);
        U_GNSS_CFG_SET_VAL_RAM(devHandle, SIGNAL_BDS_ENA_L, 0);
        U_GNSS_CFG_SET_VAL_RAM(devHandle, SIGNAL_QZSS_ENA_L, 0);
        U_GNSS_CFG_SET_VAL_RAM(devHandle, SIGNAL_GLO_ENA_L, 0);

[RobMeades]

I think the problem has been fixed

Excellent!

just to confirm that If I only enable GPS signals via the below command, the computed position, velocity solution won't be comprised?

An excellent question. I suspect it probably will, since you are relying now only on GPS satellites rather than on multiple constellations; question is: do you care? If the GPS satellite system is maintained and extended over multiple years then I guess it's fine?

[juncheng-dd]

An excellent question. I suspect it probably will, since you are relying now only on GPS satellites rather than on multiple constellations; question is: do you care? If the GPS satellite system is maintained and extended over multiple years then I guess it's fine?

@RobMeades I see, I would love to still keep using all the satellites as I want to make sure the final solution won't be compromised in any way. Do you think whether disabling other interfaces, e.g. SPI, I2C, UART would help since I probably only need the USB port for now. If yes, would it be possible to advise about how to turn them off in the code?

[RobMeades]

I suspect that the issue is not associated with the "comms load", IYSWIM, I think it is more to do with the behaviour of the GNSS device when it is asked to deliver GPS time and yet it is receiving time from many different systems, not just the GPS system.

You could try experimenting with disabling just some non-GPS systems, instead of all of them: it might be that something about the way reception from certain non-GPS systems beats with reception from the GPS system means that GPS time is never derived; there is some other system "in scope" at the time, which delivers a navigation solution, and is not GPS.

However, recalling that UBX-NAV-PVT delivers a navigation solution that may have nothing whatsoever to do with GPS; only if you limit it to GPS will you get a GPS-based time for each UBX-NAV-PVT message. It may depend on why you need GPS-based time in the first place: if you have a non-GPS-based navigation solution then is GPS time of any value...?

[juncheng-dd]

It may depend on why you need GPS-based time in the first place: if you have a non-GPS-based navigation solution then is GPS time of any value...

Thanks for your insights! The main motivation is to timestamp the position/velocity output from the evaluation kit so that we can properly evaluate its performance, and we think GPS time is a good source for the timestamping purpose since it doesn't have the leap seconds unlike UTC time.

I will investigate further to see whether I can disable some of the non-GPS systems or use other workarounds, and will get back to this thread in a few days. I will keep this ticket open for now

[juncheng-dd]

Hi @RobMeades , I tried out a few things today and it appeared that I was able to get 5Hz time gps data after I disabled the UART1 output even with all the GNSS satellites. I tried to disable the UART1 output via:

        U_GNSS_CFG_SET_VAL_RAM(devHandle, UART1OUTPROT_UBX_L , 0);
        U_GNSS_CFG_SET_VAL_RAM(devHandle, UART1OUTPROT_NMEA_L , 0);
        U_GNSS_CFG_SET_VAL_RAM(devHandle, UART1OUTPROT_RTCM3X_L , 0);

Note that I also tried to disable UART2 and SPI output, but they didn't seem to address the problem. Curious to know what your thoughts are about this and whether this is expected?

[RobMeades]

Could you post the ubxlib log output for these disable operations, then we can determine if they are being accepted by the GNSS chip?

As to obtaining GPS time versus with all satellite systems enabled, it is difficult for me to comment: that would down to the innards of the GNSS chip rather than a ubxlib question, not something I really know anything about I'm afraid, and it may be time dependent as, I guess, the satellite systems are not coordinated (there is no reason for them to be).

[juncheng-dd]

Yes sure, the log output looks like below:

U_APP: Running exampleGnssDec...
U_GNSS: initialising with ENABLE_POWER pin not connected, transport type UART.
Opened device with return code 0.
U_GNSS: sent command b5 62 06 00 01 00 03 0a 24.
U_GNSS: decoded UBX response 0x06 0x00: 03 00 00 00 00 00 00 00 00 00 00 00 63 00 21 00 00 00 00 00 [body 20 byte(s)].
current protocal: 5
U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 02 00 78 10 00 25 cc.
U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 01 00 74 10 00 20 bb.
U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 02 00 74 10 00 21 c0.
U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 04 00 74 10 00 23 ca.
U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
U_GNSS: sent command b5 62 06 8b 08 00 00 00 00 00 ff ff 21 00 b8 cc.
U_GNSS: decoded UBX response 0x06 0x8b: 01 00 00 00 05 00 21 10 00 03 00 21 20 01 01 00 21 30 c8 00 02 00 21 30 01 00 [body 26 byte(s)].
Current navigation rate: 200
fallback set up 
U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 09 00 91 20 01 56 5b.
U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 4a 00 91 20 01 97 a0.
U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 3b 00 91 20 01 88 55.
U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 2c 00 91 20 01 79 0a.
U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
id: 7 
fix: 3, horizontal accuracy: 1482, vertical accuracy: 2242, valid: 7, flag: 3, flag2: 234, flag3: 0
NavPvt tow: 259796800
UTC time 1706659778800364130 nanoseconds.
id: 2 
id: 4 
id: 32 
Time GPS data 
TIMEGPS tow: 259796800, ftow: 364130, gps week: 2299
id: 7 
fix: 3, horizontal accuracy: 1479, vertical accuracy: 2239, valid: 7, flag: 3, flag2: 234, flag3: 0

The above output is from disabling the NEMA output at the USB port and disabling all UBX, NEMA and RTCM3 output at the UART1 port

[RobMeades]

Thanks: that shows that all of your configurations are being acknowledged as successful by the GNSS device, you can see the:

U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].

...lines, where 0x05 0x01 it the ack and 06 8a is the message class/ID that it is acknowledging.

[juncheng-dd]

Got it, thanks for confirming that! It appears that disabling the UART1 port does solve this issue. Does it mean the root cause is still some sort of IO issues as hinted in https://github.com/u-blox/ubxlib/issues/187#issuecomment-1910295239 ?

[RobMeades]

Unclear: when I tried this, disabling transports did not cause me to start receiving GPS time messages, only removing GNSS system types allowed the GNSS device to send me GPS time messages.

[juncheng-dd]

I see. Thanks for all the help and guidance. I will close this issue now since my current problem has been addressed even though the root cause is still a bit unclear.