Module not having bytes available

[nseidle]

Platform: Artemis

Measurement period is extreme: 10Hz with nav rate of 5Hz (update rate of 2Hz). Problem also shows itself with Example6_OutputRate (nav freq set to 10Hz).

Module will say bytes are available but will present 0xFFs towards the end of the frame.

In this example, 0x64 bytes are 'available':

But part of the way through the byte harvesting, we start getting 0xFFs:

And then our CRC is corrupt. This error occurs ~3 times per 10 seconds.

Often the frame will include 0xFFs in between what looks to be valid data:

It seems as though the module is busy updating other ports (serial, SPI, etc) and is not serving up bytes to I2C buffer.

[nseidle]

I've updated my ZED-F9P to UBX_F9_100_HPG_112_ZED_F9P firmware and have the same issue.

I2C rate is 400kHz.

[mazgch]

Could this issue be related to a mechanism of the u-blox GPS referred to as clock stretching. An I2C slave is allowed to hold down the clock if it needs to reduce the bus speed. The master on the other hand is required to read back the clock signal after releasing it to high state and wait until the line has actually gone high.
Does Artemis support slaves that make use of clock stretching?

[mazgch]

Have you disabled the UART1 out protocol before switching to high nav rate. I like to avoid that Issue in the I2C is caused by the overload on other ports ports such as the UART. The receiver may run low on memory because the buffer queue up due to low baud rate on the UART (even it is not used).

So can you try to disable UART1/2/USB out protocol with CFG-PORT before switching to high rates.

I will try again to reproduce Example6_OutputRate.

[mazgch]

Could you please try to disable the UART output in example Example6_OutputRate before switching to 10 Hz around line 49.

// do not overload the buffer system from the GPS, disable UART output
myGPS.setUART1Output(0); //Disable the UART1 port output 
myGPS.setUART2Output(0); //Disable Set the UART2 port output
myGPS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise)
myGPS.setNavigationFrequency(10); //Set output to 10 times a second

I am using the Arduino Nano 33 BLE with a SAM-M8Q and your Example6_OutputRate. without issues. If I do this I see stable 10Hz in the serial monitor. I have not checked in detail with the logic analyzer.

[sslupsky]

@nseidle I understand the FF's are inserted by the module to indicate there is no data available to send. I noticed you had a comment about that here

SparkFun_Ublox_Arduino_Library/src/SparkFun_Ublox_Arduino_Library.cpp

Line 311 in 61c85b6

//I believe this is a Ublox bug. Device should never present an 0xFF.

It is not a bug with the module but expected behaviour.

[nseidle]

Yes and no. The preamble includes the number of bytes that should be available. These are read out and, at times, include 0xFFs. This is the bug.

[sslupsky]

I think the module might still be indicating that data is not available? That is, you are reading too fast? Try re-reading the last byte and see if the checksum works out. If that is the case, then it is likely that it just can't keep up.

[sslupsky]

The module likely runs time sensitive functions from time to time. If you are reading when one of these things is going on, it might just defer the read.

[sslupsky]

On second thought, that would violate their specification. They only place they are supposed to insert the FF is at the beginning of the message to indicate it is not a valid message/not ready.

Did you file a bug report with ublox about this? I think you are correct, this looks like a bug.

[PaulZC]

I'm wondering if this issue is related to pull-ups too?
Please see my comment on #40.
Food for thought?
Cheers,
Paul

[nseidle]

I think we've solved most of this issue by removing the pull up resistors. If you're experiencing anything like this be sure to remove all pullups on peripheral boards and or the controller. Most, if not all, u-blox modules have built in pull ups.

Notes added to main readme.