checkUbloxI2C() should return 0xFF

[aortner]

From the Ublox Manual:

If there is no data awaiting transmission from the receiver, then this register will deliver the value 0xFF.

line 205:

_i2cPort->requestFrom((uint8_t)_gpsI2Caddress, (uint8_t)2);
if (_i2cPort->available())
{
uint8_t msb = _i2cPort->read();
uint8_t lsb = _i2cPort->read();
bytesAvailable = (uint16_t)msb << 8 | lsb;
}

should we better check for 0xFF ??

if(lsb == 0xFF) return(false);

i think that removes the massive stocks of the lib..

[nseidle]

i think that removes the massive stocks of the lib..

I'm sorry, I don't understand this statement.

I agree with you that we could make the function return if LSB is 0xFF but it makes me nervous. There are many instances where LSB might be 0xFF. I trust Ublox and their documentation but I'm not confident checking LSB is the right thing to do unless you're experiencing an error in a reading,

What issue are you having? Can you provide code that demonstrates the issue?

[aortner]

you can check it yourself.

try to change rate to 5 hertz at ublox providing 5 messages per second

and count messages with arduino per second

[nseidle]

You are not being a very helpful community member. I've implemented your 'fix' and there are still problems. I appreciate code. I appreciate working PRs most of all.

The changes you recommend don't do much. I see a mixture of zero bytes and no byte returns from checkUbloxI2C(). It's curious but not very helpful.

I can verify that the per second update is not happening on example 14 DebugOutput. I've pushed my changes so far (no release of library, just changes to master). I see less frequent I2C hangs when the I2C_POLLING_WAIT_MS is increased to 100ms. I need to dig deeper into the I2C packet traffic. There is very much something that is blocking the regular message updates.

[aortner]

sorry when i am not be very helpful. i can only report what i see. i am not a big c++ coder.

i did turn all other ubx messges and I have taken your code and used in arduino to parse 2-3 different ubx messages as below..

i use blackboard an f9 via i2c. i am able to parse all messages at the full rate of f9 (5/8 hertz).
what i also see if i connect also a usb to sparkfun f9 board at the same time i have more crc errors..

//Get the number of bytes available from the module
bytesAvailable = 0;
Wire.beginTransmission(0x42);
Wire.write(0xFD); //0xFD (MSB) and 0xFE (LSB) are the registers that contain number of bytes available
if (Wire.endTransmission(false) != 0) {
return (false);
} //Send a restart command. Do not release bus.
//Sensor did not ACK

Wire.requestFrom(0x42, 2);
if (Wire.available())
{
  uint8_t msb = Wire.read();
  uint8_t lsb = Wire.read();
  bytesAvailable = (uint16_t)lsb;
  bytesAvailable += (uint16_t)msb << 8;
  if(lsb == 0xFF) return;      
}

[nseidle]

Got it. No worries. Thanks for looking into the problem.

I agree there is an issue. I need to dig deeper and find out where the code is hanging. We should be able to hit 5Hz+ without glitches or timeouts.

[nseidle]

I am learning many things. First, it looks like we are reading I2C bytes when the module is not ready. For example, in the packets below there is a block of 7F FF FF bytes

Here is the full packet in text:

Checksum failed. Response too big?
Received: CLS:1 ID:7 Len: 0x5C Payload: C8 88 A4 5 E3 7 7 F 2 11 1F 37 4 0 0 0 C3 B 1 0 5 1 EA 16 65 26 3F C1 F6 43 DA 17 86 C9 18 0 BA 1C 19 0 F2 F 0 0 47 B 0 0 0 0 0 0 0 0 0 0 0 0 7F FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0 0 0 0 0 84 29 2A 1 A 0 0 0 ED 3C 2C 0 F
Size: 92 checksumA: 39 checksumB: 0 rollingChecksumA: 179 rollingChecksumB: 18

Here is the start of the scan showing 92 bytes (0x64) available:

Below is the read of a 32 byte chunk. The module clock stretches then presents 0x7F followed by 0xFFs.

I assumed the following process:

• Ask module for bytes available by reading registers 0xFD and 0xFE
• Get '92' as the number of bytes available
• Proceed to read 92 blocks but in blocks of 32 bytes (max I2C read for Arduino Uno)

The problem is the reading of blocks of 32. The module seems to be 'not ready' at certain times. The module seems to report 0x7F followed by 0xFF if it doesn't have data ready (even tho it said it did earlier). Later, on the same I2C transaction, the 'lost' bytes are made available. We're just asking for them when the module is not ready/available.

The solution is to bail on a read if we come across a read of 0xFF. The datasheet alludes to this. But also in my logic scans I'm seeing a 0x7F in front of 0xFFs. I plan to bail on 0x7F as well.

In the image above image the module was pinged for a final 4 byte read but responded with 0x7F 0xFF 0xFF 0xFF (two bytes are shown, the other two bytes went to CRCA and CRCB). Again, the module presented the correct four bytes later, but because it was not ready at this point in time the packet failed CRC.

[nseidle]

It's very interesting that the module is clock stretching just to then respond with 'I am not ready with data' in the form of 0x7F 0xFFs.

Unfortunately it looks like there are legitimate 0x7Fs:

Size: 92 Received: CLS:1 ID:7 Len: 0x5C Payload: F8 7F B9 5 E3 7 7 F 2 28 19 37 4 0 0 0 DF 3A 7 0 5 1 EA 15 65 26 3F C1 F6 43 DA 17 86 C9 18 0 BA 1C 19 0 F2 F 0 0 47 B 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 84 29 2A 1 A 0 0 0 ED 3C 2C 0 F 27 0 0 8 9D 43 2C 0 0 0 0 0 0 0 0
CLS/ID match!

And singleton 0xFFs:

Size: 92 Received: CLS:1 ID:7 Len: 0x5C Payload: 4 F5 BA 5 E3 7 7 F 2 2A 0 37 4 0 0 0 A6 FF D3 1D 5 1 EA 15 65 26 3F C1 F6 43 DA 17 86 C9 18 0 BA 1C 19 0 F2 F 0 0 47 B 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 84 29 2A 1 A 0 0 0 ED 3C 2C 0 F 27 0 0 8 9D 43 2C 0 0 0 0 0 0 0 0
CLS/ID match!

So we can't simply bail on a reading of 0x7F. But it does look like the problem is when 0x7F is the first byte in the read. If we incorrectly 'throw out' part of a valid packet the CRC will fail and we'll throw out the entire (valid) packet. This should be rare and acceptable. Definitely something I'll bring up with Ublox.

[nseidle]

After much work I think I've fixed the underlying problem, thanks in part to your recommendation.

We now read successfully, and without CRC error at 10Hz with large PVT packets. Please see example 16 for a demo. Please test this new code and let me know if you still have issues.

Thanks for bringing this issue to my attention. It was a big one, but I think the library is much better because of this fix.