Sparkfun F9P and ESP I2C problem

I am facing a very strange problem.

I have connected sparkfun f9p board with Esp32 board using I2C communication. While working, i have noticed that the f9p i2c address changes from 0x42 to 0x44. After that, I need to set it through ucenter and then it starts working again

Why is this happening? Is there a problem with f9p i2c? How should I solve this?

Are you using qwiic? How long are the wires/cables? Is anything else on the i2c bus?

Yes, I am using qwiic. SparkFun GPS-RTK2 Board - ZED-F9P (Qwiic) | GPS RTK Board - SparkFun Electronics

As of now, i am using the standard jumper wires. I guess the length will be close to 10 cm.

No, there is nothing else on the board. It is just the Esp32 dev board and f9p board.

The issue is that sometimes it is working fine and then suddenly, the address changes and I am not able to connect.

Is it a hardware issue or can be solved through software?

Hi @Nayak ,

The F9P I2C address can be changed using a UBX-CFG-PRT or a UBX-CFG-VALSET (CFG-I2C-ADDRESS, 0x20510001) message. Could your code be sending one of those?

I hope this helps,
Paul

No, I am not changing the address through code.

There is a command to change the i2c address setI2CAddress() but it has not been used

Hi @Nayak ,

OK. Thank you.

Please try opening the I2C Jumpers:

image

The ZED-F9P has internal active I2C pull-ups. The extra resistors can sometimes cause problems. On later F9P boards, the jumpers are open by default.

There is a tutorial linked below, if you need it.

I hope this helps,
Paul

Hi @PaulZC ,

Thank you for the suggestion. I have removed the pull-up resistors, but the behaviour is still random.
Just a quick question—can the F9P ever change its I2C address to 0x44 on its own? Have you ever seen the address automatically switch to 0x44?

That should be impossible…?!

The only plausible explanation I have is that maybe you have noise on UART1, and it is somehow creating a valid UBX-CFG-PRT or UBX-CFG-VALSET message? But I think that is extremely unlikely. The messages are CRC-checked.

Do you have any other hardware connected to UART1? Could it be generating the message?

Best,
Paul

Or maybe you have 0x44 saved as the default address in flash? If the F9P restarts / resets, it will use that saved address.

To check, ensure the address is set to 0x42 and then saveConfiguration() or use UBX-CFG-CFG in u-center.

I have setup to raspberry pi as well.

I have just enabled UBX for IN and OUT. UART1 is connected to the UART of RPi. It receives UBX-NAV-SAT packet.

Also, I have doubled checked but I have not set 0x44 address anywhere.

I have recorded the screen. https://drive.google.com/file/d/1bWyoeWlXucUE70C61nZnckIai_bAJ3Bc/view?usp=sharing

I have set it 0x42 and then I save it in flash. After that, I run the script and the address changes. And it is random, it is not always behaving. Sometimes, it changes and sometimes, it does not.

921600 is very fast. Are you sure the UART1 baud rate needs to be that fast?

Do you have any code running on the Pi that could be generating the UBX-CFG-PRT or UBX-CFG-VALSET message?

Yes, actually, I am receiving UBX-NAV-SAT data, RTCM messages and NMEA data on this port and segregating them. Hence, I have kept the baud rate so fast.

I have double-checked the code. We are not using UBX-CFG-PRT anywhere. We are using UBX-CFG-VALSET, but not for any I2C-related settings, especially not for the key 0x20510001.

But you only have UBX enabled on UART1 - for both input and output:

I am sorry. I have no more suggestions. I hope you find your issue.

Best,
Paul

Yeah, I just turned it off thinking NMEA and RTCM messages are producing the noise but still the address was changing.

Actually, I have more than 10 F9P modules, including 2–3 SparkFun Qwiic boards, and this behaviour is consistent across all of them.

Anyways, thank you for your support. If you have anything else to suggest, I’d be happy to test it.

There is an option in the u-center that you can choose Protocol In and Protocol Out as none for port settings, How it can be done programmatically?

With UBX-CFG-PRT: set the inProtoMask and/or outProtoMask to zero.

With UBX-CFG-VALSET, set CFG-UART1INPROT-UBX / -NMEA / -RTCM3X / -SPARTN to zero. Same for UART1OUTPROT.