RV-C Protokoll

RV-C ist ein CAN-basiertes Kommunikationsnetzwerk, das speziell für Recreation Vehicles (Wohnmobile) entwickelt wurde. Es ermöglicht allen Geräten in einem Wohnmobil (Lichter, Markisen, Klimasteuerung, Generatoren, Wechselrichter usw.), miteinander zu kommunizieren und von einer zentralen Schnittstelle aus gesteuert zu werden.

• Entwickelt von: Recreation Vehicle Industry Association (RVIA)
• Basiert auf: CAN 2.0B (Controller Area Network) - die gleiche Technologie, die in der Automobilindustrie verwendet wird
• Website: www.rv-c.com ↗

Das große Ganze - Wie es funktioniert

Stell dir RV-C wie einen gemeinsamen Kommunikationsbus vor, auf dem alle Geräte sprechen und zuhören können:

1. Alle Geräte sind mit zwei verdrillten Drähten verbunden (CAN_H und CAN_L)
2. Geräte senden Nachrichten auf dem Bus, die jeder hören kann
3. Jede Nachricht hat eine eindeutige ID (DGN), die angibt, welche Art von Daten sie enthält
4. Geräte filtern Nachrichten und verarbeiten nur diejenigen, die für sie relevant sind
5. Kein Master-Gerät - es ist ein Peer-to-Peer-Netzwerk, in dem alle gleichberechtigt sind

Physikalische Schicht

Verkabelung

• Kabel: Twisted Pair (2 Drähte: CAN_H = Weiß, CAN_L = Blau)
• Optionale Drähte: Stromversorgung (Rot/Schwarz) und Abschirmung (blank)
• Drahtgröße: 15-24 AWG (typischerweise 18 oder 20 AWG)
• Topologie: Linearer Bus mit kurzen Abzweigungen (Stern-Topologie NICHT erlaubt)

Bus-Konfiguration

[Gerät]   [Gerät]            [Gerät]   [Gerät]
    |          |                    |          |
====*==========*====================*==========*====
120Ω                                           120Ω
(Terminator)                         (Terminator)
         ^----- Haupt-Stammleitung ------^

Wichtige Grenzen

• Max. Geräte: 172 Knoten auf einem Bus
• Max. Buslänge: Abhängig von der Drahtgröße (z.B. 265m für 20 AWG)
• Max. Abzweiglänge: 6 Meter pro Gerät
• Terminierung: Zwei 120Ω Widerstände (einer an jedem Ende)
• Geschwindigkeit: 250 kbit/s (fest)

Nachrichtenstruktur

Jede RV-C-Nachricht verwendet das CAN Extended Frame Format (29-Bit-Identifier + 8 Datenbytes).

Aufschlüsselung der Nachrichten-ID

Die 29-Bit-CAN-ID ist in aussagekräftige Teile unterteilt:

┌─────────────────────────────────────────────────┐
│  Priorität  │ DGN-High │  DGN-Low  │   Source   │
│   (3 Bits)  │ (7 Bits) │  (8 Bits) │  Address   │
│             │          │           │  (8 Bits)  │
└─────────────────────────────────────────────────┘
    Bits         Bits       Bits         Bits
   28-26        24-18      15-8          7-0

Komponenten:

• Priorität (3 Bits): Nachrichtendringlichkeit (0=höchste, 7=niedrigste, üblicherweise 6 für Status)
• DGN (Data Group Number, 17 Bits): Identifiziert die Art der Daten
  • DGN-High (7 Bits): Haupt-Nachrichtenkategorie
  • DGN-Low (8 Bits): Entweder Unter-Kategorie ODER Zieladresse für Befehle
• Source Address (8 Bits): Welches Gerät diese Nachricht gesendet hat (0-253)

Daten-Payload

Immer 8 Bytes Daten, auch wenn nicht alle verwendet werden. Ungenutzte Bytes werden mit 0xFF gefüllt.

Schlüsselkonzepte

Source Address (SA)

Jedes Gerät im Netzwerk benötigt eine eindeutige 8-Bit-Adresse (0-253).

Zwei Wege, eine Adresse zu erhalten:

• Statisch: Fest codierte Adresse (z.B. Generator ist immer 35)
• Dynamisch: Gerät beansprucht beim Start eine Adresse über das Address-Claiming-Verfahren

Wichtig:

• Die Source Address identifiziert den Mikroprozessor/Knoten, nicht das physische Gerät
• Ein Mikroprozessor kann mehrere Geräte verwalten (z.B. eine Platine, die 3 Markisen steuert)

Gerätetyp

Definiert, was ein Gerät kann. Beispiele:

• Markise
• Thermostat (Klimasteuerung)
• Generator
• Wechselrichter
• DC-Last (Lichter, Pumpen usw.)
• Warmwasserbereiter

Jeder Gerätetyp hat:

• Spezifische Nachrichten (DGNs), die er senden/empfangen kann
• Eine Standard-Source-Adresse (DSA) für Diagnosen

Instanz

Da Wohnmobile oft mehrere Geräte desselben Typs haben (z.B. 7 Markisen, 4 Thermostate), verwendet RV-C Instanzen, um sie zu unterscheiden.

So funktioniert es:

• Die Instanz ist das erste Datenbyte in Nachrichten von Multi-Instanz-Geräten
• Instanz 1 = Haupt-Terrassenmarkise
• Instanz 2 = Seitenmarkise
• Instanz 3 = Heckmarkise usw.

Wichtiger Unterschied:

• Source Address = Welcher Mikroprozessor hat die Nachricht gesendet
• Instanz = Welches physische Gerät wird beschrieben/gesteuert

Beispiel: Ein Thermostat-Controller (SA=100) kann 4 Zonen (Instanzen 1-4) steuern

Nachrichtentypen

1. Informationsaustausch (Statusnachrichten)

Geräte senden regelmäßig ihren Status:

• Generator: “Ich laufe mit 50% Last, 240V AC, 3500 RPM”
• Batteriemonitor: “Batterie ist zu 85% geladen, 13,2V, 15A Ladestrom”
• Thermostat: “Zone 1 ist 72°F, eingestellt auf 70°F, Klimaanlage läuft”

Eigenschaften:

• Priorität: Normalerweise 6
• Broadcast-Intervall: Variiert (mindestens 50ms Abstand)
• Kann “bei Änderung” oder nach Zeitplan senden

2. Steuernachrichten (Befehle)

Geräte senden Befehle an andere Geräte:

• Bedienfeld → Markise: “Fahre Markise #2 aus”
• Thermostat → Klimaanlage: “Einschalten, auf 70°F einstellen”

Ziel-Adressierung:

• Für Multi-Instanz-Geräte: Erstes Datenbyte enthält Ziel-Instanz
• Für direkte Befehle: DGN-Low enthält Ziel-Source-Adresse

3. Informationsanfrage

Ein Gerät kann sofortige Daten von anderen anfordern:

• “Bitte sende mir JETZT deine aktuelle Temperaturmessung”
• Verwendet spezielles DGN: EA00h

4. Diagnosenachrichten (DM-RV)

Jedes Gerät muss seinen Gesundheitsstatus melden:

• Betriebsstatus (normal, Warnung, Fehler)
• Fehlercodes (welche Komponente ist ausgefallen)
• Wird regelmäßig gesendet, auch wenn alles in Ordnung ist

Spezielle Datenwerte

RV-C definiert zwei universelle Werte für alle Datentypen:

“Daten nicht verfügbar”

• Alle Bits auf 1 gesetzt (0xFF, 0xFFFF usw.)
• Bedeutung hängt vom Kontext ab:
  • In Befehlen: “Diesen Wert nicht ändern”
  • Im Status: “Dieser Sensor wird nicht unterstützt” oder “Daten noch nicht bereit”

“Fehler / Außerhalb des Bereichs”

• Alle Bits auf 1 gesetzt außer dem MSB (0xFE, 0xFFFE usw.)
• Im Status: “Sensorfehler oder anormaler Zustand”
• Wird nie in Befehlen verwendet

Praktisches Beispiel: Steuerung einer Markise

Gehen wir Schritt für Schritt durch das Ausfahren von Markise #2:

1. Benutzer drückt “Ausfahren” am Bedienfeld

2. Bedienfeld sendet AWNING_COMMAND-Nachricht:

CAN ID:
  Priorität: 3 (hoch, weil es ein Befehl ist)
  DGN: 1FED9 (Awning Command)
  Source Address: 80 (Bedienfeld)

Datenbytes:
  Byte 0: 2 (Instanz = Markise #2)
  Byte 1: 1 (Befehl = Ausfahren)
  Byte 2-7: 0xFF (nicht verwendet)

3. Markisen-Controller empfängt Nachricht

• Lauscht auf DGN 1FED9
• Prüft Byte 0 (Instanz): “Ist das für mich?”
• Instanz = 2? Ja! Befehl ausführen.

4. Markise fährt aus und sendet Status

CAN ID:
  Priorität: 6 (normaler Status)
  DGN: 1FEE5 (Awning Status)
  Source Address: 45 (Markisen-Controller)

Datenbytes:
  Byte 0: 2 (Instanz = Markise #2)
  Byte 1: 50 (Position = 50% ausgefahren)
  Byte 2: 1 (Status = Fährt aus)
  Byte 3-7: Andere Statusdaten

5. Bedienfeld empfängt Status und aktualisiert Anzeige

• “Markise #2: Fährt aus… 50%”

Compliance-Level

RV-C definiert zwei Compliance-Level:

Level One

Grundlegende Netzwerkteilnahme

• Address Claiming (falls dynamisch)
• Antworten auf erforderliche Nachrichten
• Aufrechterhaltung der Netzwerkintegrität

Level Two

Vollständige Interoperabilität

• Verwendung geeigneter DGNs für den Gerätetyp
• Korrekte Diagnoseberichterstattung
• Aussagekräftige Fehlerantworten (NAKs)
• Dokumentation aller Funktionen

Kurzreferenz: Häufige DGNs

Hier sind einige häufig verwendete Data Group Numbers:

(Vollständige Liste von über 100 DGNs in Abschnitt 6 der Spezifikation)

Protokoll-Referenzen

• RV-C Official Website ↗ - Offizielle RV-C-Spezifikation und Updates
• CAN-Bus-Spezifikation ↗ - Zugrunde liegende CAN-Protokollstandards