GPS-RTK2-SMA I2c and USB-C connection fails

GPS/GNSS Development Boards
1

Is anyone else [still] having problems with I2C quitting after 0 - 15 GPS coord updates (does not seem to matter what protocol I request, have to keep using the reset pin to try again), or with u-center not connecting via USB and win10 also not recognizing it?

2

Hi @grumpy,

Two questions:

  1. Which microcontroller are you using?
  2. Which firmware version is running on the u-blox ZED-F9P?

Cheers,
Adam

3

Also: are there any other devices on the i2c bus? Share photos of your wiring/setup

4

image
image1920×1440 241 KB

Thanks. There are no other devices on the I2C bus.

5

Thanks. Arduino UNO R4 WiFi, and have not yet found a way to get fw ver over I2C.

6

5V MCU, grimaces…
Not sure I’d be feeding that into a $200 ZED

7

Thanks clive1, 5V scared me at first documents reading, so I checked and verified that the qwiic is at 3.3V, and I only use gnd to reset the ZED. Although some spec sheets claim that the qwiic will supply power, I found that it will light the ZED LEDs, but I cannot get gps data without supplying independent pwr to the ZED.

8

Hi @grumpy ,

The Qwiic port on the R4 WiFi is Wire1 - not Wire. Please see this issue for the details:

I hope this helps,
Paul

9

PS. for the ZED-F9P, I’d recommend using v3 of our GNSS library. But you still need to make the changes for Wire1.

10

Thanks for the code link - did the usual Wire1 mods, inserted some time delays, and it ran like a charm! In the meantime, seems I got an I2C delivered 'factory [soft] reset to work, and was able to use u-center over the usb-C port, and receive hundreds of GPS packets, confirming that the module is functioning well enough internally, to not overwhelm itself after zero - 42 readings. Here are the versions query results:

Sending: CLS:MON ID:0x4 Len: 0x0 Payload:
sendCommand: Waiting for No ACK response
checkUbloxI2C: 228 bytes available
Incoming: Size: 220 Received: CLS:MON ID:0x4 Len: 0xDC Payload: 52 4F
4D 20 42 41 53 45 20 30 78 31 31 38 42 32 30 36 30 0 0 0 0 0 0 0 0 0 0
0 46 57 56 45 52 3D 48 50 47 20 31 2E 33 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 50 52 4F 54 56 45 52 3D 32 37 2E 33 31 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 4D 4F 44 3D 5A 45 44 2D 46 39 50 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 47 50 53 3B 47 4C 4F 3B 47 41 4C 3B 42 44 53 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 53 42 41 53 3B 51 5A 53 53 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
packetCfg now valid
packetCfg classAndIDmatch
waitForNoACKResponse: valid data with CLS/ID match after 87 msec
getModuleInfo: FWVER: 1.32
getModuleInfo: PROTVER: 27.31
getModuleInfo: MOD: ZED-F9P
FWVER: 1.32
Firmware: HPG
PROTVER: 27.31
MOD: ZED-F9P
Unique chip ID: 0x
Sending: CLS:0x27 ID:0x3 Len: 0x0 Payload:
sendCommand: Waiting for No ACK response
checkUbloxI2C: 17 bytes available
Incoming: Size: 9 Received: CLS:0x27 ID:0x3 Len: 0x9 Payload: 1 0 0 0
2B 43 2 17 9E
packetCfg now valid
packetCfg classAndIDmatch
waitForNoACKResponse: valid data with CLS/ID match after 21 msec
2B4302179E

Sending: CLS:0x27 ID:0x3 Len: 0x0 Payload:
sendCommand: Waiting for No ACK response
checkUbloxI2C: 17 bytes available
Incoming: Size: 9 Received: CLS:0x27 ID:0x3 Len: 0x9 Payload: 1 0 0 0
2B 43 2 17 9E
packetCfg now valid
packetCfg classAndIDmatch
waitForNoACKResponse: valid data with CLS/ID match after 21 msec
Unique chip ID: 0x2B4302179E

Sending: CLS:0x27 ID:0x3 Len: 0x0 Payload:
sendCommand: Waiting for No ACK response
checkUbloxI2C: 17 bytes available
Incoming: Size: 9 Received: CLS:0x27 ID:0x3 Len: 0x9 Payload: 1 0 0 0
2B 43 2 17 9E
packetCfg now valid
packetCfg classAndIDmatch
waitForNoACKResponse: valid data with CLS/ID match after 22 msec
Unique chip ID: 0x2B4302179E

end of query results
I will now look for how old my fw version is.
Near as I can tell, the ublox library v3 routines report inconsistent results, with a
failure to detect/connect reported also as a [bogus] returned error code from the
ZED-F9P, as if it was receiving and transmitting data, which I doubt.
Assuming it is a problem with detection of rising and falling voltage levels on
the I2C bus, I have been also looking to see if there is a way to slow down the I2C.
No luck yet.
I plan to eventually move on to snipping traces on pullup resistors.
If/after that doesn’t work, build an ftdi/UART interface and start diagnostics
with that to see if I can still use the GPS-RTK-SMA.

11

I put a scope on the I2C SDA & SCL lines. My fnirsi 1013D scope only allows half of its memory for capturing after the trigger point, so it does not capture the complete record, but it did allow me to see that the I2C bus was indeed freezing up, and that the SDA line gets pulled down to gnd by the GPS module, and only released upon hardware reset or pwr cycle.

Snipping resistor pullup traces did not improve things, and updating the firmware seemed to make things a little worse.

By trial and error time delay insertions, and different protocol requests, I was able to extend the run time form a few seconds, to a few minutes and sometimes hours (at 1 - 2Hz sampling). This was achieved with getPVT() as the basic call, waiting with a time delay after almost every I2C cmd. Perhaps the latest Arduinos are a little faster than expected by the GPS hardware and sw providers, and their jitter may be wider if the additional processors are sharing the comm workload.

My advice is for Arduino Uno4Wifi users to avoid u-blox F9P fw 1.50; use 1.13 or 1.40, COM_TYPE_UBX, and not to spend much time on the examples, because even with the recommended edits, none of them worked reliably for me. If there is interest, I can post some working code. The most successful library examples generally only gave only few seconds of data before I2C freeze-up. Be prepared for your code to reset the module via the RST pin, and have tiny tools on hand for when the quiic connectors break off; mine broke off near the end of testing, after about 10 attachment cycles.

12

Hi @grumpy ,

You shouldn’t be having these issues. The ZED breakout should work just fine when powered via Qwiic. You shouldn’t need USB power. And it shouldn’t ‘freeze’. Please try a different Qwiic cable if you have one. I suspect yours has a broken wire or intermittent contact?

I hope this helps,
Paul

13

Thanks Paul,

I have further controlled the exact timing of waiting certain milliseconds before calling functions that use the qwiic I2C channel, and then polling a minimal amount just before the GPS update is due, and have now hit 100% measured reliability over the last few hours at 1Hz, smoothly through commanded stops and resumes, over 2hours on both GPS modules.
I kept the same qwiic cable, pwr supply, and antenna through all tests, and swapped out GPS-RTK-SMA modules and their firmware versions.

One of the quiic sockets broke off and I hand soldered a patch pigtail/cable, which also works. I will still be to fearful for a while, to try daisy chaining anything but a scope on a quiic bus with a GPS module on it.

Had a bonus unexpected test result:
Normally, every tie one connects the Arduino to my Linux PC, one has to chmod the USB channel, otherwise the Arduino interface will fail to recognize the Arduino. It also requires a closing of any serial monitors before that cmd work, or serial console is disallowed.
I happened yesterday to run a GPS-RTK-SMA through USB-C on a win10 PC using u-center, then unplugged it and plugged it into the Linux box running Ubuntu, that still had the Arduino interface opened up with Serial monitor. I accidentally plugget the GPS’s usb into the Ubuntu system, and the Serial monitor quickly began listing NMEA data lines. No chmod needed.
… [Less] Grumpy

1 Like