u-blox M10 GPS support

[Allerhopp]

u-blox GPS with M10 chipset do not work anymore with oXs. Eventually this is because NAV-SOL messages are not supported.

From u-blox M10_ROM_5.00_ReleaseNotes_UBX-20050981: 5.2.3 Removed UBX messages

UBX-NAV-SOL PUB Use UBX-NAV-PVT instead

Is it possible to implement NAV-PVT instead or additionally?

[mstrens]

I tried to add UBX-NAV-PVT in a new version of the program. Currently the change is only available in a new branch named "hott" (because it is supposed to support Hott protocol too). I did not test the change (I have only a ublox M8).

Please test it and let me know if it is OK. I will then put the version in master branch.

[Allerhopp]

GPS, GSpd, Hdg, GAlt and Tmp1 are working!

IIRC the M10 GPS was at 115200 Bd by default. I've used u-center 2 to set it to 9600 Bd. It would be good, if someone else could test a M10 GPS out of the box to verify the default baudrate.

[mstrens]

Thanks for the feedback. I checked the M10 datasheet and it says that the default baudrate is 9600. So I expect that oXs firmware should work for a M10 out of the box

[Allerhopp]

I've reopened this issue. It is still not sure from some posts in a German forum that 9600 works for out of the box M10 GPS.

[mstrens]

Here an extract of M10 doc on page 15 from https://content.u-blox.com/sites/default/files/MAX-M10S_DataSheet_UBX-20035208.pdf

5.3 Default interface settings Interface Settings UART • 9600 baud, 8 bits, no parity bit, 1 stop bit. • Input messages: NMEA and UBX. • Output messages: NMEA GGA, GLL, GSA, GSV 29 , RMC, VTG and TXT.

[Satcomix]

Hallo Mstrens, The BeiTian Gps with M10 Chipset (BE-220) have a default baudrate of 38400 and must be set to 9600baud to work with oXS_on_RP2040 https://store.beitian.com/products/beitian-gps-module-with-antenna-ubx-m10050-gnss-chip-ultra-low-power-gnss-receiver-for-track-be-220 Greetings, Torsten

[mstrens]

I put a version 1.4.14 in test branch that tries to find the gps baudrate automatically (between 9600, 19200, 38400 and 115200). This could probably solve this issue.

[doloebig]

i tested with BE-220 (new and 38400Baud) is not detected (man. set to 9600 is working) Blinks still with 1hz Ver. 1.5.0

KRegard Doro

[mstrens]

oXs is supposed to analyse the GPS frame during 600 msec (currently). It could be , if the GPS is configured on 1Hz, that oXs does not get any frame during this interval. I would perhaps have to increase the interval.

Can you make a test setting the GPS on 38400 bauds and 10Hz. If oXs recognizes the baudrate, then the code is ok and just have to increase the interval.

[doloebig]

@mstrens for make it clear, if i set BE-220 manule to 9600 ->work, during startup will set to 2Hz If i leave default setting (38400) oXs will not register.

[mstrens]

can you try version 1.5.7 with gps being on default setting (38400) I increased the delay to have more chance to detect the baudrate. Please activate serial monitor at power up in order to see the first messages that will be generated.

You should get gps baudrate not detected; will be set on 9600 or gps baudrate detected = xxxxx) depending on the fact that baudrate is detected or not.

[doloebig]

works for me. I guess was timing issuew

Start detecting baudrate gps baudrate detected = 38400 Attention: setup on core 1 did not ended within timeout Setup1 takes 5000144 usec

Version = 1.5.7 Function Pin Change entering XXX=yyy (yyy=255 to disable) Primary channels input = 255 (PRI = 5, 9, 21, 25) Secondary channels input = 255 (SEC = 1, 13, 17, 29) Telemetry . . . . . . . . = 7 (TLM = 0, 1, 2, ..., 29) GPS Rx . . . . . . . . . = 3 (GPS_RX = 0, 1, 2, ..., 29) GPS Tx . . . . . . . . . = 2 (GPS_TX = 0, 1, 2, ..., 29) Sbus OUT . . . . . . . . = 255 (SBUS_OUT= 0, 1, 2, ..., 29) RPM . . . . . . . . . . = 255 (RPM = 0, 1, 2, ..., 29) SDA (I2C sensors) . . . . = 255 (SDA = 2, 6, 10, 14, 18, 22, 26) SCL (I2C sensors) . . . . = 255 (SCL = 3, 7, 11, 15, 19, 23, 27) PWM Channels 1, 2, 3 ,4 = 255 255 255 255 (C1 / C16= 0, 1, 2, ..., 15) PWM Channels 5, 6, 7 ,8 = 255 255 255 255 PWM Channels 9,10,11,12 = 255 255 255 255 PWM Channels 13,14,15,16 = 255 255 255 255 Voltage 1, 2, 3, 4 = 26 27 255 255 (V1 / V4 = 26, 27, 28, 29)

Protocol is Sport (Frsky) CRSF baudrate = 420000 Voltage parameters: Scales : 1.000000 , 25.862000 , 1.000000 , 1.000000 Offsets: 0.000000 , 13448.299805 , 0.000000 , 0.000000 No temperature sensors are connected on V3 and V4 RPM multiplier = 1.000000 Baro sensor is not detected Acc/Gyro is not detected First analog to digital sensor is not detected Second analog to digital sensor is not detected Foreseen GPS type is Ublox :GPS is detected but has not (yet) a fix Failsafe type is HOLD

THX Doro

[mstrens]

Thanks for the feedback. The current solution is still not optimal. Testing the baudrate blocks the startup of oXs for some seconds. This is not a real issue when oXs is used only for telemetry but when it is used also for generating Sbus and/or PWM signals it would be safier if oXs can be operational much faster. I will probably try to find a solution to make the autobaudrate detection a non blocking process.

[mstrens]

Configuration of GPS U-blox M10 uses different messages compared to M6/M8 and has a different default baudrate. I made changes in version 1.9.0 in order to configure both types. I tested it with a M8 but I do not have a M10 to test it.

[Satcomix]

Hello Mstrens, I just installed the new version 1.9.0. GPS M10 (Beitian BE-220/250 M10050) is not recognized. With version 1.8.10 everything worked. The new M10 GPS are also the reason why I haven't reported the last two weeks, because I've tried a lot of tests with different GPS (8030 and 10050) configs. The config of an M10 is five times larger than that of the M8. Best regards, Torsten

[mstrens]

Perhaps that I made an error in the set of char I sent for configuring a M10. Question: in u-center (or with another tool) are you able to send a set of char to the GPS and see if it replies with an ack or an nack. If it reply with a nack I made a mistake in the set of char I am sending. The set of char I send is: 0xB5,0x62,0x06,0x8A, // config 34, 0, //length 4 + payload here after 0x00,0x01,0x00,0x00, // in ram 0X01,0X00,0X21,0X30, 0X64 , 0X00, // key + Val in little endian for measurement rate (100 = 10Hz) 0X2A,0X00,0X91,0X02, 0X01, // key + Val in little endian for POSLLH 0X43,0X00,0X91,0X92, 0X01, // key + Val in little endian for VELNED 0X07,0X00,0X91,0X92, 0X01, // key + Val in little endian for PVT 0X02,0X00,0X74,0X10, 0X00, // L - - Flag to indicate if NMEA should be an output protocol on UART1 0X3F,0X3E// checksum

[Satcomix]

Hello Mstrens, I have attached some configurations of the BeiTian M10 BE-220/250 default config 38400 baud. For the questions about ACK or NACK from you, I have to try something else. Beitian_BE_220_GPS_SBAS_Galileo_BeiDou_QZSS_config.txt

Beitian_BE_220_GPS_SBAS_Galileo_QZSS_GLONASS_config.txt

Beitian_BE_220_ONLY_UBX_in_out_NMEA_Child_messages_disabled_config.txt br, Torsten

[Satcomix]

Hello Mstrens, I copied the config values ​​from the U-Center Config-Terminal for the specific settings. I hope it helps.

M10_Config_Values.txt

br, Torsten

[mstrens]

Can you try version 1.9.3. I found some mistake in the code being sent. Here the sequence I sent now (to use if you find a way to send a sequence and listen to ack/nack: 0xB5,0x62,0x06,0x8A, // config 34, 0, //length 4 + payload here after 0x00,0x01,0x00,0x00, // in ram 0X01,0X00,0X21,0X30, 0X64 , 0X00, // key + Val in little endian for measurement rate (100 = 10Hz) 0X2A,0X00,0X91,0X20, 0X01, // key + Val in little endian for POSLLH 0X43,0X00,0X91,0X20, 0X01, // key + Val in little endian for VELNED 0X07,0X00,0X91,0X20, 0X01, // key + Val in little endian for PVT 0X02,0X00,0X74,0X10, 0X00, // L - - Flag to indicate if NMEA should be an output protocol on UART1 0X79,0XC6// checksum

[Satcomix]

Here are some more informations about GNSS config. UBX-CFG-GNSS GPS 8/16 L1C/A, SBAS 3/3 L1C/A, Galileo 8/12 E1, QZSS 3/4 L1C/A L1S, GLONASS 8/12 L1OF, Number of channels: 49 0000 B5 62 06 3E 34 00 00 00 31 06 00 08 10 00 01 00 01 01 µb>41 0012 01 03 03 00 01 00 01 01 02 08 0C 00 01 00 01 01 03 06  0024 0E 00 00 00 00 01 05 03 04 00 01 00 05 01 06 08 0C 00  0036 01 00 01 01 35 58 5X

I will make the next test with 1.9.3. br, Torsten

[Satcomix]

Hello Mstrens, Sorry,Version 1.9.3 no GPS in terminal, FV or handheld br, Torsten

[mstrens]

FIY, I saw in the M10 datasheet that old configuration messages (UBX_CFG...) are deprecated "This message is deprecated in protocol versions greater than 23.01. Use UBX-CFG-VALSET, UBX-CFGVALGET, UBX-CFG-VALDEL instead."

That is why I try to use UBC_CFG_VALSET and I sent the command at 38400 baud (which is the default rate for M10). There must be a mistake somewhere but as I have no M10 gps I can't test it.

Perhaps can you make a capture with a logic analyser of the TX and the Rx GPS signals when GPS and OXS are powered on.

[Satcomix]

Hello Mstrens, the only way to see ack or nack would be with a logic analyzer, right? I could also connect the RX and TX lines from the oXs_RP2040 to the GPS in parallel to the U-Center, I just don't know if I can see these confirmation values ​​(ack/nack). I try the way with RX/TX parallel to the U-Center first and than i will make a capture with the Kingst. br, Torsten

[Satcomix]

Kingst capture: one TX, one RX capture 2023-0 [2023-03-25_21-25-01.zip](https://github.com/mstrens/oXs_on_RP2040/files/11070006/2023-03-25_21-25-01.zip) 3-25_21-24-19.zip

[mstrens]

I presume that the timelaps of your capture is to short. I do not see the messages sent by oXs. Best is to capture on 10 sec about.

[Satcomix]

The problem with the Kingst Capture is that the oXs Tx line switches off and no more data is visible. The RX line receives the data from the GPS all the time. But we already had this problem with the GPS measurements in the last few weeks.

[mstrens]

Sorry, I did not saw the second capture. In the second one the capture seems to start to late. In fact both signals should be in the same capture (if possible) and for 10 sec from power on. Is this possible

[Satcomix]

Next try: i hope i stopped at the right moment. 2023-03-25_21-40-24.zip

[mstrens]

If Kingst can capture 2 channels simultenously I could

• first find at the first messages sent by oXs
• see if just after the first message, the GPS reply (and so see if it is an Ack or a NACK reply

[Satcomix]

ok, i will make two new captures one RX, one TX.

[mstrens]

I saw both signals on the last capture. It should be OK. Still the capture start to late. Can you e.g. trigger the capture base on the signal sent by the receiver. This one exist before the signal sent by oXs. Or (easier) start the capture manually just before powering on OXS/GPS

[Satcomix]

I always start the capture before i power on oXs_RP2040 2023-03-25_21-52-48.zip 2023-03-25_21-50-18.zip

[mstrens]

I do not understand what happens The first capture is "empty" (no signal) The second contains messages sent by oXs but not the first part of messages.

I will make a debug version that will send to the PC a copy of what is sent to the GPS.

[Satcomix]

It was a long day and i will make the next Tests tomorow. br, Torsten

[mstrens]

OK. Thanks for testing. FYI, I made a capture myself and I see that oXs sent the expected frame. Still as I am using a M8 with 9600 default baud, I do not see the ACK/ACK when I sent the first sentence (for M10) at 38400 bauds.

[Satcomix]

Hello Mstrens, The M10 GPS is not initialized with version 1.9.7, and drives with default 38400baud and 1Hz, without connection to the oXs (Foreseen GPS type is Ublox :GPS is not (yet) detected) Wouldn't it be possible to read the configuration commands in HEX with a connected M10 GPS in the U-Center at Messages View (not Configuration View) and enter them into oXs Config? Here are some informations about M10. https://github.com/sparkfun/SparkFun_u-blox_GNSS_v3 Greeting, Torsten

[mstrens]

With an M8 (or previous) I was able to send configuration commands to the GPS with U-Center and to see the hex message being sent by U-center. That is the way I proceeded previously. This works only if a GPS is connected to U-Center. As I do not have a M10, I can't try it with a M10. I will look at the library you found. Perhaps I will see the issue.

Yesterday I connected my logic analyser to oXs and I started a capture for 10 sec. I clearly saw that oXs sent the expected messages (first a short messages at 38400 and then several messages at 9600). This seems OK but I do not know if the content of the first message (for M10) was valid or not.

[Satcomix]

Hello Mstrens, I have connected several M10s here.(BE-180/220/250/280) If you want, I could send you one to your home for free, it only takes 3 days from GE to BE. Just a suggestion. I could also read out the hex messages that are to be sent in the Message Viewer, as I did yesterday, but then I would only have to know which ones exactly. Greeting, Torsten

[mstrens]

If you can read out the hex message, then it should be possible to move on. Currently I assume that the GPS is in default config and I send 5 commands All commands are supposed to be loaded in the RAM layer. The 5 commands are (name , key, value , comment): CFG_RATE_MEAS 0x30210001 100 // set measurement rate to 10Hz CFG_MSGOUT_UBX_NAV_POSLLH_UART1 0x2091002a 1 // ask to output a UBX-NAV-POSLLH message on port UART1 (at 10hz) CFG_MSGOUT_UBX_NAV_VELNED_UART1 0x20910043 1 // ask to output a UBX-NAV-VELNED message on port UART1 (at 10 hz) CFG_MSGOUT_UBX_NAV_PVT_UART1 0x20910007 1 // ask to output a UBX-NAV-PVT message on port UART1 (at 10 Hz) CFG_UART1OUTPROT_NMEA 0x10740002 0 // ask to stop sending NMEA msgon UART1

    0x00,0x01,0x00,0x00,  // in ram
    0X01,0X00,0X21,0X30,   0X64 , 0X00, // key + Val in little endian for measurement rate (100 = 10Hz)
    0X2A,0X00,0X91,0X20,   0X01, // key + Val in little endian for POSLLH
    0X43,0X00,0X91,0X20,   0X01, // key + Val in little endian for VELNED
    0X07,0X00,0X91,0X20,   0X01, // key + Val in little endian for PVT
    0X02,0X00,0X74,0X10,   0X00, // L - - Flag to indicate if NMEA should be an output protocol on UART1

[Satcomix]

Hello Mstrens, I read the values ​​in the U-Center at VALGET. I hope it fits. Or should I read out the values ​​at VALSET? No problem, I'm on it. br, Torsten M10_VALGET_RAM.txt

[mstrens]

The idea is to get the hex values for valset commands to compare them with what I sent.

For a full test, you could also:

• reset the GPS to default config
• send the command to avoid all output NEMA msg on UART1 (so U-center should then be quiet)
• send the command to activate one of the NAV msg (e.g. CFG_MSGOUT_UBX_NAV_POSLLH_UART1 0x2091002a 1 ) You should then get only this type of message in U-center. If this works, you could send the other commands to change the rate and get other NAV msg.

[Satcomix]

I reset the M10 to DEFAULT values. After that I ran NMEA disable Child messages. (No NMEA output to U-Center) Where do the values ​​have to be stored with VALSET? Set values ​​in layers: FLASH BBR RAM default is RAM When I enter the 10Hz(100=64hex) EDIT: It works!!! Key Name Key ID Type Value CFG-RATE-MEAS 0x30210001 U2 100 0x64 s scaled 0.001 set to: No transaction 0000 B5 62 06 8A 0A 00 00 01 00 00 01 00 21 30 64 00 51 B9 µb!0dQ¹ set to : Start transaction 0000 B5 62 06 8A 09 00 01 01 01 00 2A 00 91 20 64 DB 6A µb* dÛj Than SEND

[Satcomix]

I found a problem. If I disable all NMEA child messages and enable UBX messages, U-Blox only shows UBX, right! But when I execute the first command (Config-Rate_Meas 10Hz) NMEA starts again! How can I switch off the NMEA messages permanently stored? EDIT: I found it in cFG-PRT-OUTPROT

[mstrens]

Perhaps you have to execute Config-Rate_Meas 10Hz first followed by the others commands.

Looking at your HEX trace, I found a difference in the way the payload was calculated. I made a new version 1.9.8. (on github) Perhaps this will solve the issue.

[Satcomix]

You got it!!! It works with Ver.1.9.8 with 38400 and 10Hz Foreseen GPS type is Ublox :GPS is detected and has a fix In Handheld everything seems ok. Thank you for your work and time. br, Torsten

[mstrens]

Thanks too. It is your trace that helped to find the bug.

[Satcomix]

Hello Mstrens, I've looked at the M10's UBX output and it seems to me that the M10's default satellites are transmitting the messages. I receive BeiDou instead of GLONASS. UBX-CFG-GNSS GPS 8/16 L1C/A, SBAS 3/3 L1C/A, Galileo 8/12 E1, QZSS 3/4 L1C/A L1S, GLONASS 8/12 L1OF, Number of channels: 49

With BeiDou and without GLONASS (include GPS,SBAS,Galileo,QZSS) 0000 B5 62 06 3E 34 00 00 00 31 06 00 08 10 00 01 00 01 01 01 µb>41 0013 03 03 00 01 00 01 01 02 08 0C 00 01 00 01 01 03 06 0E 00  0026 01 00 01 01 05 03 04 00 01 00 05 01 06 08 0C 00 00 00 00  0039 01 35 78 5x

With GLONASS and without Beidou (include GPS,SBAS,Galileo,QZSS) 0000 B5 62 06 3E 34 00 00 00 31 06 00 08 10 00 01 00 01 01 01 µb>41 0013 03 03 00 01 00 01 01 02 08 0C 00 01 00 01 01 03 06 0E 00  0026 00 00 00 01 05 03 04 00 01 00 05 01 06 08 0C 00 01 00 01  0039 01 35 58 5X

br, Torsten

[mstrens]

You can find the default config at the end of this doc https://content.u-blox.com/sites/default/files/u-blox%20M10-SPG-5.00_InterfaceDescription_UBX-20053845.pdf

[Satcomix]

OK, this is apparently the difference to the original U-Blox. With the Beitian (M10) BE chipset it looks like this: DEFAULT Values: Configuration item Key ID Type Scale Unit Default value CFG-SIGNAL-GPS_ENA 0x1031001f L - - 1 (true) CFG-SIGNAL-GPS_L1CA_ENA 0x10310001 L - - 1 (true) CFG-SIGNAL-SBAS_ENA 0x10310020 L - - 1 (true) CFG-SIGNAL-SBAS_L1CA_ENA 0x10310005 L - - 1 (true) CFG-SIGNAL-GAL_ENA 0x10310021 L - - 1 (true) CFG-SIGNAL-GAL_E1_ENA 0x10310007 L - - 1 (true) CFG-SIGNAL-BDS_ENA 0x10310022 L - - 1 (true) CFG-SIGNAL-BDS_B1_ENA 0x1031000d L - - 1 (true) CFG-SIGNAL-QZSS_ENA 0x10310024 L - - 1 (true) CFG-SIGNAL-QZSS_L1CA_ENA 0x10310012 L - - 1 (true) CFG-SIGNAL-GLO_ENA 0x10310025 L - - 0 (false) CFG-SIGNAL-GLO_L1_ENA 0x10310018 L - - 1 (true)

oXs-config values: Configuration item Key ID Type Scale Unit Default value CFG-SIGNAL-GPS_ENA 0x1031001f L - - 1 (true) CFG-SIGNAL-GPS_L1CA_ENA 0x10310001 L - - 1 (true) CFG-SIGNAL-SBAS_ENA 0x10310020 L - - 1 (true) CFG-SIGNAL-SBAS_L1CA_ENA 0x10310005 L - - 1 (true) CFG-SIGNAL-GAL_ENA 0x10310021 L - - 1 (true) CFG-SIGNAL-GAL_E1_ENA 0x10310007 L - - 1 (true) CFG-SIGNAL-BDS_ENA 0x10310022 L - - 0 (false) CFG-SIGNAL-BDS_B1_ENA 0x1031000d L - - 1 (true) CFG-SIGNAL-QZSS_ENA 0x10310024 L - - 1 (true) CFG-SIGNAL-QZSS_L1CA_ENA 0x10310012 L - - 1 (true) CFG-SIGNAL-GLO_ENA 0x10310025 L - - 1 (true) CFG-SIGNAL-GLO_L1_ENA 0x10310018 L - - 1 (true)

u-blox-M10-ROM-5.10_ReleaseNotes_UBX-22001426.pdf

br, Torsten

[Satcomix]

Hello Mstrens, I put Version 1.9.9 on my board with a M8030 GPS , but it doesn't initialize properly and blinks in 1Hz. Should I open a new issue for M8 GPS or shall we continue here? 3D fix with 11 satellites available, but only GPS time, 3D fix, PDOP is transmitted. Everything else is missing!!! Cmd to execute: FV

GPS Num sat. = 111 GPS Date J M A = 27 3 23 GPS Time H M S = 10 40 28 GPS Pdop = 179 Volt 1 = 1562 mVolt Current (Volt 2) = 1657 mA Volt 3 = 1600 mVolt Volt 4 = 239 mVolt Capacity (using current) = 406 mAh Vspeed = 0 cm/s Baro Rel altitude = 95 cm Pitch = -4 degree Roll = 0 degree RPM = 998 Hertz Ads 1 1 = 119 mVolt Ads 1 2 = 119 mVolt Ads 1 3 = 119 mVolt Ads 1 4 = 119 mVolt Ads 2 1 = 119 mVolt Ads 2 2 = 119 mVolt Ads 2 3 = 119 mVolt Ads 2 4 = 119 mVolt Airspeed = 69 cm/s Compensated Vspeed = -6 cm/s

Greetings, Torsten