-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RP2040 GPS driver #12
Comments
Going to start with some test hardware, RP2040 feather and a random NEO M8N board I found in the lab |
Will be using these for note-taking - starting with M8 test hardware Using I2C compliant DDC interface, default address is https://www.u-blox.com/en/product/neo-m8-series?legacy=Current#Documentation-&-resources |
Reading3 registers can be read from over the DDC interface, registers 253-255
Will likely want random access reading which lets you specify the register to read each time
Random Read Access
|
WritingWriting just for UBX and NMEA messages for config data and other stuff, the registers aren't writable
|
Dynamic Platform ModelsWill need to use one of the airborne models since those are the only ones with permissive max altitude, probably |
UBX ChecksumCalculated over the message from the class to the end of the payload
|
Ok well I can definitely read something over I2C, it doesn't quite make sense what I'm getting back yet |
Ok so it looks like this device is sitting at address I'm sending some different poll request messages but I keep getting something like I also tried the SparkFun Arduino library which couldn't seem to connect to it Since this is just random garbage I pulled out of the lab it's entirely possible that it's cooked May try another Arduino library later to see what happens but am going to focus on other things until I have actual BITS hardware |
Ok so it definitely isn't cooked, it's spitting out plenty of NMEA strings over the UART connection. Just need to figure out how to configure it properly, sometimes it will stop sending NMEA data if I ask it to and sometimes not, and when it does work it doesn't persist through a power cycle which would be nice. In other news u-center is very useful for creating NMEA and UBX messages that are known good. |
Ok so I need to actually read the documentation it seems First of all, with a 10 second start up delay it seems that disabling NMEA on UART consistently works with the following NMEA message Then I generated the UBX message Lastly, it is worth noting that the payload length field is a 2-byte little endian value, which I had failed to internalize the first time around. thank god for u-center is all I can say, also little endian seems weird |
Looks like the below has permanently disabled NMEA on UART by saving to the flash, both UBX messages got an ACK
|
I2C should now be good to go as well, also changed address to
|
ok well the address change definitely didn't work, still at Moreover I don't get a UBX ack over i2c, just a whole lot of crap
there's definitely something being repeated but I have no idea what it is, it's not a UBX or NMEA message UART seems to be working pretty well though so once again Jon was right |
Ok so I'm fairly certain that the GPS module that I was testing with over break had borked I2C (it was a random one I found in the lab) Now working with the GPS on the BITSv5 boar the I2C comms are behaving as I would expect them to (proper 0xFF read) Looks like it has been automatically configured to report some NMEA messages every second or so, will need to disable those and then figure out what UBX messages I want and write parsers for them. |
Maybe I don't have to do all the parsing myself https://github.com/u-blox/ubxlib https://github.com/jacketizer/libnmea That should make this whole thing a lot faster |
Need to write a library to interface the RP2040 with the MAX-M10S
The text was updated successfully, but these errors were encountered: