"Lauschangriff" am CAN-Bus - Theorie und Praxis

[Pfriemler]

offtopic zum für SEAT-Fahrer neuen $FIND in Gerolds BT-App: ... müsste man eigentlich im Telemetriefred andocken, aber da war das Thema noch nicht...

Mit der Silence App kann diese Modus für einige Lampen für etwa 8 sec aktivieren, wenn man in der App auf das Dreieck zwischen der Alarm- und Sitzöffnenfunktion drückt. Laut Log des Telemetriemoduls wird damit der in der Commandref nicht dokumentierte Befehl <$FIND,0,19,1,30,1> gesendet.
...
Die Bedeutung der restlichen Parameter habe ich noch nicht herausgefunden.

Also ich habe es nicht ausgestoppt, aber bei der Blinkfrequenz und mitgezählten ~45 Piepsern tippe ich stark darauf, dass die 30 die Sekunden sind, die das Signal ertönen soll. Entsprechend funktioniert $FIND,0,19,1,10,1 deutlich kürzer.
Verwunderlich ist jetzt, dass der so ausgelöste Such-Alarm bei Gerold nach 8 Sekunden gecancelt wird.

$FIND wird bei mir nur bei ausgeschaltetem Roller akzeptiert (liefert sonst $FIND,ER als feedback). Der Roller wird dann eingeschaltet, blinkert wie eingestellt/befohlen und schaltet sich danach wieder ab. In dieser Zeit reagiert er auch erwartungsgemäß auf ein $PBAT,0 zum vorzeitigen Ausschalten.

[Gerold]

Die Ursache der unterschiedlichen Reaktionen des Moduls auf das $FIND Kommando liegt in den unterschiedlichen Firmwareversionen.
Mit der 7.0.39.35 funktioniert $FIND nur bei eingeschaltetem Roller für die Dauer vom 8s, unabhängig vom vorletztem Parameter des Kommandos.
Mit der aktuellen (7.0.66.35) funktioniert das Kommando bei mir so, wie @Pfriemler es beschrieben hat. Der vorletzte Parameter legt hier die Blinkdauer in Sekunden fest.

Ein $FIND,0,19,1,10,1 löst ein Blinken für 10s aus und liefert folgende Logausgabe:

Code: Alles auswählen

$FIND,OK
S01 FIND INITIATE: act-flags 0, loc-flags 13, pre-pwr 1, duration 10s, post-pwr 1
S01 Power on flags: F8
SCUTUM CAN SEND [0x1F0]
DIG-OUT 5 ON
sending [AT+USORD=0,0]
[
+USORD: 0,0

OK
]
ACCEL NORMALISED X:+1 Y:+0 Z:+1
Battery SoC:      87
Battery Max Temp: 12 C
Battery Min Temp: 12 C
Battery Voltage:  54.9 V
Battery Current:  0.0 A
S01 STATUS CHANGED TO: 1
S01 PBAT1 SUCCESS!

[Rudi Ratlos]

Mangels Astra-Modul muss ich mir ja die Daten vom CAN-Bus abkratzen um so was Ähnliches wie Gerold mit seiner BTLE-App hinzubekommen. Im Moment finde ich den aktuellen Stromverbrauch (noch) nicht auf CAN. Weder in den Bytes 6 und 7 der ID 0x181 noch in den Bytes 0 und 1 der ID 0x189 steht irgendwas plausibles, sondern zumeist irgendwas wie 0xf0 0xff, was dezimal 65520 entspräche und somit je nachdem 655,2 oder 6552,0 Ampere. Und so viel Strom liefert mein Akku vermutlich nicht. Kann mir jemand helfen?

Gruß Rudi

[Gerold]

Der Strom wird in "signed integer" ausgegeben, d.h. der Wertebereich liegt zwischen -32768 und 32767 und nicht wie bei "unsigned integer" zwischen 0 und 65535.
Positive Ströme fließen in den Akku hinein (Laden, Reku), negative hinaus.

[Rudi Ratlos]

Der Strom wird in "signed integer" ausgegeben, d.h. der Wertebereich liegt zwischen -32768 und 32767 und nicht wie bei "unsigned integer" zwischen 0 und 65535.
Positive Ströme fließen in den Akku hinein (Laden, Reku), negative hinaus.

Oh Mann, danke, @Gerold!

Sollte mir ja wirklich etwas peinlich sein, aber an die Rekuperation hab ich diesmal tatsächlich gar nicht gedacht

[Rudi Ratlos]

Sodele. Ich hab jetzt mal ein (noch zu erweiterndes) Programm geschrieben, das meine CAN-Logdateien auswertet. Ja, oldschool, ich weiß...

Interessant sind aber die Erkenntnisse hieraus: Der Maximalstrom, der auf dieser Fahrt gezogen wurde (I max, negativ(!)), liegt bei 220A, was bestätigt, dass als Limit der Wert "Current-Limiting(A)" auf Page2 der Votol-Software entspricht.

Der maximal (durch Rekuperation) zurückgewonnene Strom beträgt hier 31.1 Ampere. Beim Laden zieht er übrigens ziemlich haargenau 10 A, was wiederum den hier mehrfach genannten (und von mir gemessenen) ungefähr 600 Watt an der Schukosteckdose entspricht.

Vermutlich ist dieses Programm für euch aber nicht sehr hilfreich, da ihr keinen Raspi mit PiCAN besitzt. Wer doch: PM an mich

Gruß Rudi Ratlos

[Rudi Ratlos]

Update

[error]

Cool, läuft das auf einem Zero W? Was brauche ich als CAN-Interface? Gibt es nur einen PiHat für CAN? So teuer scheint der nicht zu sein. Hatte letztens beim Stöbern einen mit RS485 und CAN entdeckt.

[Rudi Ratlos]

Zum Loggen der Daten benötigst du ein beliebiges CAN-Interface, welches die SocketCAN userspace Utilities und Tools unterstützt
https://github.com/linux-can/can-utils
Das zeichnet per "candump" eine Fahrt, einen Ladevorgang oder sonstwas, was gerade auf dem CAN-Bus passiert, auf.
Genau genommen reicht jede Logadatei aus, die die CAN-Telegramme zeilenweise im Format xxx#b0b1b2b3b4b5b6b7 enthält. xxx ist die CAN-ID (hex) und b0...b7 die jeweiligen Nutzdaten ebenfalls in hex, siehe oberste Zeile im Screenshot.

Später, z.B. zu Hause, lässt du die Raspi-Software auf diese Logdatei los und erhältst im Zeitraffer alle möglichen mehr oder weniger interessanten Ausgaben. Diese Raspi-Software läuft sicherlich auch auf einem Zero, das ist in Standard-C geschrieben.

Gruß Rudi

[Rudi Ratlos]

Wohl die meisten Meldungen in der Statuszeile des Displays werden (teils leicht abgewandelt) als Telegramm mit der CAN-ID 0x310 DLC=8 gesendet. Unverändert im Vergleich zum Display wird "LIM UV ", THRO ERR, "WARN OV " und WARN UV " in der 0x310 übertragen. Folgende Displaymeldungen werden abgewandelt; Non-ASCII-Zeichen habe ich durch ein Fragezeichen (?) ersetzt:

Aus "CHARGING" wird hex 4348415247C94E47, was "CHARG?NG" entspricht.
Aus "CHARGED " wird hex 4348415247C54420, was "CHARG?D " entspricht.
Aus "KPLU$OFF" wird hex 4BF0EC757320CF46, was "K??us ?F" entspricht; diese Meldung wird auch bei jedem Abschalten des Rollers übertragen, aber nicht (mehr) auf dem Display angezeigt.

Weiterhin erscheinen als 0x310er CAN-Telegramm die Meldungen
hex 5349C4455354C14E, ASCII für "SI?EST?N" (was wohl etwas mit dem Seitenständer zu tun hat) und
hex 53C5C1D4204FD045, ASCII für "S??? O?E" (was ich noch gar nicht deuten kann).

Gruß Rudi.