Elektroroller-Forum.de

Gerold hat geschrieben: Sa 1. Jul 2023, 16:06 Über eine ID könne bis zu 8 Datenbytes gesendet werden. Zum Öffnen der Sitzbank muss Byte 0 auf 0x01 gesetzt werden.
Byte 1 = 0x01: Warnblinker an, = 0x00: Warnblinker aus.

Wie könnte man denn die gefundenen Puzzleteile am besten gesammelt dokumentieren? Sende ich irgendwas mit der ID 0x222, sagt mir mein Mo GOODBYE und schaltet sich aus.

Immer schön hier schreiben. Gerold sammelt sicher schon lange alles. Noch fehlt mir ein Sketch zum Schreiben fürs Nachtesten. Final würde ich es am liebsten ins Wiki packen. (Bitte keine vorschnellen Schlüsse oder Zuarbeiten, ich bin dort erst in den ersten Anfängen und tüftele noch an der Menüstruktur. Mittelfristig sollen auch die Infos der gepinnten Technikthreads dort landen.)

Mit der ID 0x2A0 habe ich noch weitere Kommandos über den CAN-Bus getestet. Grundsätzlich können mit einer ID bis zu 8 Datenbytes gesendet werden. Mein S01 reagiert aber nur auf Änderungen in den ersten beiden Bytes.
Mit Byte 0 = 0x01 kann, wie bereits berichtet, die Sitzbank geöffnet werden. Auf andere Werte führen zu keiner Reaktion.

Byte 1 ist ein binärer Schalter. Damit können sämtliche Lampen sowie die Hupe in einen "Blinkermodus" gesetzt werden. In diesem Modus blinkt/hupt die eingeschaltete Lampe/Hupe in der Blinkerfrequenz, bis der Modus durch Setzen des Bytes auf 0x00 wieder ausgeschaltet wird. Alle anderen Lampen werden in dieser Zeit ausgeschaltet, auch der Motor wird, ähnlich wie bei Ausklappen des Seitenständers, deaktiviert. Nach Beendigung des Modus wird der vorherige Zustand wieder hergestellt. Die einzelnen Lampen sind wie folgt zu schalten:

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. Das Modul sendet daraufhin folgende Sequenzen über den CAN-Bus:
Was der erste Befehl mit der ID 0x1F0 bewirkt, ist mir nicht klar, im Telemetrielog findet man dazu den Eintrag : <S01 Power on flags: FD>
Vermutlich wird er aber vom BMS und nicht von der ECU ausgewertet.
Die anderen beiden Kommandos schalten den Blinkermodus ein und aus.

In einer älteren Silence App hatte ich auch den Befehl <$FIND,0,35,1,30,1> gefunden. Damit wird zusätzlich zu den anderen Lampen noch die Hupe dazugeschaltet. er zweite Parameter in dem $FIND Kommando enthält somit dem zweiten Byte der ID 0x2A0 (19d = 0x13, 35d = 0x23). Die Bedeutung der restlichen Parameter habe ich noch nicht herausgefunden.

Uneinholbar, der Mann.
Nu gugge, da isses doch, das per CAN einzuschaltende Bremslicht. Und sogar an einen "Rollerfinder" haben sie gedacht.
0x1.. "alle Lampen aus" bezieht sich dann aber wohl nur auf ... ? Denn Blinker und Tagfahrlicht vorn+hinten werden ja mit dem 0x13 offenbar gesetzt oder haben neu zu setzende Lampen Priorität gegenüber dem "alles aus"?

Ich habe keinen Unterschied zwischen 0x03 und 0x13 gefunden. 0x10 schaltet wohl nur alle bereits eingeschalteten Lampen aus, das Setzen dieses Schalters im $Find ist eigentlich überflüssig. In dem zweiten $Find mit der Hupe hat man es weggelassen.

Gerold hat geschrieben: Mi 5. Jul 2023, 15:54
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. Das Modul sendet daraufhin folgende Sequenzen über den CAN-Bus:

Code: Alles auswählen

10:07:09.507 -> New standard frame from 0x1F0, DLC 1 Data; 0xFD 
10:07:09.707 -> New standard frame from 0x2A0, DLC 2 Data; 0x00  0x13 
10:07:17.772 -> New standard frame from 0x2A0, DLC 2 Data; 0x00  0x00 

Das Dreieck gibt es in der aktuellen IOS Version nicht

Nö, is ja auch SEAT. Deren App fehlt ja im Vergleich zu Silence so ziemlich alles. Bitte nicht durcheinander bringen.
Im "überarbeiteten App"-Thread geht es ausschließlich um Silence, für die Mo-App haben wir noch nichts. Hier geht es um die Hardware, da sind sich die Roller aber sehr gleich.

Zugegeben - hier in diesem Thread ist es etwas ruhig geworden; nach mehrmaliger Erinnerung will ich deshalb hier mal wieder etwas posten: Bald ein Jahr ist es her, dass ich versprochen habe, außer den beiden hier
viewtopic.php?p=290393#p290393
genannten Lösungen zum Lesen und Schreiben auf den CAN-Bus auch noch eine Dritte vorzustellen. Jede dieser Lösungen hat ihre ganz eigenen Vor- und Nachteile; die beiden oben genannten Tools sind je nach Anwendungsfall einfach performancemäßig nicht in der Lage, alle CAN-Frames zuverlässig zu erfassen, wie ich z.B. hier
viewtopic.php?p=291306#p291306
beschrieben habe.

Technisch ist die Folgende die zuverlässigste und eleganteste, meines Erachtens besteht der wichtigste Nachteil darin, dass sie einfach auch die teuerste ist - wobei "teuer" bei CAN immer relativ ist. Nach oben sind keine Grenzen gesetzt, 5-stellige Beträge sind keine Seltenheit...

Aber keine Sorge, hier bist du so um die 175-300 Euro dabei. Das Herzstück ist ein Raspberry Pi mit der PiCAN Zusatzplatine. Zum Anschluss an unseren Roller musst du noch ein passendes OBD2/Sub-D Kabel stricken und prinzipiell kannst du loslegen. Programmierkenntnisse sind erstmal gar nicht nötig, da es für die PiCAN die SocketCAN userspace can-utils gibt, die Basisbefehle (wie candump, canplayer, can-sniffer usw.) enthalten, z.B.:
viewtopic.php?p=321968#p321968
Eigene Programme kannst du dann in C (von mir bevorzugt) oder Python schreiben.

Bezugsquellen (Beispiele):

Raspberry Pi4 https://buyzero.de/products/raspberry-pi-4b
PiCan 3 https://buyzero.de/products/pican-3
Handbuch https://cdn.shopify.com/s/files/1/1560/ ... PICAN3.pdf
Gehäuse https://buyzero.de/products/pican-3-cas ... an-gehause
SocketCAN userspace can-utils https://github.com/linux-can/can-utils/ ... /README.md
Python: https://github.com/skpang/PiCAN-Python-examples

Ja und wenn du dann etwas gebastelt hast, freue ich mich auf den Austausch hier

Grüße von

Rudi Ratlos

Sehr schön. Frage mich nach heutiger Recherche, ob man so viel Geld in die Hand nehmen muss: Ich habe noch einen Pi2B hier liegen und das PiCan2-Interface bekommt man teilweise für unter 50 Euro.
Für mich interessant: Auch das PiCan3 "zaubert nicht", verwendet die gleichen MCP-Bausteine und Quartze wie ein 6,99€-Bord. Der Mehrpreis ist aber dennoch teilweise begründet, weil mehr Schutzmechanismen und auch ein Wandler verbaut ist, der den ganzen Pi vom OBD mit Strom versorgen kann. Für eine lückenlose Verarbeitung ist die Rechenpower wichtiger und die hat jeder Pi sicher zur Genüge - aber ein ESP32 sollte da auch helfen, wenn der Sketch richtig programmiert ist.
Für mich als gelegentlichen Sniffer ist die Einstiegshürde zu hoch. Was ein potenter Wandler im Zusammenhang mit einem Handy hergeben könnte, sollte eigentlich reichen, zumal das Handling bedeutend bequemer ist.
Rudis OBD LX-101 wird nicht mit erweiterter Funktionalität beworben - inzwischen sind Adapter verfügbar, die mit langen Frames, 2k-Zwischenpuffer und doppelter Baudrate (230-500K) werben und dank BTLE auch Apple unterstützen. vLinker fiel mir heute auf und dieser hier. Ich glaube, ich investiere da mal was...

Pfriemler hat geschrieben: Fr 8. Sep 2023, 15:17 Ich habe noch einen Pi2B hier liegen und das PiCan2-Interface bekommt man teilweise für unter 50 Euro.

Keine Frage: Ein älter Raspi (ab 2B, ich nutze selbst einen 3B) und ein älteres PiCAN (ich nutze selbst das 2) funktionieren natürlich auch! Die OBDLink-Dongles ( https://www.obdlink.com/ ) sind m.E. das Beste, was es in dieser Richtung gibt, guter Support, ein Forum und Firmwareupdate eingeschlossen; es gibt auch Modelle, die sich mit iOS-Geräten verstehen. Den LX hab ich, weil der u.a. prima mit der MotoScan App (fürs BMW Motorrad) zusammenwerkelt.