OpenDCC - Zentrale für DCC - Rückmeldungen

Einleitung

    Hier ist eine Zusammenfassung der verschiedenen Aspekte (Adressbereiche, Updateraten usw.) bei der Rückmeldung in OpenDCC.

Physikalische Implementierung, Timing

    Die Kontrolle der S88-Leitungen erfolgt per 'Bit-Bang' durch Software. Die Rückmelder werden innerhalb des Task-Schemas von OpenDCC mittels zylischer Abfrage eingelesen, wobei die eingestellten Mindestzeiten durch eine Timerüberwachung garantiert werden. Die Maximalzeiten können je nach aktuelle Prozessorlast etwas streuen, so dass die Signale CLK, LOAD, RESET etwas Jitter enthalten. Dieser ist aber ohne Belang.
    Die Zeiten sind in Schritten von 10µs einstellbar, in der Defaulteinstellung werden je 20µs für High und Lowzeit des Clocks verwendet. OpenDCC ist damit vermutlich eine der schnellsten s88-Implementierung.
    Es werden immer alle 3 Stränge simultan eingelesen, wobei der längste Strang die Anzahl der Taktpulse bestimmt. Beispiel: 288 angeschlossene Rückmelder, welche auf 3 Stränge aufgeteilt sind werden ca. alle 5ms komplett eingelesen.

Hostprotokoll (zum PC)

    Zum Absenden der Rückmeldungen sind 3 verschiedene Protokolle implementiert, diese haben folgende Merkmale:
    Protokoll: Intellibox
    (p50xb)    		Lenz
    (xpressnet)    		 Littfinski
    HSI88
    max. Anzahl:1024 1024 496
    unterteilt in: je 8 je 4 je 16
    Bitorder: invers normal normal
    Technik: Polling Pushing Pushing
    Eines der Protokolle kann per Compileoption als Hostprotokoll ausgewählt werden, wobei beim HSI88 natürlich kein Zentralenbetrieb möglich ist. Getestet wird bei mir i.d.R. mit p50xb.

    Eine Anmerkung zur Polling-Methode des IB-Protokolls:
    OpenDCC versucht, möglichst zeitnah die Zustände der Melder einzulesen, um eine möglichst direkte Reaktion des PC zu gewährleisten. Dadurch entspricht der Zustand der Rückmeldebits in der Zentrale i.d.R. direkt den Zuständen der Melder. Wenn nun der Melder 'draußen' wieder auf 0 geht, bevor das interne Ereignis vom PC abgeholt worden ist, dann wird bei der PC-Abfrage der aktuelle Zustand (also 0) gemeldet. Die Zentrale macht kein 'Aufsammeln' der Melder, dies ist auch im Protokoll nicht vorgesehen. Der Wechsel des Rückmeldebits wird jedoch immer gemeldet, auch wenn es nur ganz kurz aktiv war.
    Daraus ergibt sich bei Verwendung der IB-Syntax folgende Bedingung: der PC muß einfach öfter fragen als die Haltezeit der HW-Melder bzw. das Busintervall des S88-Busses.

Adresszuordnung

    Es gibt innerhalb der Zentrale vier Adressbereiche für Rückmelder. Diese Bereiche folgen aufeinander, jeder Bereich darf auch 0 Byte groß sein:
    Bereich 1 2 3 4
    Zuordnung S88-1 S88-2 S88-3 Weichenrückmeldung
    festgelegt durch: CV9 CV10 CV11 CV16
    Die Hardwarebereiche S88-1, -2 und -3 werden jeweils durch ihre Größe definiert (Anzahl der Rückmeldebits in Einheiten von je 8 Bit) und schließen sich aneinander an. Es ist darauf zu achten, dass die jeweiligen Größen richtig eingestellt sind, da sonst die Rückmeldung nicht funktionieren kann. Der Beginn des Bereiches für die Weichenrückmeldung wird mit CV16 definiert, es kann/darf also durchaus eine Lücke in den Rückmeldebits vorhanden sein. Vorteil: Beim Hinzufügen weiterer S88-Module verschieben sich die Weichenrückmeldungen nicht.

    Beim Protokoll p50xb werden immer alle vier Bereiche über den normalen Rückmeldeweg zurückgemeldet, die Bits für die Weichenrückmeldung sind hier einfach in die normalen Rückmeldebits einsortiert. Die Auswertung, ob eine Weiche umgelaufen ist, muß dann am PC erfolgen.

Xpressnet und Schaltinformationen

    Beim Xpressnet ergeben sich Einschränkungen, weil die Rückmelder und Weichenbefehle sich den Adressbereich teilen. (Anmerkung: Das ist m.E. ein erheblicher Mangel des Xpressnetprotokolls.) Laut Lenz-Doku gibt es 1024 Rückmelder, dabei wird das Byte 1 der Xpressnet-Anfrage von 0..127 kodiert und es werden je 8 Rückmelder damit erfaßt. Des weiteren sind 1024 Weichen vorgesehen, hier deckt das Byte 1 einen Bereich von 0..255 ab, es werden je 4 Weichen adressiert. Die Adressbereiche liegen übereinander, es werden also max. 2048 Bits addressiert. 
    0                            1024                        2048
|--------  Feedback  ---------|
|-----------------------   Weichen   ---------------------|
    Anhand der Graphik wird auch klar, warum das Xpressnet nur auf dem ersten 512 Weichen Schaltdekoder mit Rückmeldung kann.

    Was bedeutet das nun für OpenDCC?
    Bei OpenDCC gibt es ja externe Rückmelder (S88) und interne Rückmeldungen (eben die Weichenrückmeldung) und man muß sich nun entscheiden, wie man das in den gemeinsamen Adressraum einsortiert:
  • Wenn bei Weichen eine Quittungnachricht gesendet wird (so wie Xpressnet das als Broadcast vorsieht), so überlagert diese Quittung zwangsläufig einen S88-Melder, sofern die Weichenadresse < 512 ist. Die Folge: bei s88-Betrieb kann man nur Weichenadressen >= 512 vergeben, was unschön ist.
  • Wenn man hingegen versucht, die Rollen zu tauschen (also Weichen von 0 an adressieren und Feedback mit einem Offset meldet), so muß man das anhand von Byte 1 unterscheiden. Dadurch würden sich folgende Einschränkungen ergeben:
    Byte 1:Bedeutung
    0..63 Dieser Bereich wird DCC-Accessory zugeordnet und mit einer Schaltdecoder-Rückmeldung aus dem Bereich 4 (Turnout-Buffer) geladen. Das bedeutet 256 mögliche Weichen
    64 .. 127 Dieser Bereich wird als Feedback-Bereich interpretiert (d.h. die Melder beginnen bei 513 bzw. Baustein 65-1). Das bedeutet 512 mögliche Melder
    • Implementierung in der OpenDCC-Z1
    Ich habe die zweite Alternative genommen: Die S88-Rückmelder (also die Bereiche 1, 2 und 3) werden beim Xpressnet-Protokoll als Feedback-Broadcasts (TT = 10) beginnend bei 513 gemeldet. Das Schalten von Weichen wird mit Broadcast einer Schaltinformation gemeldet, allerdings nur bis Weiche 256. Diese Meldung erfolgt beim Abschalten des Antriebes einer Weiche und Eintreffen der entsprechenden Rückmeldung, wobei die gemeldete (Schalt-)Adresse innerhalb des Bereiches 4 neu beginnend gezählt wird.

    Für Sonderanwendungen (z.B. extrem viele Rückmeldungen) kann diese Zuordnung mit CV29 verändert werden.

Multi-Protokollbetrieb

    OpenDCC Z1 (in der Version OpenDCC_XP) kann p50xb und Xpressnet parallel bedienen. Hierzu sind die entsprechenden Change-Flags für die beiden Protokolle doppelt ausgeführt, um trotz eines per Push-Dienst am Xpressnet abgesandten Ereignisses dieses auch noch für die event-Abfrage am p50xb vorzuhalten. Die Rückmeldungen werden also verlustfrei parallel in beiden Protokollbereichen verteilt.