> For the complete documentation index, see [llms.txt](https://taiphoon-com.gitbook.io/taiphoon.com-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://taiphoon-com.gitbook.io/taiphoon.com-docs/de/support/knowledge-base/can-bus.md). # CAN Bus ### Was ist ein CAN Bus? CAN (Controller Area Network) ist ein für störbehaftete Umgebungen entwickelter kabelgebundener Kommunikationsbus. Ursprünglich wurde er in der Fahrzeugelektronik eingesetzt, heute wird er auch häufig für die Kommunikation zwischen Flugcontrollern, Sensoren, GPS, ESCs und anderen Peripheriegeräten verwendet. An einem Fluggerät können Motoren, ESCs, Strommodule und Funkgeräte deutliche elektromagnetische Störungen erzeugen. CAN wird vor allem deshalb häufig eingesetzt, weil es in solchen Umgebungen in der Regel stabiler ist als gewöhnliche unsymmetrische serielle Kommunikation. ### Zentrale Eigenschaften von CAN Die wichtigste Eigenschaft von CAN ist die Verwendung von **Differenzsignalen** und einer **gemeinsam genutzten Busarchitektur**. Das bedeutet, dass mehrere Geräte dieselben CAN\_H- und CAN\_L-Leitungen gemeinsam nutzen können. Die Empfangsseite liest die Potenzialdifferenz zwischen den beiden Leitungen und ist daher sehr widerstandsfähig gegenüber Störungen, die beide Leitungen gleichermaßen betreffen. ### Was ist ein Differenzsignal? CAN verwendet zwei Datenleitungen: **CAN\_H** und **CAN\_L**. Bei der Übertragung ändern sich die Signale auf diesen beiden Leitungen in entgegengesetzter Richtung. Die Empfangsseite betrachtet nicht nur die absolute Spannung einer Leitung, sondern die Differenz zwischen beiden. Der Vorteil dieses Verfahrens: Wenn externes Rauschen gleichzeitig in beide Leitungen einkoppelt, ist die Gleichtaktstörung auf beiden Leitungen annähernd gleich, sodass die Empfangsseite diese Störung bei der Differenzbildung weitgehend auslöschen kann. Daher bleibt CAN auch in der Nähe von Motoren, ESCs und Hochstromsystemen recht zuverlässig. ### Unterschiede zwischen CAN und UART / I2C CAN, UART und I2C können alle zum Anschluss von Flugcontroller-Peripheriegeräten verwendet werden, unterscheiden sich jedoch in Einsatzzweck und Designphilosophie. | Schnittstelle | Typische Struktur | Vorteile | Typische Verwendung | | ------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------ | --------------------------------------------- | | UART | Punkt-zu-Punkt. | Einfach, verbreitet, leicht zu konfigurieren. | GPS, Telemetrie, Empfänger, Debug-Konsole. | | I2C | Mehrere Geräte teilen sich zwei Leitungen. | Geeignet für kurze Strecken auf der Platine oder für nahe Sensoren. | Kompass, Barometer, einfache Sensoren. | | CAN | Gemeinsamer Bus für mehrere Knoten. | Hohe Störfestigkeit, besser geeignet für längere Strecken und die Integration vieler Peripheriegeräte. | CAN GPS, CAN ESC, CAN-Sensoren, Knotenmodule. | ### Bustopologie CAN ist ein echter **Mehrpunktbus**. Alle Knoten hängen an derselben Hauptleitung, jeder Knoten kann Daten senden, und alle Knoten können die Frames auf dem Bus empfangen. Bei Flugcontrollern werden Flugcontroller, GPS, Sensoren, ESCs oder andere Knoten üblicherweise nacheinander in Reihe an dieselbe CAN-Hauptleitung angeschlossen, statt wie bei UART für jedes Gerät ein eigenes TX/RX-Paar zu verlegen. ### Arbitrierungsmechanismus Da sich mehrere Knoten denselben Bus teilen, verfügt das CAN-Protokoll über einen integrierten Mechanismus zur Nachrichtenarbitrierung. Wenn mehrere Geräte gleichzeitig senden möchten, wird anhand der Frame-Priorität entschieden, wer zuerst sendet. Dies ist einer der Gründe, warum CAN für Echtzeit-Steuerungsanwendungen geeignet ist. Es verlässt sich nicht auf ein einfaches „Wer zuerst kommt, gewinnt“, sondern die Protokollebene entscheidet, welche Nachricht vorrangig auf dem Bus bleibt. ### Abschlusswiderstand Ein ordnungsgemäßer CAN-Bus muss an **beiden physischen Enden** jeweils einen **120-Ohm-Abschlusswiderstand** haben. Der Abschlusswiderstand absorbiert Signalreflexionen. Ohne korrekten Abschluss können Signale, die am Kabelende reflektiert werden, zu Datenverfälschungen, zeitweise sichtbaren und verschwindenden Knoten oder einer mal funktionierenden, mal gestörten Kommunikation führen. ### Wie Sie prüfen, ob der Abschluss korrekt ist Wenn sich an beiden Enden des Busses je ein 120-Ohm-Abschlusswiderstand befindet und Sie bei ausgeschaltetem System den Widerstand zwischen CAN\_H und CAN\_L messen, sollte dieser in der Regel nahe **60 Ohm** liegen, da die beiden 120-Ohm-Widerstände parallel geschaltet sind. Dies ist eine sehr praktische Schnellprüfung bei der Fehlersuche vor Ort. Weicht der Messwert deutlich von 60 Ohm ab, bedeutet dies in der Regel, dass die Anzahl der Abschlüsse falsch ist, ein Verkabelungsfehler vorliegt oder der integrierte Abschluss einiger Knoten nicht korrekt konfiguriert ist. ### Häufige Abschlussfehler Das häufigste CAN-Problem ist eine falsche Konfiguration der Abschlusswiderstände. Typische Fälle sind: * Gar kein Abschluss, was zu starken Reflexionen führt. * Abschluss an jedem Knoten aktiviert, was zu einer zu niedrigen Gesamtimpedanz führt. * Abschluss nicht am physischen Ende, sondern an einem mittleren Knoten. Der richtige Grundsatz ist einfach: **Nur die beiden Enden des Busses benötigen einen Abschluss**; mittlere Knoten sollten in der Regel keinen weiteren Abschluss erhalten. ### Bitrate Im gängigen Flugcontroller-Ökosystem beträgt die übliche CAN-Bitrate in der Regel **1 Mbps**; dies ist auch der gängige Standardwert vieler Flugcontroller-Firmwares und DroneCAN-Peripheriegeräte. Anders als bei UART muss die CAN-Bitrate in der Regel nicht häufig geändert werden. Alle Knoten müssen jedoch dieselbe Bitrate verwenden, andernfalls ist ein falsch eingestelltes Gerät auf dem Bus in der Regel völlig unsichtbar. ### Stecker und Kabel In vielen Flugcontroller-Systemen wird für CAN häufig ein **4-pin JST-GH**-Stecker verwendet, mit der typischen Pinbelegung 5V, CAN\_H, CAN\_L, GND. Auch wenn diese Steckerform verbreitet ist, ist nicht garantiert, dass alle Geräte völlig identisch sind. Prüfen Sie vor der eigentlichen Verkabelung die Pinbelegung des Geräts, die Versorgungsspannung und ob es eine Versorgung über den Bus unterstützt. ### Die Stromversorgung ist nicht automatisch gegeben CAN-Leitungen führen häufig zusätzlich 5V und GND, um Peripheriegeräte mit geringem Stromverbrauch zu versorgen. Das bedeutet jedoch nicht, dass alle Geräte direkt über den Bus versorgt werden sollten. Wenn sich viele Knoten am Bus befinden, die Leitungen länger sind oder manche Geräte mehr Strom verbrauchen, kann der Spannungsabfall dazu führen, dass Peripheriegeräte instabil starten, wiederholt neu starten oder zeitweise offline gehen. Erstellen Sie daher bei der Umsetzung zunächst eine Strombilanz und bewerten Sie die Leitungsverluste. ### Warum CAN für Flugcontroller-Peripherie geeignet ist Für Flugcontroller-Peripheriegeräte liegt der Vorteil von CAN nicht nur in der Störfestigkeit. Typische Vorteile sind: * Mehrere Geräte teilen sich denselben Bus, was die Erweiterung erleichtert. * Geräte können ihren Status zurückmelden, statt nur unidirektional Daten zu liefern. * Geeignet für längere Leitungswege und stärker störbehaftete Umgebungen. * Knotenverwaltung, Parametereinstellung und teilweise Firmware-Updates können über den Bus erfolgen. ### Was ist DroneCAN? Bei Flugcontrollern ist CAN nur das zugrunde liegende Kommunikationsverfahren auf Bitübertragungs- und Sicherungsschicht. Was tatsächlich festlegt, „wie Dateninhalte dargestellt, Knoten verwaltet und Parameter konfiguriert werden“, ist in der Regel ein übergeordnetes Protokoll wie **DroneCAN**. DroneCAN kann als Anwendungsschichtprotokoll betrachtet werden, das auf CAN aufsetzt. Es definiert standardisierte Nachrichtenformate, die Knotenverwaltung, die dynamische Zuweisung von Knotennummern, den Parameterzugriff und den Ablauf von Geräte-Firmware-Updates, sodass kompatible Geräte verschiedener Hersteller leichter auf demselben Bus zusammenarbeiten können. ### Node ID In der DroneCAN-Architektur benötigt jeder Knoten eine eindeutige **Node ID**; der übliche gültige Bereich liegt zwischen 1 und 127. In vielen Flugcontroller-Firmwares kann die Knotennummer automatisch vom System zugewiesen werden. Dies erleichtert die erstmalige Integration. Wenn Sie die Nummern jedoch manuell festlegen, müssen Sie doppelte Node IDs bei verschiedenen Geräten vermeiden, da sich die Knoten sonst gegenseitig stören. ### Dynamische Knotenzuweisung Der Vorteil der dynamischen Knotenzuweisung besteht darin, dass ein neues Gerät nach dem Anschluss an den Bus vom Flugcontroller erkannt und in das System aufgenommen werden kann, ohne dass zuvor zwingend eine feste Nummer manuell eingetragen werden muss. Das ist beim tatsächlichen Aufbau sehr hilfreich, insbesondere wenn mehrere Sensoren oder Module gleichzeitig integriert werden. Bei einer festen Systemkonfiguration wird jedoch häufig empfohlen, die Nummern wichtiger Knoten nach bestätigtem einwandfreiem Betrieb festzulegen, um das Risiko von Änderungen bei einer späteren Neuorganisation des Netzwerks zu verringern. ### Redundanter CAN Manche Flugcontroller und Peripheriegeräte unterstützen eine zweite CAN-Schnittstelle, mit der ein redundanter Kanal aufgebaut werden kann, um die Zuverlässigkeit der Verbindung insgesamt zu erhöhen. Diese Funktion muss nicht in jedem System verwendet werden, doch bei großen Fluggeräten, Fahrzeugen für kritische Missionen oder Systemen mit langen Leitungen bietet eine Dual-CAN-Architektur eine höhere Fehlertoleranz. ### Häufige Probleme Typische Probleme beim CAN-Bus konzentrieren sich meist auf einige wenige Punkte: * **Fehlender Abschlusswiderstand**: Knoten erscheinen und verschwinden gelegentlich. * **Zu viele Abschlüsse**: Die Impedanz ist zu niedrig, die Kommunikationsqualität sinkt. * **Unterschiedliche Bitraten**: Manche Knoten sind überhaupt nicht sichtbar. * **Node-ID-Konflikt**: Zwei Knoten mit derselben Nummer stören sich gegenseitig. * **Unzureichende Stromversorgung**: Geräte können instabil sein, neu starten oder zufällig offline gehen. * **Zu lange Kabel oder schlechte Leitungsführung**: Auch wenn CAN störfester ist, gibt es physikalische Grenzen. ### Empfohlene Reihenfolge der Fehlersuche Wenn ein CAN-Gerät nicht ordnungsgemäß funktioniert, wird empfohlen, in folgender Reihenfolge zu prüfen: 1. Stellen Sie sicher, dass CAN\_H, CAN\_L, 5V und GND richtig verkabelt sind. 2. Stellen Sie sicher, dass sich an beiden Enden des Busses je ein 120-Ohm-Abschlusswiderstand befindet. 3. Messen Sie bei ausgeschaltetem System, ob der Widerstand zwischen CAN\_H und CAN\_L etwa 60 Ohm beträgt. 4. Stellen Sie sicher, dass alle Knoten dieselbe Bitrate verwenden. 5. Stellen Sie sicher, dass keine doppelten Node IDs vorhanden sind. 6. Stellen Sie sicher, dass die Stromversorgung über den Bus ausreicht, insbesondere in Systemen mit vielen Knoten. 7. Verwenden Sie bei Bedarf ein Überwachungswerkzeug mit CAN/DroneCAN-Unterstützung, um zu prüfen, ob Knoten online sind und Frames übertragen werden. ### Hinweise **Hinweis:** CAN wird als Bus verkabelt, nicht sternförmig. Wenn mehrere Knoten großzügig von einem zentralen Punkt aus abgezweigt werden, werden die Buseigenschaften leicht beeinträchtigt und das Reflexionsrisiko steigt. **Hinweis:** Nur an den beiden physischen Enden sollten Abschlusswiderstände vorhanden sein. Aktivieren Sie nicht alle, nur weil jedes Gerät einen integrierten Abschluss hat. **Hinweis:** CAN ist störfester als UART, aber nicht völlig unabhängig von der Verkabelung; Leitungslänge, Steckerqualität, Qualität der Stromversorgung und Bustopologie wirken sich weiterhin direkt auf die Zuverlässigkeit aus.