Feature Request: Add support for sending RTCM data over I2C (Qwiic connectors)
shaneperera opened this issue · 18 comments
After playing around with the GPS-RTK2 board and the Sparkfun ESP-32 Thing Plus WROOM, I would like to send RTCM data over the I2C bus using the Qwiic connection system. I have tried this previously, however I have failed to get it working. Luckily, I was able to send RTCM data over UART2 to the GPS-RTK2 board as an alternative. It would be great if you could add new support for sending the RTCM data using the Qwiic connection system on the Sparkfun Ublox Arduino Library. I have tried online forums, however their solutions have not worked. Thanks in advance.
Hi @shaneperera ,
Please have a look at the ZED-F9P\Example3_StartRTCMBase. Does that not do what you need?
Best wishes,
Paul
Hi @PaulZC,
Sorry for the confusion. Currently, my implementation involves receiving a RTCM correction message from an iOS device to the Sparkfun Thing Plus (via BLE). I would like to send this RTCM message to the Sparkfun GPS-RTK2 board via I2C. I was thinking of a basic template for writing the message to the GPS board using the I2C. I can't find useful examples out there that assist me on this.
Kind regards,
Shane
Hi Shane,
I think it might be as simple as streaming the RTCM3 data to the I2C port. But you must make sure that the port is configured for RTCM3 input first. Have a look at UBX-CFG_PRT in the documentation and u-center.
This is not something I can easily test... But I'm happy to continue the discussion. Can you send me a link to your BLE to I2C code so I can take a look?
Cheers,
Paul
Hi Paul,
I found the relevant section in the interface description, however I'm struggling to make sense of it. I have attached the code below, I am yet to test this version as I am waiting for a new ESP32 ThingPlus to arrive. Thank you for spending your time on this, it is much appreciated.
Hi Shane,
Try commenting out this line:
Wire.write(0xFF); //register OxFF (used for RTCM data)
Why? Looking at the Integration Manual:
I see no mention of needing to use register 0xFF for write. I'm sure that only applies for read.
Let me know if this works!
If you don't already have one, I'd strongly recommend buying a cheap logic analyzer so you can spy on the I2C data. This one is great and you can configure PulseView to automatically decode I2C data for you.
All the best,
Paul
Hey,
I am currently trying to implement the usage of an NTRIP Client on the ESP32 myself. I got an ublox m8p assembled and using the SparkFun_Ublox_Arduino_Library for i2c communication, everything is working great, thanks for that!
However, implementing to write rtcm data via i2c I get some strange behaviour now.
I tried it straight forward with simply writing on the i2c as you suggested:
m_i2cwire->beginTransmission(0x42); m_i2cwire->write(buffer, len); //send the RTCM data m_i2cwire->endTransmission();
On the first try it instantly worked and I could conform via u-center that messages where received and the ublox chip was able to get into rtk float mode.
Looked good, so I started to implement some configurations on startup (disableing some nmea messages via i2c and setNavigationFrequency to increase the output speed). After running the code now (configuration works fine), I can see rtcm messages are still received via i2c (u-center MON-MSGPP is showing messages are parsed via i2c), however the ublox chip is not able the get any DGPS fix now.
So I wanted to ask if you got any similar problems @shaneperera @PaulZC ?
Or did you need to implement the write in a different way?
All the best,
Marco
Hi Marco (@mstranne ),
Let me ask the obvious question... What other changes have you made to the configuration? Have you done anything which may accidentally prevent the chip from using DGPS?
What happens if you go back to the default settings? Does it start working again?
// Uncomment the next line if you want to reset your module back to the default settings with 1Hz navigation rate
//myGPS.factoryDefault(); delay(5000);
Best wishes,
Paul
thanks, everything is working fine again, also with the configurations I had.
I guess it was because of a powering issue, since the battery was not fully charged at the beginning and now it seems to work fine in all cases.
Cheers,
Marco
Hi @mstranne,
Do you mind sharing your configuration and Arduino file if you don't mind? I have been working on this over the past few weeks and I still haven't been able to get an RTK fix using my current setup. I feel as if I am missing something here. Additionally, thank you again for the replies above @PaulZC? Unfortunately, I still wasn't able to get it working.
Cheers,
Shane
Hey Shane,
for me the straight forward approach is working fine now.
However, I see that you are handling the rtcm data as string? Maybe that is causing some problems.
You could use u-center to check if data is received by the ublox center and when if the received data is parsed correctly as rtcm messages.
I checked MON-MSGPP and there you can see if bytes are received and parsed as rtcm or if its just unknown bytes and nothing is parsed as rtcm
Cheers,
Marco
Hi Marco,
Okay that could be a starting point. Instead of a string are you just passing through the RTCM data and not specifying the data type? I checked U-center and there are unknown packets being parsed through I2C. So I will try again and update you.
Cheers,
Shane
Hi Shane (@shaneperera ) & Marco (@mstranne ),
Shane: how's it going? Have you had any success?
I'm doing some tidying up in the u-blox library ready for the next release. I'm going to close this issue as I don't think there is any way we can add the functionality you need as part of the library. What you are asking for is something quite unique, code that can receive an RTCM stream over (e.g.) serial / bluetooth and push it to the u-blox module over I2C. I really can't think of a clean way of doing that as part of the library - I'm sure it needs to be a separate piece of code specific to this task.
However, I will take an action to write this up as a tutorial - as soon as time permits.
Speaking of which, you might find these two tutorials useful:
https://learn.sparkfun.com/tutorials/setting-up-a-rover-base-rtk-system
https://learn.sparkfun.com/tutorials/how-to-build-a-diy-gnss-reference-station
Best wishes,
Paul
Hey,
All working fine!
How RTCM data is received does not need to be part of the library. If you would just add a write function for sending an byte array would be fine already.
I mean its quite straight forward, but then you dont need to touch the i2c in your own code, which was the reason to choose your lib in the first place.
Thanks for your support,
Marco
Hi Marco,
Ah, OK. Yes, I guess we can do that. Reopening...
Cheers!
Paul
RTCM data will have null (0x00) bytes in it so we'll need something that can tolerate those. How about:
pushRawBinary(const uint8_t *rawBinary, size_t numBytes); // Push (e.g.) RTCM data directly to the module
then we can just pass rawBinary and numBytes straight to .write?
that sounds exactly like what I was looking for.
Then you can directly pass the rtcm data received via the WiFiClient to the ublox !
Hi @PaulZC,
I have stuck with another solution for now. But, I would be interested in a tutorial when the time permits it. Thanks for the help in the meantime.
Hi Shane (@shaneperera ) & Marco (@mstranne ),
Well, that was fun! And it turned out to be quite straight forward...:
I've added a function called pushRawData which allows you to push (e.g.) RTCM data directly to I2C or Serial.
I've updated two of the ZED-F9P examples to test this. It works nicely. I've had a ZED-F9P acting as the base and outputting RTCM data to Serial1 after doing a surveyIn. Meanwhile I had a ZED-F9K acting as a Rover. The RTCM data is received on Serial1 and pushed to I2C using the new command. I see the ZED-F9K diffSolution and relPosValid flags go valid very quickly. If I pull the serial jumper wire, the RTK LED on the F9K stops blinking and - after a few seconds - the flags go invalid.
The changes are here:
b7e7d8a
I'm going to release the changes shortly.
All the best - and thanks again for raising this. I'm sure a lot of people will find it useful.
Paul