Untersuchungen an "schwierigen" neo8m GPS Modulen

Projekte und Forschung
#1

Wir hatten dieses Jahr eine Charge neo8m Module im Einsatz, die sich seltsam verhalten haben. Kurze Zusammenfassung, was dabei passiert ist:

  • Die Module funktionieren beim Test auf dem Schreibtisch komplett einwandfrei
  • Beim Test auf dem Workshop im Gerät aufgebaut sind sie auch noch weitgehend unauffällig
  • Später finden sie nur langsam einen Fix, ggf. manchmal gar nicht.

Ich habe jetzt eins der problematischen Module auf dem Schreibtisch.
Erste Ergebnisse. Ich teste mit verschiedenen initialisierungsmodi immer wieder den kaltstart und messe, wie viele Sekunden es bis zum Fix braucht.

Ich probiere 4 Startmodi:

  • almanach_gnss agps mit daten aus dem Internet, außerdem werden die galileo satelliten mit verwendet
  • gnss die galileo satelliten werden mit verwendet, aber kein agps
  • agps agps aber kein galileo
  • stock Auslieferungszustand - So werden die Module mit der derzeitigen Firmware angesprochen (die nur m6n agps beherrscht).

neo8m, das im OpenBikeSensor problematisch war

  • almanach_gnss: 63.5 s über 122 starts
  • gnss: 92.6 s über 121 starts
  • agps: 60.8 s über 121 starts
  • stock: 85.4 s über 121 starts

Frisches neo8m aus der Tüte

  • almanach_gnss: 56.2 s über 210 starts
  • gnss: 75.8 s über 211 starts
  • agps: 49.9 s über 211 starts
  • stock: 71.5 s über 211 starts

Man sieht, dass agps jeweils etwa 20-30 Sekunden beschleunigung bringt und das anschalten von galileo den Start um etwa 5 Sekunden verlangsamt. Ich vermute das es technisch keinen Unterschied zwischen dem neo8m aus der Tüte und dem „problematischen“ neo8m gibt, und werde bei der nächsten Runde tests die Antenne ins OpenBikeSensor gehäuse einbauen, um zu sehen, ob dadurch die Leistung der Antenne verschlechtert wird.

1 „Gefällt mir“
#2

Ich habe jetzt ein auch ein paar Tests gemacht und bin der Meinung es liegt an der Firmware.

Ich habe einen UART-USB Converter direkt an den rx-Pin des ESP geklemmt (tx vom GPS Modul) und mit pygpsclient ausgewertet. Während der OBS „Wait for GPS“ anzeigt, gibt mir pygpsclient die Koordinaten und fix und alles.

Ich habe mit Debug-Ausgaben kompiliert und herausgefunden, dass mLastTimeTimeSet nie gesetzt wurde.

Mit Allow debugging of GPS vs location drift and GPS week handling (#276 … · openbikesensor/OpenBikeSensorFirmware@9ab7c9e · GitHub wurde nicht nur die notwendige message.tAcc auf 20ms Sekunden gesetzt sondern auch die Bedingung

&& delayMs < 20

Mit der Änderung auf

&& delayMs < 80

geht es wunderbar.

3 „Gefällt mir“
#3

Oh, das klingt ja extrem vielversprechend. Das werde ich gleich mal ausprobieren!

edit: erster test hatte nach 2 Minuten einen Fix. Ist aber noch eine weitere Modifikation von mir dabei, die die galileo-satelliten anschaltet, dich ich vorher versucht hatte, in der Hoffnung Fixfinden zu verbessern.

#4

Habe ein Ticket und pull request erstellt.

1 „Gefällt mir“
#5

Hi Jens,

danke für den PR.

Kannst Du bei den betroffenen Systemen in den CSVs oder, wenn der OBS im Server Modus läuft auf der About Seite mal nach TIMEGPS set: suchen und den Eintrag hier teilen? Dort steht auch der delay Wert, der beim Setzen der Zeit aufgetreten war.

Z.b. TIMEGPS set: 1970-01-01T00:00:03 -> 2024-09-14T11:26:33 delay 4ms. tAcc:113375ns

Ich sehe da in der Regel deutlich kleinere Werte - kann natürlich sein, dass andere GPS Module da andere timings haben, eventuell müssen auch Puffer angepasst werden.

Zu arg sollte der Wert nicht Auseinanderlaufen, die Zeit wird oft zur externen Synchronization mit Kameras etc. verwendet und eigentlich haben wir mit GPS ja eine sehr genaue Zeitreferenz.

Grüße,
Andreas.

#6

Messpunkte von mir mit Neo8m (allerdings warmstart) - delay 200ms maximum.

Der lange delay scheint häufig in Folge von Failed to send 0x0406 aufzutreten.

Versuch 0

 11338][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 237187000 lon: 85618329 lat: 499165846 height: 157607 hMsl 110045, hAcc 61532, vAcc 43510 delay 3ms
[ 11573][W][gps.cpp:508] sendAndWaitForAck(): Retry to send 0x0406 after 5000ms.
[ 11581][E][gps.cpp:513] sendAndWaitForAck(): Failed to send. 0x0406 NAK: 0 after 10016ms
[ 11813][I][gps.cpp:650] addStatisticsMessage(): New: swVersion: ROM CORE 3.01 (107888)
[ 11821][I][gps.cpp:650] addStatisticsMessage(): New: hwVersion: 00080000
[ 11827][I][gps.cpp:650] addStatisticsMessage(): New: romVersion: FWVER=SPG 3.01
[ 11835][I][gps.cpp:650] addStatisticsMessage(): New: extension: PROTVER=18.00
[ 11842][I][gps.cpp:650] addStatisticsMessage(): New: extension: GPS;GLO;GAL;BDS
[ 11849][D][gps.cpp:1087] parseUbxMessage(): MON-VER SW Version: ROM CORE 3.01 (107888), HW Version 00080000, len 160
[ 11861][D][gps.cpp:1273] parseUbxMessage(): CFG_NAV5
[ 11867][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x2406 took 77ms
[ 11884][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x3406 took 9ms
[ 11940][I][gps.cpp:331] enableAlpIfDataIsAvailable(): Enable ALP
[ 11950][E][gps.cpp:1039] parseUbxMessage(): ACK-NAK overrun had ack: 1 for 0x3406
[ 11957][E][gps.cpp:1041] parseUbxMessage(): ACK-NAK 0x0106
[ 12051][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x0106 took 5ms
[ 12225][D][alpdata.cpp:174] loadMessage(): Read 54 bytes
[ 12231][I][gps.cpp:1378] aidIni(): Will send AID_INI
[ 12237][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 237188000 lon: 85618329 lat: 499165846 height: 157607 hMsl 110045, hAcc 64752, vAcc 45787 delay 186ms
[ 12253][I][gps.cpp:1293] handleUbxNavTimeGps(): TIMEGPS: iTOW: 237188000, fTOW: -432948, week 2343, leapS: 18, valid: 0x07 (TOW WEEK UTC), tAcc 407ns, DATE: 2024-12-03T17:53:08, delay 202ms

Versuch 1

[ 12225][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 237096000 lon: 85615441 lat: 499165358 height: 162917 hMsl 115356, hAcc 493852, vAcc 176803 delay 177ms
[ 12241][I][gps.cpp:1293] handleUbxNavTimeGps(): TIMEGPS: iTOW: 237096000, fTOW: -460075, week 2343, leapS: 18, valid: 0x07 (TOW WEEK UTC), tAcc 1179ns, DATE: 2024-12-03T17:51:36, delay 193ms
[ 12259][I][gps.cpp:650] addStatisticsMessage(): New: readGPSData(longDelay: 167ms received 214(214) in 44ms)
[ 12269][W][Wire.cpp:301] begin(): Bus already started in Master Mode.
[ 12349][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x0106 took 5ms
[ 12361][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x0106 took 5ms
[ 13112][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 237097000 lon: 85615169 lat: 499165398 height: 162917 hMsl 115355, hAcc 494603, vAcc 176803 delay 3ms
[ 13128][I][gps.cpp:1293] handleUbxNavTimeGps(): TIMEGPS: iTOW: 237097000, fTOW: -459785, week 2343, leapS: 18, valid: 0x07 (TOW WEEK UTC), tAcc 1180ns, DATE: 2024-12-03T17:51:37, delay 19ms
[ 13146][I][gps.cpp:1312] handleUbxNavTimeGps(): TIMEGPS set: 1970-01-01T00:00:13 -> 2024-12-03T17:51:36
[ 13155][I][gps.cpp:650] addStatisticsMessage(): New: TIMEGPS set: 1970-01-01T00:00:13 -> 2024-12-03T17:51:36 delay 19ms. tAcc:1180ns
[ 13202][D][gps.cpp:751] hasFix(): Got location...
[ 13240][E][gps.cpp:1029] parseUbxMessage(): ACK overrun had ack: 1 for 0x0106
[ 13252][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x0106 took 12ms
[ 13264][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x0106 took 5ms
[ 13276][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x1606 took 5ms
[ 13289][D][gps.cpp:1270] parseUbxMessage(): CFG_SBAS
[ 13294][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x1606 took 11ms
[ 14111][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 237098000 lon: 85614898 lat: 499165437 height: 162917 hMsl 115355, hAcc 495830, vAcc 176803 delay 3ms
[ 14128][I][gps.cpp:1293] handleUbxNavTimeGps(): TIMEGPS: iTOW: 237098000, fTOW: -459498, week 2343, leapS: 18, valid: 0x07 (TOW WEEK UTC), tAcc 1181ns, DATE: 2024-12-03T17:51:38, delay 20ms
[ 14425][D][gps.cpp:1087] parseUbxMessage(): MON-VER SW Version: ROM CORE 3.01 (107888), HW Version 00080000, len 160

Versuch 2:

[ 12215][I][gps.cpp:1378] aidIni(): Will send AID_INI
[ 12221][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236969000 lon: 85619744 lat: 499166968 height: 138659 hMsl 91098, hAcc 62808, vAcc 44412 delay 184ms
[ 12237][I][gps.cpp:1293] handleUbxNavTimeGps(): TIMEGPS: iTOW: 236969000, fTOW: -497408, week 2343, leapS: 18, valid: 0x07 (TOW WEEK UTC), tAcc 405ns, DATE: 2024-12-03T17:49:29, delay 200ms

Versuch 1 (26 ms)

[  1850][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236717012 lon: 85619407 lat: 499165333 height: 146699 hMsl 99138, hAcc 39367, vAcc 27836 delay 14ms
[  2279][D][gps.cpp:1264] parseUbxMessage(): INF 516 message: ANTSTATUS=INIT
[  2286][I][gps.cpp:650] addStatisticsMessage(): New: NTC: ANTSTATUS=INIT
[  2792][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236718000 lon: 85619407 lat: 499165333 height: 146699 hMsl 99138, hAcc 39866, vAcc 28189 delay 3ms
[  3281][D][gps.cpp:1264] parseUbxMessage(): INF 516 message: ANTSTATUS=OK
[  3288][I][gps.cpp:642] addStatisticsMessage(): Update: NTC: ANTSTATUS=OK
[  3792][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236719000 lon: 85619407 lat: 499165333 height: 146699 hMsl 99138, hAcc 41350, vAcc 29239 delay 3ms
[  4793][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236720000 lon: 85619407 lat: 499165333 height: 146699 hMsl 99138, hAcc 43719, vAcc 30914 delay 3ms
[  5792][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236721000 lon: 85619407 lat: 499165333 height: 146699 hMsl 99138, hAcc 46838, vAcc 33120 delay 3ms
[  6559][W][gps.cpp:508] sendAndWaitForAck(): Retry to send 0x0406 after 5000ms.
[  6572][D][gps.cpp:1264] parseUbxMessage(): INF 516 message: Resetting GNSS
[  6847][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236722020 lon: 85619407 lat: 499165333 height: 146699 hMsl 99138, hAcc 57767, vAcc 40848 delay 3ms
[  7280][D][gps.cpp:1264] parseUbxMessage(): INF 516 message: ANTSTATUS=INIT
[  7287][I][gps.cpp:642] addStatisticsMessage(): Update: NTC: ANTSTATUS=INIT
[  7789][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236723000 lon: 85619407 lat: 499165333 height: 146699 hMsl 99138, hAcc 58103, vAcc 41085 delay 3ms
[  8281][D][gps.cpp:1264] parseUbxMessage(): INF 516 message: ANTSTATUS=OK
[  8288][I][gps.cpp:642] addStatisticsMessage(): Update: NTC: ANTSTATUS=OK
[  8788][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236724000 lon: 85619407 lat: 499165333 height: 146699 hMsl 99138, hAcc 59125, vAcc 41808 delay 3ms
[  9790][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236725000 lon: 85619407 lat: 499165333 height: 146699 hMsl 99138, hAcc 60800, vAcc 42992 delay 3ms
[ 10635][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236726000 lon: 85619407 lat: 499165333 height: 146699 hMsl 99138, hAcc 63076, vAcc 44601 delay 3ms
[ 11155][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236726500 lon: 85444507 lat: 499295321 height: 146699 hMsl 99142, hAcc 26494576, vAcc 100041 delay 3ms
[ 11567][W][gps.cpp:508] sendAndWaitForAck(): Retry to send 0x0406 after 5000ms.
[ 11575][E][gps.cpp:513] sendAndWaitForAck(): Failed to send. 0x0406 NAK: 0 after 10016ms
[ 11642][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236727000 lon: 85395579 lat: 499332685 height: 148731 hMsl 101174, hAcc 21156438, vAcc 167844 delay 3ms
[ 11807][I][gps.cpp:650] addStatisticsMessage(): New: swVersion: ROM CORE 3.01 (107888)
[ 11815][I][gps.cpp:650] addStatisticsMessage(): New: hwVersion: 00080000
[ 11821][I][gps.cpp:650] addStatisticsMessage(): New: romVersion: FWVER=SPG 3.01
[ 11829][I][gps.cpp:650] addStatisticsMessage(): New: extension: PROTVER=18.00
[ 11836][I][gps.cpp:650] addStatisticsMessage(): New: extension: GPS;GLO;GAL;BDS
[ 11843][D][gps.cpp:1087] parseUbxMessage(): MON-VER SW Version: ROM CORE 3.01 (107888), HW Version 00080000, len 160
[ 11855][D][gps.cpp:1273] parseUbxMessage(): CFG_NAV5
[ 11860][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x2406 took 76ms
[ 11876][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x3406 took 9ms
[ 11932][I][gps.cpp:331] enableAlpIfDataIsAvailable(): Enable ALP
[ 11942][E][gps.cpp:1039] parseUbxMessage(): ACK-NAK overrun had ack: 1 for 0x3406
[ 11949][E][gps.cpp:1041] parseUbxMessage(): ACK-NAK 0x0106
[ 12043][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x0106 took 5ms
[ 12207][W][Wire.cpp:301] begin(): Bus already started in Master Mode.
[ 12292][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x0106 took 9ms
[ 12305][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x0106 took 5ms
[ 12637][I][gps.cpp:650] addStatisticsMessage(): New: TimeToFix: 4500ms
[ 12644][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236728000 lon: 85275549 lat: 499422858 height: 149533 hMsl 101980, hAcc 18406960, vAcc 145487 delay 9ms
[ 12661][I][gps.cpp:1293] handleUbxNavTimeGps(): TIMEGPS: iTOW: 236728000, fTOW: 421125, week 2343, leapS: 18, valid: 0x07 (TOW WEEK UTC), tAcc 42399ns, DATE: 2024-12-03T17:45:28, delay 26ms
[ 12678][I][gps.cpp:1312] handleUbxNavTimeGps(): TIMEGPS set: 1970-01-01T00:00:12 -> 2024-12-03T17:45:28
[ 12688][I][gps.cpp:650] addStatisticsMessage(): New: TIMEGPS set: 1970-01-01T00:00:12 -> 2024-12-03T17:45:28 delay 26ms. tAcc:42399ns
[ 12734][E][gps.cpp:1029] parseUbxMessage(): ACK overrun had ack: 1 for 0x0106
[ 13633][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236729000 lon: 85262324 lat: 499432663 height: 149573 hMsl 102020, hAcc 18451086, vAcc 145452 delay 3ms
[ 13650][I][gps.cpp:1293] handleUbxNavTimeGps(): TIMEGPS: iTOW: 236729000, fTOW: 421022, week 2343, leapS: 18, valid: 0x07 (TOW WEEK UTC), tAcc 42477ns, DATE: 2024-12-03T17:45:29, delay 20ms
[ 14634][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236730000 lon: 85249098 lat: 499442468 height: 149615 hMsl 102062, hAcc 18521418, vAcc 145380 delay 3ms
[ 15666][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236731000 lon: 85619504 lat: 499168724 height: 170028 hMsl 122466, hAcc 321344, vAcc 285359 delay 3ms
[ 16637][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236732000 lon: 85618736 lat: 499167972 height: 176846 hMsl 129285, hAcc 290761, vAcc 206775 delay 3ms
[ 16687][D][gps.cpp:751] hasFix(): Got location...
[ 16729][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x0106 took 4ms
[ 16741][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x0106 took 5ms
[ 16753][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x1606 took 5ms
[ 16766][D][gps.cpp:1270] parseUbxMessage(): CFG_SBAS
[ 16771][D][gps.cpp:511] sendAndWaitForAck(): Success in sending. 0x1606 took 11ms
[ 17639][D][gps.cpp:1158] parseUbxMessage(): POSLLH: iTOW: 236733000 lon: 85616885 lat: 499166826 height: 183813 hMsl 136252, hAcc 162386, vAcc 153109 delay 3ms
[ 17902][D][gps.cpp:1087] parseUbxMessage(): MON-VER SW Version: ROM CORE 3.01 (107888), HW Version 00080000, len 160
[ 17913][D][gps.cpp:1273] parseUbxMessage(): CFG_NAV5
#7

Danke für die Daten - ich muss mal schauen was da zu so verhältnismäßig langer Verzögerung führen kann. Ich vermute, dass mehrere Nachrichten im Block verarbeitet werden. Beim warten auf den GPS fix sind - wenn ich mich recht erinnere - auch noch ein paar andere Nachrichtentypen aktiviert. Eventuell sollte ich da die Frequenz runter schrauben und den Fokus zunächst auf die zum setzen der Uhrzeit nötige TIMEGPS legen.

Zum 0x0406 gibt es zumindest bei den neueren Modulen keine Bestätigung. Ich schau da nochmal wie das „normale“ Modul sich verhält und pass das eventuell an. Wir hatten die Wartezeit hier aus anderen Gründen schon mal erhöht.

#8

Meine Beobachtung ist, dass einmal pro Sekunde ein Block mit einer handvoll Nachrichten kommt.
Während dieses Blocks nimmt der delay mit jeder Nachricht zu. TIMEGPS ist die letzte Nachricht und hat dann den größten delay.

zB so:

[  2629][V][gps.cpp:878] encode(): Expecting UBX Payload: 52 bytes
[  2636][D][gps.cpp:1016] parseUbxMessage(): parseUbxMessage: delay 8ms
[  2642][V][gps.cpp:1113] parseUbxMessage(): SOL: iTOW: 420361000, gpsFix: 0, flags: 5c, numSV: 0, pDop: 9999.

[  2652][V][gps.cpp:878] encode(): Expecting UBX Payload: 28 bytes
[  2659][D][gps.cpp:1016] parseUbxMessage(): parseUbxMessage: delay 31ms
[  2666][D][gps.cpp:1149] parseUbxMessage(): POSLLH: iTOW: 420361000 lon: xxx lat: xxx height: xxx hMsl 191760, hAcc 35454, vAcc 25070 delay 31ms

[  2680][V][gps.cpp:878] encode(): Expecting UBX Payload: 18 bytes
[  2686][D][gps.cpp:1016] parseUbxMessage(): parseUbxMessage: delay 58ms
[  2693][V][gps.cpp:1105] parseUbxMessage(): DOP: iTOW: 420361000, gDop: 9999, pDop: 9999, tDop: 9999, vDop: 9999, hDop: 9999, nDop: 9999, eDop: 9999

[  2706][V][gps.cpp:878] encode(): Expecting UBX Payload: 36 bytes
[  2713][D][gps.cpp:1016] parseUbxMessage(): parseUbxMessage: delay 85ms
[  2720][V][gps.cpp:1140] parseUbxMessage(): VELNED: iTOW: 420361000, speed: 0 cm/s, gSpeed: 0 cm/s, heading: 0, speedAcc: 450, cAcc: 18000000

[  2732][V][gps.cpp:878] encode(): Expecting UBX Payload: 16 bytes
[  2739][D][gps.cpp:1016] parseUbxMessage(): parseUbxMessage: delay 111ms
[  2745][I][gps.cpp:1281] handleUbxNavTimeGps(): TIMEGPS: iTOW: 420361000, fTOW: 130575, week 2343, leapS: 18, valid: 0x07 (TOW WEEK UTC), tAcc 1258ns, DATE: 2024-12-05T20:46:01, delay 111ms

Wenn dann der nächste Nachrichten-Block kommt wird handleStart neu gesetzt und wir starten wieder mit einem niedrigen delay.

Wozu ist eigentlich folgender Code?

  if (mSerial.available() == 0) {
    mMessageStarted = millis(); // buffer empty next message might already start now
  }

Soweit ich das sehe hat das Auswirkungen auf die Berechnung von lastCallDelayMs, aber den Kommentar dazu verstehe ich nicht.

#9

Danke fürs tiefer Reitschauen. Es ist etwas ungeschickt, dass die Nachricht mit der wir die Uhr stellen ausgerechnet als letzte kommt.

Wenn bereits Daten an der Seriellen anliegen kann ich nicht sagen, wann die tatsächlich gesendet wurden. Nur wenn der Puffer leer ist weiß ich, die nächsten Daten sind nicht älter als der aktuell millis Zähler. Das hat Einfluss auf die delay Berechnung und ist so gewollt. Es kann gut sein, das das Modul einer anderen Generation hier ein anderes Timing-Verhalten hat. Das Debuglog tut sicher auch etwas dazu beitragen.

#10

Ich frage mich ja nach wie vor, wie relevant es wirklich ist, die Zeit auf genauer als eine Sekunde einzustellen, aber gut versuchen wir es.

Können wir nicht einfach den delay zur empfangenen GPS Zeit dazu addieren, wenn wir setClockByGps() aufrufen?

Also hier etwas wie:

    delayNs = delayMs * 1000 * 1000 
    TimeUtils::setClockByGps(message.iTow, message.fTow+delayNs, message.week);

Und dann wäre es doch für die Genauigkeit auch egal, wie groß der delay ist. Oder übersehe ich da was?

#11

@andreas kann ich dir irgendwie mit konkreten Messungen weiterhelfen? Meine Vermutung wäre: 250ms wäre noch im Rahmen für videosynchronisation, und damit wären wir safe gegen das GPS timing. In @jens erstem Vorschlag hat ja schon die Rückkehr zu 80ms geholfen, das wären bei Videosynchronisation unter 2 frames (angenommen PAL 25 Bilder/s).

Ist auch ein wenig ein Heisenbug: Der Wert ist leider nicht immer doof - dann wäre ja auf den Workshops schnell aufgefallen, dass die GPS nie funktionieren. Aber offenbar gibts bedingungen unter denen die Kombination GPS-Module + OpenBikeSensor dauerhaft (oder zumindest über mehrere-viele starts) in den zustand kommt.

#12

Die 20ms wären gerade ein Frame. Aber das hilft ja nicht, wenn es dadurch keinen Sync gibt. Betrifft das großflächig neuere GPS Module? Ich hatte das sehr spezifisch auf das „damals“ verbreitete Modul optimiert. Heute würde ich eher einen Ansatz wählen, der auch das Modul des OBS pro abdeckt. Da gibt es aber deutliche Unterschiede…

Ich hab heute eine Änderung auf 200ms eingebaut.

1 „Gefällt mir“
#13

Das betrifft einige der ca. 80 OpenBikeSensoren, die dieses Jahr im Rahmen von Workshops gebaut wurden, alle mit den potentiell betroffenen Modulen. deshalb hilft deine Änderung von heute dann schon einigen. Händisch hatte ich schon mit @jens vorschlag getestet, von daher würde ich, wenn der GitHub Workflow durch ist noch die Variante aus dem Repo testen.

Als nächstes hab ich noch einen patchvorschlag, um auf den neo8m die Galileosatelliten mit anzuschalten, den würde ich dann aber als PR machen, wenn der Bugfix durch ist.

#14

Ich hab jetzt mal die Versionen der Module die ich hier habe ausgelesen. Die Versionen sieht man auch auf der „About“ Seite oder im CSV File in den debug Infos. Aktuell ist der GPS Code mittels ifdefsunterschiedlich vom OBS pro und vom klassischen OBS. Ich hoffe, das so anpassen zu können das der selbe code auf beiden Varianten zum Einsatz kommt. Dann kann der klassische OBS auch mit dem 10er Modul umgehen.

Ich hab folgende Versionen in meiner Kiste gefunden:

  • swVersion: 5.0 (28483) / hwVersion: 00040005
  • swVersion: 6.02 (36023) / hwVersion: 00040007
  • swVersion: 7.03 (45969) / hwVersion: 00040007

Mein test OBS pro:

  • swVersion: ROM SPG 5.10 (7b202e) / hwVersion: 000A0000 / romVersion: FWVER=SPG 5.10 / extension: PROTVER=34.10 / extension: MOD=MAX-M10M

In der FW haben wir viele Optimierungen für die älteren Module, in dem Umfang wird das sicher nicht für die neuen Module umgesetzt werden - ich hoffe, dass es auch nicht nötig ist.

#15

Aus meinem NEO-M8N-0-10 kommt folgendes:

swVersion: ROM CORE 3.01 (107888)
hwVersion: 00080000
romVersion: FWVER=SPG 3.01
extension: PROTVER=18.00
extension: GPS;GLO;GAL;BDS

#16

Bei der Zeit geht es auch darum mit anderen Systemen synchronisieren zu können.

Leider ist beim delay nicht klar wann die Nachricht tatsächlich gesendet wurde. Sie ist maximal „delay“ alt kann aber auch gerade erst gesendet worden sein.

#17

Bei der synchronisation ist das glaube ich eigentlich so gedacht, dass man den LED pin als interrupt nutzt (der auf den ublox modulen die LED blinken lässt). Wenn man eine genaue Zeitquelle haben will. TIMEGPS sagt einem dann genau, welche Zeit beim letzten Blinken des Pins war. (also - wir können das natürlich nicht machen, weil der interrupt pin nich tnach außen geführt ist. Aber das könnte der grund sein dass es für die ublox leute egal ist, dass die TIMEGPS nicht als erste rausgeschickt wird).

Evtl. können wir die TIMEGPS nachricht pollen, anstatt sie im sekündlichen Intervall mit zu bestellen. Wenn sie nicht in einem burst of messages kommt hat sie mutmaßlich weniger delay? Aus dem Datasheet:

32.5.2 Polling Mechanism
All messages that are output by the receiver in a periodic manner (i.e. messages in classes MON,
NAV and RXM) and Get/Set type messages, such as the messages in the CFG class, can also be
polled.
The UBX protocol is designed so that messages can be polled by sending the message required to
the receiver but without a payload (or with just a single parameter that identifies the poll request).
The receiver then responds with the same message with the payload populated.

… Oder wir pollen immer dann, wenn beim letzten Versuch der Delay zu hoch war noch mal.

#18 
hwVersion: 00080000
romVersion: FWVER=SPG 3.01
extension: PROTVER=18.00
extension: GPS;GLO;GAL;BDS
#19

Hallo zusammen, ich hab im nächsten Prerelease noch ergänzt, dass OBS mit Neo8m auch Galileo mitbenutzen - was hoffentlich die GPS-Qualität verbessert. Testweise hab ich sowohl mit Neo8m als auch Neo6m mit dem neusten Firmware prerelease v0.21.928 erfolgreich einen Fix bekommen.

#20

Noch eins gefunden:

swVersion: 1.00 (59842)
hwVersion: 00070000
romVersion: PROTVER 14.00
extension: GPS;SBAS;GLO;QZSS