RP2040 GPS driver

[michaelshipman]

Need to write a library to interface the RP2040 with the MAX-M10S

[michaelshipman]

Going to start with some test hardware, RP2040 feather and a random NEO M8N board I found in the lab

[michaelshipman]

Will be using these for note-taking - starting with M8 test hardware

Using I2C compliant DDC interface, default address is 0x42

https://www.u-blox.com/en/product/neo-m8-series?legacy=Current#Documentation-&-resources
https://content.u-blox.com/sites/default/files/NEO-8Q-NEO-M8-FW3_HIM_UBX-15029985.pdf
https://content.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_UBX-13003221.pdf

[michaelshipman]

Reading

3 registers can be read from over the DDC interface, registers 253-255

0xFD and 0xFE are the number of bytes that can be read and 0xFF allows the data stream to be read, if no data available then 0xff returned

Will likely want random access reading which lets you specify the register to read each time

RW bit - low for write access, high for read access

Random Read Access

• Start condition
• 7 bit address
• RW bit low
• 8 bit register address
• Receiver ACK
• Start condition
• 7 bit address
• RW bit high
• read 1 to N bytes
• NACK and stop condition to stop

[michaelshipman]

Writing

Writing just for UBX and NMEA messages for config data and other stuff, the registers aren't writable

Following the start condition from the master, the 7-bit device address and the RW bit (which is a logic low for write access) are clocked onto the bus by the master transmitter. The receiver answers with an acknowledge (logic low) to indicate that it is responsible for the given address. Now, the master can write 2 to N bytes to the receiver, generating a stop condition after the last byte being written. The number of data bytes must be at least 2 to properly distinguish from the write access to set the address counter in random read accesses.

• 7-bit address
• RW bit low
• 2 to N bytes
• Stop condition

[michaelshipman]

Dynamic Platform Models

Will need to use one of the airborne models since those are the only ones with permissive max altitude, probably Airborne <2g to start with

[michaelshipman]

Let's try a test with the UBX-INF-DEBUG message, should return some debug info

[michaelshipman]

UBX Checksum

Calculated over the message from the class to the end of the payload

The checksum algorithm used is the 8-Bit Fletcher Algorithm, which is used in the TCP standard (RFC 1145). This algorithm works as follows:

• Buffer[N] contains the data over which the checksum is to be calculated.
• The two CK_ values are 8-Bit unsigned integers only! If implementing with larger-sized integer values, make sure to mask both CK_A and CK_B with 0xFF after both operations in the loop.
• After the loop, the two U1 values contain the checksum, transmitted after the Message, which conclude the Frame.

CK_A = 0, CK_B = 0
for (i = 0; I < n; i++) {
    CK_A = CK_A + buffer[I];
    CK_B = CK_B + CK_A;
}

[michaelshipman]

Ok well I can definitely read something over I2C, it doesn't quite make sense what I'm getting back yet

[michaelshipman]

Ok so it looks like this device is sitting at address 0x0F which is a bit weird but not really an issue.

I'm sending some different poll request messages but I keep getting something like 16 29 15 2 6 10 ff if I read without specifying a register and something even weirder if I do specify a register (for instance the registers that indicate the number of bytes available to be read come back as ff)

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

[michaelshipman]

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.

[michaelshipman]

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 $PUBX,41,1,0001,0001,9600,0*14\r\n which is lovely.

Then I generated the UBX message 0xB5, 0x62, 0x06, 0x00, 0x14, 0x00, 0x01, 0x00, 0x00, 0x00, 0xD0, 0x08, 0x00, 0x00, 0x80, 0x25, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x9A, 0x79 which provided me with a nice ACK 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

[michaelshipman]

Looks like the below has permanently disabled NMEA on UART by saving to the flash, both UBX messages got an ACK

const uint8_t
        message4[28] = {0xB5, 0x62, 0x06, 0x00, 0x14, 0x00, 0x01, 0x00,
                        0x00, 0x00, 0xD0, 0x08, 0x00, 0x00, 0x80, 0x25,
                        0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x00, 0x00,
                        0x00, 0x00, 0x9A, 0x79};  // UBX message to do the same
                                                  // as the NMEA message below,
                                                  // was here just to see if I
                                                  // could get an ACK, which I
                                                  // did

    const uint8_t save_msg[21] = {0xB5, 0x62, 0x06, 0x09, 0x0D, 0x00,
                                  0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF,
                                  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                                  0x03, 0x1D, 0xAB};  // UBX message to save
                                                      // current config to
                                                      // battery backed RAM and
                                                      // flash

    const char *message2 =
        "$PUBX,41,1,0001,0001,9600,0*14\r\n";  // NMEA message that enables only
                                               // UBX on UART

    printf("Sending config\n");

    uart_write_blocking(uart0, (uint8_t *)message2, 32);
    uart_write_blocking(uart0, message4, 28);
    sleep_ms(100); // next message won't get an ACK unless a delay is here, 100 worked but could probably be shorted
    uart_write_blocking(uart0, save_msg, 21);

[michaelshipman]

I2C should now be good to go as well, also changed address to 0x42

const uint8_t ubx_cfg_prt_i2c_ubx_only[28] = {
        0xB5, 0x62, 0x06, 0x00, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00,
        0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0xA0, 0x96};  // sets I2C to UBX
                                                          // only, also sets I2C
                                                          // address to 0x42