Inkompatible Version von GPS-Modulen (Baudrate?!)

preya · 15. Mai 2023 um 09:20

Hallo liebe OBS-Community,

bei unserem letzten Workshop in Hamburg haben wir anscheinend mal wieder eine neue/ander Charge an GPS-Modulen erwischt und haben das gleiche Fehlerbild bei 8 Sensoren:

Optisch/äußerlich sind sie vollkommen identisch zu unseren letzten, funktionierenden Modulen (Beschriftung auf dem IC sagt NEO-6M2. Auf dem PCB steht GY-GPS6MV2 wie immer).
Wir haben alle Module vor dem Einbau mit u-center getestet und verifiziert dass die Antennen funktionieren/die Module erfolgreich einen Fix bekommen. Die Module scheinen also prinzipiell funktionsfähig zu sein. Ältere (funktionierende) Module identifizieren sich in der u-center Software als „u-blox 5“ (Angabe in der Fußleiste). Diese neuen, problematischen Module identifizieren sich dort als „u-blox M8/8“ („Richtige“ M8 sind es aber anscheinend auch nicht – die haben einige Leute wohl schon erfolgreich verbaut, und die Module würden anders aussehen).
Allerdings können die Module nicht mit dem ESP32 aus dem OBS kommunizieren. Auf dem Display bleibt immer „0 sats SN: 0“ stehen. Und über das serielle Terminal meldet der ESP32 Folgendes:

[    37][I][OpenBikeSensorFirmware.cpp:199] setup(): openbikesensor.org - OBS/v0.18.849
[    39][I][esp32-hal-i2c.c:75] i2cInit(): Initialising I2C Master: sda=21 scl=22 freq=100000
[    44][W][Wire.cpp:301] begin(): Bus already started in Master Mode.
[    90][I][VoltageMeter.cpp:40] VoltageMeter(): Initializing VoltageMeter.
[    91][I][VoltageMeter.cpp:54] VoltageMeter(): Characterized using eFuse Vref
[    93][I][VoltageMeter.cpp:62] VoltageMeter(): eFuse Two Point: NOT supported
[   100][I][VoltageMeter.cpp:66] VoltageMeter(): eFuse Vref: Supported
[   109][I][VoltageMeter.cpp:75] VoltageMeter(): VoltageMeter initialized got 0.21V.
[   146][I][OpenBikeSensorFirmware.cpp:617] loadConfig(): Load cfg
[  1049][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms.
[  1250][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms.
[  1250][E][gps.cpp:361] sendAndWaitForAck(): Failed to send cfg. 0x3406 NAK: 0 after 401ms
[  1284][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 4d M
[  1285][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 05
[  1287][W][gps.cpp:663] encode(): Unexpected GPS char in state null: b1 �
[  1293][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 41 A
[  1300][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 2c ,
[  1306][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 33 3
[  1313][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 2c ,
[  1319][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 32 2
[  1326][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 31 1
[  1333][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 2c ,
[  1339][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 30 0
[  1346][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 31 1
[  1352][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 2c ,
[  1359][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 30 0
[  1366][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 38 8
[  1372][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 2c ,
[  1379][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 33 3
[  1385][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 32 2
[  1392][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 2c ,
[  1399][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 31 1
[  1405][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 30 0
[  1412][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 2c ,
[  1418][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 31 1
[  1425][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 34 4
[  1432][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 2c ,
[  1438][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 32 2
[  1445][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 37 7
[  1451][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 0c
[  1683][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms.
[  1883][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms.
[  1883][E][gps.cpp:361] sendAndWaitForAck(): Failed to send cfg. 0x3406 NAK: 0 after 400ms
[  2087][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms.
[  2117][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GNRMC: $GNRMC,153547.00,A,5334.76976,N,01001.29712,E,0.037,,140523,,,A,V*17
[  2127][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GNGGA: $GNGGA,153547.00,5334.76976,N,01001.29712,E,1,08,1.01,10.3,M,46.3,M,,*7F
[  2131][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GNGSA: $GNGSA,A,3,21,01,08,32,10,14,27,,,,,,2.04,1.01,1.78,1*03
[  2142][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GNGSA: $GNGSA,A,3,14,,,,,,,,,,,,2.04,1.01,1.78,4*09
[  2152][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GPGSV: $GPGSV,3,1,12,01,52,283,36,02,34,102,16,03,17,227,21,08,49,178,32,0*64
[  2164][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GPGSV: $GPGSV,3,2,12,10,30,057,26,14,24,299,29,17,06,317,,21,82,287,39,0*62
[  2176][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GPGSV: $GPGSV,3,3,12,22,34,124,22,24,05,020,,27,20,157,22,32,42,094,27,0*6C
[  2187][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA BDGSV: $BDGSV,1,1,02,12,,,13,14,45,184,42,0*48
[  2196][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GNTXT: $GNTXT,1,1,01,ANTENNA OK*2B
[  2287][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms.
[  2287][E][gps.cpp:361] sendAndWaitForAck(): Failed to send cfg. 0x3406 NAK: 0 after 400ms
[  2291][I][gps.cpp:180] softResetGps(): Soft-RESET GPS!

Irgendwie sprechen der ESP32 und das GPS-Module nicht die gleiche Sprache. Wenn man davon ausgeht, dass der Befehlssatz sich bei dem Modul nicht geändert hat, dann scheint das irgendwie an einer anderen Codierung oder Baudrate zu liegen?!
Laut Web-Interface identifiziert sich das problematische Modul im GPS-Abschnitt so:

image629×685 27.2 KB

Hat jemand Ideen, wie wir hier weiter debuggen können? Wir haben nen ganzen Sack von den Modulen und würden die ungern entsorgen müssen.

opatut · 15. Mai 2023 um 09:33

Ich habe leider inhaltlich nichts beizutragen, begrüße aber eure Methodik der offenen gemeinsamen Problemlösung mit klarer Kommunikation. Eine wunderbare Zusammenfassung! So geht Open Source!

Ich drücke die Daumen dass sich ein:e Spezialist:in meldet, die hier helfen kann.

osc · 15. Mai 2023 um 13:13

Moin,
ich habe hier seit kurzem zwei (ein Air360, ein Neo6, über Berrybase) und beschäftige mich mit denen ein bißchen. Noch reden die nicht mit PyGPS am seriellen… und pulseview am 8-Port saleae-clone zickt derzeit rum (hat mal funktioniert)… ansonsten bringe ich das gerne zum WS in zwei Wochen mit… DSO ggf. auch. Dann kann man der Sache besser auf den Grund gehen.
Olaf

maehw · 15. Mai 2023 um 13:43

Hallo,

liest sich sehr ähnlich wie „unser Fehlerbild“.

Auf github ein Issue von mir:

github.com/openbikesensor/OpenBikeSensorFirmware

Startup fails due to GPS module communication

opened 08:44PM - 05 May 23 UTC

maehw

Hi all! As I've taken my notes in English (and everything is becoming quite t…echnical), I am adding his as an issue to github, not the the OBS forum: We are currently trying to build some OBS **HW v00.03.12**. The flashed firmware version is **OBS/v0.18.849**. As we've previously seen GPS modules failing, we've been testing the GPS modules in advance: we've hooked the modules up to a Windows PC using a USB/serial converter cable and running the [u-blox u-center](https://www.u-blox.com/en/product/u-center?lang=de) GNSS evaluation software (using a [small test jig](https://github.com/maehw/ObsHwModuleTests/tree/main/ObsGpsModuleTestJig)). Everything worked fine - all the GPS modules all got fixes with their antennas were attached, at least 4 satellites in sight, quick fix! When being soldered on to the OBS PCB, the OBS won't boot up correctly and "freeze" showing "0 sats SN:0" in the display. I've made two approaches to narrow the issue down: 1. Use a Saleae Logic analyzer, sniff and analyze ([using a UBX HLA](https://github.com/maehw/SparkFun_u-blox_UBX_HLA)) the traffic between OBS and GPS module ; no ESP32 UART connection to the PC; powering the OBS by operating the switch 2. Have a look at the ESP32 UART logging data and also sniff the data; the OBS power switch doesn't play any role here # Approach 1 ### Initialization: agreement on a common baud rate * Around 55 ms after powerup, the GPS module sends a lot of NMEA data at 9600 baud (multiple `$TDINF` messages, `$GNRMC`, `$GNGGA`, 2x `$GNGSA`, 3x `$GPGSV`, `$BDGSV`, `$GNTXT` including the text `ANTENNA OK`) * After another approx. 540 ms, the GPS module sends some more NMEA messages * After this burst, another approx. 670 ms pass, until the OBS starts to send some data itself: it queries `CFG-RINV` at 115'200 baud and doesn't get an answer after 200 ms twice * ***OBS then switches to 9600 baud and sends `CFG-PRT` for reconfiguration to 115'200 baud, directly switches itself back to 115'200 baud and re-sends `CFG-RINV` at the higher baud rate while the GPS still sends using the lower 9600 baud rate*** * ***GPS reconfigures to using 115'200 baud and sends an `ACK-ACK` for the `CFG-PRT` message at that higher rate*** ### Continued failed queries of the remote inventory * After around 200 ms the OBS resends the `CFG-RINV` query as it has not gotten a response in the meantime * After another approx. 200 ms the OBS again resends the CFG-RINV query as it has not gotten a response in the meantime * The GPS doesn't seem to care and sends some `$GNRMC`, `$GNGGA`, `$GNGSA`, `$GPGSV`, `$BDGSV`, `$GNTXT` NMEA message * After another approx. 200 ms the OBS again resends the CFG-RINV query as it has not gotten a response in the meantime - for two more times! * ***OBS finally issues a `CFG-RST` request*** * ***GPS acknowledges the request by responding with an `ACK-ACK` for `CFG-RST`*** ### Failed message configurations after reset and still no remote inventory * After some 85 milliseconds delay, again NMEA data from the GPS module * OBS sends an `CFG-MSG` request for message `0x0B 0x32`, i.e. `AID-ALPSRV` * **GPS replies with `ACK-NACK`** * OBS requests `AID-ALP`, `MON-VER`, `MON-HW`, `NAV-STATUS` and `CFG-NAV5` * GPS replies with 37(! seems not to be specification conformant) byte long `MON-VER` * GPS replies with 36 byte long `CFG-NAV5` * After another approx. 200 ms the OBS sends another `CNFG-NAV5` request * GPS replies with `CFG-NAV5` * After a short delay, the GPS also sends again some `$GNRMC`, `$GNGGA`, `$GNGSA`, `$GPGSV`, `$BDGSV`, `$GNTXT` NMEA message * **OBS once again requests `CFG-RINV`** * **No reply from the GPS module within approx. 200 ms so OBS once again requests `CFG-RINV`** * Still no reply from the GPS module within about 240 ms * OBS requests `CFG-MSG` for `0x01 0x20`, i.e. `NAV-TIMEGPS` with a rate of `1` on the relevant port * **`ACK-NACK` from the GPS module** * OBS requests `CFG-MSG` for `0x01 0x03`, i.e. `NAV-STATUS` with a rate of `1` on the relevant port * **`ACK-NACK` from the GPS module** * OBS requests `CFG-MSG` for `0x0A 0x09`, i.e. `MON-HW` with a rate of `1` on the relevant port * **`ACK-NACK` from the GPS module** * Afterwards, cyclic NMEA message burst from the GPS module continue - no UBX messages, no more data from the OBS ## Findings - The response of `MON-VER` doesn't look as if it was conforming to the specification (I'd expect a 40 byte long reply with 30 bytes software version and 10 bytes hardware version); the value starts with `T3,RomFw,1.1(48)`, not sure if this is what one would expect from an original u-blocks module! - Why no `CFG-RINV` reply at all? Nor an empty dump neither even an `ACK-NACK` (not sure if we expect any `ACK-*` though)? - Why the `ACK-NACK` to the `CFG-MSG` requests? - In my understanding either OBS does not request muting NMEA messages or it does not work. # Approach 2 ``` E (933) esp_core_dump_flash: No core dump partition found! [ 36][I][OpenBikeSensorFirmware.cpp:199] setup(): openbikesensor.org - OBS/v0.18.849 [ 38][I][esp32-hal-i2c.c:75] i2cInit(): Initialising I2C Master: sda=21 scl=22 freq=100000 [ 43][W][Wire.cpp:301] begin(): Bus already started in Master Mode. [ 89][I][VoltageMeter.cpp:40] VoltageMeter(): Initializing VoltageMeter. [ 90][I][VoltageMeter.cpp:54] VoltageMeter(): Characterized using eFuse Vref [ 92][I][VoltageMeter.cpp:62] VoltageMeter(): eFuse Two Point: NOT supported [ 99][I][VoltageMeter.cpp:66] VoltageMeter(): eFuse Vref: Supported [ 109][I][VoltageMeter.cpp:75] VoltageMeter(): VoltageMeter initialized got 0.21V. [ 155][I][OpenBikeSensorFirmware.cpp:617] loadConfig(): Load cfg [ 1058][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms. [ 1259][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms. [ 1259][E][gps.cpp:361] sendAndWaitForAck(): Failed to send cfg. 0x3406 NAK: 0 after 401ms [ 1370][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GNRMC: $GNRMC<snip-to-end-of-line> [ 1371][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GNGGA: $GNGGA<snip-to-end-of-line> [ 1380][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GNGSA: $GNGSA,A,1,,,,,,,,,,,,,99.9,99.9,99.9,1*0A [ 1388][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GNGSA: $GNGSA,A,1,,,,,,,,,,,,,99.9,99.9,99.9,4*0F [ 1398][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GPGSV: $GPGSV,<snip-to-end-of-line> [ 1409][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GPGSV: $GPGSV,<snip-to-end-of-line> [ 1420][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GPGSV: $GPGSV,<snip-to-end-of-line> [ 1431][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GPGSV: $GPGSV,<snip-to-end-of-line> [ 1440][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA BDGSV: $BDGSV,<snip-to-end-of-line> [ 1447][W][gps.cpp:1156] parseNmeaMessage(): Unparsed NMEA GNTXT: $GNTXT,1,1,01,ANTENNA OK*2B [ 1492][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms. [ 1692][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms. [ 1692][E][gps.cpp:361] sendAndWaitForAck(): Failed to send cfg. 0x3406 NAK: 0 after 400ms [ 1696][E][gps.cpp:305] setBaud(): Switch to 115200 was not possible, back to 9600. [ 1903][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms. [ 2103][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms. [ 2103][E][gps.cpp:361] sendAndWaitForAck(): Failed to send cfg. 0x3406 NAK: 0 after 400ms [ 2107][E][gps.cpp:310] setBaud(): NO GPS???? [ 7112][I][gps.cpp:450] addStatisticsMessage(): New: readGPSData(clear: 190 bytes in buffer, lastCall 5009ms ago, at 1970-01-01T00:00:07) [ 7315][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms. [ 7398][W][gps.cpp:663] encode(): Unexpected GPS char in state null: c7 Ç ... [ 7631][W][gps.cpp:663] encode(): Unexpected GPS char in state null: fe þ [ 7639][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 324ms. [ 7645][E][gps.cpp:361] sendAndWaitForAck(): Failed to send cfg. 0x3406 NAK: 0 after 534ms [ 7853][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms. [ 8053][W][gps.cpp:356] sendAndWaitForAck(): Retry to send 0x3406 after 200ms. [ 8053][E][gps.cpp:361] sendAndWaitForAck(): Failed to send cfg. 0x3406 NAK: 0 after 400ms [ 8057][I][gps.cpp:180] softResetGps(): Soft-RESET GPS! [ 8232][W][gps.cpp:663] encode(): Unexpected GPS char in state null: c7 Ç ... [ 8247][W][gps.cpp:663] encode(): Unexpected GPS char in state null: 88 ... ``` I haven't put the same amount of effort into analysing this situation. But after start-up it looks like the GPS sending at 115'200 baud and the OBS having fallen back to 9600 baud - so the cyclic NMEA messages may not even be interpretable as ASCII/NMEA messages. All UART input is garbage this makes everything fail?! # Summary I am not sure what's going on but I can provide further debugging details when I get some guidance. Random thoughts: - Is it possible that u-blox u-center activated NMEA messages that the OBS firmware cannot cope with as they are unexpected? - Some corner case where baud rates are changed without being required? - It looks to me that the OBS does not wait for neither the reset request nor the baudrate reconfiguration being acknowledged by the GPS module before continuing communication. - Counterfeit GPS module that is not specification-conformant - works with the u-blox u-center but not the OBS firmware? - Is missing almanach data problematic? Didn't provide any so far. If that's the case, I suggest the firmware handling this situation differently if it can be recognized. - Is the remote inventory or the access to it broken and causing all those issues? I haven't dived too much into the firmware. Your help is highly appreciated. --- Edit: I played around with the u-blox u-center and found out about the NMEA messages: - `GxGGA` seems to stand for Global Positioning System Fix Data - `GxGSA` GNSS DOP and Active Stallites - `GxGSV` GNSS Satellites in View - `GxRMC` Recommended Minimum Specific GNSS Data - `GxTXT` Text Transmission - `BDGSV` still seems like random unknown magic Maybe they cannot be deactivated and are even required by the OBS? Or did u-blox u-center just activate them because of its opened views and store those settings on the module? E.g. GxGGA "SVs Used" or GxGSA "SVs Used": "Number of SVs used for Navigation" Could OBS display the min./max. [`C/N_0`](https://en.wikipedia.org/wiki/Carrier-to-noise_ratio) of the 4 satellites with the best `C/N_0` instead of some magic (absolute?) `noisePerMs` noise level from `MON-HW`? Maybe the latter correlates with `N_0` but doesn't give any info about signal reception quality? --- Edit2: Okay, does not look like any NMEA relations: - `Gps::parseUbxMessage()` calls `mIncomingGpsRecord.setInfo(mGpsBuffer.navSol.numSv, ...)` when it receives UBX `NAV-SOL` messages. - `GpsRecord::setInfo(uint8_t satellitesInUse, GPS_FIX gpsFix, uint8_t flags)` stores the argument in member `mSatellitesUsed` - `Gps::showWaitStatus()` prints `String(mCurrentGpsRecord.mSatellitesUsed) + "sats SN:" + String(mLastNoiseLevel);` on the display From a static code analysis (not runtime debugging) view, we're stuck in the following endless loop: ``` while (!gps.hasFix(obsDisplay)) { currentTimeMillis = millis(); gps.handle(); // ... gps.showWaitStatus(obsDisplay); if (button.read() == HIGH) { log_d("Skipped get GPS..."); obsDisplay->showTextOnGrid(2, obsDisplay->currentLine(), "...skipped"); break; } } ``` - `gps.hasFix()` uses `GpsRecord::hasValidFix()` (https://github.com/openbikesensor/OpenBikeSensorFirmware/blob/53e9ea4440d13a7292031f45227c5144bc04e8e1/src/gpsrecord.cpp#L118..L121) which includes `&& mSatellitesUsed != 0` as condition - I think we won't be able to break outside of this loop without receiving a `NAV-SOL` message which **never has been requested** (according to my log above)

Im Forum ein wenig versteckt unter dem Titel „Modultests“:

Schickt mir gerne mal eines eurer Module. Und spielt auch gerne mal meine Test-Firmware auf. Technisch kann ich hier unterstützen… ggf. auch die Firmware vorbauen über eine CI.

maehw · 15. Mai 2023 um 13:55

Ich habe kürzlich Änderungen zum Saleae Logic High Level Analyzer (HLA) für das u-blox UBX beigetragen. Auch das könnte die Fehlersuche unterstützen.

(Siehe Release v1.0.2 bzw. aktueller main-Branch.)

preya · 16. Mai 2023 um 08:15

Wow, Danke für deine Links. In der Tat sieht das nach dem gleichen Fehlerbild aus.

Wie können wir das Thema denn weiter voranbringen?

Ich werde gerne mal deine Test-Firmware aufspielen, und gucken was sie ausspuckt.
Ich schicke dir auch gerne eins der betreffenden Module zu

Können wir sonst noch was tun?

maehw · 16. Mai 2023 um 18:29

Ich habe gerade nochmal die Test-Firmware aktualisiert.

Mein GPS-Modul hier spricht primär NMEA, einzelne UBX-Nachrichten (das Binärprotokoll von u-blox) kann es aber schon. Ich denke wir könnten hier für einzelne Nachrichten prüfen, wie sich das Modul im Detail verhält und vom „echten“ u-blox NEO-6M abweicht.

Wenn mann wollte, könnte man auch die Firmware anpassen - aber hier gibt’s Qualitätsbedenken (Genauigkeit und Fix afair). Vielleicht können wir die aber auch ausräumen.

andreas · 16. Mai 2023 um 18:39

Die Frage ist tatsächlich wie weit es hilft und zur Stabilität beiträgt hier die NMEA Nachrichten auszuwerten.
Das Wechseln auf 115200 geht offensichtlich per UBX, manch anderes wird aber ignoriert. Insbesondere die Nachrichten die wir verwenden um Zeit & Ort zu erhalten kommen offensichtlich nicht. Zusätzliches Testen hilft da vermutlich wenig, die Ursache ist ja klar. Interessant ist eventuell welche NMEA Nachrichten so ankommen - die Firmware logt das raus: Unparsed NMEA ... dazu hat @maehw schon Details auf Github gepostet - sind es die selben Nachrichten?

maehw · 18. Mai 2023 um 09:13

Ich das Log oben im Post mal angeschauen und mit meiner Analyse aus issue 340 verglichen:

$GNRMC, $GNGGA, 2x $GNGSA, 3x $GPGSV, $BDGSV, $GNTXT including the text ANTENNA OK)

… findet sich dort genau so wieder.

Gibt es eine Übersicht, welche UBX-Nachrichten gerade genutzt werden?

Vielleicht lässt sich das über NMEA auch abbilden?

Ich habe überlegt in die Test-Firmware alle pollbaren UBX-Nachrichten auch zu pollen und auf eine Antwort zu warten. So müsste man für die GPS-Module heraus bekommen, welches Subset des Original-Protokolls sie bedienen. Könnte die Fehlersuche bei zukünftigen Modulen erleichtern (einsteigerfreundlicher machen).

Gibt es Meinungen dazu?

PS: Ich habe die Test-Firmware über GitHub Actions mittels Arduino-CLI baubar bekommen. Jetzt hänge ich an den nächsten Schritten: GitHub - maehw/ObsHwModuleTests at try-to-build-package - welche vier Binaries müssen alle erzeugt werden?

Nach meinem (gestern angelesenen) Verständnis:

Es gibt eine 3 kByte Partitionstabelle (bei mir dann ObsGpsTest.ino.partitions.bin), die wird geflasht an Adresse 0x08000.
An Adresse 0x10000 wird die Applikation geflasht (bei mir dann ObsGpsTest.ino.bin).
Der Rest wird mit einem Bootloader zu tun haben. Welchen nutzt ihr da? Was eigenes? Kann ich das auch nutzen? Wo komme ich da ran?

Bisher baue ich lokal mit Arduino 1.8.19 und nutze die Boardmittel zum Flashen.

Mit dem oberen Ansatz wäre es denkbar, die Test-Firmware auch per Weboberfläche upzudaten - und auch die Original-OBS-Firmware wieder einzuspielen oder? Also theoretisch ohne esptool (und erst recht ohne IDE und Buildtools, das versuche ich ja durch die CI zu machen).

maehw · 28. Mai 2023 um 10:13

Ich habe nochmal Zeit in die Fehlersuche investiert.

@preya und @michaelAUX zur Info

@preya danke für euer zugeschicktes Modul. Es meldet sich ebenso als „Techtotop Multi-GNSS Receiver“ wie unsere Module und verhält sich auch so. Verhält sich auch so bedeutet:

es sendet eigenständig NMEA-Nachrichten
es antwortet nahezu nicht auf Poll-Requests von UBX-Nachrichten (Ausnahme: CFG-PRT)

Im Vergleich dazu antworten GPS-Module, die sich als „u-blox AG (…)“ melden auf nahezu alle UBX Poll-Requests, die ich verschicke. (NMEA-Nachrichten sehe ich keine, aber möglicherweise, weil die OBS-Firmware diese im Modul mal deaktiviert hat.)

Ich habe jetzt noch einmal einige Verbesserungen an ObsHwModuleTests/ObsGpsTest at main · maehw/ObsHwModuleTests · GitHub durchgeführt. Damit kann man ohne ein Hardware/Firmware-Experte sein am Verhalten der GPS-Module recht einfach feststellen, was los ist.

Man sollte herausfinden, …

ob die Verdrahtung & Baudrate stimmen (Wechsel zwischen den beiden typischen 9600 und 115’200 per „Knopfdruck“ beim Start der Test-Firmware)
NMEA-Nachrichten verschickt werden
UBX-Nachrichten verschickt werden (was die OBS-Firmware nutzt)
überhaupt UBX Poll-Requests beantwortet werden (unterschiedliches Verhalten von u-blox GPS-Modulen und denen von Techtotop)

Ich habe kürzlich nochmal eine Bestellung bei AliExpress angestoßen und jetzt wieder Module bekommen, die behaupten sie wären „u-blox“ (und deren Polling-Request-Antwortverhalten auch so konform ist).

Es ist also ein wenig Glücksspiel, was man bestellt.

Spielt gerne die Test-Firmware auf, ansonsten könnt ihr auch Kontakt aufnehmen und ich teste GPS-Module für euch.

preya · 30. Mai 2023 um 09:48

Danke @maehw. Zumindest können wir mit deiner Test-Firmware jetzt vorab Module auf ihre Eignung prüfen.

Dennoch sieht es für mich so aus, als ob die betroffenen Fake-Module auch durch FW-Update/Modifikation nicht auf einen funktionsfähigen/gleicherwetigen Stand gebracht werden können. Die Funktionsweise der Fake-Module scheint sich ja deutlich zu unterscheiden von den funktionierenden Modulen.

gluap · 23. Juni 2023 um 15:11

Vielen Dank fürs ausführliche Aufschreiben euch! konnte so recht schnell rausfinden dass eins meiner Module Schrott war!