Autobauding and chip detection not reliable

[prichterich]

I have experienced random failures with the automatic detection of baud rate and chip at startup with FW 5.74 and 5.75. This affected 2 different units with Beitian BN220 chips which never had problems with versions up to 5.72.

This is not well reproducible. I have seen issues first after switching the BN220 against a Beitian BE220, and the going back to the original chip. The display still showed 38kBaud after the switch, although the recording seemed to work ok. At other times, the startup screens reported not being able to identify the chip. While at home, the communication still worked fine (judging by the unit showing that it got satellites), but when I used it in a windsurf session today, it staid at "waiting for satellites" (v. 5.74), and did not record at all. Back at home, it discovered M8 @ 9600 correctly several times in a row.

The vast majority of GPS units will be built with one kind of GPS chip, and then keep this chip from then on. In any sealed units, this cannot change after the built. So rather than doing an autodetect every time, it may make more sense to autodetect only on an "as needed" basis (e.g. when verifying the chip type using previously saved information fails).

[RP6conrad]

I could make a field in the configuration with "Auto detect GPS on", @startup then autodetect, then writing the type of gps in the same field. So, this field can then have next values :

1. Autodetect on
2. M8@9600bd
3. M8@38400bd
4. M10@9600bd
5. M10@38400bd So, the user can always "force" the type of gps.

[prichterich]

That looks like a very good solution. The software purist in me would also suggest to clean up the autobauding code, and to support detecting other baud rates and the M9. But there are no good reasons to choose an M9 that hold up to closer inspection, and no U-blox/Beitian GPS units that come with other baud rates, so all that can wait a long time (or forever).

[RP6conrad]

I have just ordered a ublox M9 (m9140 chip), as Beitian has now the BK-line for a very reasonable price ! Lets see if we can log @ 25 Hz !Verzonden vanaf mijn Galaxy -------- Oorspronkelijk bericht --------Van: prichterich @.> Datum: 31/05/23 14:59 (GMT+01:00) Aan: RP6conrad/ESP-GPS-Logger @.> Cc: RP6conrad @.>, Comment @.> Onderwerp: Re: [RP6conrad/ESP-GPS-Logger] Autobauding and chip detection not reliable (Issue #22) That looks like a very good solution. The software purist in me would also suggest to clean up the autobauding code, and to support detecting other baud rates and the M9. But there are no good reasons to choose an M9 that hold up to closer inspection, and no U-blox/Beitian GPS units that come with other baud rates, so all that can wait a long time (or forever).

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[prichterich]

I got an original u-blox M9 chip a year or so ago, and was quite disappointed to find out that the chip automatically reduced the number of satellites used to 16 when logging at 10 Hz and higher. For the M8, the Beitian chips actually were better than original u-blox M8s with respect to rates and multiple GNSS systems. If you're lucky, you may see the same for the M9. I would not bet on it, though - I think the u-blox M10 can do 4 GNSS systems simultaneously, but the BE220 and 250 chips are limited to 3. Re 25 Hz, even at 10 Hz, the observed "noise" while windsurfing is dominated by movements of the arm/hand/boom that the GPS is mounted to, and not by random noise. That's quite obvious if you look at nauti or 1 h for units attached at different positions. Alpha differences with 2 boom mounted units is somewhat similar - the results often differ at a level that is significant because the slight difference int turn diameter for inner and outer unit. Once you go beyond 5 Hz, the reported "accuracy" estimates calculated by Gaussian error propagation become more and more meaningless, at least for windsurfing and similar applications. I think that even replacing 10 Hz raw measurement with 1 or 2 Hz averages would be very close in actual accuracy for 2 second speeds, and even more so for 10 seconds and beyond. The biggest difference is in "top speed" - but that is always overstated by single-point measurements, and this error only gets worse is you use higher rates.

[RP6conrad]

With the SW 5.76, the function "Autodetect ublox" is done with a new device, then the result is saved to the EEPROM memory. Next boot, no Autodetect anymore. If needed, the Autodetect can be activated again over the configuration menu. Added support for the M9 ublox.