What am I doing wrong?

GPS/GNSS
1

I have a Pro Micro connected to a uBox neo M10 from Sparkfun with TX on the PM connected to the GNSS via a voltage divider so the 5V level on the PM is 3V on the GNSS.

I run Paul’s code to stop all NEMA sentences and poll for just GGA and it works fine. This proves that my Pro Micro TX to GNSS RX path is OK.

Then I want to change from the default CFG-NAVSPG-UTCSTANDARD from PORT to AIR1 so I get altitude data above 12,000 meters. Others have used Paul’s code to make this change and it worked. I want to directly change this parameter by sending the GNSS the proper sequence of bytes to prove to myself that I understand the spec sheet.

I sent the following hex values to the GNSS:

B5 62 06 8A 09 00 01 00 00 20 11 00 1C 06 ED BA

but I get no ACK response.

Where did I go wrong?

Thanks in advance,
Rick

2

It’s CFG-NAVSPG-DYNMODEL, and the key# is encoded little-endian
So “21 00 11 20 06”
I didn’t check the fletcher sums, but if those are wrong the packet will be ignored.

3

Sum/Form is also wrong. The length of 9 bytes is encoded as 16-bit, not 8-bit

1 Like
4

I now see all of my mistakes and it now works.

Thank you for your invaluable assistance.

Rick

5

I have documented what PaulZC and Clive1 have taught me plus a few other insights about sending commands to this GNSS:

I welcome your corrections and comments.

Rick

6

https://rick.sparber.org/neoM10.pdf#page=6

09 is the LSB (least significant byte) of the length. The entire UBX packet is little endian, its not flipping around, the checksum is of the bytes composed and bytes sent, in machine order. The payload length field is 16-bit, this I would say is the most often misunderstood and perhaps a tad ambiguous in u-Blox’s documentation.

The payload of the keys is more free-form in nature, as the high-order byte of the key determines the field types/sizes. Some have IEEE-754 float and double forms.

Covered checksumming here, generally computing on-the-fly

Covered sending a sub-set of values here, quickly, so not float, double, 64-bit or ASCII types

Compound VALSET here

7

The u-Blox 6 Series devices there’s a bigger structure, for UBX-CFG-NAV5, where I can just send the Dynamic setting via bit field flag. The 9 and 10 Series use the individual keys for configuration items, so the compound structures can be deprecated.

8

From page 15, this is an ACK-ACK response to UBX-CFG-VALGET (0x06 0x8B) request, checksums are correct

unsigned char data[] = {
0xB5,0x62,0x05,0x01,
0x02,0x00,
0x06,0x8B,
0x99,0xC2
};
9

I think I understand your comments and have updated the document to version 1.0.1.

Thanks!

Rick