Hallo Stephan,
herzlichen Dank für die Info und deine Hinweise. Ich weiß jetzt allerdings nicht, was du mit geändertem Timing bei SX2 relativ zu SX1 meinst. Wie ich schon weiter oben aufgeführt habe hat sich an der grundsätzlichen Bit-Codierung am Gleis (und übrigens auch am SX-Bus) absolut nichts geändert. Das einzige was sich soweit ich das Überblicke beim „Timing“ geändert hat ist der Refresh-Zyklus am SX-Bus. Dies ist dem Faktum geschuldet, dass die zusätzlichen Datenpakete für SX2, DCC, MM ja in diesen Zyklus integriert werden müssen.
Die klassischen SX-Zentralen haben unabhängig davon, ob die Daten eines Frames (Rahmen) ungleich 0 waren immer pauschal alle 16 Frames am Gleis ausgegeben und am SX-Bus. Dies wäre am Gleis grundsätzlich nicht nötig gewesen. Es war dem Sachverhalt geschuldet, dass SX bisher auf seinem Datenbus (Gerätebus) ein zum Gleis absolut identisches Protokoll verwendet hat. Welches zudem synchron lief. So etwas war, programmiertechnisch einfach zu realisieren. Vor 30 Jahren waren die µC zudem auch noch nicht so schnell und flexibel, dass man den SX-Datenbus und das SX-Gleissignal ohne größeren Aufwand hätte unabhängig voneinander behandeln können.
Aktuelle SX-Zentralen, die am Gleis verschiedene Protokolle auch im Mischbetrieb ausgeben können, behandeln heute ähnlich wie DCC-ZEs den Datenbus und das Gleissignal individuell und separat voneinander. Das Gleis- und Datenbussignal läuft damit nicht mehr wie bisher synchron. Bei der FCC von D&H ist es noch taktsynchron aber nicht mehr datensynchron. Bei der Rautenhaus ZE mit RMX ist es weder takt- noch datensynchron. Auch hier muss ich noch mal auf das Verweisen, was ich diesbezüglich schon weiter oben zu den Methoden von D&H und Rautenhaus hinsichtlich der Verarbeitung am Gerätebus ausgeführt habe. Es wäre also ein Irrglaube, wenn man annimmt, dass am SX-Gerätebus ein typisches DCC- oder gar MM Protokoll übertagen wird, wenn ein solches am Gleis ausgegeben werden muss.
Als äußerst unglücklich empfand ich in diesem Kontext die Ausführung des Datenbus-Protokolls bei der TRIX Systems Gleisbox, die zusammen mit der TRIX Mobile Station 1 auf den Markt kam. Auf Grund der Tatsache, dass man in dieser preiswerten Box einen billigen, leistungsschwachen µC eingebaut hatte, war es offensichtlich nicht möglich die Behandlung des Gleissignals und des Datenbussignals komplett voneinander zu separieren. Dies hatte den unschönen Effekt, dass wenn DCC-Signale am Gleis ausgegeben wurden, die zeitlich ja deutlich länger als SX Pakete sind, der Datenbus durch hinzufügen von Dummy-Bits unnötig warten musste bis das DCC-Signal vollständig ausgegeben war.
Dies führte bei kompletter Ausnutzung von allen verfügbaren Buserweiterungen zu Busumlaufzeiten von bis zu 15ms. Dies steht/stand im absoluten Kontrast zu dem was man bei SX bisher gewohnt war. Eventuell basiert darauf auch der Grund, warum sich Rautenhaus nicht für die Erweiterung des SX-Frames zur Übertragung der für DCC und MM erforderlichen Daten erwärmen konnte und für den Handreglerbus sein Multiplex-Verfahren entwickelt hat.
In Ermangelung der ZS2 von Staerz und der DZ2012 von DIGIT-ELECTRONIC kann ich zwar nicht sagen, wie genial die erweiterte (SX2-)Gerätebus-Implementierung (SX-Frame Erweiterung) dort ausgeführt ist, was ich aber kenne ist, wie dies bei der FCC aussieht. Diese führt keine sinnlose Dummy-Bits in das SX-Busprotokoll ein, wenn am Gleis DCC oder MM ausgegeben wird. Damit verlängert sich selbst im „worst case“ dort die Umlaufzeit am SX-Datenbus nur von ca. 80ms auf max. ca. 130ms. Ja insofern hast du Recht, wenn du von geändertem Timing sprichst. Dies bezieht sich aber lediglich auf den Gerätebus (Datenbus) und trifft dort nur auf die Zentralen zu, die zur Übertragung der zusätzlichen Informationen die Methode der SX-Buserweiterung anwenden. Für RMX gilt dies so direkt nicht. Hier werden die Daten ereignissgesteuert in mehren Umläufen der normalen SX-Frames übertragen (Muliplex). Was am Ende effizienter ist, darüber streiten sich die Geister.
Die Herausforderungen bei der Einführung von SX2 lagen also unter Wahrung der Kompatibilität weniger im Bereich des Gleissignals, sondern eindeutig stärker im Bereich des Gerätebus-Protokolls. Dieser Bus ist ja ebenfalls standardisiert und wird mit Ausnahme der Booster Ansteuerung für alle anderen Aufgaben verwendet. An diesen Bus sind in einem SX-System die stationären (rückmeldefähigen) Funktionsdecoder, die (intelligenten) Belegtmelder, Interface, Handregler und sonstige De- und Encoder angeschlossen und all diese Geräte sollten nach Möglichkeit ohne ein (Zwangs-)Update mit ihrer bisherigen Funktionalität weiterhin funktionieren. Das war der Rebus, den es wohl hauptsächlich zu knacken galt.
Wie gesagt soweit ich dies beurteilen kann, ist das gelungen, wenn auch D&H auf der einen Seite und Rautenhaus/Radtke auf der anderen Seite hierzu unterschiedliche Lösungsansätze verfolgt haben. An meiner FCC funktionieren, wie bereits erwähnt alle meiner „alten“ SX-Busgeräte mit Ausnahme der nahezu 30 Jahre alten TRIX Interface. Das macht aber nichts, denn in der FCC ist eines integriert und die weiteren, die ich von Uwe Magnus besitzen funktionieren, wenn letztere auch nur Zugriff auf den normalen SX-Datenbereich haben.
Wie man sieht lag und liegt die Schwierigkeit bei den SX-Erweiterungen eigentlich nie am Gleisprotokoll, sondern da man offensichtlich keinen neuen, zusätzlichen Bus in der ZE einführen wollte immer am umfassend genutzten Datenbus. Hier hat es DCC deutlich einfacher. Es gibt außer dem Gleisbus keinen gemeinsamen Datenbus. In DCC-Systemen verwenden die zahlreichen Anbieter nicht nur verschiedene Bussystem mit unterschiedlicher Physik (RS485, CAN, LocoNet, S88, etc.), sondern es kommen teilweise für unterschiedliche Aufgaben (z.B. Rückmeldungen) auch noch separate, autarke Bussystem zum Einsatz.
Darüber hinaus kann man leider auch nicht davon ausgehen, dass selbst dann, wenn dem Bussystem die gleiche Physik zu Grunde liegt, auch ein kompatibles Protokoll zur Anwendung kommt. CAN ist hier nicht gleich CAN usw. Mir mit meinem einfachen Verständnis der Materie sind die zahlreichen Bussysteme, die oft an typischen DCC-Zentralen herausgeführt werden und was dann an welchem Anschluss funktioniert schlicht und einfach zu komplex. Muss gestehen, da kommt mir SX mit seiner charmanten, gradlinigen Busstruktur doch etwas entgegenen.
Dank deinen Ausführungen Stephan und denen von Carsten, scheint bei mir jetzt der Groschen bezüglich des ACK und des Bandbreitengewinns bei DCC gefallen. Eine DCC Zentrale kann sich jetzt die bisher zur sicheren Übertragung angewandte, mehrfache, schnelle, intermittierende Wiederholung eines gerade geänderten Befehls ersparen, wenn sie bereits nach der Aussendung der ersten Übertragung eine ACK vom Decoder erhält und anschließend in einen normalen Refresh-Zyklus übergehen. Soweit ist die Sache klar und dies könnte auch das Defizit bei DCC, von verzögerten Reaktionen bei zahlreichen, in schneller Sequenz durchgeführten Änderungen (z.B. bei Computer Betrieb oder bei sehr vielen Mitspielern), zumindest weitgehend kompensieren.
Wenn ich den damit verbundenen Sachverhalt richtig überblicke, so bedeutet dies doch aber auch, dass in jedem Booster Abschnitt ein „Global Detector“ vorhanden sein muss, der dieses ACK vom Lokdecoder empfängt, auswertet und an die Zentrale weiterleitet, damit diese sofort alle Booster entsprechend synchronisieren kann. Der absolute Gleichlauf der Booster muss ja unter allen Umständen gewährleistet bleiben, da es sonst an den Trennstellen zwischen den Booster-Abschnitten zu Kurzschlüssen kommt, wenn diese gerade von einer Lok oder einem Wagen überbrückt werden.
Ich habe da so meine Bedenken, wann und vor allem auch wie dieses Verfahren unter Beibehaltung der Kompatibilität in die im freien Markt erhältlichen, diversen und verbreiteten DCC-System (Lenz, ESU, Zimo, Tran, Uhlenbrock, Tams, Digitrax, Märklin, Roco, etc.) integriert wird/werden kann. Man wird sehen.
Habe mir gerade mal die Seiten von OpenDCC angeschaut. Das dort beschrieben BiDiB System scheint ja mit all den tollen Features ausgestattet zu sein, über die wir hier diskutieren. Auf diesen Seiten sind wirklich, phantastische, detaillierte Infos zu den Grundlagen von Digitalsystemen speziell zu DCC zu finden. Chapeau, Respekt. Muss mit meiner bescheidenen Urteilskraft unumwunden gestehen, dass Herr Kufer, seine Mitwirkenden und die Probanden sich hervorragend mit der Technik auskennen. Noch sympathischer wäre mir, wenn diese Experten auch ihr zauberhaftes Engagement in SX einbringen würden. Eventuell kann man ja auch das SX-Gleisprotokoll (SX1 + SX2) noch in das BiDiB System integrieren. Träumen darf man doch …
In diesem Sinne wünsche ich allen einen guten Rutsch ins neue Jahr und immer viele und hinreichend schnelle Daten auf dem digitalen Gleis.
Beste Grüße
Werner
PS. Meine Ausführungen sind leider wieder etwas lang geworden. Tschuldigung. Nun, bald ist meine Freizeit ja schon wieder zu Ende und dann verursache ich auch nicht mehr, dass der SX-Thread immer wieder nach oben rutscht 
.
