ESP32 und CAN-Bus: Fahrzeugdaten im Auto auslesen

ESP32 und CAN-Bus: Fahrzeugdaten im Auto auslesen ist ein Thema, das viele Maker, Diagnostik-Fans und IoT-Entwickler interessiert – und das zu Recht. Der CAN-Bus (Controller Area Network) ist das Rückgrat moderner Fahrzeuge: Steuergeräte tauschen darüber Informationen zu Motor, Fahrwerk, Komfortfunktionen und Sensorik aus. Mit einem ESP32 lassen sich diese Daten nicht nur mitschneiden, sondern auch strukturiert auswerten und beispielsweise per WLAN an ein Dashboard oder an Home-Server weiterleiten. Damit das zuverlässig und sicher funktioniert, braucht es jedoch mehr als „zwei Kabel an OBD-II und los“: Sie benötigen die passende CAN-Hardware (Transceiver), korrekte Pegel, saubere Verdrahtung und ein Verständnis für Bitrate, Frame-Formate und Protokolle wie OBD-II/UDS. Ebenso wichtig ist der rechtliche und praktische Rahmen: Das Auslesen von Diagnosedaten ist in vielen Szenarien legitim, aber Eingriffe in fahrrelevante Systeme sind sicherheitskritisch und können unzulässig sein. In diesem Artikel erfahren Sie, wie Sie den ESP32 für CAN-Logging und OBD-II-Datenabfragen aufbauen, typische Stolperfallen vermeiden und aus Rohframes verwertbare Messwerte machen – mit Fokus auf stabile Praxislösungen statt fragiler Basteltricks.

CAN-Bus im Fahrzeug verstehen: Was Sie wirklich auslesen können

Im Auto existieren häufig mehrere Busse und Gateways. Der klassische High-Speed-CAN ist typischerweise für Antriebs- und Fahrdynamiksysteme zuständig, während weitere Netze (Low-Speed-CAN, LIN, FlexRay, Automotive Ethernet) je nach Modell parallel arbeiten. Über die OBD-II-Buchse ist in vielen Fahrzeugen ein Diagnosezugang verfügbar, häufig per CAN (ISO 15765-4), teils auch per K-Line bei älteren Modellen. Was Sie darüber erhalten, hängt von Fahrzeug, Baujahr und Konfiguration ab.

• Standardisierte OBD-II-Daten: Grundlegende Parameter wie Drehzahl, Geschwindigkeit, Kühlmitteltemperatur oder Fehlercodes (wenn unterstützt).
• Herstellerspezifische Frames: Viele interessante Signale laufen „intern“ auf dem CAN, sind aber nicht standardisiert dokumentiert.
• Gateways und Security: Moderne Fahrzeuge trennen Netze und schützen Diagnosefunktionen; nicht jede Nachricht ist von der OBD-Schnittstelle erreichbar.

Für Einsteiger ist OBD-II ideal, weil Sie über standardisierte PID-Abfragen reproduzierbar Daten bekommen, ohne Reverse Engineering. Für fortgeschrittene Projekte ist das passive Logging (Sniffing) interessant, um fahrzeuginterne Frames zu analysieren – allerdings ist das deutlich komplexer und modellabhängig.

ESP32 und CAN: Welche ESP32-Varianten eignen sich?

Viele ESP32-Modelle besitzen einen integrierten CAN-Controller (bei Espressif häufig als TWAI bezeichnet). Das ist ein großer Vorteil: Sie benötigen dann keinen externen CAN-Controller wie MCP2515, sondern „nur“ einen CAN-Transceiver, der die Logiksignale (TX/RX) auf den differentiellen Bus (CANH/CANL) umsetzt.

• ESP32 mit integriertem CAN (TWAI): Direkte Anbindung an einen Transceiver möglich, oft die beste Lösung für stabile Bitraten.
• ESP32 ohne passenden Controller: Dann ist ein externer CAN-Controller (z. B. MCP2515 via SPI) erforderlich, was zusätzliche Latenz und Komplexität bringen kann.
• Projektanforderungen: Für reines Logging reicht oft ein klassischer ESP32; für paralleles WLAN-Streaming und Filterung kann ein leistungsfähigeres Modell mit mehr RAM vorteilhaft sein.

Eine technische Referenz zur TWAI/CAN-Schnittstelle finden Sie in der offiziellen Espressif-Dokumentation: TWAI (CAN) im ESP-IDF.

Die wichtigste Hardware: CAN-Transceiver und sichere Verdrahtung

Der ESP32 spricht „logischen CAN“ (TX/RX), aber nicht den physikalischen Bus. Dafür brauchen Sie einen Transceiver. Häufig genutzt werden SN65HVD230 (3,3 V), TJA1050 (oft 5 V) oder MCP2551 (klassisch, meist 5 V). Entscheidend ist die Versorgung und die Logikkompatibilität.

Transceiver-Auswahl: 3,3 V vs. 5 V

• 3,3-V-Transceiver: Sehr bequem mit ESP32, z. B. SN65HVD230. Weniger Pegelkonflikte, meist „Plug-and-Play“.
• 5-V-Transceiver: Häufig in Kfz-Umgebungen; erfordert sauberes Pegelkonzept. Nicht jeder 5-V-Transceiver akzeptiert 3,3-V-Logik direkt.
• Automotive-Transceiver: Für dauerhaften Einsatz im Auto sind ESD- und Störfestigkeit besonders wichtig.

Ein Datenblatt-Einstieg zum verbreiteten SN65HVD230 finden Sie über den Hersteller: SN65HVD230 Transceiver.

OBD-II-Buchse: Pins und Vorsicht

Bei OBD-II über CAN liegen CAN-High und CAN-Low typischerweise auf Pin 6 (CANH) und Pin 14 (CANL). Die Fahrzeugbatterie (12 V) liegt auf Pin 16, Masse auf Pin 4/5. Achtung: Der ESP32 darf niemals direkt an 12 V betrieben werden. Nutzen Sie einen geeigneten Kfz-tauglichen Step-Down-Wandler (Buck Converter) und sorgen Sie für Schutz gegen Spannungsspitzen.

• Pin 6: CAN-High
• Pin 14: CAN-Low
• Pin 16: +12 V (Batterie)
• Pin 4/5: GND

Terminierung und Busregeln

Ein typischer CAN-Bus ist an beiden Enden mit 120-Ohm-Abschlusswiderständen terminiert. Wenn Sie über OBD-II an einen bestehenden Bus „dranhängen“, ist der Bus in der Regel bereits korrekt terminiert. Zusätzliche Terminierung durch Ihr Gerät kann den Bus belasten. Für Diagnose- und Logger-Geräte gilt meist: keine zusätzliche 120-Ohm-Terminierung setzen, sondern „hochohmig“ mitlaufen – es sei denn, Ihr Setup bildet tatsächlich ein Busende (was im Fahrzeug selten der Fall ist).

• Keine Extra-Terminierung am OBD-Adapter: Häufig die richtige Wahl für passives Logging.
• Kurze Leitungen: Vermeiden Sie lange ungeschirmte Kabel, die Störungen einkoppeln.
• ESD-Schutz: Kfz-Umgebung ist elektrisch rau; robuste Module sind klar im Vorteil.

Bitrate und Frame-Formate: Ohne diese Parameter geht nichts

Damit der ESP32 Frames korrekt decodieren kann, müssen Bitrate und Frame-Format stimmen. Im Fahrzeug sind typischerweise 250 kbit/s oder 500 kbit/s verbreitet, aber das ist nicht universell. OBD-II per CAN ist häufig 500 kbit/s (ISO 15765-4), es existieren jedoch Varianten und Abweichungen je nach Hersteller und Plattform.

• Standard Frame: 11-bit Identifier (häufig in OBD-II-Basisfällen)
• Extended Frame: 29-bit Identifier (in vielen modernen Netzen üblich)
• Datenlänge: Klassisch bis 8 Byte pro CAN-Frame (CAN 2.0); CAN FD ist ein eigenes Thema und nicht automatisch mit Aderpaar/OBD zugänglich.

Wenn Sie die Bitrate nicht kennen, ist ein strukturierter Ansatz sinnvoll: erst passiv mithören, Bitrate testen, dann Filter setzen. In professionellen Umgebungen nutzt man dafür häufig PC-Tools (z. B. SocketCAN), doch auch ein ESP32 kann durch „Autobaud“-Strategien unterstützt werden, sofern Sie sorgfältig testen.

OBD-II mit ESP32: Standardisierte Fahrzeugdaten abfragen

Für viele Anwendungen reicht OBD-II völlig aus. Das Prinzip: Ihr ESP32 sendet eine Anfrage (Mode + PID) und wartet auf eine Antwort. Beispiele sind Mode 01 (aktuelle Daten) und Mode 03 (Fehlercodes). In CAN-OBD werden die Daten in CAN-Frames verpackt, oft mit ISO-TP (ISO 15765-2), wenn die Antwort länger als 8 Byte ist.

Typische OBD-II-PIDs (Mode 01) als Einstieg

• Motordrehzahl (RPM): Häufig PID 0x0C
• Fahrzeuggeschwindigkeit: Häufig PID 0x0D
• Kühlmitteltemperatur: Häufig PID 0x05
• Drosselklappenstellung: Häufig PID 0x11

Eine kompakte Übersicht zu PIDs (inklusive Formeln zur Umrechnung) finden Sie als Nachschlagewerk hier: Übersicht OBD-II PIDs. Für seriöse Diagnose-Workflows ist außerdem eine ISO-TP-Referenz hilfreich, da Multi-Frame-Antworten ohne ISO-TP unvollständig bleiben: ISO-TP Grundlagen (ISO 15765-2).

CAN-Filtering am ESP32: Weniger Daten, mehr Klarheit

Ein fahrzeuginterner CAN kann sehr „laut“ sein: Hunderte bis Tausende Frames pro Sekunde sind möglich. Wenn Sie alles ungefiltert über WLAN streamen, sind Paketverlust, Pufferüberläufe und unübersichtliche Logs vorprogrammiert. Die Lösung ist ein klarer Filteransatz: erst mithören, dann relevante IDs auswählen, anschließend nur noch diese IDs verarbeiten oder übertragen.

• Hardware-/Treiberfilter: Viele CAN-Controller bieten Acceptance-Filter, die uninteressante IDs verwerfen.
• Softwarefilter: Zusätzliche Logik im ESP32, z. B. nur bestimmte IDs oder nur geänderte Werte senden.
• Sampling/Downsampling: Nicht jede Größe muss mit Busfrequenz gesendet werden; 5–20 Hz reichen für viele Dashboards.

Buslast und Datenrate: Warum Logging schnell anspruchsvoll wird

Gerade beim ESP32 ist es sinnvoll, die zu erwartende Datenlast grob abzuschätzen. Das hilft bei der Entscheidung, ob Sie lokal auf SD speichern, per WLAN streamen oder nur ausgewählte Signale übertragen.

Eine einfache Näherung für die Buslast (ohne tiefe Protokolldetails) ist:

$\mathrm{Load}=\frac{\mathrm{Bits}\_\mathrm{Frame}\times \mathrm{Frames}\_\sec }{\mathrm{Bitrate}}$

Wenn Sie beispielsweise 300 Frames pro Sekunde mit je grob 120 „On-the-Wire“-Bits auf einem 500-kbit/s-Bus haben, ergibt sich:

$\mathrm{Load}\approx \frac{120\times 300}{500000}=\frac{36000}{500000}=0.072$

Das entspricht etwa 7,2% Buslast. In realen Fahrzeugnetzen können Werte deutlich höher liegen. Für Ihr ESP32-Design bedeutet das: Puffer, Filter und ein effizientes Datenformat sind wichtiger als „maximale Rohdaten“.

ESP32-Softwarearchitektur: Stabil lesen, sicher speichern, sauber übertragen

Wer CAN-Daten im Auto ausliest, hat fast immer mehrere Aufgaben parallel: Frames empfangen, decodieren, loggen, und optional per WLAN übertragen. Der ESP32 ist dafür gut geeignet – wenn Sie die Aufgaben trennen und blockierende Operationen vermeiden.

• Empfangs-Task: Priorisiert, nimmt Frames an und schreibt sie in eine Queue/Ringbuffer.
• Decode-Task: Wandelt Frames in Messwerte um, setzt Filter, erkennt Änderungen.
• Storage/Netz-Task: Schreibt auf SD/Flash oder sendet per MQTT/Websocket; darf den Empfang nicht blockieren.
• Watchdog-freundlich: Keine langen Busy-Loops ohne Yield, keine großen Speicherallokationen im Hot-Path.

Wenn Sie Daten ins Heimnetz senden möchten, sind schlanke Formate (z. B. kompakte JSON-Strukturen oder binäre Frames) und ein begrenzter Sende-Takt (z. B. 10 Hz) meist stabiler als „alles immer sofort“.

Reverse Engineering vs. Standarddaten: Realistische Erwartungen setzen

Viele Einsteiger erwarten, über OBD-II „alle Daten“ zu bekommen. In der Realität ist OBD-II bewusst begrenzt und herstellerneutral. Wenn Sie Signale wie Lenkwinkel, Türstatus, Lichtzustand oder spezielle Sensorwerte wollen, landen Sie häufig im Reverse Engineering: Sie loggen CAN-IDs, verändern Zustände (z. B. Blinker an/aus) und suchen Korrelationen. Das ist zeitintensiv und stark fahrzeugspezifisch.

• OBD-II: Schnell, stabil, standardisiert, aber begrenzt.
• Interner CAN: Reichhaltig, aber undokumentiert und ggf. durch Gateways geschützt.
• Sicherheit: Passive Analyse ist deutlich risikoärmer als aktive Eingriffe in den Bus.

Sicherheits- und Rechtsaspekte: Verantwortungsvolle Nutzung im Fahrzeug

Ein ESP32-CAN-Projekt sollte so gebaut sein, dass es den Fahrzeugbetrieb nicht gefährdet. Selbst passives „Mithören“ kann durch falsche Terminierung, Kurzschluss oder Störungen Probleme verursachen. Aktives Senden von CAN-Nachrichten ist noch kritischer und gehört – wenn überhaupt – in kontrollierte Testumgebungen und mit klarer rechtlicher Grundlage. Für den Alltag im Straßenverkehr gilt: Keine Experimente an sicherheitsrelevanten Systemen.

• Elektrische Sicherheit: Kfz-Spannungsspitzen abfangen, saubere Wandler, Sicherung vorsehen.
• EMV und Robustheit: Keine fliegenden Kabelbündel im Fahrgastraum; stabile Steckverbindungen.
• Datenschutz: Fahrzeugdaten können personenbezogen sein (Fahrprofile, Standorte). Speichern/Übertragen bewusst gestalten.
• Nur lesen statt schreiben: Für die meisten Projekte ist Read-Only die richtige Strategie.

Typische Probleme und Troubleshooting: Wenn nichts ankommt

Wenn Ihr ESP32 „keine Frames sieht“, liegt es meist an wenigen, gut prüfbaren Ursachen. Ein systematisches Vorgehen spart Stunden.

• Falsche Bitrate: Häufigster Fehler. Testen Sie 250 kbit/s und 500 kbit/s, ggf. auch fahrzeugspezifische Werte.
• CANH/CANL vertauscht: Kein Empfang oder sehr instabil.
• Keine gemeinsame Masse: Logik funktioniert nicht zuverlässig, Transceiver „schwebt“ elektrisch.
• Zusätzliche Terminierung: 120-Ohm-Widerstand am OBD-Adapter kann den Bus unnötig belasten.
• Versorgung instabil: Billige Wandler ohne Filter können Resets oder Paketverlust verursachen.
• ADC/Noise-Mythos: CAN ist digital – wenn es „rauscht“, ist das fast immer ein Hardware-/Verdrahtungsthema.

Praxis: Daten sinnvoll darstellen und weiterverarbeiten

Der Mehrwert entsteht erst bei der Auswertung. Je nach Projekt bieten sich unterschiedliche Wege an: Live-Dashboard im Browser, Logging zur späteren Analyse oder Integration in eine Smart-Home-/Server-Umgebung.

• Live-Dashboard: ESP32 stellt eine lokale Weboberfläche bereit (z. B. JSON-Endpoint oder Websocket), um Drehzahl/Speed/Temperatur live zu sehen.
• MQTT-Integration: Messwerte als Topics publizieren, um sie in Automationen oder Datenbanken zu nutzen.
• Langzeitlogging: Zeitstempel + Frame-ID + Payload speichern; später am PC analysieren (z. B. mit Tools aus dem Linux-Umfeld).

Wenn Sie PC-Analyse ergänzend nutzen möchten, ist SocketCAN ein etablierter Standard im Linux-Umfeld: SocketCAN Dokumentation. Das hilft, Frames zu interpretieren und Filterstrategien zu entwickeln, bevor Sie alles auf den ESP32 portieren.

Outbound-Links zu relevanten Informationsquellen

• TWAI (CAN) im ESP-IDF: Offizielle ESP32-CAN-Peripherie-Dokumentation
• SN65HVD230: 3,3-V-CAN-Transceiver als gängige ESP32-Ergänzung
• Allegro A4988 Produktseite (für Abgrenzung: Stepper-Treiber ist nicht CAN)
• OBD-II PIDs: Überblick zu standardisierten Diagnoseparametern und Umrechnungen
• ISO-TP (ISO 15765-2): Multi-Frame-Transport auf CAN für Diagnoseantworten
• SocketCAN: Linux-Standardwerkzeuge und Kernel-Dokumentation für CAN-Analyse

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.