CAM-M8C not detected (regression issue from version 2)

[dizcza]

Subject of the issue

Your lib v3 cannot detect an I2C CAM-M8C-0-10 while lib v2 detects successfully.

Your workbench

• What development board or microcontroller are you using? - ESP32 Frogboard
• What version of hardware or breakout board are you using? - CAM-M8C
• How is the breakout board wired to your microcontroller? - Default GPIO SDA/SCL pins
• How is everything being powered? - USB

Steps to reproduce

I used Example 29 Jamming info in both lib versions.

Expected behavior

The module is detected.

Below are the logs from v2.

SparkFun u-blox GNSS Example
createFileBuffer: Warning. fileBufferSize is zero. Data logging is not possible.

Sending: CLS:CFG ID:0x0 Len: 0x1 Payload: 0
sendCommand: Waiting for ACK response
checkUbloxI2C: Reading 38 bytes
Incoming: Size: 20 Received: CLS:CFG ID:0x0 Len: 0x14 Payload: 0 0 0 0 84 0 0 0 0 0 0 0 7 0 3 0 0 0 0 0
packetCfg now valid
packetCfg classAndIDmatch
Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 0
packetCfg now valid
packetAck now valid
packetCfg classAndIDmatch
packetAck classAndIDmatch
waitForACKResponse: valid data and valid ACK received after 37 msec

Sending: CLS:CFG ID:0x39 Len: 0x0 Payload:
sendCommand: Waiting for ACK response
checkUbloxI2C: Reading 26 bytes
Incoming: Size: 8 Received: CLS:CFG ID:0x39 Len: 0x8 Payload: F3 AC 62 AD 1E 3 0 0
packetCfg now valid
packetCfg classAndIDmatch
Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 39
packetCfg now valid
packetAck now valid
packetCfg classAndIDmatch
packetAck classAndIDmatch
waitForACKResponse: valid data and valid ACK received after 36 msec
The jamming / interference monitor is enabled

Actual behavior

The module isn't detected.

Below are the logs from v3.

SparkFun u-blox GNSS Example
createFileBuffer: Warning. fileBufferSize is zero. Data logging is not possible.
getVal key: 0x10710001

Sending: CLS:CFG ID:0x8B Len: 0x8 Payload: 0 0 0 0 1 0 71 10
sendCommand: Waiting for ACK response
checkUbloxI2C: 10 bytes available
processUBX: NACK received: Requested Class: 0x6 Requested ID: 0x8B
Incoming: Size: 2 Received: CLS:ACK ID:0x0 Len: 0x2 Payload: 6 8B
packetCfg now valid
packetAck now valid
waitForACKResponse: data was NOTACKNOWLEDGED (NACK) after 23 msec
getVal: sendCommand returned: Command not acknowledged (NACK)
begin: isConnected - second attempt
getVal key: 0x10710001

Sending: CLS:CFG ID:0x8B Len: 0x8 Payload: 0 0 0 0 1 0 71 10
sendCommand: Waiting for ACK response
checkUbloxI2C: 235 bytes available
processUBX: NACK received: Requested Class: 0x6 Requested ID: 0x8B
Incoming: Size: 2 Received: CLS:ACK ID:0x0 Len: 0x2 Payload: 6 8B
packetCfg now valid
packetAck now valid
waitForACKResponse: data was NOTACKNOWLEDGED (NACK) after 37 msec
getVal: sendCommand returned: Command not acknowledged (NACK)
begin: isConnected - third attempt
getVal key: 0x10710001

Sending: CLS:CFG ID:0x8B Len: 0x8 Payload: 0 0 0 0 1 0 71 10
sendCommand: Waiting for ACK response
checkUbloxI2C: 10 bytes available
processUBX: NACK received: Requested Class: 0x6 Requested ID: 0x8B
Incoming: Size: 2 Received: CLS:ACK ID:0x0 Len: 0x2 Payload: 6 8B
packetCfg now valid
packetAck now valid
waitForACKResponse: data was NOTACKNOWLEDGED (NACK) after 23 msec
getVal: sendCommand returned: Command not acknowledged (NACK)
u-blox GNSS not detected at default I2C address. Please check wiring. Freezing.

[dizcza]

The most recent releases are used in both libs.

[PaulZC]

Hi Danylo (@dizcza ),

Yes, this is expected. Please see the README, Compatibility for v3 and v3 vs v2. The M8 does not support the Configuration Interface (VALSET).

Best wishes,
Paul