search

mstrens / oXs_on_RP2040

version of openXsensor to be used on raspberry pi pico RP2040 (more protocols, more functionalities)
85 stars 22 forks source link

MPU6050 behavior with GPS M10 Chipset on Ver.1.7.x #63

Closed Satcomix closed 1 year ago

Satcomix commented 1 year ago

Hello Mstrens, A few days ago I discovered something strange. The synchronization with the protocols S.PORT, FBUS, HOTT with a Beitian GPS system depends on the MPU6050. Figuring out this behavior took me some time and a few boards and it is only on GPS with M10(38400baud). M8030 Chipsets (9600Baud) works normaly, with or without MP6050. Normally, after a reset or power down, the GPS is re-initialized and set to specific transmission values. If I connect a new GPS to a fresh oXs board, it flashes with the blue LED at 1HZ and the red LED flashes at 1Hz with a 3D FIX. Do I now configure this oXs and I now do a reboot, the blue LED lights up with 10Hz and the red LED with 1Hz with 3D FIX. That's how it should be! If I only connected an MS5611 to I2C on the board, the blue LED lights up continuously (high frequency) and the red LED with 1Hz. This behavior also exists when I have nothing connected to the I2C bus, or only MS5611, or ADC1115. This behavior only changes when I run a GY86 (including MPU6050) or a GY63 with MPU6050. As soon as an MP6050 is connected, the GPS will initialize properly. I did some tests with different protocols and different GPS systems with different Gy86/GY63 and MP6050 on different boards. Always the same behavior. Greeting, Torsten

mstrens commented 1 year ago

I think that the blue led lighting at high frequency would be the "normal" case. I think that the blue led says if the GPS is sending data on his TX pin. At power on, GPS is on 1Hz and sent at 1Hz. When GPS is reconfigured by oXs, it is set to a refresh rate of 10hz (with default value in config.h file). So the led blink must faster.

The question is: why does it blink slowly when MS6050 is connected? Normally the GPS does not know if oXs is listening or not on what the GPS sent on his Tx pin. This is not clear at this stage for me. Perhaps a logical analyser put on TX and Rx pins would help to see what happens.

Satcomix commented 1 year ago

Hello Mstrens, I don't think the blue LED flashes slower after an initialization (normally 10Hz), it seems to me it looks more like around 50Hz. A slight flickering can be seen, so I assume that the LED is not permanently lit. I will make some tests with my Kingst. br, Torsten

mstrens commented 1 year ago

I made a test changing the value in config.h and it changes the frequency of blue led blinking after GPS is configured.

Satcomix commented 1 year ago

Here are the results, with MP6050(10Hz blue LED), and without MP6050 (0Hz or 50Hz??? blue LED). I can not measure the initialyse in the beginning. I don`t know why? br, Torsten 2023-03-13_13-17-42_without_MP6050.zip 2023-03-13_13-16-22_with_MP6050.zip

Satcomix commented 1 year ago

Hello Mstrens, Port 1 in the Kingst is GPS_TX and Port 2 is GPS_RX. At the beginning after a power down, I can see data on port 2 for a very short time, but I can't find it in the result. Greeting, Torsten

Satcomix commented 1 year ago

Hello Mstrens, I did some more experiments with the Kingst Logic Analyzer. GPS_RX Port is GND all the time until initialization, briefly sends the oXs Init, and is then GND again. GPS_TX sends data at the beginning with default and after initialization with oXs Init data. The short initialization handshake is not stored in the logic analyzer, for whatever reason. What I don't understand at all: What does the GPS UART have to do with the I2C??? If a GY86 is connected to the I2C the M10 GPS will sync at 10Hz RATE, if a GY63 is connected the blue TX LED will be solid. (maybe it's 50-60Hz too, hard to see) In my opinion, the GPS with M10 chipset are better than the somewhat older ones with M8030, although you don't know whether Galileo is being received or not (GPS firmware dependent) br, Torsten

mstrens commented 1 year ago

It is only during initialization that oXs sent data to GPS RX (it is just to upload the config) When there are no mp6050, I see in the capture that the GPS is sending more frames than expected. On top of the expected 3 types of frames in Ublox format, the GPS continue to generate NEMA messages (like the $GNRC). I do not yet know why. I do not think it would be different with a M10 chipset. I presume it is related to the initialisation oXs sent. It is quite strange that I do not have the same issue on my system: even without MP6050 I do not get unexpected NEMA messages. I am testing with a version not yet on github where I have changed one line in gps.h There was uint8_t initGpsIdx = 0 ; // index of the bytes to be sent to configure the GPS

I changed to uint16_t initGpsIdx = 0 ; // index of the bytes to be sent to configure the GPS

But I do not think it matter.

mstrens commented 1 year ago

When you do not have a MP6050, your capture shows that the GPS is sending 3 types of messages: GNRMC, GNVTG and GNGGA. GN means it is a mix of GPS and Glasnoss. At the end of the initialization process oXs send one command that has 2 actions: set the baudrate and says which types of messages (NEMA/UBLOX...) may/may not be sent. This command is accepted by your GPS (because it switches from 9600 baud to 38400 (because the capture is at 38400). It could be that depending on the model/firmware version of GPS, the bits to set ON/OFF in this command to disable the NEMA messages are different. This could be an explanation for what you saw but only if the test with/without MP6050 where done with 2 different GPS.

Did you make the tests with/without switching the same GPS device from one config to the other one? As test, still using the same board and GPS, you can also just activate/deactivate the SDA/SCL pins using the oXs commands. Best is still to make a capture with the logic analyser to be able to control the types of messages provided by the GPS (this is more reliable than just looking at the led)

Satcomix commented 1 year ago

Hello Mstrens, Sorry for the late message, I was on the night shift. The same M10 GPS BE-220 was always used for the measurements (captures), and the same board was always used for the two measurements. Once with GPS and MS5611 and MP6050 connected, and once without MP6050 but with MS5611. The strange thing is that GLONASS satellites are not available in the default config of the GPS and are not displayed under the U-Center either. Only GPS(US), Galileo(EU),Beidou(CN), and the Japanese. The default setting for the Beitian BE-220/250 is 38400 baud, which has not been changed. Best regards, Torsten

mstrens commented 1 year ago

Are you sure your BE-220 is using a M10. In some doc I saw that it uses a M8 I just made a test an mine is using 9600 baud per default.

The issue is perhaps that your GPS does not accept the initialization oXs sent. As it is on 38500 bauds, it generates perhaps some messages that oXs can decode (even if it sent more types of messages than expected)

Satcomix commented 1 year ago

Hello Mstrens, I got a little closer to the solution. My new BeiTian GPS systems BE-180, BE-220, BE-250, BE-280 all have the M10 (M10050) chipset. You can easily see it in the U-Center. As I had already assumed, the permanent light (with the MP6050 disconnected) corresponds to a frequency of 12.5-15Hz / measurement period 80mSec-65mSec at a data rate of 115200 baud. If I reduce this rate to 38400, there are problems with the resolution. Summary of the BE-220 or the BE series is set to approx. 60-80ms/12-18Hz with one command. I believe 18Hz is maximum sampling. I can't judge why this doesn't happen with the I2C MP6050 connected. I will continue to operate it with the default 38400 baud and GY86 so that there are no synchronization problems. You have forgotten to update GitHub Test to 1.7.4 as you wrote in RCG Greeting, Torsten

Satcomix commented 1 year ago

The new 1.7.5 is now on my Boards :-)) And the BE-220 only synchronizes with 1Hz??? Ver.1.7.5_Terminal.txt The GPS is connected all the time, but it is not shown in the startup.

mstrens commented 1 year ago

In version 1.7.5 I sent all GPS configuration at only 115200. So, it should be discarded (it was for a test). in 1.7.6 I sent again the config at different baudrates (e.g. 38400, 9600)hoping that at least one will match. Based on your previous test, we can expect that the GPS accept part of the config commands being sent. Still it does not accept the last one (that disable the NEMA messages) because this command seems changed for M10.

Satcomix commented 1 year ago

Hello Mstrens, Version 1.7.6 works normally again. The M10 BE-220 synchronizes with the connected GY-86(MS5611+MP6050) again with 10Hz sampling. With the MS5611 connected, it syncs to 15Hz? sampling. It is definitely related to some software change by BeiTian CN. I can set everything as desired from the U-Center, including the little beetle with all the debug messages, to turn on the UBX and NMEA messages Thank you for your work. Greeting, Torsten

mstrens commented 1 year ago

it could be that when there is a MP6050, the GPS initialization is delayed and so the GPS is up and running when oXs starts sending the initialization. I could increase the delay before oXs starts the GPS initialization to be sure that GPS is up and running when GPS initialization begin. In gps.cpp, you have case GPS_WAIT_END_OF_RESET: if (millisRp() > 1000) { //after x msec

you could try to replace 1000 by 5000. I am not sure it will help because there was already a delay of 1 sec.

Perhaps you can see in the u-center what are the messages sent by Ublox in order to

If you provide me the full message (in hexa) I can perhaps add it to the actual list.

Satcomix commented 1 year ago

Hello Mstrens, I modified the GPS.cpp for M10 GPS systems. I read the information for this from the BE-220 with U-Center. How do I calculate the two checksums? The Beitian M10 system can only receive 49 instead of 72 satellites, for M8030 chipset it is only 32 satellites.

M10_GPS_CPP.txt

Next I will change the settings from your last post and try to read out the messages from the U-Center br, Torsten

mstrens commented 1 year ago

I think that when you ask ucenter to change some parameters, it is possible to view the messages exchanged by ucenter and the GPS. The messages contains the checksums so you do not have to calculate them. That is the way I proceeded to find the current commands being part of oXs.

Satcomix commented 1 year ago

Hello Mstrens, But I have adjusted the configuration in GPS.cpp: x = hook GPS x x 8 16 x L1C/A SBAS x x 3 3 x L1C/A Galileo x x 8 12 x E1 BeiDou x x 6 14 x B1 INES 0 0 QZSS x x 3 4 x L1C/A x L1S Glonass x 8 12 not active 49 Satellites or Autoset Here is the complete config of the M10 BE-220 with all debug messages activ BeiTianM10050_220_config.txt

mstrens commented 1 year ago

Your txt file gives the config of the GPS but not the commands to be send to change some parameters. I would like to see the command used by a UBX_CFG_VALSET to disable all NEMA message going out via UART. I presume you can activate an option in ucenter to view in hexadecimal the messages exchanged between ucenter and the GPS when you make a change in ucenter and save it to the GPS. At least with my M8 it was so. I think you have first to activate that view (in meny view) Then you enter a menu to change some config parameter, you fill the boxes with the values you want (e.g. only UBOX as output on UART) and you press a button save. Then Ublox send the command and the GPS sent a ACK back. Those 2 are displayed in the view you activated before. At least it is how I expect it work (it was so with my M8) The command sent by ucenter should begin with 0XB5 0X62 0X06 0X8A ... and should be much smaller than those in your previous .txt file. I presume they should contains the CRC bytes.

Satcomix commented 1 year ago

it could be that when there is a MP6050, the GPS initialization is delayed and so the GPS is up and running when oXs starts sending the initialization. I could increase the delay before oXs starts the GPS initialization to be sure that GPS is up and running when GPS initialization begin. In gps.cpp, you have case GPS_WAIT_END_OF_RESET: if (millisRp() > 1000) { //after x msec

you could try to replace 1000 by 5000. I am not sure it will help because there was already a delay of 1 sec.

Perhaps you can see in the u-center what are the messages sent by Ublox in order to

* set the baudrate to 38400

* disable the NEMA messages for the UART out
  Currently I was using a command CFG_PRT but it could be that this command does not exist anymore for M10
  The CFG_PRT I used was
  0xB5,0x62,0x06,0x00,0x14,0x00,0x01,0x00,0x00,0x00,0xD0,0x08,0x00,0x00,0x00,0x96, 0x00,0x00,0x07,0x00,0x01,0x00,0x00,0x00,0x00,0x00,0x91,0x84

If you provide me the full message (in hexa) I can perhaps add it to the actual list.

I made the change from 1000 to 5000 but nothing changed in Data update/Hz with MP6050 10Hz, without 15Hz The baudrate is default set to 38400baud, so i dont change it. I am searching for the hex files in u-center to disable the nema, only ubx on target1 uart1, protocol in / out ubx, baudrate 38400

mstrens commented 1 year ago

I further looked in ucenter and I think you have to look in the view menu for "configuration view". Then you select (left) VALDEL (to delete something) and in the right panel you select group = cfg_uart1_outprot and in keyname the same but with NEMA at the end. It show you the key to use. There is an icon "send" below. I presume that if you press on it the "binary view" ( to be activated before) will show yo the command

Satcomix commented 1 year ago

Hello Mstrens, Is it shown as $GNVTG ???

16:50:58 0000 24 47 4E 56 54 47 2C 2C 54 2C 2C 4D 2C 30 2E 30 $GNVTG,,T,,M,0.0 0010 32 33 2C 4E 2C 30 2E 30 34 32 2C 4B 2C 41 2A 33 23,N,0.042,K,A*3 0020 41 0D 0A A...

There are so many messages during and after I hit send

or is it this? when i hit send a few times? 16:57:28 0000 B5 62 06 8C 04 00 00 00 00 00 96 1C µb...........

16:57:28 0000 B5 62 05 00 02 00 06 8C 99 BE µb.......¾.

16:57:28 0000 B5 62 06 8C 04 00 00 00 00 00 96 1C µb...........

16:57:28 0000 B5 62 05 00 02 00 06 8C 99 BE µb.......¾.

16:57:28 0000 B5 62 06 8C 04 00 00 00 00 00 96 1C µb...........

16:57:28 0000 B5 62 05 00 02 00 06 8C 99 BE µb.......¾.

16:57:28 0000 B5 62 06 8C 04 00 00 00 00 00 96 1C µb...........

Satcomix commented 1 year ago

I made a mistake, this is outprot NMEA 17:02:27 0000 B5 62 06 8C 04 00 00 00 00 00 96 1C µb...........

17:02:27 0000 B5 62 05 00 02 00 06 8C 99 BE µb.......¾.

mstrens commented 1 year ago

Perhaps that they reload the whole config when you change just one item. Anyway, I found the way to calculate the checksum and I presume I can build a command to avoid NEMA message. I will provide in a few min a version to test it.

mstrens commented 1 year ago

When a line begin with B5 62, it is a UBX msg. When a line begin with 24 ($), it is a NEMA

mstrens commented 1 year ago

Version 1.7.9 is uploaded. If it works as expected, the GPS should not send NEMA messages after the initialization. Could be checked with the logic analyser.

Satcomix commented 1 year ago

Test result with GPS M10 BE220 and GY-86 connected. 2023-03-14_18-20-45.zip Ver.1.7.9_Terminal.txt After this, i disconnect GY86 and connect only GY63-MS5611. IT WORKS with Version 1.7.9 the M10 GPS initializes at 10 Hz with only a MS5611 connected. Thank you very much for this work and your time. br, Torsten

Satcomix commented 1 year ago

Hello Mstrens, I modified the GPS.cpp for M10 GPS systems. I read the information for this from the BE-220 with U-Center. How do I calculate the two checksums? The Beitian M10 system can only receive 49 instead of 72 satellites, for M8030 chipset it is only 32 satellites.

M10_GPS_CPP.txt

Next I will change the settings from your last post and try to read out the messages from the U-Center br, Torsten

Last Question, when i want to modify the settings for Galileo, Beidou,QZSS and SBAS without Glonass, how can i calculate the checksum for this changes? All changes i made are in the .txt

mstrens commented 1 year ago

I am not sure it is totally solved. The command I added follow the M10 datasheet to disable the NEMA message and this seems OK.

Still current code sent also other commands in order

So I do not understand what happens. Perhaps that some of them are still supported (even if not in the doc) but I am unsure.

mstrens commented 1 year ago

About the checksum, I added some lines of code in oXs to calculate the checksum for buffer. It is in gps.cpp: the function is here and you can fill manually the buffer with what you want. void uboxChecksum(){ uint8_t buffer[]= { 0xB5,0x62,0x06,0x8A, 13, 0, //length 4 + payload here after 0x00,0x01,0x00,0x00, // in ram 0x10,0x73,0x00,0x02, // key 0x00 // value };

You must then activate this function in line 311 (removing the //) gpsState = GPS_CONFIGURED; //uboxChecksum();

When you run this code, then it will display the buffer and the checksums to be added. Take to fill the 2 bytes about the length accordingly to the datasheet and this before calculating the checksum.

Satcomix commented 1 year ago

Ok,thank you. I hope i make it right. I will change the config, make a build and readout the buffer and the checksum for all used sats (49) and SBAS checksum.

Satcomix commented 1 year ago

Here are the changes for M10 Beitian BE-220 in gps.cpp My question was about these two checksums, or do I not have to change these checksums even though I changed the number of satellites and the SBAS query

const uint8_t initGps1[] = { // send command to GPS to change the setup // Here the code to activate galileo sat. (This has not yet been tested and is based on I-NAV code)

        0xB5,0x62,0x06,0x3E, 0x3C, 0x00, // GNSS + number of bytes= 60 dec = 003C in HEx
        0x00, 0x00, 0x20, 0x07,  // GNSS / min / max / enable
        0x00, 0x08, 0x10, 0x00, 0x01, 0x00, 0x01, 0x01, // GPS / 8 / 16 / Y
        0x01, 0x03, 0x03, 0x00, 0x01, 0x00, 0x01, 0x01, // SBAS / 1 / 3 / Y
        0x02, 0x08, 0x0a, 0x00, 0x01, 0x00, 0x01, 0x01, // Galileo / 8 / 12 / Y
        0x03, 0x06, 0x0c, 0x00, 0x01, 0x00, 0x01, 0x01, // BeiDou / 6 / 14 / Y
        0x04, 0x00, 0x08, 0x00, 0x00, 0x00, 0x01, 0x01, // IMES / 0 / 8 / N
        0x05, 0x03, 0x04, 0x00, 0x01, 0x00, 0x01, 0x01, // QZSS / 3 / 4 / Y
        0x06, 0x08, 0x0a, 0x00, 0x00, 0x00, 0x01, 0x01, // GLONASS / 8 / 12 / N
        0x30, 0xD8, // **checksum**

// Here the code to activate SBAS for Europe (This has not yet been tested and is based on I-NAV code)
        0xB5,0x62,0x06,0x16, 0x08, 0x00, // SBAS + number of bytes = 8
        0x03, 0x03, 0x03, 0x00, // mode = test + enabled, usage=range+diffcorr, max =3, scanmode2=0
        0x7b, 0x7e, 0x7f, 0x80, 0x81, 0x83, 0x85, 0x88, 0x89, 0x8a, // scanmode1 123,126-129,131,133,136-138
        0x86, 0x2C, //**checksum**

// Here other code        
        0xB5,0x62,0x06,0x01,0x08,0x00,0x01,0x02,0x00,0x01,0x00,0x00,0x00,0x00,0x13,0xBE, // activate NAV-POSLLH message
        0xB5,0x62,0x06,0x01,0x08,0x00,0x01,0x06,0x00,0x01,0x00,0x00,0x00,0x00,0x17,0xDA, //        NAV-SOL
        0xB5,0x62,0x06,0x01,0x08,0x00,0x01,0x12,0x00,0x01,0x00,0x00,0x00,0x00,0x23,0x2E, //        NAV-VELNED
        0xB5,0x62,0x06,0x01,0x08,0x00,0x01,0x07,0x00,0x01,0x00,0x00,0x00,0x00,0x18,0xE1, //        NAV_PVT
        0xB5,0x62,0x06,0x01,0x08,0x00,0x01,0x02,0x00,0x01,0x00,0x00,0x00,0x00,0x13,0xBE, // activate NAV-POSLLH message
        0xB5,0x62,0x06,0x01,0x08,0x00,0x01,0x06,0x00,0x01,0x00,0x00,0x00,0x00,0x17,0xDA, //        NAV-SOL
        0xB5,0x62,0x06,0x01,0x08,0x00,0x01,0x12,0x00,0x01,0x00,0x00,0x00,0x00,0x23,0x2E, //        NAV-VELNED
        0xB5,0x62,0x06,0x01,0x08,0x00,0x01,0x07,0x00,0x01,0x00,0x00,0x00,0x00,0x18,0xE1, //        NAV_PVT
mstrens commented 1 year ago

for sure you have to change the checksums if you change something to a command. Still I am not sure it will work. E.g. changing the sats in done in the first command. The command is identified with the code 0x06,0x3E. Are you sure this command is supported in M10. I do not see it in the datasheet.

Note: when a command is sent to the GPS, it has to reply with a ACK or a NAK code. If you put a logic analyser you could see those codes and know if the command is valid or not

Satcomix commented 1 year ago

Hello Mstrens, I had the configuration of the Beitian BE-220 displayed on U-Center. Everything is programmed there exactly as I entered it in the gps.cpp. In addition to the number of sats, a total of 49, the SBAS query areas were also changed

Here is the checksum code for gps.cpp ubox checksum()

check sum for 6 8a d 0 0 1 0 0 10 73 0 2 0 is 23 7d lenght to specify is 13

I think i search in the inav www. and hope to find something about inav code for M10 br, Torsten

mstrens commented 1 year ago

I do not 100% understand what you are dooing. In your previous post you say: Here is the checksum code for gps.cpp ubox checksum()

check sum for 6 8a d 0 0 1 0 0 10 73 0 2 0 is 23 7d lenght to specify is 13

This is just generated when you do not change the checksum function. It was a test with my own values in the buffer. You have to change the lines related to buffer[] inside the function if you want to get the checksums for your own command.

Satcomix commented 1 year ago

Hello Mstrens, I made something wrong, a copied the new build without changing the GPS values for M10. It was a long day, i think tomorow i will make a new build with the changes for the 49 Sats and SBAS. I will search for inav and M10 gps values, i hope it will help. greetings, Torsten

Satcomix commented 1 year ago

Hello Mstrens, Today I started again with tests for the GPS with M10 chipset. For this I installed the latest version 1.8.3 and connected a USB_UART_RX to the U-Center parallel to the GPS_TX. I noticed that the GPS M10 doesn't care what the config gps.cpp says about the use of the different types. The data is sent from satellites to the oXs, which is stored in the default config of the M10. This means that Beidou GPS data is also sent, but no Glonass GPS data, as actually intended in the gps.cpp. I've added a binary console plot of the M10's startup process after PowerDown for you. You can clearly see the NMEA data, which becomes UBX data after about 16 seconds. I am happy with how the M10 is working with oXs and will not be making any changes to gps.cpp in relation to this. br, Torsten

GPS_M10_NMEA_UBX_DATA.zip

mstrens commented 1 year ago

It seems me logic that M10 does not take care of the config commands sent by oXs because those commands are not supported ( at least not those of the datasheet). Still, it could make sense that oXs changes part of the config (using the commands foreseen for M10).

Do you know what are the different types of ubx messages that are sent by default (to see if I have to disable some of them)?

Satcomix commented 1 year ago

It seems me logic that M10 does not take care of the config commands sent by oXs because those commands are not supported ( at least not those of the datasheet). Still, it could make sense that oXs changes part of the config (using the commands foreseen for M10).

* disable nema message; this is already done

* allow to change the refresh rate (to slow it to e.g. 5 or 1hz)

* disable some UBOX messages that are perhaps sent by default but not needed.
  when I have time, I could search in the datasheet what are the commands to be used for this.

Do you know what are the different types of ubx messages that are sent by default (to see if I have to disable some of them)?

Hello Mstrens, Thanks a lot for the response. The problem I see is not the configuration in the oXs gps.cpp, but the different settings of the different GPS chipsets from Ali from CN. Original products are just expensive but correspond to the information in the data sheet, cheap products from Ali from CN are always a surprise. You can never say 100% which settings have been released by default. All systems from CN differ enormously. Apparently it varies from retailer to retailer, and you're lucky if you get the same chipsets with the same basic settings/firmware. I own some M8030 (BN series and TBS), M10050 (BE series) chipsets, whereby the M10050 are all the same from the default values, but you can only select a maximum of 49 satellites (not 72). With the M8030 chipsets, a maximum number of 32 is allowed, whereby it depends on the firmware whether Galileo can be set at all.

br, Torsten

Satcomix commented 1 year ago

Here is a new binary view when i connect the M10050 with U-Center port Default settings M10: 38400baud , Target1-UART1, Protocol in UBX-NMEA, Protocol out UBX-NMEA, Measurement Frequency 1Hz,

UBX_messages_at_connection.zip I hope you can see what you need. br, Torsten

Satcomix commented 1 year ago

38400baud, Target1-UART1, Protocol in UBX, Protocol out UBX, Measurement Frequency 1Hz. UBX_messages_at_connictio_without_NMEA.zip I don`t know the different types of UBX messages, that are sent by default. I search and find a document with all types of messages for M10, this one for SPG 5.00 https://content.u-blox.com/sites/default/files/u-blox%20M10-SPG-5.00_InterfaceDescription_UBX-20053845.pdf this one for ROM 5.10 https://content.u-blox.com/sites/default/files/u-blox-M10-ROM-5.10_ReleaseNotes_UBX-22001426.pdf br, Torsten