CAN-Bus Community

Moin, ich arbeite gerade an einem spannenden Projekt namens tesberry (Tesla Raspberry Pi) und nutze dafür die Daten des CAN-Bus. Gibt es hier eine Community mit der man sich darüber austauschen kann oder die Interesse hat daran mitzuarbeiten.

Tesberry (WIP):

  • UI im Tesla Browser
  • Programmieren eigener Tesla-Funktionen mit NodeRED
  • Apple CarPlay
  • Ambient Light, welches sich dem Auto anpasst bspw. Blinklicht (Türen blinken orange), Autopilot (alles blau) oder Totwinkelwarner (Türen rot)
  • Anzeigen von HDMI Input auf Display

Grüße aus Düsseldorf

2 „Gefällt mir“

Sehr interessantes Thema. Mich interessiert auf jeden Fall was da so auf dem CAN gesendet wird. Praktisch wären auch Daten zum Ladevorgang bzw. zur Ladekommunikation um evtl. Probleme zu analysieren.

Interesse habe ich, nur beim Coden sind meine Grenzen schnell erreicht.

Was den CAN-Bus angeht findest du hier viele Infos: https://www.teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/
Auf die Infos von JWardell kannst du dich verlassen. Der hat eine eigene Lösung für den CAN-Bus entwickelt.

Hier im TFF müssten @BlackNoIce und @Eugenius mithelfen können.

2 „Gefällt mir“

Danke, in dem Tesla-Owners-Forum bin ich bereits aktiv und auch auf GitHub im Repository von Josh Wardell, nur leider ist er, sowie die Community dort eher inaktiv. Es sind eher Leute dort die Interesse haben aber so gut wie niemand der Ahnung hat.

Ich nutze übrigens auch eine angepasste DBC Datei auf Basis von Josh Wardell’s Datei.

Danke auch für den Hinweis auf die beiden Kollegen hier im Forum, vielleicht melden die sich ja. :slight_smile:

Ja, Josh ist in letzter Zeit nicht mehr sonderlich aktiv. Wenn man seinen Links folgt findet man heraus dass er inzwischen Rivian fährt :grin: Ob er überhaupt noch einen Tesla hat?

Ich wollte schon im Tesla Owners Forum nachfragen ob jemand bereit ist einen Fork zu pflegen, bin bisher nicht dazu gekommen. Ich glaube dass das Problem an der weiteren Pflege der dbc Datei darin liegt dass sie sehr stark von nicht trivial zugänglichen Informationen abhängt. Ich kann mir nicht vorstellen dass die Signalnamen, -positionen, Faktoren, etc. durch Raten entschlüsselt wurden.

Irgendwo habe ich mal einen Screenshot von einem Tesla Servicemenü gesehen auf dem man alle CAN Signale auf dem Bildschirm im Auto anzeigen lassen kann. Mit diesem Hilfsmittel ist es einfach, wenn auch zeitraubend, die CAN Datenbank perfekt zu aktualisieren. Ohne dieses Hilfsmittel kann man nur raten. Z.B. wurde kürzlich das Telegramm für die Motortemperaturen um weitere Temperaturen erweitert. Welche Bedeutung haben diese…? Welche der Temperaturen sind jetzt die „alten“ Werte? Ähnliches ist bei den Batteriedaten passiert. Soweit ich rausfinden konnte ist dieses Servicemenü nicht (mehr?) ohne Root zugänglich.

Mit meinem Projekt verfahre ich jetzt so dass ich die Änderungen von ScanMyTesla verfolge und versuche mit Hilfe von CAN Logs und „Educated Guesses“ diese nachzuvollziehen. Mal sehen wie lange das noch funktioniert.

Ich finde es extrem gefährlich irgend etwas auf den CAN Bus zu schreiben - auch vermeintlich harmlose Telegramme - gerade weil Tesla die Telegramme ohne Vorwarnung ändert. Die S3XY Buttons z.B. würde ich nie anschließen!

3 „Gefällt mir“

Tatsächliche sehe ich kein Problem darin CAN-Messages zu verändern und wieder in den Bus zu schicken, da wenn die Werte nur verändert werden können, wenn die gleiche Message auch schon dekodiert werden konnte. Bei Veränderungen am Aufbau einer Nachricht seitens Tesla, würde das Dekodieren ja schon fehlschlagen.
Des Weiteren sind sicherheitsrelevante Messages mit einer Checksum versehen, daher kann man diese Werte sowieso nicht schreiben/verändern.

Wo es gefährlich wird ist wenn man einen „man in the middle“ Angriff macht, wie ja das BONUS Module von Ingenext relevante Daten verändern kann.

Aber klar, grundsätzlich sollte man nur an der Fahrzeugelektronik etwas verändern, wenn man auch genug darüber weiß.

@BlackNoIce Darf ich fragen wie genau du die Änderungen von ScanMyTesla verfolgst? Und was für Änderungen du bereits vorgenommen hast - vielleicht könnte ich die dann in mein DBC file mit übernehmen, welches auch in meinem Repo ist.

Danke jedenfalls für die ausführlichen Infos.

Interessantes Projekt :yum: . Ich werde es mal weiter verfolgen. Vielleicht kommt ja etwas dabei heraus, dass auch für mein Projekt interessant wäre.

Kurze Vorwarnung, weil ich genau das versucht habe. Mit digitalen LEDs wird das mit einem Raspi ganz schnell pain in the butt :stuck_out_tongue: . Stichworte CPU scheduling, Timing, Interrupts und schlechter Hardware Support. Ich hatte irgendwann angefangen einen Treiber dafür zu schreiben und es am Ende komplett verworfen. Ein großer Faktor bei der Entscheidung war auch die boot time. Hat mir einfach zu lange gedauert, bis das Licht dann endlich mal anging. Viel zu unresponsive :yum: .

2 „Gefällt mir“

@anon80619572 Ich probiere es mal aus - es sind fast alles Teile für das Ambient Light bereits da. Werde es aber erstmal nicht so komplex machen wie deine Umsetzung, die ist mir tatsächlich zu aufwendig. ^^

Bezüglich des Pi’s: Mir ist bewusst, dass es nicht gerade die performanteste Variante ist, um so etwas umzusetzen, dafür aber vielfältig. Aber es gibt viel Optimierungspotential, auch was die Boot Time angeht. Um die CPU mache ich mir bereits sorgen, was die Auslastung angeht, denn die ist schon jetzt recht viel am Arbeiten um die CAN Messages (ca. 5000 Messages/s) zu verarbeiten. Ich nutze übrigens einen Raspberry Pi 4 mit 2GB und dem 128GB Tesla/Samsung Stick zum Booten.

1 „Gefällt mir“

Ich denke die CPU wird dir wegen der LEDs gar keine großen Probleme machen. Das macht schlimmstenfalls 1-2% Last zusätzlich aus. Wenn du jetzt noch hinkommst, wird es auch mit LEDs noch gehen :yum: . Das Schwierige war das timing der digitalen LEDs. Als ich das versucht hatte gab es eigentlich nur die Möglichkeit, die per SPI anzusteuern. Da hast du dann Hardware Unterstützung. Das Problem dabei ist nur, dass du dann genau einen Channel hast. Deswegen war das für mich keine Option gewesen. Dann musst dir die Daten Leitung ja einmal durch das ganze Auto legen. Theoretisch könnte man das vielleicht auch softwareseitig per bitbanging lösen. Ich muss aber ehrlich gestehen, daran bin ich gescheitert. Die CPU selbst würde das sehr sehr einfach schaffen. Aber Linux hat mir da wegen des CPU schedulings einen Strich durch die Rechnung gemacht. Dein Programm wird ja in gewissen Abständen vom OS unterbrochen. Da die einzelnen Bits (angenommen ws2812) teilweise unter einer Mikrosekunde sind, ist das wirklich schwierig. Da schaffst du kaum, das timing einzuhalten. Falls du da eine gute Lösung findest wäre ich echt interessiert :yum: .

Du kannst dich übrigens wegen Animationen ect. gerne bei TesLight bedienen :yum: . Teilweise kann man das auch auf dem PC/Raspi bauen. Musst nur die LED Library rauswerfen.

Ich drücke dir die Däumchen.

1 „Gefällt mir“

Schau Dir mal DietPi an, im gegensatz zu Raspbian sind die Bootzeiten bei ca. 12 - 15 Sekunden.

1 „Gefällt mir“

Ich schaue ab und zu hier vorbei: ScanMyTesla & TM-Spy und dann im ScanMyTesla Changelog

Ich habe meine Patches mal auf meinen Fork hochgeladen: GitHub - mgerczuk/model3dbc: DBC file for Tesla Model 3 CAN messages

Wie gesagt: Bei den Signalen ist alles geraten. In den Temperatur-Messages gibt es z.B. inzwischen weitere Temperaturen. Vielleicht sind das teilweise die „alten“ Signale? In der BMS Message weiß ich nicht wo das BMS_fullChargeComplete Signal im neuen Layout abgeblieben ist…

Ich habe jetzt auch wieder den Hinweis auf das Tesla Service Menü gefunden: Neuer Tesla Service Mode - #34 von Merc Im zweiten Bild wird der „live CAN signals viewer“ erwähnt. Man braucht also kein Root, sondern nur viel Geld :laughing:

1 „Gefällt mir“