userpages:rainerk:rk-railcom-basics-de
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
userpages:rainerk:rk-railcom-basics-de [2019/09/25 18:05] – rainerk | userpages:rainerk:rk-railcom-basics-de [2022/11/09 01:33] (current) – removed rainerk | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== RailCom-Basics ====== | ||
- | * [[: | ||
- | |||
- | \\ | ||
- | ===== Kapitel 1 - 3 aus NMRA S-9.3.2 ===== | ||
- | Deutsche Textabschnitte aus **[[http:// | ||
- | |||
- | ==== 1. Übersicht ==== | ||
- | Die von Lenz Elektronik entwickelten und verwendeten elektronischen Steuerungen, | ||
- | Diese Spezifikation gilt ausschließlich für die Anwendung von RailCom innerhalb des DCC-Datenformats (Protokolls). Die Anwendung von RailCom innerhalb anderer Datenformate ist nicht zugelassen. | ||
- | |||
- | ==== 2. Physikalische Ebene ==== | ||
- | === 2.1. Allgemeine Information === | ||
- | Der Informationsfluss im DCC-System erfolgt normalerweise von der Zentrale (Booster) über das Gleis zu den Decodern. Für die umgekehrte Übertragungsrichtung ist es erforderlich, | ||
- | | {{: | ||
- | | Abbildung 1: Anordnung von Booster, Detector und Decoder während des RailCom-Cutout.|\\ | ||
- | |||
- | === 2.2. RailCom–Sender im Decoder === | ||
- | Um eine ' | ||
- | | {{: | ||
- | | Abbildung 2: Eine mögliche Hardware-Realisierung |\\ | ||
- | |||
- | **Erläuterung der Schaltplan-Darstellung: | ||
- | Der RailCom–Teil besteht nur aus den Widerständen R1 bis R3 und den Transistoren T1a bis T2b. T1a und T1b bilden eine Stromquelle, | ||
- | Alle anderen Teile der Schaltung gehören zur normal notwendigen Hardware des Decoders. Man beachte den äußest geringen Hardwareaufwand für den RailCom–Sender. | ||
- | |||
- | === 2.3. Der RailCom-Detektor === | ||
- | Ein Detector muss einen Strom von größer 10 mA während der mittleren 50% der Bitzeit als ' | ||
- | | {{: | ||
- | | Abbildung 3: Ein Beispiel für den Schaltplan eines einfachen RailCom-Detektors |\\ | ||
- | |||
- | Der Spannungsabfall über dem Cutout-Gerät darf 10 mV bei maximal 34 mA während des Cutout nicht übersteigen.\\ | ||
- | Es dürfen maximal zwei Detektoren (inkl. des globalen Detektors) in Reihe verwendet werden, wobei der lokale Detektor einen Anschluss für externe Auswertung einer Gleisbelegung enthalten sollte. Ist dies nicht der Fall, müssen extern verwendete Belegtmelder für RailCom spezifiziert sein.\\ | ||
- | |||
- | **Erläuterung: | ||
- | Getestet wurden diese Schaltungen (Sender und Detektor) auf großen Clubanlagen bis zu einer Entfernung von 100m. Diese Entfernung wurde problemlos überbrückt. Zugelassen sind dabei – nicht vom Gleis durch Brückengleichrichter isolierte - Verbraucher von 5 Ohm, die parallel zum Messwiderstand des Detektors liegen. \\ | ||
- | Der Wert von 5 Ohm entspricht bei einer Gleisspannung von 15V einem Strom von 3A. \\ | ||
- | Glühlampen (Kaltleiter) sind immer über einen schnellen Brückengleichrichter (<500ns) zu betreiben. \\ | ||
- | |||
- | === 2.4. Timing === | ||
- | In einem Cutout können bis zu 8 Byte Daten übertragen werden. Jedes übertragene Byte beginnt mit einem Startbit (' | ||
- | Das RailCom-Cutout ist in zwei Kanäle unterteilt. Im Kanal 1 können 2 Bytes, im Kanal 2 bis zu 6 Bytes übertragen werden. Abbildung 4 zeigt das Timing-Diagramm. Sämtliche Zeiten sind auf den Null-Durchgang des letzten Flankenwechsels des Packet-End-Bits bezogen.\\ | ||
- | | {{: | ||
- | | Abbildung 4: Timing-Diagramm | | ||
- | \\ | ||
- | | {{: | ||
- | | Tabelle 1: Timing-Parameter |\\ | ||
- | |||
- | **Bemerkung: | ||
- | Obige Abbildung zeigt das RailCom-Timing mit ' | ||
- | Eine Cutout-Zeit von ca. 450 μs darf die Funktion eines Decoders, der RailCom nicht beherrscht, nicht beeinflussen, | ||
- | |||
- | === 2.5. Sicherung der Datenübertragung === | ||
- | Die Sicherung der Datenübertragung erfolgt via 4/8 Codierung, d.h. jedes übertragene Byte enthält 4 ' | ||
- | Es gibt 70 verschiedene Bitkombinationen innerhalb eines Bytes, die dieses Verhältnis 4:4 aufweisen. Davon werden 64 für die Übertragung von 6 Nutzbits verwendet, von den 6 übrigen werden 3 für kurze Sondermitteilungen genutzt, ACK, NACK und BUSY. Die restlichen drei Kombinationen werden im Moment nicht benutzt.\\ | ||
- | Es lassen sich in Kanal 1 netto 12 Bit, in Kanal 2 netto bis zu 36 Bit Nutzdaten übertragen.\\ | ||
- | Die möglichen Codierungen: | ||
- | |||
- | | {{: | ||
- | | Tabelle 2: 4/ | ||
- | |||
- | ==== 3. Paket-Ebene ==== | ||
- | Dieses Kapitel beschreibt den Aufbau von RailCom-Paketen.\\ | ||
- | RailCom-Pakete (im folgenden mit Datagramm bezeichnet) haben eine Länge von 6, 12, 18 oder 36 Nutz-Bits. Somit ergeben sich für die beiden Kanäle folgende Übertragungsmöglichkeiten: | ||
- | |||
- | | {{: | ||
- | | Tabelle 3: Übertragungs-Optionen |\\ | ||
- | |||
- | Datagramme (außer ACK/ | ||
- | |||
- | | {{: | ||
- | | Tabelle 4: Datagramm-Struktur |\\ | ||
- | |||
- | Die Länge des Datagramms ist durch den Identifier bestimmt. Die Identifier werden weiter unten definiert.\\ | ||
- | Mobile Decoder (Lok-Decoder) und stationäre Decoder (Accessory-Decoder) haben unterschiedliche Rückmeldeanforderungen. Entsprechend werden die Kanäle für beide Decodertypen unterschiedlich genutzt. Die Bedeutung der Datagramme ist somit abhängig von der Adresse des vorangestellten DCC-Pakets. Daneben gibt es Systemanforderungen die alle Decoder gleichermaßen erfüllen müssen. Für diesen Zweck wird die DCC-Adresse 255 als " | ||
- | |||
- | | {{: | ||
- | | Tabelle 5: Befehls-Typen und System-Adressen |\\ | ||
- | |||
- | Auf andere Adressen sowie auf Service-Mode-Pakete dürfen Decoder keine Rückmeldung senden. | ||
- | |||
- | === 3.1. RailCom Befehls-Typ MOB === | ||
- | __Kanal 1__ nutzen mobile Decoder zur schnellen Lokalisierung auf der Anlage (siehe app:adr). Dazu müssen sie nach jedem an einen mobilen Decoder gerichteten DCC-Paket ihre DCC-Adresse senden, die dann von lokalen Detectoren auf der Anlage empfangen wird. Ausgenommen sind die Servicemode Packets von dem Zeitpunkt an, zu dem der Decoder den Servicemode erkennt.\\ | ||
- | __Kanal 2__ darf nur vom adressierten Decoder benutzt werden und dient zur Übermittlung von Decoderinformationen. Ein adressierter Decoder muss stets eine Rückmeldung in Kanal 2 senden (gegebenfalls ACK/ | ||
- | Eine Rückmeldung im Kanal 2 signalisiert, | ||
- | Die folgenden Identifier (Datagramme) sind für mobile Decoder definiert: | ||
- | |||
- | | {{: | ||
- | | Table 6: Befehls-Typ MOB Kennzeichnung (Datagramme) |\\ | ||
- | |||
- | " | ||
- | " | ||
- | **Bemerkung: | ||
- | Ältere Decoder haben während einer Testphase verschiedene Identifier belegt, die jetzt als "nicht freigegeben" | ||
- | Ältere Decoder ohne Versionsnummer sollte man updaten (lassen). | ||
- | |||
- | === 3.2. RailCom Befehls-Typ STAT === | ||
- | Die RailCom Spezifikation für ortsfeste Decoder ist noch nicht abgeschlossen. Alle Angaben dazu sind als vorläufig zu betrachten.\\ | ||
- | Ortsfeste Decoder nutzen Kanal 1 zur Meldung von Service Request Anforderungen (siehe app:srq). Dazu können sie in jedem an einen ortsfesten Decoder gerichteten DCC Paket ihre Identität (12-Bit Adresse) senden (12 Bit Wert ohne Identifier !!) (Nicht bei Adressierung via Decoder ID). Melden sich mehrere Decoder gleichzeitig muss eine Suche gestartet werden.\\ | ||
- | Kanal 2 darf nur vom adressierten Decoder benutzt werden und dient zur Übermittlung von Decoderinformationen. Ein adressierter Decoder muss stets eine Rückmeldung in Kanal 2 senden (gegebenfalls ACK) um den fehlerfreien Empfang des DCC-Pakets zu bestätigen.\\ | ||
- | Eine Rückmeldung im Kanal 2 signalisiert, | ||
- | Die folgenden Identifier (Datagramme) sind für stationäre Decoder definiert: | ||
- | |||
- | | {{: | ||
- | | Table 7: Befehls-Typ STAT Kennzeichnung (Datagramme) |\\ | ||
- | |||
- | " | ||
- | " | ||
- | \\ | ||
- | |**Die Abschnitte 4.ff sind bisher nicht erfasst.**| |
userpages/rainerk/rk-railcom-basics-de.1569427550.txt.gz · Last modified: 2019/09/25 18:05 by rainerk