I have two GPS-RTK2 units, and I’m using a Redboard to connect to either one via I2C. I am able to successfully connect using address 0x42 or 0x43 (the addresses of the two units, respectively), but all subsequent operations I have tried fail.
For example myGPS.factoryReset() does not reset the I2C address (and I haven’t checked whether it does anything else. Since this method is of type void, there’s no way to see whether it thinks the reset is successful.
myGPS.setI2COutput(COM_TYPE_UBX) returns false, as does myGPS.enableRTCMmessage(UBX_RTCM_1005, COM_PORT_I2C, 1), etc.
Everything on both boards seems to be working if I connect via USB from the u-center program. It’s only the SparkFun_Ublox_Arduino_Library calls that seem to be failing. Here’s a fairly minimal example:
/*
Minimal example of an apparent problem with interface to ZED-F9P
Hardware Connections:
Plug a Qwiic cable into the GPS-RTK2 and the Redboard
*/
#include <Wire.h> //Needed for I2C to GPS
#include "SparkFun_Ublox_Arduino_Library.h"
SFE_UBLOX_GPS baseGPS ;
byte baseAddress = 0x43 ;
byte defaultAddress = 0x42 ;
void setup()
{
Serial.begin(115200);
while (!Serial); //Wait for user to open terminal
Serial.println("Bug demonstration example");
Wire.begin();
if (baseGPS.begin(Wire, baseAddress) == false) //Connect to the Ublox module using Wire port
{
Serial.println(F("Ublox GPS Base Unit not detected at 0x43. Please check wiring. Freezing."));
while (1);
} else {
Serial.println(F("Successful connection to Ublox GPS Base Unit at 0x43")) ; // THIS LINE EXECUTES
}
while (Serial.available()) Serial.read(); //Trash any incoming chars
Serial.println("Press a key to reset module to factory defaults");
while (Serial.available() == false) ; //Wait for user to send character
baseGPS.factoryReset() ; //Reset everything: baud rate, I2C address, update rate, everything.
if (baseGPS.begin(Wire, baseAddress) == false) { //Attempt to re-connect using original address
Serial.println(F("Ublox GPS not detected at original I2C address 0x43."));
if (baseGPS.begin(Wire, defaultAddress) == false) { //Attempt to re-connect using default address
Serial.println(F("Ublox GPS not detected at default I2C address 0x42. Freezing"));
while (1);
}
} else {
Serial.println(F("Ublox GPS detected at original I2C address 0x43. Address unchanged.")); // THIS LINE EXECUTES
}
Serial.println("Press a key to set the I2C port to output UBX only");
while (Serial.available() == false) ; //Wait for user to send character
if (baseGPS.setI2COutput(COM_TYPE_UBX) == false) { //Set the I2C port to output UBX only (turn off NMEA noise)
Serial.println(F("Failed to set I2C port. Freezing.")) ; // THIS LINE EXECUTES
while(1) ;
}
}
void loop()
{
delay(250);
}
I think the issue here may be with your code. The [Factory Default Example works just fine to reset the I2C address in my testing here. I used the [Change I2C Address example to set it to 0x08 and then just adjusted the Factory Default example to look for the GPS at that address and it worked perfectly to reset it to 0x42. I would recommend testing with these two examples to try and debug your code to identify the issue.
Similarly, the “myGPS.setI2COutput();” function works just fine in our examples. Several examples like the [Get Position Example use that function with no issue. Make sure you’re running the “myGPS.saveConfiguration();” function after setting that to store it to the module.
Thanks for your reply. The problem I’m experiencing exists even when I use the examples you cited verbatim. So my suspicion is that the problem lies not with my code but with settings on GPS RTK2 board, such as not accepting commands via the I2C channel. I had used u-center to try modifying things prior to connect the GPS RTK2 to the Redboard, and I’m not sure whether any of those changes could have affected its behavior. I have also not yet found in u-center where one can reset the GPS RTK2 to factory settings, though I will keep looking.
I had already tried updating the firmware via u-center, but the process repeatedly hung without showing any progress at all; I even had to reboot my Windows VM each time to regain control. There have been no other obvious issues using u-center. I’m prepared to believe that the firmware update process simply doesn’t work correctly from a virtual machine (Parallels on a Mac) so will try a real Windows machine as soon as I can find one. (However, the use of a VM to upload a sketch shouldn’t have any bearing on the Redboard’s communication with the GPS RTK2 boards.)
If necessary, I will also try your suggestion to use the serial pins to do a factory reset. Is there no operation within u-center that can do the same thing? I looked but couldn’t find anything obvious.
Hmm, we have not tested u-center on a VM machine so that might be the root of the issue with updating the firmware since u-center is a Windows-only software at the moment. If you have not looked at it yet, the [u-center User Guide has detailed information about running a firmware update.