Rund um das Telemetriemodul: Infos, Nutzen, Hacks...

[Klaona]

Danke Pfriemler,
so langsam werden es immer mehr Daten.
Ziel ist es, einen kompletten Block einzulesen und verständlich übersetzt auszugeben

Noch schöne Weihnachtsfeiertage

Gruß Klaona

[Gerold]

Die gesendeten Daten bestehen immer aus einem Protokoll Header gefolgt von 1 bis n Reports, wobei die Reports immer gleich aufgebaut sind. Der Protokoll Header besteht je nach Einstellung des MODE Parameters entweder aus 4 oder 11 Bytes, der Unterschied entsteht durch bei MODE=4 mit gesendete IMEI (7 Bytes).

Der Aufbau der Reportdaten kann durch den PROT Parameter beeinflusst werden. Es lassen beim Silence (und vermutlich auch beim Seat) nicht alle "Module" aktivieren, die in den Infos zum Report X erwähnt werden. Vermutlich hat Silence aus Speicherplatzmangel Überflüssiges aus der Astra Firmware entfernt, um Platz für die eigene Entwicklung zu schaffen. So ist es mir z.B. nicht gelungen, die Daten des Beschleunigungssensors in die Daten zu integrieren.

Wenn ich meinen eigenen Server, der die Astra Daten verarbeitet, in den Debug Modus versetze, erhalte ich u.A. Folgendes:

.......
[INFO_|09/04 17:26:01|TrackClientPacketHandler.getActualPacketLength:501] Protocol: Z
[INFO_|09/04 17:26:01|TrackClientPacketHandler.getActualPacketLength:508] Packet length: 105
[INFO_|09/04 17:26:01|TrackClientPacketHandler.getHandlePacket:528] Recv[HEX]: 5A0069010123456789ABCD1700010000002F4C7D1F051001000000183C624C7D1F0402FAF27B007DFFD90000760400000000000000000001DD151D1D01E4FFF90000106F000001C2015E0017FFFFFFFF00000000000145F8000B1A731C030000049E000001111254F7
[INFO_|09/04 17:26:01|TrackClientPacketHandler.debugMsg:1366] packet length=105
[INFO_|09/04 17:26:01|TrackClientPacketHandler.debugMsg:1366] numOfReport=1
[INFO_|09/04 17:26:01|TrackClientPacketHandler.debugMsg:1366] Imei=0123456789ABCD
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] SQN=23 (sequenz number)
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] MM=00010000002F (modul mask)
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] RTC=2020/09/04 15:25:57 GMT
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] R=10010000 (reason flag)
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] S=00000018 (status flag)
[INFO_|09/04 17:26:01|TrackClientPacketHandler.debugMsg:1366] module_device_power=3C62
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] P=12.0V
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] B=98.0%
[INFO_|09/04 17:26:01|TrackClientPacketHandler.debugMsg:1366] module_gps_data=4C7D1F0402FAF27B007DFFD9000076040000
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] GT=2020/09/04 15:25:56 GMT
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] LAT=50.000507
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] LON=8.257497
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] SPD=0.0kmh (current speed)
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] M=0.0kmh (max speed)
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] HD=236.0deg (heading)
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] ALT=80.0m (altitude)
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] JD=0.0km (journey distance)
[INFO_|09/04 17:26:01|TrackClientPacketHandler.debugMsg:1366] module_digitals=00000000
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] IOS=0000
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] IOC=0000
[INFO_|09/04 17:26:01|TrackClientPacketHandler.debugMsg:1366] module_analogues=00000001
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] A1=0.0
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] A2=1.0
[INFO_|09/04 17:26:01|TrackClientPacketHandler.debugMsg:1366] module_signal_quality=DD
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] SS=-61dBm (signal strength)
[INFO_|09/04 17:26:01|TrackClientPacketHandler.outputRawData:1360] SC=13 (sattellite count)
[INFO_|09/04 17:26:01|TrackClientPacketHandler.debugMsg:1366] module_silence_s01=151D1D01E4FFF90000106F000001C2015E0017FFFFFFFF00000000000145F8000B1A731C030000049E0000011112
.....

Der Unterschied in der Paketlänge von hier 105 Bytes zu @Pfriemlers 94 Bytes ergibt sich hier durch die. neben der IMEI, auch noch zusätzlich gesendeten Daten der analogen Ausgänge (4 Bytes).

In @Pfriemlers SCUTUM UIDS könnten die Bytes 54-65 ein BMS UID analog zur ECU UID in den Bytes 18-29 enthalten.

[Pfriemler]

@klaona: Danke, dito.
@Gerold: Ist auch meine Vermutung: wenn es einen Firmware-Hash vom BMS gibt, sollte auch eine ID irgendwo sein. Ich habe aber nirgends Hinweise in den Logs gefunden.

GNSS: T1 T2 T3 T4 B1 B2 B3 B4 L1 L2 L3 L4 xx xx xx xx xx xx
mit
T1-T4 = vier Byte als Dezimalzahl: Anzahl der Sekunden seit 1.1.1980 00:00 (nein, NICHT UTC/Unix).
Nein, die Daten, die ich da errechne, sind doch falsch. Richtig scheint der 6.1.1980 0:00 zu sein - dem Startzeitpunkt und Zählbeginn der GPS-Wochen, nachzulesen beim Thema "GPS week rollover", wo eine zu kleine Speichervariable für einen vorzeitigen Überlauf und damit unkorrekte Daten sorgt (offtopic: Ich habe selbst noch ein paar uralte GPS-Empfänger hier, und leider ist auch einer davon betroffen)

B1-B4 = vier Byte als Dezimalzahl: Breitengrad * 1.000.000
L1-L4 = vier Byte als Dezimalzahl: Längengrad * 1.000.000
die nächsten 6 Bytes sind ... (klaube ich aus Gerolds Post )

(konstruiertes) Beispiel (edit: Zeit korrigiert, Rechenfehler):
"GNSS: 50 D9 E9 A0 03 1E AB 65 00 C5 BF A9 00 00 00 00 00 00" - müsste vor kurzem irgendwo im Caputher See bei Potsdam gewesen sein...

[Gerold]

journey distance; 2Byte, der Rest (current speed bis altitude) je 1 Byte.

current speed, max speed und heading = Wert * 2, altitude = Wert * 20 und journey distance = Wert /10.

[Pfriemler]

Ausgehend von Gerolds Zitat habe ich mal ein bisschen weitergewurschtelt. Die Struktur des Protocol X ist ja in Ansätzen ersichtlich, also habe ich mal einen 25-Minuten-Fahrtmitschnitt mit insgesamt 134 übertragenen Protokollen gesichtet und zuvor mein Tool so umprogrammiert, dass es künftig ausschließlich vollständige "Protocol X Reports" berücksichtigt (in denen ja der SCUTUM S01 enthalten ist) und dabei ggf. das "Zwischenfunken" anderer Meldungen im Log ignoriert.

Dabei sind mir folgende Zustände aufgefallen

module mask - Festlegung welche der einzelnen Reports Bestandteil des Protocol X werden.
0001 0000 0027 - kein UIDS, kein JNY_STOP
0001 0000 002F - +ANALOGUES (Werte analoger Ausgänge)
0005 0000 0027 - +UIDS
0001 0000 0827 - +JNY_STOP - im Zusammenhang mit reason-flag 1000 0080 (erscheint dann vor SCUTUM S01)

reason flags - Gründe für das Versenden des Reports (aufgetretenes Ereignis)
8000 0000 - "Motion detected" - Roller wurde bewegt. Ja, kommt bei mir zu Beginn der Fahrt fünfmal
0000 0040 - "JNY Start" - Roller wurde eingeschaltet
1000 0000 - "SCUTUM" (mit und ohne UIDS - siehe module mask) - wird so benannt, Auslöser?
0080 0000 - "CANBUS" (Ursache z.B. : erste Aktualisierung der Motor/Inverterparameter, BlinkerLI, BlinkerRe)
0000 0100 - "HEAD" (Änderung der Bewegungsrichtung)
0000 0001 - "TIMED" (zeitlich bestimmte regelmäßige Aussendung, $STIM?)
0010 0000 - "CORNERING MAX" (Änderung der Bewegungsrichtung in starkem Maße - Abbiegen)
1000 0080 - "JNY STOP" (Ausschalten des Rollers, Ende der Fahrt) - beachte 1 am Anfang ??

status flags
0000 1000 - aus, (auch bei Motion detected)
0000 1001 - Zündung an
0001 1001 - xxx1 xxxx wenn bereits ein Bericht in der Warteschlange ist (Report 2,3,... wird generiert)

Bei dieser Gelegenheit bemerkt: einige Zeit nach JNY_START und einem CANBUS Event wird - nach dem Aktualisieren der Motor/Inverterwerte (bis dahin wurden die Werte von vor dem Ausschalten gesendet) - ein SCUTUM-generiertes Protocol gesendet, das einen UIDS-Sektor beinhaltet (auf dieser Fahrt genau 1x), mit den ein paar Beiträgen zuvor erwähnten Beiträgen.
Anbei ein Demoshot eines solchen Protocols dekodiert soweit ich es inzwischen kann.

[Gerold]

Die Interpretation der reason flags gilt diese Liste:

und für die status flags diese:

[Pfriemler]

Danke! Eingepflegt. Fehlt nur noch die module mask
Nach meinen Aufzeichnungen ist bei meinem Roller das Bit 31 der reason flags mit dem Event MOTION belegt. Alles übrige kongruiert mit meinen Erkenntnissen. Nur der letzte gesendete Report hat zwei Reasons (SCUTUM und JNY STOP), das listet auch das Log klarschriftlich auf:

14:45:31.010 REPORT REASON(S):
14:45:31.010 JNY STOP
14:45:31.010 SCUTUM

Im Status ist logischerweise das roaming flag immer aktiv.

[Klaona]

Danke! Eingepflegt. Fehlt nur noch die module mask
Nach meinen Aufzeichnungen ist bei meinem Roller das Bit 31 der reason flags mit dem Event MOTION belegt. Alles übrige kongruiert mit meinen Erkenntnissen. Nur der letzte gesendete Report hat zwei Reasons (SCUTUM und JNY STOP), das listet auch das Log klarschriftlich auf:

Na die Protokoll X fehlt doch auch noch oder hab ich da was übersehen

[Pfriemler]

Na die Protokoll X fehlt doch auch noch oder hab ich da was übersehen

Das Protokoll hat Gerold als vertraulich erhalten und wird es nicht veröffentlichen (und das ist völlig ok so, ich freue mich ja schon was da sonst so bisher durchsickerte). Mir erschließt sich das aber auch so jetzt langsam. Die Reihenfolge der enthaltenen Informationen kannst Du ja aus meinem Screenshot erkennen, bzw. ich habe sie in viewtopic.php?p=293567#p293567 schon skizziert.
Er beginnt mit dem "REPORT No. HDR" aus 17 Byte, bestehend aus einer von 0-255 durchlaufenden Sequenznummer (jeder Bericht bekommt eine höhere Nummer, der Server kann so feststellen, ob alle Protokolle durchgekommen sind), dann der "module mask" (6 Byte), die festlegt, welche Bestandteile nachfolgend aneinandergereiht zu erwarten und zu interpretieren sind, anschließend folgen der Zeitstempel des Reports (4), Grund/reason(4), Status flags(2).
Alle folgenden Bestandteile werden durch die "module mask" festgelegt. Die tatsächliche Reihenfolge entspricht dabei offenbar nicht genau der Reihenfolge von links nach rechts. edit: siehe Folgebeitrag.
Bei einer Interpretation von X muss man also immer wissen, welche Bestandteile enthalten sind, und entsprechende Offsets für die bereits entschlüsselten Sachen vorsehen, sozusagen.
Die im Klarschriftlog enthaltenen Bestandteile reihen sich also bisher zusammen in dieser Reihenfolge (wobei eben nicht alle enthalten sind)
[REPORT No.1 HDR][ModulbatterieInfos][GNSS][DIGITALS][ANALOGUES][SIGNAL QUALITY][JNY STOP][SCUTUM S01][UIDS]

edit:
In JNY STOP (5 Byte) sind die ersten 3 Byte die auf ganze km gerundete GPS-Wegstrecke (Bsp. 1234,7 km > 1235.
Die nachfolgenden beiden dürften die Betriebsstunden des Rollers sein. Im Klarschriftlog werden Minuten angegeben, hier nur die ganzen Stunden.

[Pfriemler]

Nochmal weiter oben gelesen: Gerold meint, ein Protokol Z von Silence besteht aus Protokoll X + Zusätzen.
Ich habe alles nochmal in eine Reihenfolge zu bringen versucht:
Demnach könnte die "module mask" wie folgt aufgebaut sein (von rechts beginnend in 6 Byte, Bits 0-47 gelesen:

0:ModulePower
1:GNSS
2:Digitals
3:ANALOGUES (ist per $PROT bei mir ausgeblendet und erscheint daher nie)
4: (ausgeblendet per Maske)
5:SIGNAL QUALITY
6:GSM NETWORK
7-9: (ausgeblendet per $PROT)
10:??? (bei Gerold aktiv, bei mir nicht)
11:JNY STOP
12-15: (ausgeblendet per $PROT)
16-26: (ausgeblendet per $PROT)
27:??? (ist in meinem $PROT erlaubt, aber noch nie aufgetaucht
28-31: (ausgeblendet per $PROT)
32:SCUTUM S01
33: (ausgeblendet per $PROT)
34:UIDS
35-: (ausgeblendet per $PROT)

Wenn es so stimmt, würde auch die Reihenfolge in den Daten stimmen.

edit 9.1.23: Ich habe noch einen Reportbaustein gefunden: "GSM NETWORK" kommt bei gesetztem Bit 6, besteht aus vier Byte (hier bei mir 01 06 00 03), Bedeutung noch unklar: 0x0106 = 262 (MCC), 0x0003 = 3 (MNC) (danke an Gerold)