Vorschlag Norm: RCN218

DCC-A, Automatische Dekoderanmeldung mit DCC/Railcom

    Revision:
     0.01 2019-01-22 kw start
     0.02 2019-02-11 kw get info - no tid
     0.03 2019-03-19 kw Redaktionelle Überarbeitung
     0.04 2019-04-09 kw Befehlslängen inkl. Prüfbyte
     0.05 2019-06-17 kw Update nach Arbeitskreistreffen

Inhalt

Vorbemerkung

    Im Zuge der Diskussionen zu DCC-A ist eine Präsentation entstanden, welche die wesentlichen Leitgedanken zusammenfaßt. The Way to DCC-A

1. Allgemeines

Zweck der Norm, Ziele

    Diese Norm beschreibt DCC-A, ein automatisches Anmeldeverfahren für DCC. Damit wird die Anwenderfreundlichkeit von Modellbahnsteuerungen signifikant erhöht. Bei Anwendung dieser Norm wird der Benutzer bei der Vergabe von Adressen und Zuweisung von Funktionen entlastet. Ziel ist es, z.B. ein Fahrzeug nach dem Aufgleisen sofort mit Namen und allen Eigenschaften im Stellpult verfügbar zu haben.
    Anwendung dieser Norm bietet:
  • Super schnelles Anmelden - echtes Plug&Play. Auspacken, aufs Gleis, loslegen.
  • Direkte Verfügbarkeit der Eigenschaften des Dekoders / der Lok
  • Bequemer Dekoderupdate ohne Lok öffnen, ohne Herstellerprogrammer
  • Aufwandsarme Implementierung sowohl für Zentralen als auch für Dekoder
  • Kompatibilität zu vorhandenen Dekodern und Zentralen

    • Diese Norm setzt auf die in den Normen [RCN211] und [RCN217] beschriebenen Paketstrukturen für DCC bzw. für Railcom auf. Zuigehörige Datendefinitionen finden sich in [RCN219]
    Für die Implementierungsunterstützung in der Zentrale/Dekoder stehen header-Dateien und Beispiele zur Prüfsummenberechnung bereit.

Anforderungen

    Um diese Norm zu erfüllen, ist es erforderlich, dass alle hier genormten Befehle und Datenstrukturen unterstützt werden. Optionale Bestandteile sind separat gekennzeichnet. Der korrekte Empfang der in dieser Norm definierten Nachrichten ist für den Anmeldevorgang wichtig. Damit dies gewährleistet ist, sind folgende Vorgaben einzuhalten:
  • Die in dieser Norm definierten Befehle sollten nur bei fest verbundenen Dekoder oder stehendem Fahrzeugen angewendet.
  • Zur Dekodierung der in dieser Norm definierten Befehle sind beide Flanken der jeweiligen DCC-Bits auszuwerten. Damit wird ein möglicher Falschempfang trotz korrekter Prüfsumme wirksam verhindert.
    • Mit der Anmeldefähigkeit nach dieser Norm gibt der Dekoder implizit zu erkennen, dass er XPOM und Pageadressierung über CV31/CV32 sowie die entsprechenden Short-Write Nachrichten zum Setzen der Adresse bzw. zum Setzen von CV31/32 beherrscht.

Glossar, Definitionen

    Innerhalb dieser Norm gelten folgende Festlegungen:
    Darstellung
    BitorderDie Bits eines Bytes werden von 0 bis 7 gezählt. Bit 0 ist das niederwertigste Bit und steht ganz rechts und Bit 7 ist das höchstwertigste und steht ganz links.
    Zwischen den Bits 4 und 3 wird für eine bessere Lesbarkeit ein Strich eingefügt: 7654-3210.
    DCC-PaketeAbgesehen von der Beschreibung des Aufbaus der DCC-Pakete im Abschnitt 3 werden folgend Bit aus Gründen der Übersichtlichkeit nicht dargestellt:
    • die Nullen zwischen den Bytes eines DCC-Paketes
    • die Synchronbits
    • das einleitende Byte 1111-1110
    • das Prüfbyte PPPP-PPPP
    Damit sind die DCC-Pakete immer 2 Byte länger als der dargestellte Befehl.
    PlatzhalterPlatzhalter stehen für je ein Bit, kleine Buchstaben bezeichnen bei gleichartigen Platzhalter die Position des LSB.
    Glossar
    UniqueID:Die von Hersteller in den Baustein (Dekoder/Zentrale) fest programmierte, eineindeutige Kennung, bestehend 12 Bit Herstellerkennung und 28 Bit herstellerspezifischer Nummer (z.B. Produktindex und Seriennummer).
    Sofern eine Eingabe/Darstellung erforderlich ist, soll diese im folgenden Format erfolgen:
    VVV:PPPPPpp (Ausnahme: Hierbei steht jeder Buchstabe für ein Hexzeichen (Nibble)), VVV bezeichnet die VendorID (12 Bit), PPPPPPPpp bezeichnet die eindeutige Kennung (als 28 Bit Hex), diese wird (wie sonst auch in DCC typisch) als Big endian dargestellt. pp bezeichnet also das niederwertigste Byte. Bei der Herstellerkennung stehen in ersten Byte die unteren 8 Bit der Kennung nach S-9.2.2).
    DID:Die UniqueID eines Dekoders.
    CID:Die Kennung der Zentrale.
    SessionID:Eine Variable, welche die aktuellen Betriebsphase kennzeichnet.
    Backoff:Sollte ein Dekoder nach einer versuchten Anmeldung keine Bestätigung erhalten, so beantwortet diese (variable) Anzahl von LOGON_ENABLE-Nachrichten nicht mehr.
    DCC-Länge:Bezeichnet alle DCC-Bytes inkl. Prüfbyte.

2. Genereller Ablauf

    Dekoder werden bei einer DCC-Ansteuerung parallel angesteuert. Deshalb ist ein Adressierungsschema erforderlich. Zur Unterscheidung von mehreren Dekodern wird eine eindeutige Kennung verwendet (UniqueID). Ausgehend von dieser UniqueID wird den Dekodern eine verkürzte (Sitzungs-)Adresse zugewiesen, um in laufenden Betrieb die knappe Resource 'DCC-Bandbreite' möglichst optimal zu nutzen. Sofern möglich, wird bei der Sitzungsadresse die bisherige Dekoderadresse verwendet. Hierzu wird zu Beginn eine Anmeldeprozedur durchgeführt, um diese Zuordnung durchzuführen und die Dekoder-/Fahrzeugeigenschaften für die Steuerung des Fahrzeuges bekannt zu machen.

    Die automatische Anmeldung unterteilt sich in folgende Hauptphasen:
  • Vereinzelungsphase:
    Hier werden die vorhandenen Dekoder ermittelt und fallweise auftretende Zugriffkonflikte gelöst. Am Ende der Vereinzelungsphase sind der Zentrale die DIDs der vorhandenen Dekoder bekannt.
  • Bekanntmachungsphase:
    Hier tauschen Zentrale und Dekoder Informationen über zu verwendende Adresse, Loknamen, vorhandene Funktionen usw. aus.
  • Registrierung:
    Der Dekoder wird an die Zentrale registriert und kann in Folge betrieblich kontrolliert ('gesteuert') werden.
    • Zur Beschleunigung des Anmeldeverfahrens kann und soll die Zentrale versuchen, aus der letzten Betriebsphase bereits bekannte Dekoder direkt ohne Vereinzelungsphase zu registrieren.

Vereinzelungsphase

    Die Zentrale sendet Aufforderungen an die Dekoder, sich anzumelden (Befehl: LOGON_ENABLE). Diese Logonaufforderungen enthalten eine eindeutige Kennung Zentralen/AnlagenID (Hash) und eine SessionID, die Dekoder können anhand der ID die Zentrale nach einem PowerCycle wieder erkennen. Die Dekoder antworten auf den Befehl LOGON_ENABLE nach bestimmten Regeln mit einem Logon. Dieser Logon trägt in sich die UniqueID des Dekoders.

    Wenn bereits viele Dekoder in der Zentrale bekannt sind oder lokale Railcomdetektoren verwendet werden, wird diese Phase kurz sein. Bei Kollisionen von gleichzeitigen Antworten mehrerer Dekoder ist die Erkennung nicht sicher, es wird dann eine Vereinzelung mittels dynamischen Backoff der Dekoder durchgeführt. Die Vereinzelung erfolgt (gekennzeichnet durch die Kodierung des LOGON_ENABLE Befehls) getrennt für Zubehördekoder und mobile Dekoder oder gemeinsam.

Bekanntmachungsphase

    Die Zentrale bestätigt die Anmeldung und spricht den Dekoder über seine DID an (Befehle: SELECT_INFO / GET_DATA). Der Dekoder weiß nun, dass sein Logon erkannt wurde und übermittelt in der zugehöigen Railcom-Antwort eine Zusammenfassung seiner wichtigsten Steuerparameter wie z.B. die gewünschte Dekoderadresse bzw. weitere Informationen.

Registrierung

    Die Zentrale weist dem Dekoder eine Lokadresse zu, welche in dieser Sitzung zu verwenden ist. (LOGON_ASSIGN). Der Dekoder beantwortet diese Nachricht mit einer Revisionskennung (inkrementale Nummer / Hash seiner CVs), damit kann die Zentrale überprüfen, ob die (eventuell bereits bekannten) Parameter des Dekoders weiterhin gültig sind oder ob weitere Ausleseaktionen bzw. Einmessen erforderlich sind.

Beschleunigtes Einlesen von Dekoderparametern:

    Die Bandbreite von DCC / Railcom erfordert eine effiziente Nutzung, um Daten in akzeptabler Geschwindigkeit aus dem Dekoder in die Zentrale zu bringen.
    Hierzu werden die relevanten Informationen im Dekoder in Datenräume unterteilt. Jeweils ein kompletter Datenraum kann mit den Befehlen SELECT_INFO / GET_DATA ausgelesen werden. Die Gruppen umfassen u.a. Dekodereigenschaften, Loknamen, Funktionsmapping, Lokbild, CV-direkt, ...

3. DCC-Nachrichten

    Generell gilt für alle DCC-Befehle zur automatischen Anmeldung folgendes Format:
    {Synchronbits} 0 1111-1110 0 {Befehlsbytes} 0 PPPP-PPPP 1
    Generell beginnen alle Befehle zur automatischen Anmeldung mit 1111-1110. Das erste Befehlsbyte gibt die Art des Befehls an, weitere Bytes legen die Parameter fest. Eine DCC-Nachricht kann dabei bis zu einer maximalen Länge von 11 Bytes lang werden (inkl Parity).

Befehlscodierung

    Das erste Byte eines Befehls legt die Art des Befehls fest. Nachfolgend eine Übersicht aller Befehle, sortiert nach dem Wert des ersten Bytes. In den folgenden Abschnitten werden die Befehle dann nach ihrer Funktion sortiert beschrieben.
    Befehlsbyte LängeEvalRailcom-AntwortBedeutung
    0000-0000 - - keine reserved
    0000-0001 3 histID14, D_ID, Data GET_DATA: Datenabfrage Transportbefehl
    0000-0010 11 histID14, D_ID, Data SET_DATA: Datenschreiben Quittung
    000.-.... - - keine reserved
    0001-1111 3 bc keine FW_UPDATE_RESET Abbruch FW-Update
    0011-nnnn 11 histID12, FW-ACK FW_UPDATE_DATA_n
    0100-0000 11 did ID12, FW-ACK FW_UPDATE_SET_TARGET
    0100-0001 11 did ID12, FW-ACK FW_UPDATE_SET_BASE
    0100-0010 10 did ID12, FW-ACK FW_UPDATE_SET_SIZE
    0100-0011 8 did ID12, FW-ACK FW_UPDATE_QUERY
    0100-0100 8 did ID12, FW-ACK FW_UPDATE_END
    ....-.... - did keine reserved
    1100-xxxx 9/11 did ID13, Stat SELECT_INFO_RD: Auswahl Datenbereich im Dekoder zum Lesen, zugleich Logon-Bestätigung
    1101-xxxx 9/11 did ID13, Stat SELECT_INFO_WR: Auswahl Datenbereich im Dekoder zum Schreiben, zugleich Logon-Bestätigung
    1111-0000 10 did ID13, Stat LOGON_ASSIGN: Adresszuordnung, Betriebserlaubnis
    1111-11.. - - keine reserved
    1111-11xx 6 backoffID15, Logon LOGON_ENABLE: Anmeldeaufforderung (xx = Mode)
    Hinweise:
  • Die Spalte Länge gibt die gesamte Befehlslänge in Bytes (inkl. Paritybyte) an.
  • Eval bezeichnet die im Dekoder nötige Auswertung:
    • hist: Auswertung und Railcomantwort abhängig von der Vorgeschichte
    • did: Auswertung und Railcomantwort nur bei zutreffender Dekoder-UniqueID
    • bc: Broadcast, Auswertung, aber keine Railcomantwort.
    • backoff: Auswertung und Railcomantwort je Befehl und Algorithmus (nur wenn noch nicht angemeldet)

LOGON_ENABLE

    Dieser Befehl ist 6 Byte lang und hat das Format:
    0 1111-1110 0 1111-11tt 0 TTTT-TTTT 0 tttt-tttt 0 ssss-ssss 0 PPPP-PPPP 1
    Das ist die Anmeldeaufforderung, diese wird von der Zentrale periodisch ausgesendet. Die Anmeldeaufforderung ist mindestens alle 2000ms auszusenden. Nach dem Systemstart empfiehlt sich eine häufigere Aussendung.
    Parameter Bedeutung
    tt tt bestimmt, welche Decoder reagieren dürfen
    00ALL: Alle Dekoder
    01LOCO: Nur mobile Dekoder
    10ACC: Nur stationäre Dekoder
    11NOW: Alle Dekoder (ohne Beachtung von backoff)
    TTTT-TTTT Track Identifier der CID, MSB
    tttt-tttt Track Identifier der CID, LSB
    ssss-ssss Sitzungsnummer
    Als Antwort senden die Dekoder ihre UniqueID (DID) bzw. geben keine Antwort, wenn der Dekoder aktuell eine BACKOFF-Wartezeit abwarten muß. Bei 'NOW' antworten alle noch nicht angemeldeten Dekoder, anschließend wird der dekoderinterne backoff wieder neu zufällig im Bereich 0..7 gesetzt.

SELECT_INFO_RD, SELECT_INFO_WR

    Der Befehl SELECT_INFO_RD ist 8 / 10 Byte lang (inkl. Parity) und hat das Format:

    0 1111-1110 0 1100-iiii 0 DDDD-DDDD 0 DDDD-dddd 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 (CCCC-CCCC 0 cccc-cccc 0) PPPP-PPPP 1

    Der Befehl SELECT_INFO_WR ist 8 / 10 Byte lang (inkl. Parity) und hat das Format:

    0 1111-1110 0 1101-iiii 0 DDDD-DDDD 0 DDDD-dddd 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 (CCCC-CCCC 0 cccc-cccc 0) PPPP-PPPP 1

    Mit diesem Befehl wählt die Zentrale einen Datenraum im Dekoder aus, welcher dann anschließend mit GET_DATA Befehlen abgeholt wird (SELECT_INFO_RD) oder mit SET_DATA Befehlen beschrieben wird (SELECT_INFO_WR). Die wichtigsten Dekoderdaten sind in Datenräumen gruppiert. iiii bezeichnet dabei den Datenraum im Dekoder, welcher angewählt wird. Zugleich erkennen Dekoder durch diese Nachricht, dass ihr Logon erkannt wurde und sie dürfen keine weiteren Logon-Nachrichten senden. Diese Nachricht kann daher auch vor einer allgemeinen Logonaufforderung benutzt werden, um in der Zentrale bereits bekannte Dekoder anzusprechen.
    Datenräume können eine feste (kurze) Länge oder eine variable Länge haben. Im Falle variabler Länge wird die Übertragung in Pakete der Länge 256 Byte aufgeteilt. Zur Adressierung des Paket wird der Befehl um die Parameter CCCC-CCCC 0 cccc-cccc 0 ergänzt. Diese Parameter bezeichnen die beiden MSBytes der Byteadresse im Paket (=Pageadresse). Es wird immer innerhalb einer Page von 256 Byte gelesen.
    Werden die Parameter CCCC-CCCC 0 cccc-cccc 0 gesendet, obwohl dieses nicht erforderlich wäre, werden sie ignoriert.

  • Lesevorgang:
    Mit dem Befehl SELECT_INFO_RD wird ein Datenraum im Dekoder selektiert, dieser wird anschließend durch eine unterschiedliche Anzahl von GET_DATA-Befehlen abgeholt. Bei GET_DATA sendet der Dekoder die Daten dieses Datenraumes. Er inkrementiert dabei selbständig den Zugriff innerhalb des Datenraumes (bzw. des aktuellen Pakets). Bei festen Längen des Datenraumes wird am Ende zyklisch wieder mit dem Beginn fortgesetzt. Bei Datenräumen mit variabler Länge wird am Ende des Teilpaketes dieses Teilpaketes zyklisch fortgesetzt.
  • Schreibvorgang:
    Mit dem Befehl SELECT_INFO_WR wird ein Datenraum im Dekoder selektiert, dieser wird anschließend durch eine unterschiedliche Anzahl von SET_DATA-Befehlen geschrieben. Bei SET_DATA sendet die Zentrale die Zieladresse innerhalb des Datenraumes (Index) und Nutzdaten. Nach dem vollständigen Schreiben des Datenraumes sendet die Zentrale eine Nachricht SET_DATA_END, in der Antwort be


    • Der Befehl SELECT_INFO_** wird bestätigt, indem mit ID13 der angesprochene Datenraum als Rückantwort gesendet wird.

    Ein Decoder darf nur auf SELECT_INFO + GET_DATA bzw. SET_DATA antworten, wenn er die Zentralen-ID bereits erfaßt hat.
    Parameter Bedeutung
    iiii iiii bestimmt den Datenraum
    Datenraum
    NummerInhalt
    0000Shortinfo (Size = 5 Byte), enthält u.a. die bisherige DCC-Adresse des Dekoders.
    0001ShortGUI (Size = 5 Byte), enthält Informationen zur GUI-Darstellung
    0010FirmwareID (Size = 8 Byte), enthält Informationen zum Hersteller und zum Produkt / Softwareversion
    0011Productname (Size = 8 Byte), enthält Produktnamen des Herstellers
    0100ShortName (Size = 8 Byte), enthält den Kurznamen für Bediengeräte (vom Benutzer einstellbar, Codierung utf8)
    0101FullName (Size = 28 Byte), enthält den Langnamen, (vom Benutzer einstellbar, Codierung utf8)
    elsereserviert
    1110Function-Mapping
    1111CV-Block (max. Size = 256 Byte)
    DDDD-DDDD Herstellerkennung des Dekoder
    dddd-dddd Produkt und Seriennummer des Dekoder (4 Byte, Big Endian)
    *) Die erste Anfrage der Zentrale nach einem Logon addressiert immer den Datenraum 0000.
    Der Dekoder liefert die Daten bei CV-Abfrage mit einen Index = (Adresse im Datenraum mod 256).

GET_DATA

    Dieser Befehl dient zum Abholen von Daten des durch SELECT_INFO_RD angesprochenen Dekoders und den angesprochenen Datenraum. Der Dekoder liefert die Daten des Datenraumes und Indices des vorherigen SELECT_INFO_RD. Dieser Befehl ermöglicht damit schnelles Auslesen von Blöcken aus Datenräumen. (Hinweis: Befehlsdauer: 6,4ms, damit ist ein Block von 256 Bytes in etwa 420ms auslesbar).
    0 1111-1110 0 0000-0001 0 PPPP-PPPP 1

    GET_DATA darf nur beantwortet werden, wenn der Dekoder seit dem letzten SELECT_INFO_* fehler- und unterbrechungsfrei das Gleissignal erfassen konnte.

SET_INFO

    Dieser Befehl dient zum Schreiben eines Datenraumes und hat das Format
    0 1111-1110 0 0000-0001 0 DDii-iiii 0 [DDDD-DDDD ... 0 dddd-dddd] 0 PPPP-PPPP 1
    Es können bis zu 8 Payloadbytes DDDD-DDDD übertragen werden, diese werden aufsteigend von der Index-Adresse und von der bei SELECT_PAGE_WR angegebene Pageadresse in einen Zwischenpuffer geschrieben. In diesem Zwischenpuffer werden die Daten akkumuliert und erst bei der abschließenden SET_INFO_END Nachricht und korrekter Prüfsumme (CRC) in den Datenraum übernommen.
    Der Dekoder antwortet jeweils mit den Index und der CRC, bis zu welchem er die Daten bereits ausgewertet hat. Dabei wird er eine SET_INFO-Nachricht im Rückstand sein, d.h. die Railcomantwort zur Nachricht i beschreibt den Dekoderzustand zum Zeitpunkt i-1.

LOGON_ASSIGN

    Dieser Befehl ist 10 Byte lang (inkl. Parity) und hat das Format:
    0 1111-1110 0 1111-0000 0 DDDD-DDDD 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 MMAA-AAAA 0 aaaa-aaaa 0 PPPP-PPPP 1
    Mit diesem Befehl registriert die Zentrale den Dekoder, dieser wird anschließend unter der übermittelten Adresse AA-AAAA aaaa-aaaa angesprochen. Der Dekoder darf die Registrierung nur akzeptieren, wenn er den Track Identifier und die Session ID bereits erfasst hat.
    Der Dekoder antwortet auf den LOGON_ASSIGN mit einer Nachricht, welche eine Zusammenfassung / Änderungsindex (Hash) seiner CVs enthält. Damit kann die Zentrale überprüfen, ob die (eventuell bereits bekannten) Parameter des Dekoders weiterhin gültig sind oder ob weitere Ausleseaktionen bzw. erneutes Einmessen erforderlich sind.

    Die Bits MM werden entsprechend DCC kodiert.
    MMAdressierung
    00kurze Adressierung
    01reserviert
    10Accessory
    11lange Adressierung
Die Adresszuweisung gilt nur sitzungsbezogen, für eine dauerhafte Zuweisung der übermittelten Adresse in die CV1 bzw. CV17/18 ist der DCC-Befehl POM, Shortwrite zu verwenden.

@RailCommunity: bitte beim Shortwrite das Verhalten des Dekoder bei Zuweisung einer kurzen Adressen mit aufnehmen!

FW_UPDATE_RESET

    Dieser Befehl ist 3 Byte lang (inkl. Parity) und hat das Format:
    0 1111-1110 0 0001-1111 0 PPPP-PPPP 1
    Alle Dekoder verlassen einen eventuell aktivierten Update-Modus und verwerfen die evtl. bisher empfangenen Daten so weit wie möglich. Dieser Befehl wird vor einem Firmwareupdate gesendet.

FW_UPDATE_SET_TARGET

    Dieser Befehl ist 9 Byte lang (inkl. Parity) und hat das Format:
    0 1111-1110 0 0100-0000 0 DDDD-DDDD 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 0000-TTTT 0 PPPP-PPPP 1
    Der (via DID) angesprochene Dekoder wechselt in den Update-Modus und bereitet den Zielspeicherbereich TTTT zum Schreiben vor. Befehl wird mit der Rückantwort FW-Update-ACK bestätigt. Wenn die Vorbereitung länger dauert, setzt der Dekoder das WAIT-Bit in der Antwort.
    Bei gesetztem Waitbit ist seitens der Zentrale mittels FW_UPDATE_QUERY abzufragen, bis das Waitbit zurückgesetzt ist.

FW_UPDATE_SET_BASE

    Dieser Befehl ist 11 Byte lang (inkl. Parity) und hat das Format:
    0 1111-1110 0 0100-0001 0 DDDD-DDDD 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 AAAA-AAAA 0 aaaa-aaaa 0 aaaa-aaaa 0 PPPP-PPPP 1
    Der (via DID) angesprochene Dekoder wechselt in den Update-Modus und bereitet den im Adressbereich AAAA...aaaa (MSB first) angegebenen Speicherplatz zum Schreiben vor. Dieser Befehl wird mit der Rückantwort FW-Update-ACK bestätigt.

FW_UPDATE_SET_SIZE

    Dieser Befehl ist 10 Byte lang (inkl. Parity) und hat das Format:
    0 1111-1110 0 0100-0010 0 DDDD-DDDD 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 SSSS-SSSS 0 ssss-ssss 0 PPPP-PPPP 1
    Der in SSSS-SSSS ssss-ssss übermittelte Size (in Bytes) wird in den Folgepaketen FW_UPDATE_DATA_n erwartet. Nur wenn der Dekoder sowohl TARGET als anschließend auch SIZE mit seiner ID empfangen hat, wechselt er in den Updatemode. Dieser Befehl wird mit der Rückantwort FW-Update-ACK bestätigt, dabei wird in der Antwort das Bit 'Size-is-void' gelöscht.

FW_UPDATE_DATA_n

    Dieser Befehl ist 11 Byte lang (inkl. Parity) und hat das Format:
    0 1111-1110 0 0011-nnnn 0 ffff-ffff 0 ffff-ffff 0 ffff-ffff 0 ffff-ffff 0 ffff-ffff 0 ffff-ffff 0 ffff-ffff 0 ffff-ffff 0 PPPP-PPPP 1
    ffff-ffff bezeichnet die Firmwaredaten, byteweise.
    Alle Dekoder im Update-Modus verhalten sich wie folgt:
  • Sie schreiben die 1..8 Datenbytes in ihren Speicher, wenn:
    • nnnn fortlaufend empfangen wurde
    • die mit FW_UPDATE_SET_SIZE empfangene Size noch nicht erreicht wurde.
  • Sie quittieren den Erhalt der Nachricht, indem sie den durchlaufenden Index nnnn in die Antwort einkopieren.

    • Diese Nachricht hat immer die gleiche Länge, sollte die Firmwaredatei weniger Daten enthalten, so wird die Nachricht zentralenseitig mit Daten=0xFF aufgefüllt.
    Der Zähler nnnn beginnt bei 0 und wird mit jeder Nachricht inkrementiert. Mittels des Zählers und des bei der Quittierung mitgesendetem Waitbit lassen sich Verluste von Datenpakete erkennen und diese wiederholen. Siehe hierzu auch Kapitel 8. (Firmware-Update)
    Sofern lokale Railcomdetektoren vorhanden sind, ist ein Multi-Update mehrere Dekoder möglich.

FW_UPDATE_QUERY

    Dieser Befehl ist 8 Byte lang (inkl. Parity) und hat das Format:
    0 1111-1110 0 0100-0011 0 DDDD-DDDD 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 PPPP-PPPP 1
    Der angesprochene Dekoder beantwortet die Anfrage mit aktuellem Status.

FW_UPDATE_END

    Dieser Befehl ist 8 Byte lang (inkl. Parity) und hat das Format:
    0 1111-1110 0 0100-0100 0 DDDD-DDDD 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 PPPP-PPPP 1
    Der angesprochene Dekoder verlässt den Update-Modus.

4. Railcom-Nachrichten

    Generell werden bei den Antworten zu DCC-A-Nachrichten die beiden Railcom-Kanäle Channel 1 und 2 gebündelt. Die Timingaufteilung bleibt jedoch erhalten (wie in der RCN217 angegeben). Durch die Bündelung entstehen Nachrichten mit immer 8 Byte, nach der 6-8-Kodierung verbleiben damit 48 Bit. Diese 48 Bit werden wie folgt aufgeteilt (Big Endian):
    47..4443..4039..3231..0
    ID EXT1 EXT2Databyte[3]...Databyte[0]
    (Hinweis: Die MSBs von EXT2 sind in Channel1, die 4 LSBs von EXT2 führen den Channel 2 an. )

ID15 - Decoder-Unique

    Diese Nachricht wird als Antwort auf den DCC-Befehl LOGON_ENABLE gesendet.
    ID15 - Decoder-Unique
    ID1111ID15, Kennung für Dekoder Unique
    EXT1PPPPPrüfnibble gemäß CRC-4/ITU
    EXT2VVVV-VVVVHerstellerkennung (VendorID gemäß RCN)
    DATADDD...DDD32 Bit, Eindeutige UniqueID des Dekoders
    Onlinetool zur Kontrolle der CRC4

ID14 - Decoder-Info

    Diese Nachricht wird als Antwort auf den DCC-Befehl GET_DATA gesendet. Es gibt zwei Interpretationen der Antwort:
  • Generelles Format zum übertragen eines Datenraumes:
    ID14 - Decoder-Info (generell)
    ID1110ID14, Kennung für Dekoder Info
    EXT1NNNNDatenraum (Namespace), welcher übermittelt wird.
    EXT2IIII-IIIIIndex in Namespace; Index 0 bezeichnet Databyte 0..3, Index 1 bezeichnet Datenbyte 4..7, usw.
    DATADDD...DDD4 Datenbytes: Data[4*Index+0], Data[4*Index+1], Data[4*Index+2], Data[4*Index+3]
  • Einzelblock-Format zum Übertragen spezieller, vordefinierter Datenräume verwendet, deren Größe auf 5 Byte festgelegt ist:
    ID14 - Decoder-Info (Einzelblock)
    ID1110ID14, Kennung für Dekoder Info
    EXT1NNNNDatenraum (Namespace), welcher übermittelt wird.
    EXT2IIII-IIII1 Datenbyte Data[0]
    DATADDD...DDD4 Datenbytes: Data[1], Data[2], Data[3], Data[4]
    Das Einzelblockformat wird bei den Datenräumen 0 (Shortinfo) und 1(ShortGUI) verwendet.

ID13 - Decoder-State

    not yet defined, under development
    Diese Nachricht wird als Antwort auf den DCC-Befehl LOGON_ASSIGN gesendet und enthält Informationen, ob und welche Konfiguration des Dekoders verändert wurde. Diese Nachricht bestätigt zudem die erfolgreiche Zuweisung der Adresse.
    ID13 - Decoder-State
    ID1101ID13, Decoder-State
    EXT1PPPPPrüfnibble gemäß CRC-4/ITU
    EXT2CCCC-CCCCChangeflags, welche Hinweise auf geänderte Dekoderparameter geben. (tbd)
    DATADDD...DDD4 Datenbytes: ChangeID[0], ChangeID[1], ChangeID[2], ChangeID[3]
    Die ChangeID ändert sich bei jedem CV-Zugriff (z.B. inkrementeller Zähler). Eine ChangeID 0xFFFFFFFF ist immer als 'neuer Change' zu bewerten (default nach FW-Update). Die Changeflags liefern dem steuernden System Informationen, ob sich relevante CVs verändert haben. Dadurch ist bei einer erneuten Anmeldung schnell zu erkennen, ob vorhandene Werte für Fahrverhalten und Bedienung unverändert geblieben sind.
    Changeflags
    BitBedeutung
    C0Das letzte Rücksetzen der Changeflags erfolgte an einer Zentrale mit anderer ID.
    C1Die Firmware des Dekoders wurde verändert.
    C2Das Fahrverhalten des Dekoders hat sich geändert.
    C3Die Funktionszuordnung des Dekoders hat sich geändert.
    C4GUI-Daten (wie Lokname, Lokbild) wurden verändert.
    C5reserviert.
    C6reserviert.
    C7reserviert.
    Hinweise:
    • Das Löschen der Changeflags erfolgt mit dem einer Binary-State Nachricht an den Dekoder: Binary State 28 = aus.
    • Ein erneutes Abfrage der Changeflags kann durch eine LOGON_ASSIGN-Nachricht erreicht werden.

ID12 - FW-Update-ACK

    under discussion
    Diese Nachricht wird als Antwort auf FW-Update-Befehle gesendet und enthält Zustandsinformationen über den Firmwareupdate.
    ID12 - FW-Update-ACK
    ID1100ID12, FW-Update-ACK
    EXT1SSSSAdressierter Ziel-Speicherbereich
    EXT2CCCC-CCCCZustandsflags des Updatesprozesses
    C7Error in update (ie wrong ID, wrong memory, ...)
    C6Update completed
    C5reserved; preload with 0
    C4reserved; preload with 0
    C3Destination Memory is void
    C2Target is void
    C1Size is void
    C0Wait required
    DATADDD...DDD4 Datenbytes
    D0ACK counter (wrap around); bis zu diesem zirkularen Index wurden Pakete empfangen
    D1reserved
    D2reserved
    D3reserved

5. Datenräume

    Historisch sind die Information im Dekoder in CVs kodiert, diese sind über einen gewissen Bereich verstreut und auch auch nicht überall einheitlich implementiert. Für eine automatische Anmeldung ist eine schnelle und effiziente Übertragung dieser Informationen erforderlich, diese werden daher zu Datenräumen zusammengefaßt. So kann mit wenigen Transfers die relevante Information transportiert werden.

    Beim Befehl SELECT_INFO wird ein Datenraum ausgewählt, der entsprechende Inhalt wird vom Dekoder in der Railcom-Antwort zu GET_DATA zurückgeliefert. Sofern ein Dekoder einen bestimmten Datenraum nicht unterstützt, so liefert er eine Antwort mit dem jeweilen Bezeichner des Datenraumes, Index und Datenbytes sind immer 0. Die Datenräume 0000, 0001, 0010, 0011, 0100 sind für Dekoder verpflichtend.
    Datenraum
    NummerInhalt
    00000: Shortinfo (Size = 5 Byte), enthält u.a. die bisherige DCC-Adresse des Dekoders.
    00011: ShortGUI (Size = 5 Byte), enthält Informationen zur GUI-Darstellung
    00102: FirmwareID (Size = 8 Byte), enthält Informationen zum Hersteller und zum Produkt / Softwareversion
    00113: Productname (Size = 8 Byte), enthält Produktnamen des Herstellers (utf8)
    01004: ShortName (Size = 8 Byte), enthält den Kurznamen für Bediengeräte (vom Benutzer einstellbar, Codierung utf8)
    01015: FullName (Size = 28 Byte), enthält den Langnamen, (vom Benutzer einstellbar, Codierung utf8)
    01106: FunctionMap (Size = variabel)
    else... reserviert
    110113: Railcom-Page (Size = 256 Byte)
    111014: CV-Block Phase 0 **) (max. Size = 256 Byte)
    111115: CV-Block Phase 1 **) (max. Size = 256 Byte)
    0000 Shortinfo
    Dieser Datenraum ist 5 Bytes groß und enthält die wesentlichen Informationen zum Dekoder:
    Byte:BitEnthaltene Daten
    0:7 Info über Decoderart (0=Lok, 1=Accessory)
    0:6 Zusatzinfo über Decoderart. Bei Lok: (0=Motordekoder, 1=Funktionsdekoder); bei Accessory (0=Standard, 1=Extended Accessory))
    0:5..0 Lokadresse (Wunschadresse), Bit 13...8. (high)
    1:7..0 Lokadresse (Wunschadresse), Bit 7..0. (low)
    2:7 Am Dekoder ist eine consist-Adresse aktiviert.
    2:6..0Bei Lokdekodern: Zahl der vorhandenen Funktionsausgänge; Eine Zahl von 127 zeigt an, dass mehr als 126 Funktionen vorhanden sind.
    Bei Standardaccessory: Zahl der Weichenpaare;
    Bei ext. Accessory: Zahl der Begriffe;
    3:7..2reserviert. Mit 0 vorzubelegen.
    3:1 Dekoder unterstützt FW-Update über DCC-A
    3:0 Dekoder ist aktuell im FW-Updatemode - nur FW-Update möglich
    4:7 Datenraum 12 (GUI Storage) kann abgefragt werden.
    4:5 Datenraum 11 kann abgefragt werden. Was dort liegt, ist noch tbd. / reserved.
    4:4 Datenraum 10 kann abgefragt werden. Was dort liegt, ist noch tbd. / reserved.
    4:3 Datenraum 9 kann abgefragt werden. Was dort liegt, ist noch tbd. / reserved.
    4:2 Datenraum 8 kann abgefragt werden. Was dort liegt, ist noch tbd. / reserved.
    4:1 Datenraum 7 kann abgefragt werden. Was dort liegt, ist noch tbd. / reserved.
    4:6 Datenraum 6 (FuncMap) kann abgefragt werden.
    4:0 Datenraum 5 (Fullname) kann abgefragt werden.
    0001 ShortGUI
    Dieser Datenraum ist 5 Bytes groß und enthält Kurzinfos zur graphischen Darstellung im Bediengerät:
    0..3 zu verwendendes Prinzipsymbol (Fallback Icon)
    0000:steam_locomotive:Dampflok
    0001Diesellok
    0010E-Lok
    0011Dieseltriebwagen
    0100:bullettrain_side:E-Triebwagen (S-Bahn, ICE)
    0101Steuerwagen, Zugschluß
    0110Personenwagen
    0111Lokdekoder
    1000:bulb:Funktionsdekoder
    1001Weichen/Schaltdekoder
    1010:vertical_traffic_light:Signaldekoder
    1011Drehscheibendekoder
    1100:house:(Anlagen-)Beleuchtung
    1101:car:Car-Pkw
    1110:truck:Car-Lkw/Bus
    1111:hammer:Sonstige
    4..19 Index des Bildes gemäßt Anhang xxx.xxx
    20..39 Herstellerspezifische Kennung
    0011 ProductName
    Dieser Datenraum ist 8 Bytes groß und enthält die Herstellerbezeichnung des Produktes. Der Hersteller selbst kann anhand der UniqueID bestimmt werden.
    0..63 ProductName, 8 Byte, UTF8-kodiert. Kürzere Namen sind mit 0x00 aufzufüllen.
    0100 ShortName
    Dieser Datenraum ist 8 Bytes groß und enthält eine von Benutzer frei wählbare Bezeichnung des Dekoders (z.B. ICE oder Dampflok).
    0..63 Shortname, 8 Byte, UTF8-kodiert. Kürzere Namen sind mit 0x00 aufzufüllen.
    0101 Fullname
    Dieser Datenraum ist 28 Bytes groß und enthält den Namen der Lok / des Dekoders: 1100 GUI Storage
    Dieser Datenraum ist bis zum 128 Bytes groß und Informationen zur gewünschten Darstellung des Fahrzeuges in der GUI.
    0..223 Name, 28 Byte, UTF8-kodiert. Kürzere Namen sind mit 0x00 aufzufüllen.
    0.. ... Exakter Inhalt noch zu definieren.

    Speicherorte:
    Fullname: Page 256, Bytes 0 ... 27
    Shortname: Page 256, Bytes 28 ... 35

6. Implementierung in der Zentralen

    Diese Kapitel beschreibt das Verhalten von Zentralen im Laufe der Anmeldung und wie diese mit Sonderfällen umgeht.
    Bei jedem Neustart einer Zentrale ist die SessionID zu inkrementieren. Nach 255 folgt 0.

Anmeldung

  • Beim Systemstart sendet die Zentrale ein LOGON_ENABLE(NOW), um alle Dekoder anzumelden. Die Reaktion wird je nach Art des Rückmeldesystems (lokale Detektoren / globale Detektoren) eine Reihe von ID15 Nachrichten bzw. erkannten Kollisionen sein.
  • Jeweils die mit einer ID15-Nachricht bekannt gemachten Dekoder werden ausgelesen (GET_INFO), sie sind damit bekannt und reagieren nicht mehr auf LOGON_ENABLE.
  • Wenn Kollisionen erkannt wurden, wird eine Vereinzelung gestartet: die Zentrale sendet eine Folge von LOGON_ENABLE(ALL), je nach aktuellem backoff-Wert werden sich die Dekoder vereinzeln und erfolgreich eine ID15 Nachricht absetzen können.
  • Wenn keine neuen Dekoder mehr eingehen und auch keine Kollisionen mehr erkannt werden, kann die Zentrale wieder auf LOGON_ENABLE(NOW) wechseln, um eine schnelle Anmeldung neu aufgegleister Fahrzeuge zu ermöglichen.
  • In der Zentrale von einer früheren Betriebsphase bekannte Dekoder können probehalber nach dem ersten LOGON_ENABLE ausgelesen werden, dies verkürzt i.d.R. die Anmeldephase.

7. Verhalten von Dekodern

    Diese Kapitel beschreibt das Verhalten von Dekodern im Laufe der Anmeldung und wie diese mit Sonderfällen umgehen. TEXT fehlt noch ...
  • Neustart:
    Ein Neustart des Dekoders kann entweder frisches Aufgleisen oder auch nur ein vorübergehender Kontaktwackler sein. Zudem weiß der Dekoder apriori nicht, ob er von einer Zentrale mit oder ohne Anmeldung kontrolliert wird.

    Wenn nach eine Start binnen 2000ms keine Nachricht mit Advanced DCC Befehl (1111-1110) empfangen wurde, so soll der Dekoder von einer Zentrale ohne Anmeldung ausgehen und darf auf Befehle an die normale Lokadresse reagieren.

    Detektiert ein Dekoder beim Start einen sich bereits drehenden Motor, so kann er von einem mangelnden Kontakt ausgehen und darf auf der bisherigen Adresse Steuerbefehle annehmen.
    Wenn ein Dekoder die bisherige Zentrale anhand der CID erkennt und sich die SessionID um nicht mehr als 4 inkrementiert hat, so soll der Dekoder davon ausgehen, dass der Dekoder in der Zentrale bekannt ist. Der Dekoder kann direkt auf der zugewiesenen Adresse starten und muß nicht erst die LOGON-Prozedur durchlaufen.


    • Wenn der Dekoder beim LOGON_ASSIGN die Adresse 0 zugeteilt bekommt, so wurde der Logon von der Zentrale zurückgewiesen. Der Dekoder soll diesen Fehlerzustand anzeigen (z.B. blinkenes Fahrlicht), weitere LOGON sind nicht zulässig.

Backoff

    Sollte ein Dekoder nach einer versuchten Anmeldung keine Bestätigung erhalten, so beantwortet er eine bestimmte Anzahl von LOGON_ENABLE-Nachrichten nicht mehr. Die Anzahl der zu ignorierenden Anmeldeaufforderungen bestimmt er mit einer Zufallszahl, in deren Erzeugung die UniqueID eingeht. Die erste Zufallszahl ist aus einem Bereich von 0..7 zu wählen. Wenn der LOGON erneut nicht betätigt wird, so wird die Zahl aus einem Bereich 0..15 gewählt. Wenn der LOGON erneut nicht betätigt wird, so wird die Zahl aus einem Bereich 0..31 gewählt. Wenn der LOGON erneut nicht betätigt wird, so wird die Zahl aus einem Bereich 0..63 gewählt und wird in Folge nicht mehr weiter vergrößert.

    Wenn eine LOGON_ENABLE_NOW empfangen wird, so ignoriert der Dekoder den aktuellen Backoff-Wert und versucht sich anzumelden.

8. FW-Update

    DCC-A implementiert auch einen Firmwareupdate über das Gleis. Hierbei wird die bei DCC verfügbare Bandbreite optimal ausgenutzt.

Prinzipieller Ablauf

  • Zu Beginn sendet die Zentrale einen FW_UPDATE_RESET.
  • Dann folgen ein (oder mehrere) FW-Pakete an eine bestimmte DekoderID, diese sind immer wie folgt zu übertragen:
    • FW_UPDATE_SET_TARGET
    • FW_UPDATE_SET_SIZE
    • FW_UPDATE_DATA_n (Anzahl Pakete: (SIZE+7) / 8)
  • FW_UPDATE_END beendet den FW-Update
    • Die Datenpakete FW_UPDATE_DATA sind dabei zyklisch durchnummeriert, es ist möglich (und aus Durchsatzgründen auch erwünscht), dass die einlaufenden Quittungen um einen bestimmten nummerischen Offset zeitlich versetzt ankommen.

Verhalten bei prozessbedingten Pausen

    Je nach Prozesstechnologie im Dekoder kann das Speichern von Firmwarepaketen zu einem Blockieren der sonstigen Verarbeitung führen. In diesem Fall beantwortet der Dekoder das letzte Paket vor der Blockade mit einer FW_ACK-Nachricht mit gesetztem Waitbit.
    Die Pakete FW_UPDATE_DATA_n werden dann zwar zischenzetilich weiter gesendet und n wird dabei regulär inkrementiert, diese Nachricht mit dem Waitbit erreicht das steuernde Programm nach einer kleinen Zeitspanne. Dieses stoppt dann den weiteren Stream und wiederholt dann die mit Waitbit quittierte Nachricht, bis ein ACK+n eintrifft. Bei der Wiederholung ist ein Timeout von 200ms vorzusehen. Nach dem ACK+n geht es wieder normal inkremental weiter, d.h. auch die Folgepakete werden erneut gesendet.