Verständnis ALP Data Mechanismus

Design & Entwicklung Firmware
#1

Hallo zusammen,

Ich habe keine Dokumentation gefunden und mir jetzt per Firmware Quelltext lesen zusammengereimt was wir da machen:

Leider fehlt die bei mir:

[ 12197][I][gps.cpp:312] enableAlpIfDataIsAvailable(): Enable ALP
[ 12208][E][gps.cpp:1022] parseUbxMessage(): ACK-NAK 0x0106
[ 12327][I][gps.cpp:631] addStatisticsMessage(): New: swVersion: ROM CORE 3.01 (107888)
[ 12335][I][gps.cpp:631] addStatisticsMessage(): New: hwVersion: 00080000
[ 12341][I][gps.cpp:631] addStatisticsMessage(): New: romVersion: FWVER=SPG 3.01
[ 12349][I][gps.cpp:631] addStatisticsMessage(): New: extension: PROTVER=18.00
[ 12356][I][gps.cpp:631] addStatisticsMessage(): New: extension: GPS;GLO;GAL;BDS
[ 12587][W][Wire.cpp:301] begin(): Bus already started in Master Mode.
[ 13067][E][vfs_api.cpp:105] open(): /sd/aid_ini.ubx does not exist, no permits for creation
[ 13075][E][gps.cpp:1371] aidIni(): Will not send AID_INI - invalid data on SD?

Wie wird die Erzeugt?

#2

Hallo Jens,

das sind 2 unterschiedliche Mechanismen. Die aid_ini.ubx wird mit vom GPS Modul gelieferten Daten erstellt wenn der Fix gefunden wurde und denn regelmäßig aktualisiert. Das sind auch deutlich weniger Daten.

Hintergrund über die Funktionsweise findest Du in der u-blox6_ReceiverDescrProtSpec_(GPS.G6-SW-10018)_Public.pdf Dokumentation.

Wichtig ist zu wissen, dass dies Features des u-blox6 Moduls sind. Das u-blox6 Modul unterstützt lediglich GPS, daher sind in den Daten z.B. keine Glonas Informationen enthalten. AID-ALP (mit den ‚current_14d.alp‘ Daten) wird von diesem Modul nicht genutzt.

Grüße,
Andreas.

1 „Gefällt mir“
#3

Hallo @jens

Falls du mit Blick auf den neo m8n fragst: Ich hatte angefangen ALP für neo8m zu recherchieren, bevor du das Timingproblem gefunden hattest an dem es dann eigentlich lag (weil ich fälschlicherweise davon ausging, dass das Problem tatsächlich sei, dass keine Satelliten gefunden werden).

Ich hatte deshalb AGPS für neo8m schon mal in Python gemacht. Man muss sich da für einen API Key bei ublox registrieren, mit der kostenlosen Variante darf man glaube ich 100k downloads Im Monat machen (das wäre locker genug für OpenBikeSensor).

Falls du da weiter machen willst kann ich dir den Code und API key gern schicken. Der Prozess ist wenn man den API key hergestellt hat denkbar einfach: binary blob runterladen und den gesamten inhalt ohne Änderungen ans m8n schicken (ist schon als ubx nachrichten formatiert).

Aber caveat: AGPS hat an meinen am Rechner mit neo m8n die Time to first fix aber nur um etwa 30% reduziert, deshalb hatte ich das dann nicht weiter verfolgt.

#4

Hallo zusammen,

in diesem Zusammenhang auch noch eine Frage. Ich habe mir diese Änderung des Codes angeschaut: Fix check for ALP data update. · openbikesensor/OpenBikeSensorFirmware@e9cfaaa · GitHub 1) Die zeitgleiche Überprüfung von kleiner und größer 4 Tagen ergibt für mich keinen Sinn. Wenn soll doch nur ab einem gewissen Schwellwert neu geladen werden oder? 2) Könnten wir den Wert nicht generell auf 2 Tage setzen? Wenn ich einen Sensor verleihen möchte, dann mache ich gerne nochmal ein ALP Update und da finde ich 4 Tage unpraktisch.

#5

@gluap @andreas Was ist eure Meinung dazu?

#6

So wie ich die den diff lese wurde die Richtung des vergleichs umgedreh . Das rote ist der alte, falsche Vergleich, das grüne der neue richtige. So weit ich sehe findet derzeit nur der neue Vergleich statt. Zum Schwellwert 4 Tage habe ich keine Meinung. Viel Unterschied sehe ich nicht bei mir durch Alp bei der ttff.

#7

Sorry dauert leider alles länger als ich mir wünschen würde…

Paul hat es schon beschrieben, das ist eine Änderung die gemacht wurde, es sind nicht beide Zeilen aktiv.

Was stört dich an 4 Tagen? Das ALP File enthält Daten für die nächsten 14 Tagen. Ich hänge da auch nicht dran, wenn wir einen Grund haben können wir das auch ändern.

Grüße, Andreas.