Differences

This shows you the differences between two versions of the page.

--- 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 ======
-  * [[:userpages#rainer_kuempel|Userpages RainerK]]
-\\
-===== Kapitel 1 - 3 aus NMRA S-9.3.2 =====
-Deutsche Textabschnitte aus **[[http://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf|NMRA Standard S-9.3.2 DCC Basic Decoder Transmission]]**((Die vorliegende Fassung vom 02.12.2012 befindet sich auch z.Zt. (02.2019) noch "UNDER REVISION")) \\
-==== 1. Übersicht ====
-Die von Lenz Elektronik entwickelten und verwendeten elektronischen Steuerungen, insbesondere jene betreffend des Europäischen Patents 1 380 326 B1 werden unter der markenmäßigen Kennzeichnung "RailCom" angeboten und in den Verkehr gebracht. "RailCom" ist eine auf den Namen von Lenz Elektronik für die Klasse 9 "Elektronischen Steuerungen" unter der Nummer 301 16 303 eingetragene Deutsche Marke sowie ein für die Klassen 21, 23, 26, 36 und 38 " Electronic Controls for Model Railways" in U.S.A. unter Reg.Nr. 2,746,080 eingetragenes Trademark.\\
-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, diesen Datenstrom zu unterbrechen. Dies geschieht durch die Booster, die dazu am Ende eines jeden DCC-Packets ein sogenanntes RailCom-Cutout (Ausschnitt) erzeugen, in dem sie die beiden Gleis-Leitungen von der Spannungsversorgung trennen und kurzschliessen. Die eigentliche Datenübertragung erfolgt mittels einer Stromschleife. Den dazu notwendigen Strom muss der Decoder aus seinem internen Puffer bereitstellen.
-| {{:users:rainerk:nmra-s-9.3.2:figure1.png?600}} |
-| Abbildung 1: Anordnung von Booster, Detector und Decoder während des RailCom-Cutout.|\\
-=== 2.2. RailCom–Sender im Decoder ===
-Um eine '0' zu übertragen muss der Decoder einen Strom **I** von 30 +4/-6 mA liefern, bei einem Spannungsabfall am Gleis von bis zu 2,2V. Bei einer '1' darf der Strom **I** höchstens +/-0,1 mA betragen. Die Stromquelle des Decoders muss gegen unerwartete Fremdspannung am Gleis während des Cutout geschützt sein. \\
-| {{:users:rainerk:nmra-s-9.3.2:figure2.png?600}} |
-| 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, T2a ist als Diode geschaltet und schützt die Stromquelle vor positiven Spannungen höher Vcc.\\
-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 '0' interpretieren, einen Strom von kleiner 6 mA während der mittleren 50% der Bitzeit als '1'. Der Spannungsabfall über dem Detector darf 200 mV bei maximal 34 mA während des Cutout nicht übersteigen.
-| {{:users:rainerk:nmra-s-9.3.2:figure3.png?600}} |
-| 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 ('0'), den 8 Datenbits (niederwertigstes Bit zuerst) und endet mit einem Stopbit ('1'). Die Übertragungsrate ist 250 kBit/s +/- 2%. Die Anstiegszeit (10% → 90%) und Abfallzeit (90% → 10%) darf 0,5 μs nicht überschreiten.\\
-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.\\
-| {{:users:rainerk:nmra-s-9.3.2:figure4.png?600}} |
-| Abbildung 4: Timing-Diagramm |
-\\
-| {{:users:rainerk:nmra-s-9.3.2:table1.png?600}} |
-| Tabelle 1: Timing-Parameter |\\
-**Bemerkung:**\\
-Obige Abbildung zeigt das RailCom-Timing mit '1'-Bits von 2 * 58 μs (Nominalwert des DCC '1'-Bit). Bei kürzeren '1'-Bits ist es möglich, dass das Cutout ins 5. '1'-Bit hineinreicht. Dies ist aber kein Problem, da eine Zentrale mindestens 4 + 12 = 16 Präambelbits senden muss (Stopbit des vorherigen DCC-Pakets nicht mitgezählt), der Decoder also ausreichend Präambelbits (mindestens 11; 10 sind notwendig) sieht.
-Eine Cutout-Zeit von ca. 450 μs darf die Funktion eines Decoders, der RailCom nicht beherrscht, nicht beeinflussen, da auf einer realen Modellbahnanlage Stromunterbrechungen bis 20 ms nachgewiesen wurden, d.h. ein Decoder sollte mindestens eine Stromunterbrechung in dieser Größenordnung verarbeiten können.\\
-=== 2.5. Sicherung der Datenübertragung ===
-Die Sicherung der Datenübertragung erfolgt via 4/8 Codierung, d.h. jedes übertragene Byte enthält 4 '1'- und 4 '0'-Bits. Ist dieses Verhältnis verletzt, liegt ein Übertragungsfehler vor.\\
-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:\\
-| {{:users:rainerk:nmra-s-9.3.2:table2.png?600}} \\{{:users:rainerk:nmra-s-9.3.2:table2b.png?600}}|
-| Tabelle 2: 4/8-Encodierung |\\
-==== 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:\\
-| {{:users:rainerk:nmra-s-9.3.2:table3.png?600}} |
-| Tabelle 3: Übertragungs-Optionen |\\
-Datagramme (außer ACK/NACK/BUSY) beginnen, wenn nicht anders erläutert, mit einem 4-Bit-Identifier (Kennzeichen), gefolgt von 8, 14 oder 32 Bit Nutzdaten, die wie folgt übertragen werden:\\
-| {{:users:rainerk:nmra-s-9.3.2:table4.png?600}} |
-| 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 "Systemadresse" festgelegt. Entsprechend werden die folgenden RailCom-Befehlsarten MOB (mobil) und STAT (stationär) anhand der DCC-Adresse unterschieden:
-| {{:users:rainerk:nmra-s-9.3.2:table5.png?600}} |
-| 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/NACK/BUSY) um den fehlerfreien Empfang des DCC-Pakets zu bestätigen.
-Eine Rückmeldung im Kanal 2 signalisiert, dass der Decoder den Befehl fehlerfrei empfangen hat, nicht jedoch dass der Befehl vom Decoder auch akzeptiert und ausgeführt wird.\\
-Die folgenden Identifier (Datagramme) sind für mobile Decoder definiert:\\
-| {{:users:rainerk:nmra-s-9.3.2:table6.png?600}} \\ {{:users:rainerk:nmra-s-9.3.2:table6b.png?600}} |
-| Table 6: Befehls-Typ MOB Kennzeichnung (Datagramme) |\\
-"required (erforderlich)" bedeutet vollständige Implementierung. \\
-"optional": entweder vollständige Implementierung oder: teilweise Implementierung mit den unter 4.1 genannten Bedingungen. \\
-**Bemerkung:**\\
-Ältere Decoder haben während einer Testphase verschiedene Identifier belegt, die jetzt als "nicht freigegeben" gekennzeichnet sind. Neuere Decoder müssen in einer speziellen CV (siehe Abschnitt "RailCom CVs") die RailCom-Versionsnummer eingetragen haben. Dies kann zur Unterscheidung benutzt werden.\\
-Ä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, dass der Decoder den Befehl fehlerfrei empfangen hat, nicht jedoch dass der Befehl vom Decoder auch akzeptiert und ausgeführt wird.\\
-Die folgenden Identifier (Datagramme) sind für stationäre Decoder definiert:
-| {{:users:rainerk:nmra-s-9.3.2:table7.png?600}} |
-| Table 7: Befehls-Typ STAT Kennzeichnung (Datagramme) |\\
-"mandatory (zwingend)" bedeutet vollständige Implementierung \\
-"optional": entweder vollständige Implementierung oder: teilweise Implementierung mit den unter 4.1 genannten Bedingungen\\
-\\
-|**Die Abschnitte 4.ff sind bisher nicht erfasst.**|