Elektroroller-Forum.de

Den OTA-Update gibt es nur bei Seat. Ich hatte neulich bei Silence explizit nach einem OTA Update für mein Astra Modul nachgefragt und daraufhin folgende Mail erhalten:

Good morning,

Thank you for contacting Silence support. To receive the latest updates available for your model, please bring your vehicle to one of our Flagships Stores. Please find below a link to your nearest Silence dealer.

https://www.silence.eco/flagship-store-silence/

Regards.

Gerold hat geschrieben: Mi 14. Dez 2022, 17:21 Den OTA-Update gibt es nur bei Seat. Ich hatte neulich bei Silence explizit nach einem OTA Update für mein Astra Modul nachgefragt ...

Aufgrund der Parallelen bisher gehe ich sehr fest davon aus, dass SEAT am Ende auch nur eine von Silence entwickelte Firmware verteilt. Das $LOAD Kommando wird in der Reference ja beschrieben - jetzt reizt es mich, am 11. Januar nachts einfach einen Logger am Modul mitlaufen zu lassen in der Hoffnung, dass der $LOAD auf der seriellen als Echo ausgegeben wird. Ob das am Ende allgemeingültige Infos liefert, ist dabei fraglich: Vielleicht bekommt jeder Roller über ein präpariertes Kommando genau "seine" Firmware präsentiert (vielleicht wird auch gerade so zwischen den unterschiedlichen Modulen unterschieden) und das wird dann nach Anfrage terminiert. Zumindest die Zeitenblöcke scheinen ja automatisiert vergeben zu werden. Sonst würde es mich nicht wundern, wenn da noch jede Abfrage einzeln von einer Person kontrolliert wird.

Gerold hat geschrieben: Sa 1. Okt 2022, 12:19

Code: Alles auswählen

SCUTUM S01:2A 1F 1D 02 00 FF 97 00 00 10 6F 00 00 03 CA 01 90 39 28 05 52 8A 7E 00 00 00 00 00 00 06 9C 00 00 21 D7 15 04 00 00 19 F0 00 00 02 31 0A

Eine Zusammenfassungder Hexbytes so, wie sie darin enthaltenen Parametern entsprechen, ergibt:

Code: Alles auswählen

  a  b  c  d    e    f        g  h  i    j    k  l  m        n  o      p  q      r        s  t  u  v  w    x  y  z  a1 b1 
  2A 1F 1D 0200 FF97 0000106F 00 00 03CA 0190 39 28 05528A7E 00 000000 00 00069C 000021D7 15 04 00 00 19F0 00 00 02 31 0A 

und die Aufschlüsselung:

Code: Alles auswählen

 a) 0x2A = 42 : SoC [%]
 b) 0x1F = 31 : Akku Temp max [°C]
 c) 0x1D = 29 : Akku Temp min [°C] ; der Akku hat 3 Temperatursensoren, hier werden die Min- und Maxwerte ausgegeben
 d) 0x0200 = 512 : Akkuspannung * 10 [V] --> 51,2V
 e) 0xFF97 = -105 : Strom * 10 [A] --> -10,5A; negative Werte: Strom wird entnommen; positive Werte: Laden/Rekuperation
 f) 0x0000106F : BAT ID
 g) 0x00 : Warnflags aus dem BMS
 h) 0x00 : Errorflags aus dem BMS
 i) 0x03CA = 970 Motortemp * 10 [°C] --> 97,0°C
 j) 0x0190 = 400 Inverter Temp * 10 [°C] --> 40,0°C 
 k) 0x39 = 57 Tachogeschwindigkeit [km/h]
 l) 0x28 = 40 Restreichweite [km]
 m) 0x0552BA7E : irgend ein Zähler, der bei einem Neustart des Moduls auf 0 gesetzt und nur während der Fahrt hochgezählt wird. Was gezählt wird, ist mir nicht bekannt.
 n) 0x00 unklar, da immer 0
 o) 0x00000000 = 0 : Ladeenergie [Ws]
 p) 0x00 : unklar, immer 0
 q) 0x00069C = 1692 : Rekuperationsenergie [Ws]
 r) 000021D7 = 8663 : Energieverbrauch während der Fahrt [Ws]
 s) 0x15 = 21 : Außentemperatur [°C]
 t) 0x04 : Status   00: Zündung aus; 01: BMS an; 02: Zündung an, nicht ready, 03; ready + v=0km/h; 04: v>0km/h  
 u) 0x00 : unklar, da immer 0
 v) 0x00 : dito
 w) 0x19F0 = 6640 : Odometer (Tacho) [km]
 x) 0x00 : wahrscheinlich Fehler aus ECU, Bei einer Motortemp > 100°C wir ein Wert von 0x40 ausgegeben
 y) 0x00 : unklar, da immer 0
 z) 0x02 : Lichtschalter   Bit 0: Blinker links; Bit 1: Blinker rechts; Bit 2: Fernlicht; Bit 3: Fahrlicht, Bit 7: Warnblinker 
 a1) 0x31 : Modus, Seitenständer und Rückwärtsgang
 b1) 0x0A : unklar, hängt aber mit 31 zusammen 

Und hier mal die Ansicht von unserer App (MacBook Prog). Werte von Gerold
viewtopic.php?f=128&t=32163&start=20

Ist erst mal die 1.Version, es wird nur der String in die Kommandozeile kopiert, der erst erfolgt durch das Program. Werte die noch nicht bekannt sind, werden nicht angezeigt.

sieht erstmal hübscher aus als meines (Arbeitsversion, nimmt ganze Dateien). edit: habe nochmal nachgebessert, verwendet eine Definitionsdatei für die Auswertung, bei der ich dann die im übernächsten Beitrag besprochene Änderung beim ODO einfach realisieren konnte.
Vorletzte Zeile habe ich anders: Bit 2 (von 1-8) ist Blinker rechts, Fernliicht wäre Bit 3 (Wert 4).

Ziel sollte es sein, einen ganzen Block Daten mit Hilfe des Prog. schnell umzuwandeln.

Für Korrekturen von Daten bin ich absolut offen, genau wie für weitere Anhaltspunkte der Report und Protokoll Daten.
Unbekannte Werte sind nur ausgeblendet, wenn bekannt, kommen sie mit in die Ansicht.

Allen noch einen schönen Adventssonntag.

Bei den SCUTUM S01 Daten ist mir aufgefallen, dass ich für die Odometer Werte nur 2 Hexbytes vorgesehen habe. Mit 2 Hexbytes können aber nur Werte bis 0xFFFF = 65535 km dargestellt werden, was sicherlich von einigen S01/Mo Fahrern überschritten werden dürfte. Für den Odometer müssten daher mindestens 3, wenn nicht sogar 4 Bytes veranschlagt werden, d.h. v) und w), evtl. sogar u), v) und w) in der obigen Darstellung können zu einem Werte zusammengefasst werden.

Weiterhin habe ich noch mit dem PROT Parameter experimentiert. Mit dem zweiten Wert des Parameters (<protokoll-mask>) wird bestimmt, welche Daten das Modul versendet. Im Gegensatz von dem Wert von @Pfriemler und @Klaona (55968794727) war in meinem Modul werksseitig ein Wert von 4496296047 eingestellt, Ändere ich diesen Wert auf 55968794727, wird bei mir im Log des Moduls noch eine SCUTUM UIDS Struktur angezeigt und diese auch mit den übrigen Daten versendet. Diese Struktur hat bei mir eine Länge von 46 Bytes und ist wie folgt aufgebaut: Das erste Byte ist entweder 0x00 oder 0x40 (Bedeutung unbekannt), die nächsten 17 Bytes enthalten die VIN. Dann folgen 12 mal eine 0x00, darauf die Akku ID mit 4 Bytes und abschließend noch 12 mal die 0x00. Insgesamt werden dann 147 Bytes versendet, diese sind aber immer noch weniger als die 200 Bytes, die @Priemlers Modul sendet. In @Klaonas Problemroller scheint aber trotz eines Werts von 55968794727 im Prot Parameter, die SCUTUM UIDS Struktur zu fehlen.

@Gerold
Meine SCUTUM UIDS Struktur hat eine Länge von 106 Bytes und fängt mit 0x55 an. die 0x55 (U) gehört bereits wie die nächsten 16 Bytes zur VIN.
Den Rest kann ich nicht deuten

Beim "Problemroller" geht an dieser Stelle die VIN 8 (alles 0x00)

gerade gesehen, ein Protokoll vom 06.12 des "Problemrollers" hat eine SCUTUM UIDS wo die ersten 17 Bytes die VIN enthalten und ebenso eine Länge von 106 Bytes haben

Klaona hat geschrieben: Di 6. Dez 2022, 20:54

Code: Alles auswählen

SCUTUM S01:3A 05 05 02 16 00 00 00 00 4D 87 40 00 00 FA 00 50 00 3C 00 00 00 00 00 8E 75 28 00 00 00 00 00 00 00 03 03 00 00 00 0A 8C 00 01 00 00 00 
REPORT No.1 HDR:1E 00 01 00 00 00 27 50 BA 0F 15 10 00 00 00 00 08 
Protocol X Report No.1:PKT HDR:5A 00 5E 01 
CRC: E2 B1
sending [AT+QISEND=0,94]
[
> ]
Socket write SEND OK
94 bytes sent

Das ist von dem Roller mit dem Problem, wie bereits geschrieben, bis auf die Daten der Batterie, wird ja alles andere ans Handy geliefert
Der Roller ohne Probleme wurde etwa 1 Jahr später beim gleichen Händler gekauft

Wie man diesem Log entnehmen kann, werden hier nur 94 Bytes gesendet, da sind die SCUTUM UIDS mit Sicherheit nicht enthalten.

aus meiner log vom 06.12. hab da 3 Logs gemacht. Die VIN ist von mir hier geändert
steht ein paar Zeilen weiter

Ich habe in ein paar ruhigen Minuten der letzten zwei Wochen mal meine bisherigen (nicht sehr unfangreichen) Logs gesichtet und dabei ist mir aufgefallen, dass der letzte UIDS-Eintrag am 12.10.22 war - einige Tage nach meinen Bluetooth-Koppelversuchen und auch einige Tage nach (!) dem ersten Auftreten der ersten Verzögerungen in der Anzeige der Daten, auch einige Tage nach (!) dem (bisher einzigen) $BOOT bei mir. Aber seither nicht mehr. Meine Reports fallen seither allesamt kleiner aus (94 statt 200 Byte). Seit dieser Zeit bekomme ich eben auch ständig diese "Seit mehr als 15 Minuten nicht mehr synchronisiert"-Meldungen.

Wenn das Wetter besser mitspielt, werde ich wieder einen Log ziehen und dabei den Roller einmal ein- und wieder ausschalten, um zu sehen, ob dann wieder eine UIDS generiert wird - weil genau durch diese Prozedur die Synchronisierung immer wieder für ein paar Stunden funktioniert.

Weiterhin fasse ich hier mal das Ergebnis meiner eher oberflächlichen Analysen zusammen:
In Vorbereitung eines zu sendenen Reports stellt das Astramodul offenbar einige Daten zusammen und "postet" das auch. Versendet wird dann nur ein "Protocol X Report No.[x]", wobei [x] hochzählt, insbesondere wenn sich mehrere zu sendenden Reports in einer Warteschlange befinden, was hier nachvollzuiehbar passiert, wenn das Modul bootet und diverse Berichte anfallen, bevor das Mobilfunkteil sendebereit ist.
Dieser Bericht setzt sich (n.m.E.) aus den zuvor generierten einzelnen "Posts" wie folgt zusammen:
a) "REPORT No.[x] HDR" (17 Bytes)
b) 1-Byte-Wert für Modul-Versorgungsspannung / 5 (in V) (Bsp: 0x3C => 60/5=12V, 0x3D => 61/5=12,2V)
c) dem ersten Byte von "POWER:" (das zweite ist mal 0x50, mal 0x00, mal 0x05): als Dezimalwert Ladezustand des modulinternen Akkus.
d) "GNSS:" (18 Byte)
e) "DIGITALS:" (4 Byte), bei mir bisher immer "0x00 0x00 0x00 0x00"
edit2: in einem früheren Post von Gerold folgt hier offenbar "ANALOGUES" (4 Byte), dort mit "0x00 0x00 0x00 0x01"
f) "SIGNAL QUALITY:" (1 Byte), 0xFF wenn Modul noch nicht bereit (abwärts zählend? -dB?)
g) optional: "JNY STOP:" (5 Bytes) - wird zum Ende einer Fahrt generiert und versendet, beinhaltet 3 Byte gerundete GPS-km und 2 Byte Betriebsstundenzähler
h) "SCUTUM S01:" (46 Byte)
i) offensichtlich optional: "SCUTUM UIDS:" (106 Byte)

Die Länge dieses Reports variiert entsprechend je nach enthaltenden Teilen.
Mir ist unklar, wie, der nur gelegentlich enthaltene "JNY STOP" oder auch der ANALOGUES vom folgenden "SCUTUM S01" unterschieden wird.
Die übermittelten einzelnen Bestandteile werden offenbar durch eine Maskierung im Protocol Header festgelegt ...

Generierte, aber nicht übertragene Reports werden zwischengespeichert. Ist das Modul sendebereit, werden (vermutlich) alle anstehenden Reports hintereinander versendet, vorangestellt ein 4-Byte "PKT HDR:" (zumindest beim SEAT Mo), nachfolgend ein "CRC: " mit 2 Bytes.
Der "PKT HDR" setzt sich nach meiner Beobachtung bzw. bestätigend zu @Gerolds Angaben viel weiter vorher zusammen aus
- 0x5A
- 2 Byte hex für die Zahl der Gesamtbytes der Datenübertragung (MSB-LSB)
- 1 Byte für die Anzahl der übermittelten Reports
Auch hier wieder unklar, wie in der Auswertung die 4-Byte PKT HDR von den 10-Byte von @Gerold (inkl. IMEI) unterschieden wird.

Beispiel:
Im Log nach einem $BOOT-Befehl fand ich insgesamt 9 "Protocol X Report No.1" bis "...No.9", 8 davon mit den Bestandteilen a)-f)+h), der 9. inklusive g), 8x88, 1x93 Byte, 4 Byte PKT HDR, 2 Byte CRC = 803 Bytes, so auch gemeldet als "writing 803 bytes to socket 0". Der "PKT HDR" war folgerichtig "0x5A 0x03 0x23 0x09" (803 Bytes, 9 Reports).

Fast vollständig aufgeklärt ist die Struktur von "SCUTUM S01".

Im "SCUTUM UIDS:" konnte ich bisher identifizieren (Byte x-y, Anzahl, Erklärung):
01-17 (17) „Frame ID:“ (VIN)
18-29 (3x4) „S01 ECU UID L:“ + „... M“ + „... H“ (LSB first)
30-49 (20) STM ECU FW Git HASH
50-53 (4) „Battery ID:“ (Dezimalzahl)
54-65 (12) unklar, mglw. BMS-ID
66-85 (20) „STM BMS FW GIT HASH“
86-93 (8) „BMS Sigfox ID (8):“ ??? (immer 0, wie „SIGFOX CAN HEX“)
94-103 (10) hier immer ASCII-Zeichen „NOT_STORED“ (edit: bei klaona "_ qcû°ÀÚ>Z" -??)
104-106 (3) (immer 0)
Auch ich habe wie @klaona also immer 106 Bytes im UIDS, immer beginnend mit der VIN.

In den übrigen Items stochere ich gerade noch herum...