Deutsch
Englisch
Support für Hersteller
Userkonfiguration
Beispielcode
Analysewerkzeuge
Support für BiDiB
Was ist DCC-A?
Mit DCC-A ist es möglich, Dekoder und deren Eigenschaften automatisch auf einer Modellanlage zu erfassen. Das geschieht mittels des in RCN-218 festgelegten Verfahrens. BiDiB unterstützt dieses Verfahren durch entsprechende Komponenten und Nachrichten. DCC-A stützt sich auf DCC und Railcom und ist dann besonders sinnvoll einzusetzen, wenn überall auf der Modellanlage Railcom und entsprechende Detektoren verfügbar sind.
DCC-A definiert folgende Kernfunktionen:
- Automatische Anmeldung vom Dekodern
- Zuweisung einer Lokadresse
- Erfassung des Funktionsumfanges und der Funktionszuordnung
- Vergabe und Erkennung von Hersteller, Version, benutzerdefiniertem Namen
Eine der technischen Voraussetzungen zur Implementierung von DCC-A ist, dass sowohl Decoder als auch Gleisausgabeeinheit über global eineindeutige Kennungen identifiziert werden können. Im Falle der Gleisausgabeeinheit ist das letztlich das Steuerprogramm.
Anmeldung mit DCC-A
Die Anmeldung selbst besteht aus folgenden Schritten:
- Austausch von Anmeldenachrichten
- Die Gleisausgabe öffnet Anmeldebereiche (und überträgt dabei ihre Kennung),
Dekoder versuchen sich in diesen Anmeldebereiche bemerkbar zu machen.
Gelingt die Übertragung der Dekoderkennung, so folgt Abfrage der wichtigsten Parameter (u.a. der Wunschadresse) seitens der Gleisausgabe. - Zuweisung einer Fahradresse
- Nach der Erfassung der Kenndaten des Dekoders kann die Gleisausgabe eine Adresse zuweisen. Die Adresszuweisung beantwortet der Dekoder mit einer Zusammenfassung seines Änderungszustandes. Damit kann das Steuerprogramm erkennen, ob der Dekoder bereits 'bekannt' ist oder ob an anderer Stelle für den Betrieb des Dekoders wichtige Parameter des Dekoder modifiziert wurden (wie z.B. max. Geschwindigkeit verändert).
- Schnelle Erfassung der wichtigsten Dekoderparameter
- Hierzu gibt es in den Dekodern Namensräume, deren Inhalt z.B. Usernamen, Fahreigenschaften, Funktionszuordnungen usw. sind. Diese Namensräume lassen sich 'en bloc' mit schnellen Gleisbefehlen auslesen.
Prinzipielle Funktionsweise der Anmeldung bei DCC-A
- Grundlage
- Voraussetzung einer automatischen Anmeldung innerhalb eines gemeinsamen Bussystems (Gleis + Lokomotiven kann man so betrachten) ist die Möglichkeit, die einzelnen Teilnehmer unterscheiden zu können- Hierzu dient bei DCC-A eine eindeutig Kennnummer im Decoder, bestehend aus 12 Bit Herstellerkennung und 32 Bit Produkt/Seriennummer.
- Vereinzelung
- Um die einzelnen Teilnehmer ansprechen zu können, muß eine Vereinzelungsmethode vorhanden sein. Es gibt verschiedene Methoden
(z.B. ein binärer Suchbaum), DCC-A verwendet ein statistisches Verfahren mit dynamischen Backoff. Decoder versuchen, sich nach
einer Anmeldeaufforderung bemerkbar zu machen - gelingt dieser Vorgang, wird der Dekoder 'eingebucht' (d.h. er bekommt eine
Adresszuweisung (ASSIGN), fortan ignoriert dieser Decoder Anmeldeaufforderungen.
Gelingt die Anmeldung nicht, so wartet der Decoder eine zufällige Anzahl von Anmeldeaufforderungen ab und versucht es dann erneut.
Bei kleinen Mengen (<50) an anzumeldenden Komponenten terminiert dynamisches Backoff sehr schnell, zudem wird man i.d.R. bei bereits bekannten Decoder die Adresszuweisung vor der Anmeldeaufforderung vornehmen.
Grundlage dieser Spezifikation ist die RCN-218, Stand 09-2024
Glossar
| Name | Bedeutung | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DEC_MUN[0…3] | Herstellerspezifische eindeutige Kennnung des Dekoders, 32 Bits | ||||||||||||||||||
| DEC_MID[0…1] | Herstellerkennung. Diese umfasst 12 Bits, das oberste Nibble von DEC_MID[1] wird mit 0 kodiert. | ||||||||||||||||||
| ZID[0…1] | Zentralenkennung. Diese wird aus Timinggründen (kurze Nachricht) nur mit 16 Bit auf dem Gleis gesendet und sollte durch einen Hash-Algoritmus aus der Herstellerkennung und Seriennummer der Zentrale/Softwareprojekt gewonnen werden. Ergänzend zur CID wird am Gleis eine Sitzungsnummer übertragen. Die Sitzungsnummer wird bei jeder Abmeldung und bei jeder Vergabe einer bereits einmal vergebenen Adresse um ein 1 inkrementiert. Ein Inkrement von mind. 2 auf der Sitzungsnummer erzwingt eine Neuanmeldung aller Dekoder. | ||||||||||||||||||
| Namespace | Die Informationen des Dekoder sind in logischen Einheiten gruppiert, den sog. Namespaces.
Diese Namespaces werden über eine Referenznummer (0…255) angesprochen. Der Inhalt ergibt sich aus der RCN218.
|
Features für DCC-A
Kurzübersicht der für DCC-A relevanten Features. Details sind den entsprechenden Abschnitten bei Gleisausgabe bzw. Belegtmeldung zu entnehmen.
| Nummer | Name | Bedeutung |
|---|---|---|
| 111 | FEATURE_GEN_EXT_AVAILABLE, Bit 2 | Anzeige, ob DCC-A mit der Gleisausgabe möglich ist. |
| 114 | FEATURE_GEN_EXT_ENABLED, Bit 2 | Anzeige und Einstellmöglichkeit, ob DCC-A verwendet wird. |
| 29 | FEATURE_BM_EXT_AVAILABLE, Bit 2 | Der Belegtmelder kann DCC-A Nachrichten auswerten und weiterleiten |
Steuerung der Gleisausgabeeinheit
Zu Beginn ist zu überprüfen, ob die Gleisausgabeeinheit DCC-A verfügbar hat (FEATURE_GEN_EXT_AVAILABLE) und ob es eingeschaltet ist (FEATURE_GEN_EXT_ENABLED). Sofern es noch nicht eingeschaltet ist, muss die Gleissignalerzeugung abgeschaltet werden, das Bit 2 in FEATURE_GEN_EXT_ENABLED gesetzt werden und nach 3s kann die Gleisausgabe wieder aktiviert werden. Lokdecoder erkennen aktives DCC-A durch ein um 20us längeres Startbit, welches ab Start vorhanden ist.
Die Zentralenkennung ist vor dem ersten Senden (vor dem ersten Einschalten) der Anmeldeaufforderung zu setzen: dies erfolgt mittels MSG_CS_DCCA mit dem Opcode BIDIB_DCCA_SET_TID.
Initale Decodererfassung:
- Allgemeiner Ablauf:
Zu Beginn (und nach dem Booster OFF) ist es sinnvoll, den Dekodern die Anlagenkennung zu übermitteln (z.B. durch einmaliges Aussenden der Anmeldeaufforderung DCCA_LOGON_ENABLE(Now)).
Anschließend kann man bei allen in der Steuersoftware aktiven Decoder durch einen LOGON_ASSIGN eine Adresszuweisung wiederholen und so ev. geänderte Lokzustände per zugehöriger Railcom-Nachricht erfassen. Decoder, welche ein LOGON_ASSIGN erhalten haben, fallen fortan aus der Anmeldung raus.
Es kann sinnvoll sein, LOGON_ASSIGN zu wiederholen: das hilft, wenn z.B. die Railcom-Erfassung nicht permanent verfügbar ist und eine Bestätigung des Decoder nicht weitergeleitet wird.Nun kann man weitere Anmeldeaufforderungen senden (wieder mit DCCA_LOGON_ENABLE(Now)) und die Reaktion der Anlage beobachten:
- Es kommen weitere Anmeldungen und es sind keine Kollisionen enthalten: die noch offenen Anmeldungen sind entsprechend abzuarbeiten.
- Es kommen weitere Anmeldungen, dabei sind auch Kollisionen enthalten: die noch offenen Anmeldungen sind entsprechend abzuarbeiten. Um die Kollisionen aufzulösen, muß nun den Dekoder Gelegenheit zur Vereinzelung mittels Backoff gegeben werden. Dabei wird statt DCCA_LOGON_ENABLE(Now) eine Folge normaler LOGON-Nachrichten ans Gleis gesendet.
- Wenn sich die Situation bei Kollisionen beruhigt hat, sollte erneut mit DCCA_LOGON_ENABLE(Now) versucht werden, 'Nachzügler' mit aktuell großem Backoff wieder frisch in die Anmeldung zu bringen.
- Wenn auf (mehrere) DCCA_LOGON_ENABLE(Now) keine weiteren Anmeldungen eintreffen: offenbar sind alle Dekoder angemeldet und der Betrieb kann beginnen.
- Behandlung eines einzelnen Decoders:
Ein Decoder übermittelt bei der Anmeldung seine eindeutige Kennung. Sollte die Kennung bereits bekannt sein, kann (und sollte) die bisherige Adresse verwendet werden.
Es gibt bei der Adresszuweisung zwei Modi:- Permanente Zuweisung: Hierbei wird zusammen mit der Adresszuweisung auch die normale DCC-Adresse (definiert durch CV29/CV1/CV17+18) gesetzt.
- Temporäre Zuweisung: Diese Adresse gilt (vereinfacht) solange die ZID und Sessionnummer unverändert bleibt bzw. der Decoder eine Änderung gültig verfolgen konnte. Kommt die Lok auf eine nicht-DCC-A Anlage zurück, dann gilt wieder ihre 'alte' Adresse.
Bei der Adresszuweisung antwortet der Decoder mit Changeflags, welche angeben, ob und wie sich Parameter im Decoder seit der letzten Anmeldung (an dieser Zentrale-ID) verändert haben. So kann man z.B. auf einer Anlage erkennen, ob die zur Einmessung verwendeten Fahrstufen immer noch gleich sind. Wenn man die Parameteränderung erfasst hat, kann man die Changeflags mit BIDIB_DCCA_SELECT_SET_DEC_STATE zurücksetzen.
Bei einer neuen Kennung kann man mit Hilfe dieser Kennung genauere Daten von Decoder abfragen. Das geschieht durch eine 'Einzelaktivierung' des Zieldekoders und folgende Transportbefehle, mit sehr kurzen DCC-Nachrichten (GET_DATA_START und GET_DATA_CONT) viele Railcom-Sendemöglichkeiten für den ausgewählten Dekoder schaffen.
Die Daten im Decoder sind in Namensräume unterteilt, zusammen mit der Aktivierung wählt man auch den Namensraum an:# Inhalt 0 Capabilities: Übersicht der am Dekoder verfügbaren DCC-Fähigkeiten 1 Namespaces: Liste der am Decoder vorhandenen Namesspaces 2 ShortGUI: Kurzübersicht über den Dekoder mit (kurzem) Fahrzeugnamen 3 CV: Namespace zum schnellen Lesen von CVs 4 FunctionInfo: Liste der Funktionen und der zuzuordnenden Icons 5 LongName: (benutzerdefinierter) Name des Fahrzeuges und eine Kurzbeschreibung 6 ProduktInfo: Herstellerinformationen zum Dekoder (Name, Version) 7 FahrzeugInfo: Informationen zum Fahrzeug. Eine Sonderrolle nimmt der das Datenfeld 'ShortInfo' ein, welche die wichtigsten Parameter enthält. Dieses Feld wird direkt beim Select zurückgeliefert, GET_DATA Befehl sind hierfür nicht erforderlich.
Die Datenräume habe eine variable Größe von bis zu 256 Bytes, das wird immer in Teilpaket zu max. 31 Nutzbytes übertragen. Nach einem SELECT sollten also 6 Transportbefehle ausgelöst werden. Dann kann man dieses erste Teilpaket ansehen und je nach Inhalt weitere Transportbefehle auslösen oder die Auswahl wieder aufheben.
Wenn der Decoder den Datenraum voll ausnützt, sind inkl. der Paketierungsbytes in Summe 46 GET_DATA Nachrichten erforderlich. - Beispiel einer Übertragung eines Namespaces
Das folgende Bespiel zeigt die Übertragung eines Namespaces. Der Dekoder wechselt dabei auch den Meldeabschnitt, es kommt als zu einer Überlappung der Daten.
Im Beispiel wird als Inhalt des Namespaces die Kleinbuchstabenfolge 'abcdefghi...' angenommen, der Inhalt hat eine Gesamtgröße von 33 Bytes, so dass sich 2 Subpakete ergeben.Benutzte Zeichen im Beispiel Zeichen Bedeutung a,b,c, ... Payload Data H Headerbyte gemäß RCN218, bestehend aus X, S, C und size-Angabe. C CRC8 (wird mit der Nummer des Namespaces als Startwert berechnet, gerechnet wird über H und alle folgenden Payload-Bytes ~ ACK-Symbol bzw. Nullbyte vom Decoder #1: GD_INDEX, Getdata-Index; die Schrittweite beträgt 6 Bytes je Increment Datenübertragung Stelle Zeitachse → Content of Namespace abcdefghijklmnopqrstuvwxyzabcdefg (=33 Byte Payload) Decoder, Railcom-Messages Habcde fghijk lmnopq rstuvw xyzabc deCHfg C~~~~~ BiDiB-Nachricht A #0:Habcdefghijk BiDiB-Nachricht B #1:fghijklmnopqrstuvwxyzabc BiDiB-Nachricht C #2:lmnopqrstuvwxyzabcdeCHfgC