u-blox Initialization Command Stream audit

[GPSFan]

This the first part of the audit I have done on the command stream sent to u-blox GNSS receivers by Meshtastic.

Background:

All data was captured by monitoring the GNSS serial port while starting up Meshtastic v 2.17. The M10 I used was a BZGNZZ-121 from Amazon. The M8 a GYGPSV5 with an M8N with firmware 3.01 from Amazon. The Neo-7M and Neo-6M were on GY-GPS6MV2 from Amazon.

Neo-6 gets these commands from Meshtastic:

1) b5 62 06 08 00 00 0e 30 2) b5 62 0a 04 00 00 0e 34 3) b5 62 06 39 08 00 3f 10 b1 56 1e 03 00 01 bf c9 4) b5 62 06 23 28 00 00 00 1b 00 00 00 00 00 00 00 03 10 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 01 87 5b 5) b5 62 06 08 06 00 e8 03 01 00 01 00 01 39 6) b5 62 06 01 08 00 f0 01 01 00 01 01 01 01 05 3a 7) b5 62 06 01 08 00 f0 02 01 01 01 01 01 01 07 46 8) b5 62 06 01 08 00 f0 03 01 00 01 01 01 01 07 48 9) b5 62 06 01 08 00 f0 05 01 00 01 01 01 01 09 56 10) b5 62 06 01 08 00 f0 04 01 01 01 01 01 01 09 54 11) b5 62 06 01 08 00 f0 00 01 01 01 01 01 01 05 38 12) b5 62 06 11 02 00 08 01 22 92 13) b5 62 06 3b 2c 00 01 06 00 00 0e 81 43 01 e8 03 00 00 10 27 00 00 00 00 00 00 01 00 00 00 2c 01 00 00 4f c1 03 00 87 02 00 00 ff 00 01 00 d6 4d 08 04 62 7a 14) b5 62 06 09 0d 00 00 00 00 00 ff ff 00 00 00 00 00 00 0f 29 b7

What the Neo-6 sends to Meshtastic on startup and in response to MON-VER request:

$GPTXT,01,01,02,u-blox ag - www.u-blox.com50 $GPTXT,01,01,02,HW UBX-G60xx 00040007 FF7FFFFFp53 $GPTXT,01,01,02,ROM CORE 7.03 (45969) Mar 17 2011 16:18:3459 $GPTXT,01,01,02,ANTSUPERV=AC SD PDoS SR20 $G2 �y$GPRMC,,V,,,,,,,,,,N53KNOW33 $GPVTG,,,,,,,,,N30 $GPGGA,,,,,,0,00,99.99,,,,,,48 $GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.9930

Neo-7 gets these commands from Meshtastic:

1) b5 62 06 08 00 00 0e 30 2) b5 62 0a 04 00 00 0e 34 3) b5 62 06 3e 14 00 00 00 ff 02 00 08 10 00 01 00 00 01 01 01 03 00 01 00 00 01 7a 7d 4) b5 62 06 39 08 00 3f 10 b1 56 1e 03 00 01 bf c9 5) b5 62 06 23 28 00 00 00 1b 00 00 00 00 00 00 00 03 10 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 01 87 5b 6) b5 62 06 08 06 00 e8 03 01 00 01 00 01 39 7) b5 62 06 01 08 00 f0 01 01 00 01 01 01 01 05 3a 8) b5 62 06 01 08 00 f0 02 01 01 01 01 01 01 07 46 9) b5 62 06 01 08 00 f0 03 01 00 01 01 01 01 07 48 10) b5 62 06 01 08 00 f0 05 01 00 01 01 01 01 09 56 11) b5 62 06 01 08 00 f0 04 01 01 01 01 01 01 09 54 12) b5 62 06 01 08 00 f0 00 01 01 01 01 01 01 05 38 13) b5 62 06 11 02 00 08 04 25 95 14) b5 62 06 09 0d 00 00 00 00 00 ff ff 00 00 00 00 00 00 0f 29 b7

What the Neo-7 sends to Meshtastic on startup and in response to MON-VER request:

$GPTXT,01,01,02,u-blox ag - www.u-blox.com50 $GPTXT,01,01,02,HW UBX-G70xx 00070000 FF7FFFFFo69 $GPTXT,01,01,02,ROM CORE 1.00 (59842) Jun 27 2012 17:43:5259 $GPTXT,01,01,02,PROTVER 14.001E $GPTXT,01,01,02,ANTSUPERV=AC SD PDoS SR20 $GPTXT,01,01,02,ANTSTATUS=DONTKNOW33 $GPTXT,01,01,02,LLC FFFFFFFF-FFFFFFFF-FFFFFFFF-FFFFFFFF-FFFFFFF9*51

M8N gets these commands from Meshtastic:

1) b5 62 06 08 00 00 0e 30 2) b5 62 0a 04 00 00 0e 34 3) b5 62 06 3e 1c 00 00 00 ff 03 00 08 10 00 01 00 01 01 01 01 03 00 01 00 01 01 06 08 0e 00 01 00 01 01 a4 35 4) b5 62 06 39 08 00 3f 10 b1 56 1e 03 00 01 bf c9 5) b5 62 06 23 28 00 00 00 1b 00 00 00 00 00 00 00 03 10 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 01 87 5b 6) b5 62 06 08 06 00 e8 03 01 00 01 00 01 39 7) b5 62 06 01 08 00 f0 01 01 00 01 01 01 01 05 3a 8) b5 62 06 01 08 00 f0 02 01 01 01 01 01 01 07 46 9) b5 62 06 01 08 00 f0 03 01 00 01 01 01 01 07 48 10) b5 62 06 01 08 00 f0 05 01 00 01 01 01 01 09 56 11) b5 62 06 01 08 00 f0 04 01 01 01 01 01 01 09 54 12) b5 62 06 01 08 00 f0 00 01 01 01 01 01 01 05 38 13) b5 62 06 86 08 00 00 03 00 00 00 00 97 6f 9d 0c 14) b5 62 06 09 0d 00 00 00 00 00 ff ff 00 00 00 00 00 00 0f 29 b7

What the M8N sends to Meshtastic on startup and in response to MON-VER request:

$GNTXT,01,01,02,u-blox AG - www.u-blox.com4E $GNTXT,01,01,02,HW UBX-M8030 0008000060 $GNTXT,01,01,02,EXT CORE 3.01 (107900)33 $GNTXT,01,01,02,ROM BASE 2.01 (75331)19 $GNTXT,01,01,02,FWVER=SPG 3.0146 $GNTXT,01,01,02,PROTVER=18.0011 $GNTXT,01,01,02,FIS=0xEF4015 (200030)59 $GNTXT,01,01,02,GPS;GLO;GAL;BDS77 $GNTXT,01,01,02,SBAS;IMES;QZSS49 $GNTXT,01,01,02,GNSS OTP=GPS;GLO37 $GNTXT,01,01,02,LLC=FFFFFFFF-FFFFFFED-FFFFFFFF-FFFFFFFF-FFFFFF6923 $GNTXT,01,01,02,ANTSUPERV=AC SD PDoS SR3E $GNTXT,01,01,02,ANTSTATUS=DONTKNOW2D $GNTXT,01,01,02,PF=3FF4B

M10 gets these commands from Meshtastic after it has switched the baud rate to 9600:

1) b5 62 06 08 00 00 0e 30 2) b5 62 0a 04 00 00 0e 34 3) b5 62 06 3e 1c 00 00 00 ff 03 00 08 10 00 01 00 01 01 01 01 03 00 01 00 01 01 06 08 0e 00 01 00 01 01 a4 35 4) b5 62 06 39 08 00 3f 10 b1 56 1e 03 00 01 bf c9 5) b5 62 06 23 28 00 00 00 1b 00 00 00 00 00 00 00 03 10 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 01 87 5b 6) b5 62 06 08 06 00 e8 03 01 00 01 00 01 39 7) b5 62 06 01 08 00 f0 01 01 00 01 01 01 01 05 3a 8) b5 62 06 01 08 00 f0 02 01 01 01 01 01 01 07 46 9) b5 62 06 01 08 00 f0 03 01 00 01 01 01 01 07 48 10) b5 62 06 01 08 00 f0 05 01 00 01 01 01 01 09 56 11) b5 62 06 01 08 00 f0 04 01 01 01 01 01 01 09 54 12) b5 62 06 01 08 00 f0 00 01 01 01 01 01 01 05 38 13) b5 62 06 86 08 00 00 03 00 00 00 00 97 6f 9d 0c 14) b5 62 06 09 0d 00 00 00 00 00 ff ff 00 00 00 00 00 00 0f 29 b7

What the M10 sends to Meshtastic on startup and in response to MON-VER request:

$GNTXT,01,01,02,u-blox AG - www.u-blox.com4E $GNTXT,01,01,02,HW UBX 10 000A000053 $GNTXT,01,01,02,ROM SPG 5.10 (7b202e)7C $GNTXT,01,01,02,FWVER=SPG 5.1040 $GNTXT,01,01,02,PROTVER=34.101E $GNTXT,01,01,02,CHIPID=000000DEFED20F405476 $GNTXT,01,01,02,GPS;GLO;GAL;BDS77 $GNTXT,01,01,02,SBAS;QZSS60 $GNTXT,01,01,02,ANTSUPERV=22 $GNTXT,01,01,02,ANTSTATUS=DONTKNOW2D $GNTXT,01,01,02,PF=F7FFF4F $GNTXT,01,01,02,Starting GNSS5A $GNTXT,01,01,01,PCAS inv format23 $GNTXT,01,01,01,PCAS inv format23

The next part will detail the issues with the commands sent to the modules.

[GPSFan]

This is the second part of audit of the u-blox initilazation command stream. More detail can be provided as required.

Lets look at what happens with the M10 more closely.

All commands were captured by monitoring the GNSS serial port while starting up Meshtastic v 2.17.

I have the following modules.

M10 M10Q in a BZGNSS-121 from Amazon and a M10S on a SparkFun Breakout board. M9 a custom board with an M9N, M8 a t-beam v1.1 with M8N firmware 3.01, Betian BN-880 with 8030 chip with firmware 2.01, GYGPSV5 with an M8N firmware 3.01, Neo-7M and Neo-6M were on GY-GPS6MV2 from Amazon. F9 a custom boards with an F9P and an F9T.

Not all tests were done with all boards.

At this time the only modules of interest are Neo-6, Neo-7, M8 and M10. The older Neo-6 with firmware 6->7.03 are GPS only, "newer" Neo-6s with firmware supporting protocol 14 can receive GPS and GLONASS.

I used u-Center V20.10 to generate the commands.

It might help to follow along with the protocol specs. available here:

https://content.u-blox.com/sites/default/files/products/documents/u-blox6_ReceiverDescrProtSpec_%28GPS.G6-SW-10018%29_Public.pdf https://content.u-blox.com/sites/default/files/products/documents/u-blox6-GPS-GLONASS-QZSS-V14_ReceiverDescrProtSpec_%28GPS.G6-SW-12013%29_Public.pdf https://content.u-blox.com/sites/default/files/products/documents/u-blox7-V14_ReceiverDescriptionProtocolSpec_%28GPS.G7-SW-12001%29_Public.pdf https://content.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_UBX-13003221.pdf https://content.u-blox.com/sites/default/files/u-blox-M10-SPG-5.10_InterfaceDescription_UBX-21035062.pdf

At startup the following commands are sent if a u-blox GNSS device is discovered. If the baudrate is not 9600, (38400 is default for the M10Q) these 2 commands are sent to switch it to 9600.

CFG-RATE b5 62 06 08 00 00 0e 30 // poll the RATE settings CFG-PRT b5 62 06 00 14 00 01 00 00 00 d0 08 00 00 80 25 00 00 07 00 03 00 00 00 00 00 a2 b5

Data rate is now 9600 baud

The next 2 commands poll the rate and query the version of the receiver.

CFG-RATE b5 62 06 08 00 00 0e 30

This poll RATE command is described in protocol spec version 14, but not in version 15 and later which is probably an omission in the spec.

CFG-MON-VER b5 62 0a 04 00 00 0e 34 // asks for the MON-VER string

Next Meshtastic sends a CFG-GNSS command, to turn on GPS and SBAS for Neo-6 and GPS, SBAS and GLONASS for other models. The command shown below is for the other models.

CFG-GNSS b5 62 06 3e 1c 00 00 00 ff 03 00 08 10 00 01 00 01 01 01 01 03 00 01 00 01 01 06 08 0e 00 01 00 01 01 a4 35

The M10 gives this command a NAK, the M8 gives an ACK. The checksum is correct. u-Center gives us this for the command:

CFG-GNSS b5 62 06 3e 1c 00 00 00 ff 03 00 08 10 00 01 00 00 01 01 01 03 00 01 00 00 01 06 08 0e 00 01 00 00 01 a1 17

Which decodes to: GPS channels 8 min 16 max, SBAS channels 1 min 3 max, GLONASS channels 8 min 14 max sats with # of channels to use set to 255. Plus some other bits which are in reserved fields and should be 0.

The Meshtastic command has an additional byte in all 3 systems set to 0x01. I don't fully understand little endian but there shouldn't be more than 2 flag bytes with anything set to 1 in them.

The older Neo-6 does not support this command, hense the alternate defined as GNSS_7 in ubx.h

The Neo-7 supports this command but only defines the lsb of the flags as enable. The Neo-7 spec says Don't enable GLONASS with power save mode.

The M8 supports this command and adds additional bits in the sigCfgMask for 2nd frequency support. For M8 with protocol 18 (most t-beams) the mn field needs to be a minimum of 4, for NEO-6 & NEO-7 it can be a minimum of 3. For M8, QZSS and GPS should be both either disabled or enabled. For M8, the prohibition about GLONASS & power save mode is no longer present. The M9 supports this command like the M8 but is depracated and wants you to use VALSET/VALGET/VALDEL. The M10 does not support this command and wants you to use VALSET/VALGET/VALDEL, but will ACK the command from u-Center, but not the Meshtastic command.

Maybe the M10 is more pickey than the M8 or earlier about reserved bits being 0.

So, the problems with this command for a t-beam with and M8N is the additional 0x01s in each of the 3 constallations and the lack of QZSS being enabled. Even though the M8 ACKs this command, the receiver firmware may not be happy. For a Neo-7 based board the powersave and GLONASS will cause problems. Additional constallations could be enabled for the M8. The problem for an M10 is that this command would not enable any additional constallations either. Since it is NAKd, the current GNSS config remains unchanged from whatever it was. I insured that all modules I used were reset to factory defaults before testing. As the M10 has no flash, if the module has no backup battery (or it has run down) the M10 will revert to factory defaults.

The next command the Meshtastic code sends is to enable the Jamming/Interference monitor:

CFG-ITFM b5 62 06 39 08 00 3f 10 b1 56 1e 03 00 01 bf c9

But, u-Center says with default B=3,CW=15 it should be: b5 62 06 39 08 00 f3 ac 62 ad 1e c3 42 01 19 4a

what u-Center says with broadcast and CW threshold reversed B=15,CW=3 b5 62 06 39 08 00 3f ac 62 ad 1e c3 42 01 65 aa

Neither of the u-Center generated commands match what Meshtastic sends, so we don't know what the receivers will do even though they all ACK it.

The next NAVX5 command could cause all sorts of issues if not correct. version 0 is for protocol 15,16,17. version 2 for 18-23.01. version 3 for higher.

Meshtastic will only send this version 0 command:

CFG-NAVX5 b5 62 06 23 28 00 00 00 1b 00 00 00 00 00 00 00 03 10 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 01 87 5b

u-Center says that this is what a version 0 command should be:

       b5 62 06 23 28 00 00 00 4c 66 c0 00 00 00 00 00 03 10 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 01 de 5f

The command Meshtastic sends does not look correct for version 0. Don't know what an M8 with 3.01 firmware (protocol 18) will do with a version 0 command. Or what an M10 (protocol 34) will do with a version 0, or 1 command, correct or not.

Next comes a CFG-RATE command.

CFG-RATE b5 62 06 08 06 00 e8 03 01 00 01 00 01 39

Which is correctly formed to set measRate to 1000ms, navRate ratio to 1, and timeRef to GPS time.

The next messages turn on or off specific NMEA sentences on specific ports.

R0=DDC,R1=UART1,R2=UART2(old),R3=USB,R4=SPI,R5=?? Cl Id R0 R1 R2 R3 R4 R5 ck ck
CFG-MSG b5 62 06 01 08 00 f0 01 01 00 01 01 01 01 05 3a // GLL off for UART1 CFG-MSG b5 62 06 01 08 00 f0 02 01 01 01 01 01 01 07 46 // GSA enable at 1Hz CFG-MSG b5 62 06 01 08 00 f0 03 01 00 01 01 01 01 07 48 // GSV off for UART1 CFG-MSG b5 62 06 01 08 00 f0 05 01 00 01 01 01 01 09 56 // VTG off for UART1 CFG-MSG b5 62 06 01 08 00 f0 04 01 01 01 01 01 01 09 54 // RMC enable at 1Hz CFG-MSG b5 62 06 01 08 00 f0 00 01 01 01 01 01 01 05 38 // GGA enable at 1Hz

All above look OK except for the R5 field which should be 0x00 according to u-Center.

Power management command is next, and is not formed correctly

u-blox defines the following power management commands

CFG-PM Neo-6 CFG-PM2 Neo-6, Neo-7, M8, M9 CFG-PMS M8, M9 CFG-PWR M8, M9

CFG-RXM Neo-6, Neo-7 CFG-RXM-PMREQ M8, M9

M10 should use VALSET but ACKs the M8 commands.

For different versions of u-blox modules Meshtastic sends different power management commands. CFG_RXM_PSM -->u-blox CFG-RXM command with bit 1 set CFG_RXM_ECO -->u-blox CFG-RXM command with bit 4 set CFG_PM2 -->u-blox CFG-PM2 PMS -->u-blox CFG-PMS PMREQ -->u-blox CFG-RXM-PMREQ

For the Neo-6, Meshtastic sends its CFG_RXM_PSM & CFG_PM2 commands. For the Neo-7, Meshtastic sends its CFG_RXM_ECO command. For the M8 and above, Meshtastic sends its PMS command.

Meshtastic sends the following command to the M10:

CFG-PMS b5 62 06 86 08 00 00 03 00 00 00 00 97 6f 9d 0c

Which decodes to "agressive 1Hz power management" with the wrong reserved bytes

From the ubx.h file: const uint8_t GPS::_message_PMS[] = { 0x00, // Version (0) 0x03, // Power setup value 0x00, 0x00, // period: not applicable, set to 0 0x00, 0x00, // onTime: not applicable, set to 0 0x97, 0x6F // reserved, generated by u-center

That is not correct, as the last 2 bytes are reserved and should be 0x00. 0x97,0x6f are the checksum bytes for the command as set up by u-Center.

What Meshtastic sends:

b5 62 06 86 08 00 00 03 00 00 00 00 97 6f 9d 0c

What u-Center says it should be B5 62 06 86 08 00 00 03 00 00 00 00 00 00 97 6F

Here again we don't know what the receiver will do with a command with the reserved bits non 0x00, even though the command is ACKd.

Looking at the other commands that Mashtastic could send:

from ubx.h

---

const uint8_t GPS::_message_CFG_RXM_PSM[] PROGMEM = { 0x08, // Reserved 0x01 // Power save mode };

const uint8_t GPS::_message_CFG_RXM_ECO[] PROGMEM = { 0x08, // Reserved 0x04 // eco mode };

---

CFG_RXM_PSM Looks correct to send a Neo-6 into power save mode. CFG_RXM_ECO Looks like it would send a Neo-6 into ECO mode but a Neo-7 into Continuous mode. It is only sent for a Neo-7.

Construction of PM2 command below is probablematic as the command should be 44 or 48 bytes long but the defination in ubx.h is only 42. the last 20 bytes are reserved and should be 0x00, they are not.

line 433 GPS.cpp -->> msglen = makeUBXPacket(0x06, 0x3B, 44, _message_CFG_PM2);

Line 18 and beyond in ubx.h:

---

const uint8_t GPS::_message_CFG_PM2[] PROGMEM = { 0x01, 0x06, 0x00, 0x00, // version, Reserved 0x0E, 0x81, 0x43, 0x01, // flags 0xE8, 0x03, 0x00, 0x00, // update period 1000 ms 0x10, 0x27, 0x00, 0x00, // search period 10s 0x00, 0x00, 0x00, 0x00, // Grod offset 0 0x01, 0x00, // onTime 1 second 0x00, 0x00, // min search time 0 0x2C, 0x01, // reserved 0x00, 0x00, 0x4F, 0xC1, // reserved 0x03, 0x00, 0x87, 0x02, // reserved 0x00, 0x00, 0xFF, 0x00, // reserved 0x01, 0x00, 0xD6, 0x4D // reserved };

const uint8_t GPS::_message_GNSS_7[] = { 0x00, // msgVer (0 for this version) 0x00, // numTrkChHw (max number of hardware channels, read only, so it's always 0) 0xff, // numTrkChUse (max number of channels to use, 0xff = max available) 0x02, // numConfigBlocks (number of GNSS systems), most modules support maximum 3 GNSS systems // GNSS config format: gnssId, resTrkCh, maxTrkCh, reserved1, flags 0x00, 0x08, 0x10, 0x00, 0x01, 0x00, 0x00, 0x01, // GPS 0x01, 0x01, 0x03, 0x00, 0x01, 0x00, 0x00, 0x01 // SBAS };

---

Thats only 42 bytes in the defination, so the next 2 bytes in the .h file will be sent which are coincidently are both 0x00 from the GNSS_7 command defination, if they were both in the same area of memory, which they are not, and from the data recording for a NEO-6 the last 2 bytes are 0x84 0x04.

The CFG-PM2 command is only used for a Neo-6 and in conjunction with the CFG_RXM_PSM command For protocols <18 (Neo-7 and old M8) just the CFG_RXM_ECO command is sent. Which will put the receiver into Continuous mode.

The next command Meshtastic sent is to save the configuration.

CFG-CFG b5 62 06 09 0d 00 00 00 00 00 ff ff 00 00 00 00 00 00 0f 29 b7

All the modules ACKs this message, and seem to save the config so it's probably ok, The Neo-7 and M8 might have Flash, depending on what the source of the module was. The M9 that I have has Flash. The M10 doesn't have Flash, firmware is in ROM.

u-Center gives us the following for various save options:

b5 62 06 09 0d 00 00 00 00 00 ff ff 00 00 00 00 00 00 17 31 bf // all devices b5 62 06 09 0d 00 00 00 00 00 ff ff 00 00 00 00 00 00 03 1d ab // BBR & FLASH b5 62 06 09 0d 00 00 00 00 00 ff ff 00 00 00 00 00 00 01 1b a9 // BBR b5 62 06 09 0d 00 00 00 00 00 ff ff 00 00 00 00 00 00 02 1c aa // FLASH

The problem here is that an 0x0f in the device mask field means that bit 3 is 1 and "must be set to 0" according to the CFG-CFG message spec for Neo-6 Neo-7 and M8. What that will do is anyones guess. The M8 and M10 don't NAK the message.

For the M9 and M10 the behavior has changed such that:

"if any bit is set in the clearMask: all configuration in the selected non-volatile memory is deleted if any bit is set in the saveMask: all current configuration is stored (copied) to the selected layers if any bit is set in the loadMask: The current configuration is discarded and rebuilt from all the lower layers"

The defination of the device mask remains the same but lacks the "must be set to 0" reminder, and adds notes that bits 2 & 4 are only supported on protocol versions less than 14.00.

And then some time later, this, which is to put the receiver to sleep for 120000 ms ->120 seconds or 2 minutes.

UBX-RXM-PMREQ b5 62 02 41 08 00 c0 d4 01 00 02 00 00 00 e2 0d

flags, only backup defined in M8 and below ^ for version 0 (8 byte). The u-Center version of this command is identical. Neo-6 & Neo-7 define only the 8 byte version, with the backup flag. For version 1 (16 byte) the M8 has both force and backup flags. The M9 defines both version 0 & 1 (8 byte and 16 byte) as in the M8 the 8 byte version 0 doesn't have a force flag. The M10 which only defines the 16 byte version 1. The M10 doesn't claim to support this 8 byte command. The M10 defines both the force and backup bits which should both be set in the 16 byte version 1 command:

u-Center generated PMREQ version 1: UBX-RXM-PMREQ b5 62 02 41 10 00 00 00 00 00 c0 d4 01 00 06 00 00 00 00 00 00 00 ee 71 backp and force flags set ^ no wakeup sources

The M10 doesn't NAK the 8 byte version, and both work from u-Center.

The 16 byte version with force and backup draws only 4.5ma while the 8 byte or 16 byte with just backup set draws 10ma during the 2min sleep period, and about 27ma for either full power or balanced CFG-PMS with the factory defaults. Measured with a Nordic Power Profiler Kit 2 on the BZGNSS-121

More to come...

[GPSFan]

I have not made any recommendations yet as to how to address these issues, I am still testing revised commands on the u-blox modules I have.

[jp-bennett]

Outstanding work. I'd suggest making changes small chunks at a time, so we can test each one on the various hardware we have access to. I'll be glad to help review and test changes.

[GPSFan]

Yep, that's the plan, baring conflicts with RealLife(tm) and DayJob(tm) ;>))

[GPSFan]

I will monitor the GNSS modules operating current as well to see how the "power saving" modes work. To that end I have a Nordic Semi Power Profiler Kit 2 that I'll put in series with the external GNSS module. It won't be 100% accurate as most of the modules have other circuits like leds and LDOs that draw a bit of power.

[jp-bennett]

@GPSFan thinking about this has brought some memories to mind of my similar trip through the GPS code a few months ago. It seems like I saw several instances of the GPS data sheets disagreeing with the output of the u-center app. I'll see if I can find those instances again in the next few days.

[GPSFan]

@jp-bennett I'd like to see those references, there have been versions of u-Center in the past that have had issues with incorrect commands being formed. I try to use the latest, and crosscheck with the protocol spec. I submitted a pull request to protobufs to start the process of adding the Chatter 2 board, Trying to follow the procedure outlined in the docs. I am using the Chatter 2 with a replaced Lora module for my GNSS testing as it is really easy to instrument.

[GPSFan]

@jp-bennett Do you have a t-beam with a Neo-6? I'd like to know what protocol version it is, The Neo-6 I have is 7.03 and I don't want to update it to anything newer, and that's the only Neo-6 I have. My t-beams have M8Ns.

[jp-bennett]

@jp-bennett Do you have a t-beam with a Neo-6? I'd like to know what protocol version it is, The Neo-6 I have is 7.03 and I don't want to update it to anything newer, and that's the only Neo-6 I have. My t-beams have M8Ns.

I have the t-beam 1.2 with a neo-6m.

INFO | ??:??:?? 2 [GPS] Found a UBlox Module using baudrate 9600 DEBUG | ??:??:?? 2 [GPS] Module Info : DEBUG | ??:??:?? 2 [GPS] Soft version: 7.03 (45969) DEBUG | ??:??:?? 2 [GPS] Hard version: 00040007 DEBUG | ??:??:?? 2 [GPS] Extensions:0 On these devices, the GPS seems to act really oddly. Enough so that we set isProblematicGPS to have a dedicated code path to get them to initialize properly. I think I've only ever seen reports of 7.03 from NEO-6m, too.

[jp-bennett]

I'd like to see those references,

I'm not immediately finding any, today. It's possible I'm remembering the differences between Meshtastic and u-center. Either way, as we work through what you've found, I'll cross-reference and see if any discrepancies pop up.

[GPSFan]

Sounds good, I'm surprised that the newer t-beams with Neo-6 don't have newer firmware, The Neo-6 went EOL just recently, I actually thought it had gone EOL several years ago. I guess they made a LOT of 6010 chips. Found another interesting issue, on the Neo-6, there is a ubx message that comes out every 10 sec or so in amongst the NMEA messages that might be causing some of those messages to be rejected by TinyGPS. They can be turned off with s CFG-MSG command, which I have done in my test code. I think in the long run there will need to be a more structured init scheme based on HW and protocol version, If I may be so bold to say that the current scheme is a bit on the haphazard side. I'll help with that.

[GPSFan]

What was sent out to dist's and others on the u-blox mailing list. https://www.mouser.com/PCN/u-blox_u_blox6_Modules_EOL_UBX_23001070.pdf

[GPSFan]

and: https://content.u-blox.com/sites/default/files/NEO-6P-NEO-6V_EOL_%28UBX-20009315%29.pdf

[jp-bennett]

Sounds good, I'm surprised that the newer t-beams with Neo-6 don't have newer firmware, The Neo-6 went EOL just recently, I actually thought it had gone EOL several years ago. I guess they made a LOT of 6010 chips. Found another interesting issue, on the Neo-6, there is a ubx message that comes out every 10 sec or so in amongst the NMEA messages that might be causing some of those messages to be rejected by TinyGPS. They can be turned off with s CFG-MSG command, which I have done in my test code.

The chips that get embedded in this hardware, and sold on Amazon and the like are all various levels of shady. So who knows. Neat find about that extra message. Turning it off should help.

I think in the long run there will need to be a more structured init scheme based on HW and protocol version, If I may be so bold to say that the current scheme is a bit on the haphazard side. I'll help with that.

Agreed. It has gotten more complicated as we've added more features and supported devices, and tried to work around observed quirks.

[GPSFan]

I think, for the time being I'm not going to worry about the Neo-6s with protocol 14 firmware. From what I've seen of the t-beam construction, it would be a major effort to try and re-flash the firmware for the Neo-6, and after all that effort you wouldn't have anything nearly as good as an M8N. I've had the first set of changes running on a Neo-6 all day. Antenna is cheap e-bay GPS/GLONASS puck on a ground plane in the window. It's amplified and works ok with my other receivers. it draws ~16ma all by itself. Really should have the antenna outside but it's winter and COLD... The PMREQ command drops the receiver's power down to about 1ma in sleep mode but with the antenna is about 75ma when on.

[GPSFan]

The bouncing was me unscrewing the antenna connector.

[jp-bennett]

it would be a major effort to try and re-flash the firmware for the Neo-6

Agreed.

I've had the first set of changes running on a Neo-6 all day

If you make it available, I'll put it on my small swarm of devices and see what happens.

[GPSFan]

I'll see if I can get something out to you tomorrow, My local repo has all my changes to support the Chatter 2 since that's what I am using as the esp32 host. My GITfu isn't the greatest. Haven't tested anything but the Neo-6 as yet. In addition there are lots of other changes yet to come, I only changed 2 commands and added 1 in the init stream.

[GPSFan]

Here are the 3 files I changed for the first of the Neo-6 tweaks: GPS1.tar.gz

[GPSFan]

found a couple more issues, here is an updated version: GPS3.tar.gz

[jp-bennett]

@GPSFan Getting a non-ideal result from that one on this T-beam 1.2. Relevant log output:

DEBUG | ??:??:?? 1 [GPS] Probing for GPS at 9600 
INFO  | ??:??:?? 2 [GPS] Found a UBlox Module using baudrate 9600
DEBUG | ??:??:?? 2 [GPS] Module Info : 
DEBUG | ??:??:?? 2 [GPS] Soft version: 7.03 (45969)
DEBUG | ??:??:?? 2 [GPS] Hard version: 00040007
DEBUG | ??:??:?? 2 [GPS] Extensions:0
DEBUG | ??:??:?? 2 [GPS] WANT GPS=0
DEBUG | ??:??:?? 2 [GPS] GPS Lock took 1, average 0
INFO  | ??:??:?? 2 [GPS] Setting GPS power=0
DEBUG | ??:??:?? 2 [GPS] publishing pos@0:2, hasVal=0, Sats=0, GPSlock=0
DEBUG | ??:??:?? 2 [GPS] onGPSChanged() pos@0, time=0, lat=0, lon=0, alt=0
INFO  | ??:??:?? 2 [GPS] updatePosition LOCAL pos@0, time=0, latI=0, lonI=0, alt=0
DEBUG | ??:??:?? 2 [GPS] Setting local position: latitude=0, longitude=0, time=0
DEBUG | ??:??:?? 2 [GPS] Node status update: 0 online, 1 total
INFO  | ??:??:?? 2 [RangeTestModule] Range Test Module - Disabled
INFO  | ??:??:?? 4 [PowerFSM] Initialise the NimBLE bluetooth module
INFO  | ??:??:?? 6 [Screen] Done with boot screen...
DEBUG | ??:??:?? 6 [Screen] showing standard frames
DEBUG | ??:??:?? 6 [Screen] Showing 0 module frames
DEBUG | ??:??:?? 6 [Screen] Total frame count: 103
DEBUG | ??:??:?? 6 [Screen] Added modules.  numframes: 0
DEBUG | ??:??:?? 6 [Screen] Finished building frames. numframes: 2
DEBUG | ??:??:?? 21 [Power] Battery: usbPower=1, isCharging=0, batMv=4137, batPct=100
INFO  | ??:??:?? 31 [NodeInfoModule] Sending our nodeinfo to mesh (wantReplies=1)
INFO  | ??:??:?? 31 [NodeInfoModule] sending owner !7a6d648c/Meshtastic 648c/648c
DEBUG | ??:??:?? 31 [NodeInfoModule] Initial packet id 1983951811, numPacketId 4294967295
DEBUG | ??:??:?? 31 [NodeInfoModule] Update DB node 0x7a6d648c, rx_time=0
DEBUG | ??:??:?? 31 [NodeInfoModule] handleReceived(LOCAL) (id=0x7640b3c5 fr=0x8c to=0xff, WantAck=0, HopLim=3 Ch=0x0 Portnum=4 WANTRESP priority=10)
DEBUG | ??:??:?? 31 [NodeInfoModule] No modules interested in portnum=4, src=LOCAL
DEBUG | ??:??:?? 31 [NodeInfoModule] localSend to channel 0
DEBUG | ??:??:?? 31 [NodeInfoModule] Add packet record (id=0x7640b3c5 fr=0x8c to=0xff, WantAck=0, HopLim=3 Ch=0x0 Portnum=4 WANTRESP priority=10)
DEBUG | ??:??:?? 31 [NodeInfoModule] Expanding short PSK #1
DEBUG | ??:??:?? 31 [NodeInfoModule] Using AES128 key!
DEBUG | ??:??:?? 31 [NodeInfoModule] ESP32 crypt fr=7a6d648c, num=7640b3c5, numBytes=50!
WARN  | ??:??:?? 31 [NodeInfoModule] send - lora tx disable because RegionCode_Unset
DEBUG | ??:??:?? 41 [Power] Battery: usbPower=1, isCharging=0, batMv=4138, batPct=100
INFO  | ??:??:?? 46 [DeviceTelemetryModule] (Sending): air_util_tx=0.000000, channel_utilization=0.000000, battery_level=100, voltage=4.138000
DEBUG | ??:??:?? 46 [DeviceTelemetryModule] updateTelemetry LOCAL
DEBUG | ??:??:?? 46 [DeviceTelemetryModule] Node status update: 0 online, 1 total
INFO  | ??:??:?? 46 [DeviceTelemetryModule] Sending packet to mesh
DEBUG | ??:??:?? 46 [DeviceTelemetryModule] Update DB node 0x7a6d648c, rx_time=0
DEBUG | ??:??:?? 46 [DeviceTelemetryModule] handleReceived(LOCAL) (id=0x7640b3c6 fr=0x8c to=0xff, WantAck=0, HopLim=3 Ch=0x0 Portnum=67 priority=1)
DEBUG | ??:??:?? 46 [DeviceTelemetryModule] No modules interested in portnum=67, src=LOCAL
DEBUG | ??:??:?? 46 [DeviceTelemetryModule] localSend to channel 0
DEBUG | ??:??:?? 46 [DeviceTelemetryModule] Add packet record (id=0x7640b3c6 fr=0x8c to=0xff, WantAck=0, HopLim=3 Ch=0x0 Portnum=67 priority=1)
DEBUG | ??:??:?? 46 [DeviceTelemetryModule] Expanding short PSK #1
DEBUG | ??:??:?? 46 [DeviceTelemetryModule] Using AES128 key!
DEBUG | ??:??:?? 46 [DeviceTelemetryModule] ESP32 crypt fr=7a6d648c, num=7640b3c6, numBytes=18!
WARN  | ??:??:?? 46 [DeviceTelemetryModule] send - lora tx disable because RegionCode_Unset
WARN  | ??:??:?? 46 [DeviceTelemetryModule] No suitable channel found for decoding, hash was 0x78!
DEBUG | ??:??:?? 61 [Power] Battery: usbPower=1, isCharging=0, batMv=4137, batPct=100
DEBUG | ??:??:?? 62 [GPS] GPS is not communicating, trying factory reset on next bootup.
INFO  | ??:??:?? 62 [GPS] Saving /prefs/db.proto

[GPSFan]

Interesting, that's with a Neo-6. I'll have to look at the "problematic" code path. I also noticed that when I run my Neo-6 for several hours it reverts back to factory default messages. I ran it over night and captured 2 commands that reset to defaults, hours and hours apart. This bears investigating. Sorry things didn't go as expected. What version of Meshtastic? Do you normally see satellites where you had the t-beam 1.2? Could you turn on GPS_DEBUG and GPS_EXTRAVERBOSE in hte varient.h and repeat the data dump. Thanks in advance.

[GPSFan]

And of course I was not using a t-beam so all the logic that's in GPS.cpp to fiddle with its problematic GPS isn't triggered in my test setup...

[jp-bennett]

@GPSFan Turns out it was some extra changes that sneaked into your files that caused the problem. Probably the change in getwaketime().

GPS boot log now looks like https://gist.github.com/jp-bennett/a5b273788a57ce8d2f29e5786c4f6b49 I need to put it in a window and see if it will actually get a GPS lock.

[jp-bennett]

And of course I was not using a t-beam so all the logic that's in GPS.cpp to fiddle with its problematic GPS isn't triggered in my test setup...

OK, now that's really interesting. With your changes to powersave and state save, this chip ACKs all the messages. Potentially meaning we no longer have to treat it as problematic.

[code8buster]

You're claiming that meshtastic will send bytes of unrelated structs. This is not true. in re to your cfg-pm2 command:

The byte array is 42 bytes because we calculate and append the checksum at runtime. At no point will we read out the contents of some other struct. The reserved bytes are set to what they are simply because that is what u-center 23.08 returned for me as the valid message. The ublox spec states that if the reserved values match or are 0x00 the message will be accepted. We're only sending this to the Neo-6m and perhaps this is why we haven't seen a problem with it yet. Maybe if we started using this message with the other chips we'd see incompatibilities crop up wrt the reserved field.

Good catch on the CFG-PMS command.

[jp-bennett]

You're claiming that meshtastic will send bytes of unrelated structs.

I don't think that was the point he was trying to make. He was just comparing the powersave message that we send to that module to what we send to other, similar modules.

[GPSFan]

To clarify, the CFG-PM2 command for the Neo-6 is defined as having a payload length of 44 bytes. For the M8N there are 2 versions of the command one with 44 bytes of payload one with 48. The checksum is not included in the payload. The byte array in ubx.h should be 44 bytes long and makeUBXPacket will take the length it is passed, which is 44, and grab the first 44 bytes out of the structure defined in ubx.h. Since that structure is only 42 bytes long, makeUBXPacket will grab the next 2 bytes from what ever follows the _message_CFG_PM2[] structure in whatever memory the compiler put it, Since there is a PROGMEM in the definition, that place will probably be different from where the compiler puts the next definition, which is for _message_GNSS_7[]. Other uses of the makeUBXPacket don't hard code the length. IMHO all other definitions in ubx.h have their structures the correct length for makeUBXPacket to produce the correct command, appending the checksum bytes, and pre-pending the appropriate header, etc. My point was that the structure length in ubx.h was incorrect, and BadThings(tm) might happen.

[jp-bennett]

To clarify, the CFG-PM2 command for the Neo-6 is defined as having a payload length of 44 bytes

Yikes, I missed that the first time reading through your notes, too. We should probably just make all those a sizeof() rather than individual values.

[GPSFan]

Yes, to be consistent, all the calls should use sizeof. In addition there are several commands hard coded in GPS.cpp that don't make use of makeUBXPacket. Lots of other GPS code I've seen have had problems building a correct UBX command, Meshtastic does a great job.

[GPSFan]

WRT Reserved fields: From the u-blox M8N protocol spec:

32.3.2 Reserved Elements Some messages contain reserved fields or bits to allow for future expansion. The contents of these elements should be ignored in output messages and must be set to zero in input messages. Where a message is output and subsequently returned to the receiver as an input message, reserved elements can either be explicitly set to zero or left with whatever value they were output with.

So, my interpretation is that if you read something from a module in a reserved field, you can send it back as part of a new command. But what you get out of u-Center may not agree (or be in error because of a bug) so best set them to 0x00 unless explicitly defined in the spec for that protocol version.

[code8buster]

Agreed, it'd be best to set all of them to zero. Do you have a branch where you've already committed the changes? I'd like to test them out!

[GPSFan]

Not as yet, I sent a couple of files to jp-bennett who tested the changes for only the Neo-6, with some positive results. This is a WIP and I think we can improve the overall GPA/GNSS performance over the course of a few .... weeks ? https://github.com/meshtastic/firmware/files/13968824/GPS3.tar.gz

[jp-bennett]

@code8buster I have a branch at https://github.com/meshtastic/firmware/tree/gps-rework that contains the first round of changes we've looked at. Still a bit WIP, but seems good so far.

[GPSFan]

@jp-bennett I have a first shot at a new ubx.h, it has several additional commands for different version u-blox modules. it is not as yet complete or fully tested. It also will not work with the current GPS.cpp since I have changed several message names. Lots of comments in it regarding how different fields are configured. Still nothing close to the protocol spec. Still a WIP. ubx.h.txt

BTW, I took out the PROGMEM directive as I found this on the Espressif site https://esp32.com/viewtopic.php?t=20595

[GPSFan]

@jp-bennett Updated. ubx1.h.txt

[GPSFan]

@jp-bennett Update ubx2.h.txt

[thebentern]

@GPSFan is this complete now with the latest 8 / 10 series initialization round?

[GPSFan]

@thebentern the great bulk of it is complete, what remains are some potential tweaks for new/current use cases, ie. bugs. Next will be an analysis of the performance in various cases and recommendations for improvement, this will require a lot of input from users and the designers of Meshtastic, as I am new to the project and lack the historical perspective that many others do.

[GPSFan]

@jp-bennett @thebentern With the latest changes to IO2 management and a few other tweaks that others have made, I think we can close this issue. If need be, another can be opened when the need arises. Power management across the variety of GNSS modules, Processor types, board configurations and use case is a daunting task.