Digitalsysteme .... eine Gegenüberstellung/nl

Verwendung

Digitale systemen voor modelspoorwegen ... een vergelijking; maar geen vergelijkingen en waarderingen

Digitale systemen ... een vergelijking

Het juiste digitale systeem?

Uit de vele vragen en bijdragen van het forum: Railroad & Co, Freiwald Software (Egmating) heb ik geleerd dat veel modelspoorders die nieuw zijn in het digitale tijdperk of een ombouw / uitbreiding plannen, onzeker zijn over welk digitaal systeem en welke componenten "de juiste" zijn.

Verder heb ik de indruk gekregen dat er in bepaalde bedrijfssituaties problemen ontstaan die alleen zinvol kunnen worden opgelost door rekening te houden met de kennis van het/de digitale systeem/systemen.

Dit alles deed me denken aan mijn eigen tijd toen ik overstapte van het analoge systeem naar digitaal.

Deze vergelijking is bedoeld als aanvulling op de zuivere technische gegevens en feiten zoals gedefinieerd door de fabrikanten in hun gegevensbladen of in de normen.

Ik benadruk nadrukkelijk dat dit artikel niet bedoeld is als een vergelijking van "voor en tegen", noch is het bedoeld om welk systeem dan ook te waarderen.

De lezer moet deze informatie ter harte nemen en hopelijk met succes opnemen in zijn oplossingsproces.

Overwogen digitale systemen

Er zijn een aantal digitale systemen op de markt, maar ik zal alleen kijken naar de systemen die het meest vertegenwoordigd zijn op het bovengenoemde forum; deze omvatten ...

• DCC
• Märklin met zijn varianten
• Selectrix (SX)

Dit verslag gaat over de status van de systemen zoals ze (in mijn geval) in augustus 2011 waren. Latere ontwikkelingen moeten later worden toegevoegd.

Historisch overzicht

Voor zover ik weet en herinner, was Märklin de eerste onderneming die een "compleet" digitaal systeem voor modelspoorbanen op de markt bracht, dat bekend werd als "Motorola I".

De opvolgers Motorola II en mfx' volgden in de loop der jaren.

Märklin introduceerde zijn digitale systeem onder het marketingaspect: Twee draden zijn genoeg om de modelbaan te bedienen. Geen "draadwarboel" meer zoals bij analoge systemen.

Voor zover mogelijk werden de rails gebruikt als draden, ze vormen de verbinding tussen de commandopost en de respectievelijke decoders (centrale >> locomotief-/schakeldecoder). Voor de terugmelding (bezetmelding), die later werd toegevoegd met de pc-aansluiting, werd een extra aparte communicatielijn geïntroduceerd, de "s88-bus" (terugmelddecoder >> centrale).

De technische details van het Märklin systeem werden nooit officieel bekendgemaakt. Technisch geïnteresseerde gebruikers bepaalden de protocollen voor "Motorola I / II en mfx" "achterstevoren" (reverse-engineering) en konden zo zelfgebouwde producten realiseren.

-- Het bedrijf ESU uit Ulm, dat waarschijnlijk een beslissende rol heeft gespeeld in de ontwikkeling van "mfx", verkoopt een product met het "ECOS" controlecentrum, dat ook het "mfx" protocol kan uitvoeren; om redenen van bescherming wordt dit echter het "M4" protocol genoemd.

Onder deze randvoorwaarden kunnen de Märklin-systemen worden gecategoriseerd als "gesloten systemen".

Vanwege deze "compartimentering" ontwikkelde de accessoires-industrie (Lenz), waarschijnlijk in samenwerking met andere modelspoorfabrikanten", het digitale systeem "DCC", dat werd gestandaardiseerd en waarin alle technische gegevens "open" zijn en gratis kunnen worden ingezien.

Het bedrijf Trix, toen nog juridisch onafhankelijk, ontwikkelde samen met industriële ondersteuning het digitale systeem "Selectrix". Dit systeem is ook gestandaardiseerd en alle informatie / gegevens zijn openlijk beschikbaar. Ondertussen is het systeem verder ontwikkeld wat betreft extra locomotiefadressen / functies. Dit nieuwe Selectrix systeem is "upwardly compatible" met zijn voorganger en wordt aangeduid als Selectrix "SX II" (SX2). Het "originele" Selectrix systeem wordt in het volgende aangeduid als Selectrix (SX). Tegenwoordig wordt "SX I" (SX1) ook gebruikt in sommige literatuur om onderscheid te maken tussen de twee.

DCC en Selectrix kunnen worden omschreven als "open systemen" omdat - zoals al eerder vermeld - alle systeemgegevens openbaar worden gemaakt.

Specifieke ontwikkelingsachtergronden

Märklin met zijn systemen en DCC werden ontwikkeld met het oog op de "speelgoedindustrie", wat betekent dat alle vroegere knoppen, schakelaars en transformatorfuncties in een centrale moesten worden geïntegreerd. De randapparatuur, d.w.z. de decoders, moesten zo eenvoudig en dus zo goedkoop mogelijk zijn.

De verbinding met een pc werd eigenlijk pas later toegevoegd en was niet de focus van de eerste ontwikkelingen.

Deze twee systemen kunnen daarom worden gedefinieerd als "gecentraliseerde systemen".

Tijdens de ontwikkeling van Selectrix werd voor een compleet andere aanpak gekozen, waarschijnlijk vanwege de industriële ervaring met gedistribueerde systemen. In het Selectrix netwerk zouden de perifere componenten ook zoveel mogelijk "intelligentie" moeten hebben om een "gedistribueerd systeem" te kunnen bouwen. Deze aanpak vereiste ook een compleet ander communicatiesysteem (bussysteem). Met Selectrix kan elke busdeelnemer gegevens / informatie met elkaar uitwisselen; de enige beperking is hier met de locomotiefdecoders (tijdens het rijden).

Dit is niet mogelijk met de twee eerder genoemde systemen, waar er slechts één richting is van de commandopost naar de decoders (randapparatuur); (met uitzondering van de RailCom methode die momenteel op de markt komt met DCC > zie hieronder; evenals "mfx" hier is er een tegenovergestelde richting locomotief decoder > centrale). Met deze twee functies is de tegenovergestelde richting van communicatie echter alleen beperkt tot de locomotief decoder en is niet algemeen geldig zoals bij Selectrix (>> een groot en significant technisch systeemverschil).

Selectrix valt daarom in de categorie "gedecentraliseerde of gedistribueerde systemen".

En hun effecten

Uiteindelijk is het, rekening houdend met het bovenstaande, niet verwonderlijk dat zich compleet verschillende communicatiestructuren ontwikkelden, zowel aan de hardwarekant als aan de softwarekant in de vorm van protocollen.

Terwijl Selectrix het doet met één bussysteem en één protocoltype voor rijden, schakelen en seinen, vereisen DCC en Märklin elk twee bussystemen en protocoltypes; één voor rijden en schakelen en één voor seinen. SX2 vereist een tweede protocoltype voor communicatie met de locomotief decoder.

Als er handregelaars zijn of moeten worden geïntegreerd om de modelbaan te besturen, is er meestal een derde bus- en protocolsysteem nodig voor Märklin of DCC; Selectrix heeft daarentegen geen extra bussysteem nodig. Bij SX2 kunnen er vanwege de verschillende realisaties door de afzonderlijke fabrikanten ook extra interfaces en/of apparaten op de markt komen in de controlecentra, zodat de handregelaars / bedieningsingangen ook het SX2-protocol kunnen bedienen.

Opmerking: Een Selectrix handcontroller heeft slechts toegang tot één van de SX-bussen van het systeem tegelijk. Als andere SX-bussen moeten worden bediend, moet de handcontroller opnieuw worden aangesloten of omgeschakeld met een elektronische schakelaar.

Verschillende, openbaar gemaakte bussystemen / protocollen

DCC

 Dit protocol (zonder RailCom) is zo ontworpen dat men kan spreken van een "standaard deel" en 
 een "open deel (uitbreidingen)". Deze gekozen structuur maakt het voor de individuele fabrikanten relatief eenvoudig om specifieke 
 productuitbreidingen aan het systeem toe te voegen. 
 Dit resulteert in protocollen van verschillende lengtes en dus transmissietijden van verschillende lengtes.

Selectrix

 Het Selectrix (SX1) protocol, dat bestaat uit een "adresbyte" en een "functiebyte", heeft een star, vast kader. 
 Daarom is elke zendtijd hetzelfde en kan hieruit worden afgeleid hoe vaak elke busdeelnemer 
 binnen een gedefinieerde tijdsperiode wordt aangesproken binnen een bus.
 De flexibiliteit van dit bussysteem ligt in het feit dat het busprotocol (individuele bits) zelf niet wordt toegewezen aan een decoderfunctie.
 De functie van de individuele bit volgt uit de logische toewijzing ervan aan de / decoderfunctie / functies.
 Dit betekent dat hetzelfde bit kan worden geïnterpreteerd als schakeluitgang "S" voor de ene decoder en ingesteld als detectoringang "M" 
 voor de andere > de centrale evalueert dit dan.
 Ook hier kan hetzelfde bit deel uitmaken van een bitcombinatie die een specifiek bericht verzendt, bijv. snelheidsniveau, enz.

 Met de introductie van SX2 wordt een tweede protocol voor het aansturen van (momenteel alleen) de locomotief decoders toegevoegd.
 Het doel van SX2 is om het adres- en functiegebied uit te breiden (extra functies).  
 Aangezien de nieuwe locomotief decoders van Doehler & Haas, Munchen zo kunnen worden geprogrammeerd (geconfigureerd) om te werken als 
 Selectrix (1 / 2), DCC, Märklin - decoders,
 is er een preambule nodig die de decoder vóór elk nieuw protocol informeert voor welke bedrijfsmodus en dus voor 
 welk "locomotief decodertype" de volgende informatie bedoeld is.  
 De preambule wordt dan gevolgd door nog eens 5 bytes die het adres en alle functies bevatten.

 Deze langere verzendtijd vergeleken met SX1 betekent dat de vorige tijden voor een "refresh" niet langer geldig zijn.

Ferner kommt die Herausforderung hinzu, daß nicht alle theoretisch möglichen Lokadressen ständig

 aktualisiert werden können.

Es zeichnet sich ab, daß jeder Hersteller einer Zentrale hier seine eigenen Wege in der

 Realisierung geht. Diese bedeutet auch eine unterschiedliche Anzahl von gleichzeitg steuerbaren 
 Loks auf einer Anlage.

Auf einer Anlage können die bisherigen "SX1 - Loks" (mit ihren bisherigen Adressen) neben neuen

 "SX2 - Loks" betrieben werden.

Im Jahr 2011, gibt ein Hersteller an, daß bei ihm max. 16 SX2 Loks neben den 103 SX1-Loks

 betrieben werden können.
 Ein weitere ermöglicht den gleichzeitigen Betrieb von 32 SX2 Loks.

Wiederum ein anderer verwendet auf dem Gleis ein ganz eignes, an SX angelehntes Gleissignal und

 ermöglicht den gemischten Betrieb von SX1 und SX 2 - Loks, wobei die max. Anzahl von Loks
 weiterhin bei 103 liegt.

Ein weiterer Ansatz ist, daß aus der 4 stelligen Nummer immer nur die Einer / Zehner/ Hunderter

 Stelle fest verwendet wird und letztlich die Loks dann weiterhin im SX1 - Betrieb, also 103 Loks
 zeitlich parallel zu betreiben sind.

Es wird sich zeigen, welche Varianten am Markt angenommen werden.

Dieses vorgenannte gilt für den sog. SX0-Bus einer Zentrale. Bisher wurden der SX0 und der SX1 Bus

 einer Zentrale immer vom Takt und Protokoll her gleich betrieben.
 Je nach obiger Hersteller-Lösung ist das künftig wohl nicht mehr in jedem Fall so.

Der Nutzer sollte sich daher VOR einem Einsatz von SX2 auch Gedanken über die Anschaltung /

 Funktion aller anderen Dekoder / Handsteuergeräte, etc. an den anderen SX-Bussen machen und bei
 den Anbietern nachfragen.

Märklin

Da es keine offiziellen Daten / techn. Informationen über die Märklin - Protokolle gibt, beziehe

 ich dieses System hier nicht weiter in die Protokoll-Betrachtungen ein.
 Leser können sich evtl. über die angebotenen Links weiter informieren.

System- und Kommunikations- Strukturen

zentralistische Systeme

Fahren und Schalten

Bei diesen (hier betrachteten) Systemen sind sowohl die Lok-Dekoder als auch alle anderen Dekoder zum Schalten (Anzeigen) über eine 2 adrige Verbindung (Bus) -- z.B. Schiene / Gleis oder Drähte / Kabel --mit der Zentrale verbunden.

Von der Zentrale werden alle Einstellbefehle codiert über diesen Bus übermittelt.

Die jeweilge Spannung und ihre digitale Codierung ist zwischen den beiden Systemen DCC und Märklin sehr unterschiedlich. Selbst zwischen Motorola I / II und mfx (M4) gibt es große Unterschiede.

Nähere techn. Informationen über die Busse und ihre Protokolle können über die Links (unten) abgerufen werden.

Da die mir am Markt bekannten Dekoder zum Schalten / Anzeigen relativ einfach aufgebaut sind muß zum Schalten eines Ausgangs ein Befehl ausgegeben werden > Ausgang "ein" und nach einer Zeit t der Befehl > Ausgang "aus". Die Zeit t wird in der Zentrale verwaltet. Daraus folgt, jedes Schalten eines Magnetartikels erforddert 2 Busübertragungen Plus einer Zeitverarbeitung in der Zentrale.

Melden

Diese Funktion wurde erst mit der Erweiterung der "PC-Steuerung" notwendig. Sie ist quasi das "Auge des Modellbahn-Steuerungsprogramms, hier von TrainController (TC).

Das Prinzip des Meldens ist die Erkennung eines Stromflusses, ausgelöst durch ein Fahrzeug, welches sich in einem Überwachungsbereich (Gleisabschnitt) befindet.

DCC

Die Besetztmeldung / Erkennung basiert bei DCC auf der sog. "Strommessung".

  Hier wird der gesamte Strom eines Abschnittes über einen Besetztmelder (Dekoder) geführt.
  Fließt ein Strom weil sich ein Verbraucher (Lok oder Wagen mit Beleuchtung oder
  "Widerstandsachsen") auf dem Gleisabschnitt befindet, dann wird dies erkannt und über einen
  eigenen Meldebus mit eigenem Protokoll an die Zentrale gemeldet.

Anmerkung:

  Die "Widerstandsachsen" sind elektr. parallel geschaltete Widerstände, deren Gesamtwiderstand
  sich wesentlich reduziert, was zu einem höheren Strom führt.
  Dies ist bei der Auslegung der Widerstandsachsen / Konfiguration der Anlage bzw. Empfindlichkeit der Belegtmelder zu berücksichtigen.

Märklin

Die Besetztmeldung / Erkennung basiert bei Märklin aus der "Masse-Kontaktgabe". Diese historische

  Bezeichnung ist geblieben, obwohl man bei einem digitalen System nicht mehr von "Masse" sprechen
  kann.
  Der Mittelleiter ist an einen Ausgang von Zentrale bzw. Booster angeschlossen, der andere an
  einem der beiden Außengleise (Schienen).
  Steht ein Märklin (oder 3 Leiter-Fahrzeug) auf dem Gleis, dann verbinden die elektr. leitenden
  leitenden Achsen das an der Zentrale / Booster angeschlossene Gleis (Schiene) mit dem anderen
  Melde - Gleis (Schiene). Diese Schiene ist an einem Melde-Dekoder-Eingang angeschlossen.
  Somit liegt am Meldereingang das gleiche Potential wie bei der Zentrale / Booster an.
  Über einen im Meldedekoder hochohmigen Widerstand kommt jetzt ein kleiner Stromfluß (mA)
  zustande, denn der Meldedekoder muß einen Anschluß besitzen auf dem sich das Mittelleiter- 
  Potential des Gleisabschnitts befindet; also es muß eine Verbindung zur Zentrale oder Booster
  bestehen.
  Letztendlich wird auch hier ein Stromfluß ausgewertet; im Gegensatz zu DCC ist dieser allerdings
  kleiner.

Die beiden unterschiedlichen Ansätze brachten am Markt auch unterschiedliche Dekodertypen hervor. Diese sind jeweils über unterschiedliche Bussysteme mit der Zentrale verbunden.

Während bei Märklin der "S88" Bus sein muß, hängt es bei DCC davon ab, was die jeweilige Zentrale für einen Melde-Bus zur Verfügung stellt.

Identifikation von Lok-/Fahrzeug- Adressen

DCC

Mit dem genormten Systemteil RailCom bringt die DCC Gemeinde derzeit ein Rückmeldesystem auf dem

 Markt, was nicht nur die Lok-Dekoder-Adresse meldet, sondern noch umfangreichere sonstige
 Informationen liefert, wie z.B. schnelles Lokprogrammieren überall auf der Anlage, Erkennen verschmutzter Gleise und Informationen über angekuppelte Waggons (Zukunft).
 Unter OpenDCC findet der Leser hierzu eine umfangreiche Abhandlung.

Im Prinzip basiert die Lösung auf folgendem Verfahren:

 Die Gleisspannung wird derzeit in regelmäßigen, sehr kurzen Abständen umgeschaltet, so daß
 die "Rechteckspannung" entsteht. In diesen Umschaltmoment wird eine kurze Verzögerung eingefügt,
 damit ist das Gleis für eine kurze Zeit von der Zentrale / Booster abgeschaltet > Spannungslos.
 Innerhalb dieser Zeitspanne kann jetzt ein Lokdekoder eine Meldung über die Gleise schicken,
 die dann von der Zentrale aufgenommen und ausgewertet werden muß.
 Der Lokdekoder benutzt als Energiequelle für die Aussendung einen kleinen, auf dem Dekoder vorhandenen Kondensator.

Anmerkung:

 Liegt nach der kurzen Verzögerung wieder die Gleisspannung an, dann lädt sich der Kondensator
 wieder auf.
 Die Kondensatoren aller auf der Anlage befindlichen Loks sind elektr. gesehen parallel geschaltet,
 so daß sich am Ende der Rücksendung ein durchaus beachtlicher Ladestrom ergeben kann. Das muß bei der Auslegung
 der Booster berücksichtigt werden.

Die Zeitschlitze für Railcom werden aus den sowieso vorhandenen Synchronisationsbits genommen, die Geschwindigkeit der Datenübertragung

 Richtung Lok bleibt unverändert. Dadurch, dass die Lok den Empfang einer Nachricht mit Railcom bestätigt, kann die Zentrale auf
 die prophylaktische Wiederholung verzichten und so einen höheren Durchsatz erreichen und dadurch genaueres Halten ermöglichen.

Märklin

Mit mfx (M4) hat Märklin ein Meldesystem eingeführt. Dieses hat allerdings eine ganz andere

 Funktion als das unter DCC vorgestellt und das noch unter Selectrix vorzustellende Verfahren.
 Bei Märklin melden sich die Loks mit ihrer Lokdekoder-Adresse beim Aufsetzen automatisch bei 
 der Zentrale an. Die Zentrale ordnet dieser Lokdekoder-Adresse eine "Modellbahn-Lok-Adresse" zu.
 Es findet also keine Identifikation über den Standort des Fahrzeuges (Lok) auf der Anlage statt.

Dezentrale Systeme

In diesem Beitrag wird in diesem Abschnitt nur das Selectrix-System betrachtet.

Grundsätzlich wird das Gleis über zwei Leitungen an die Zentrale oder einen Booster angeschlossen. Über diese Leitungen erfolgt, wie bei den beiden anderen Systemen auch, die elektrische Versorgung des Lokdekoders und des Lok-Motors als auch die Busübermittlung. Wie bei DCC wird auch hier die Polarität in sehr kurzen Zeitspannen zur Erzeugung einer "Rechteckspannung" umgeschaltet. Das Protokoll ist allerdings unterschiedlich zu DCC, als auch gegenüber Märklin.

Booster werden über den sog. PX-Bus mit der Zentrale verbunden. Über diesen Bus wird das Übertragungssignal von der Zentrale an die Booster übermittelt. Die Booster prägen es dann innerhalb ihres Versorgungsbereichs der Gleisspannung auf.

Fahren, Schalten und Melden

Aus Sicht der Zentrale ist das Gleis ein Teil des SX 0 - Busses. Und nur an einem SX 0 Bus kann ein Lok-Dekoder (Fahren) angeschaltet werden !!

Alle anderen SX - Dekoder (Schalten, Melden) können wahlfrei über einen der beiden SX 0 oder SX 1 Bus mit der Zentrale verbunden sein. Beide Busse sind vollkommen identisch aufgebaut --- bei Einsatz von SX1; bei SX2 kann es je nach Hersteller -Lösung Unterschiede geben (s.oben !!!).

Über diese Busse werden auch die logischen Schaltkreise der Dekoder versorgt !!, während Spannungen zum Schalten, etc. separat dem Dekoder zuzuführen sind.

Beim Schalten zeigt sich -- im Gegensatz zu DCC und Märklin -- ein großer Unterschied. Soll bei SX z.B. eine Weiche geschaltet werden, dann setzt die Zentrale an den Dekoder nur eine Meldung ab mit dem Inhalt > Weiche schalten und die Weichenstellung. Der Dekoder übernimmt das einschalten des Magnetartikels (Spule) und beachtet die Einschaltdauer (Stromflußdauer) und schaltet dann den Magnetartikel wieder aus. Aus Sicht der Zentrale ist dies pro Schaltvorgang eine 50% Busentlastung und eine starke Entlastung bei der Zeitverfolgung (Einschaltdauer des Magnetartikels).

Das Prinzip des Meldens ist das gleiche wie bei DCC, also eine Messung des Gesamtstroms im Meldeabschnitt. Wobei der Meldedekoder hier an einen der SX-Busse angeschlossen und mit der Zentrale verbunden ist.

Wollen Märklinisten allerdings -- wie ich selbst, SX verwenden --, dann steht ihnen aufgrund des 3 Leitergleises auch die "Märklin-Variante" zusätzlich zur Verfügung. Wie unter Märklin dargestellt, kann vom "Melde-Gleis (Schiene)" eine Verbindung zum SX-Melder-Eingang geführt werden. In diese Verbindung muß der Nutzer allerdings selbst einen z.B. 10 k Ohm Widerstand einfügen. Damit funktioniert eine "Masse-Kontakt" Meldung wie zuvor beschrieben.

Konfigurierungshinweis für SX-Besetztmelder

Bei der Konfiguration (Anschaltung an SX - Bus einer Zentrale) von SX - Besetztmeldern ist

 folgendes zu beachten:
 Besetztmelder OHNE Opto-Koppler, die das Gleispotential vom Potential des Besetztmelders
 trennen, müssen an der Zentrale angeschlossen werden, an die auch die Gleisversorgung
 angeschlossen ist.
 Besetztmelder MIT Opto-Koppler können auch an die SX-Busse der anderen Zentralen
 angeschlossen werden.
 Der TC-Forumsbeitrag :
 http://www.freiwald.com/forum/viewtopic.php?f=8&t=14071&hilit=sx+optokoppler+besetztmelder
 liefert hierzu in bildhafter Darstellung die "elektrische Erklärung".
 Für Detailfragen, bitte den Verfasser per eMail kontaktieren.

Selectrix II --- und die neue Lok-Adressierung

Mit Einführung von SX II wurde das bisherige "Manko" von "nur 100 Lokadressen" aufgehoben. Es lassen sich jetzt ca. 10.000 Adressen für Lok-Dekoder vergeben; mehr als genug. Ferner wurden zusätzliche Ausgänge auf dem Lok-Dekoder zum Schalten von Lok-Funktionen bereit gestellt.

Aber wie kann dann das alte Prinzip mit annähernd gleichen Zyklen in der Dekoderkommunikation eingehalten werden ??

Genau genommen gar nicht, denn eine Protokollübertragung dauert wesentlich länger als bei SX1. Hinzu kommt, daß im Gegensatz zu SX1 keine feste Anzahl von Lok-Adressen mehr durch den Systemansatz vorgegeben sind, sondern jeweils durch den Hersteller einer Zentrale festgelegt werden -- 10.000 sind wohl illusorisch und selbst 100, wie bei SX1 sprengen schon weit den bekannten "refresch - Rahmen".

Nach einigen Recherchen bin ich zu dem Ergebnis gekommen, daß bei SX2 nur das Gleissignal als solches "genormt" ist. Die eigentliche Realisierung von SX2, sowie sie den Nutzer interessiert, aber den einzelnen Herstellern der Zentralen überlassen bleibt.

Infolge legen diese auch fest, wieviele Loks auf der Anlage unter SX2 gleichzeitig aktiv betrieben werden dürfen. Aus dieser Festlegung, der max. Anzahl ergibt sich dann für den SX2 refresh-Anteil wieder ein max. zeitlicher Rahmen. Der gesamte refresh-Zyklus, soweit mir bekannt, setzt sich dann aus dem bisher bekannten SX1 refresh-Anteil und dem jeweiligen neuen SX2 refresh-Anteil zusammen.

Hierbei ist zu beachten, daß der SX2 refresh-Anteil innerhalb der min. / max. Anzahl von "aktiven" SX2-Loks zeitlich schwankt, also in sofern lastaabhängig ist.

Daraus läßt sich aber sofort ableiten, daß es einer Strategie bedarf, nach der Loks als "aktiv" oder "passiv" eingestuft werden und jeweils flexibel eine Umgruppierung stattfindet. Desweiteren ist jeweils zu definieren, wie sich der "passiv" - Zustand für den Nutzer auf der Anlage bemerkbar macht.

Die jeweilige max. Anzahl von "aktiven" Loks hat dabei zwei gegengerichtete Auswirkungen. Ist ihre Anzahl gering, dann ist zwar der gesamte refresh-Zyklus kürzer (mehr Wiederholungen z.B. pro sek oder min.) hingegen steigt die Häufigkeit der Umgruppierungen und damit der Aufwand im Handling bzw. in der "zeitlichen Wartezeit". Bei höherer Anzahl, ist dieses Verhalten invers.

Eine weitere Betrachtung gilt der höhreren Anzahl von zu übertragenden Bytes, verglichen mit SX1. Die höhere Anzahl bedingt typischerweise auch eine höhere Fehlerrate in der Übertragung, damit wird wieder eher eine schnelle Wiederholung wünschenswert.

Eine weitere Folge dieser "Freiheit" ist, daß die Schnittstelle Zentrale <> PC je nach Hersteller unterschiedlich ausfällt. Es bleibt abzuwarten, wie die einzelnen Hersteller von Modellbahn-Steuerungsprogrammen, wie TC, darauf reagieren.

Beispiel

Ein Hersteller plant die Gleichzeitigkeit von 12 SX2-Loks zu unterstützen, ein anderer offeriert

 bereits die Unterstützung von 32 SX2-Loks.
 In beiden Fällen wird das obige "passiv" so definiert, daß die Fahrstufe 0 vorliegen muß UND ALLE
 Zusatzfunktionen als auch ALLE Lok-Lichter ausgeschaltet sind.
 Dies bedeutet, daß der Nutzer -- gleich ob im manuellen Betrieb oder via PC -- diese
 Konstellation herbeiführen muß. 
 Ist die "Gleichzeitigkeitsgrenze" erreicht, bedeutet dies, daß z.B. eine Lok dunkel geschaltet
 werden muß, während sie im Bahnhof wartet, damit eine andere fahren kann.
 Ein solcher Lösungsansatz erscheint wirklichkeitsfremd, insbesondere bei Verwendung von so
 mächtigen Modellbahnsteuerungsprogrammen, wie TC.

Identifikation von Lok-/Fahrzeug- Adressen

Diese Identifikations-Methode ist etwas "tricki".

Wie bei DCC wechselt auch bei SX das Gleispotential an den Schienen. Hierbei entsteht eine kleine Spannungslücke -- während diese bei DCC sehr viel größer sein muß !!

In dieser kurzen Phase entlädt sich ein kleiner Kondensator, der sich auf dem Lok-Dekoder befindet über die Schienen und den an der Schiene angeschlossenen Meldereingang und von dort zum Booster / Zentrale und wieder zurück zum Gleis / Schiene > Lok.

Der hierbei entstehende kleine Stromfluß (bei SX I ca. 1-2 mA; bei SX II ca. 5 mA) wird vom Melder erkannt und ausgewertet.

Wie erfolgt nun die Zuordnung zur Lok-Dekoder-Adresse ??

Die Kondensatorentladung erfolgt während der Übertragung der Informationen an die Lok xyz. Der "intelligente" SX-Melder registriert (merkt sich) sich die jeweils gesendete Lok-Adresse. Folgt jetzt unmittelbar in seinem Beobachtungs (Melde-) Abschnitt eine Kondensatorentladung, dann kann er die Lokadresse diesem Abschnitt zuordnen, was z.B. bei TC (TrainController) einem Block entspricht.

Hinweis: Soll die SX-Identifikation eingesetzt werden, dann müssen nach SX-Angabe alle in Lok und Wagen vorhandenen Birnchen / LEDs auf einer Seite über eine schnell schaltende Silizium-Diode verbunden werden. Diese Diode verhindert "Querströme" die bei der Kondensatorentladung auftreten würden und dann könnte keine saubere Erkennung erfolgen. Wenn Märklinisten SX und seine Melder einsetzen (s. oben), dann muß aus solchen Gründen auch eine Diode in Serie zum Widerstand gechaltet werden.

Auch hier wird beim Aufgleisen die Lok UND der Standort erkannt. Beim Vergleich zu DCC fällt auf, daß das DCC Meldesystem sehr viel weiter ausgebaut ist als das von SX.

ACHTUNG: Das vorgenannte gilt derzeit nur für SX1 Loks; Loks mit den neuen "Multi-Protokoll-Dekodern" scheinen dieses noch nicht zu unterstützen. Analoges gilt auch für die sog. "intelligenten" Besetztmelder.

ALLGEMEIN: Die heutigen, modernen PC-Modellbahn-Steuerungsprogramme, wie TC, benötigen keine solche Identifikation für den laufenden Betrieb der Anlage. Allerdings können solche Systeme hilfreich sein, wenn in schwer einsehbaren Bereichen (z.B. Schattenbahnhöfen) manuell - ohns PC-Programm - Zugbewegungen vorgenommen werden müssen.

Multiprotokoll-Zentrale und Dekoder

Auf dem Markt werden zunehmend mehr Multiprotokoll Dekoder und Zentralen angeboten. Dies ist wohl primär als Marketing Instrument der Hersteller zu sehen, als auch ein Instrument beim "Verteilungskampf" von Marktanteilen.

In den wenigsten Fällen werden private Modellbahner (außer Clubs) eine Vielzahl und Vielfallt von Modellbahnen (Loks) besitzen. Auch wenn dies hier und da der Fall sein sollte, dann wäre ein Dekoder-Umbau auch eine gute Alternative zu einer "Multiprotokoll-Anlage".

Mit mehreren Systemen (Protokollen) auf einer Anlage zu arbeiten ist nicht unproblematisch und bedarf vom Nutzer immer ein "Mehrfach-Wissen" beim Aufbau, Betrieb und Pflege seiner Anlage.

Aus technischer Sicht ist anzumerken, daß es immer zu zeitlichen Verzögerungen beim "Umschalten" der Protokolle kommt -- gegenüber einem Reinrassigen-System. Es müssen von der Zentrale / Dekoder die Umstellung in der Gleisversorgung (Takt, Codierung) vorgenommen bzw. erkannt werden. Bei "zentralistischen Systemen" sind von solchen zeitlichen Belangen nicht nur die Lok-Dekoder betroffen, sondern zusätzlich ALLE an dem Bus (Zentrale) angeschlossenen Schaltdekoder.

Wenngleich sich die einzelnen Zeiten nur im µs / ms - Bereich bewegen mögen, so können sich diese addieren. Hier ist ein wesentlicher Faktor auch der Mix der Loks und ihre jeweils aktuelle Nutzung.

Hinweis: Die gegenwärtig von Doehler & Haas angeboteten Lokdekoder werden bei der Erstinbetriebnahme auf eines der möglichen Gleisformate (DCC, Märklin, Selectrix (1/2), je nach verwendeter Zentrale, eingestellt. Auf der Anlage arbeiten sie im Betrieb dann ausschließlich in diesem Operationsmodus.

Einsatz auf Modellbahn-Anlagen

Labor v.s. Anlage

Es wird keinen Zweifel geben, daß diese Multiprotokoll-Systeme in den Labors der einzelnen Hersteller einwandfrei arbeiten.

Auf den unterschiedlichen Anlagen, insbesondere auf mittelgroßen und dies im Zusammenwirken mit PC-Anlagen-Steuerungsprogrammen, wie TC, kann es zu zeitlichen Problemen bei der Abarbeitung der Steuerbefehle / Melderabfragen kommen.

Dies insbesondere dann, wenn zentralistische Systeme wie DCC und Märklin mit komplett unterschiedlichen Gleis-Signalen / Busprotokollen zusammen als Multiprotokoll - System betrieben werden.

Beispiel Schalten

Aufgabe: Schalten einer Weiche von TC heraus.

Lösung: Märklin / DCC

TC sendet über den Bus PC <> Zentrale eine Meldung zum Schalten der Weiche x in Stellung r.

Die Zentrale muß diese Meldung aufnehmen und in drei Aktionen zerlegen ..

1. Meldung an zugehörigen Weichendekoder senden mit dem Inhalt Ausgang (= Weiche x) einzuschalten (Stromfluß > Magnetartikel Spule)
2. Zeit für Dauer der Einschaltung der Spule setzen und abfragen, wann diese abgelaufen ist
3. Meldung an zugehörigen Weichendekoder senden mit dem Inhalt Ausgang (= Weiche x) auszuschalten (kein Stromfluß > Magnetartikel Spule)

TC sollte in dieser Zeitspanne KEINE weiteren z.B. Weichenbefehle an die Zentrale senden. D.h. in TC ist eine entsprechende "Wartezeit" einzutragen, diese sollte größer sein als die unter 2) eingestellte Zeitdauer plus Reserve.

Diese Reserve wird in der Praxis benötigt, da davon auszugehen ist, daß eine Busübertragung wegen Störungen auch wiederholt werden muß.

Es können auch sonstige Aktivitäten "dazwischen kommen".

Lösung: Selectrix - TC sendet über den Bus PC <> Zentrale eine Meldung zum Schalten der Weiche x in Stellung r.

Die Zentrale muß diese Meldung aufnehmen und in eine Aktionen zerlegen ..

1. Meldung an zugehörigen Weichendekoder senden mit dem Inhalt Ausgang (= Weiche x) auf Stellung r zu schalten.

Der SX-Weichendekoder nimmt diese Meldung auf und zerlegt diese in die Aktionen ....

1. Ausgang (= Weiche x) einschalten (Stromfluß > Magnetartikel Spule)
2. Zeit für Dauer der Einschaltung der Spule setzen und abfragen, wann diese abgelaufen ist
3. Ausgang (= Weiche x) ausschalten (kein Stromfluß > Magnetartikel Spule)

TC sollte in der Zeit, in der die Zentrale beschäftigt ist, keine weiteren Weichenbefehle senden. Im Vergleich zum vorrangegangenen Systemansatz ist diese Belegung aber wesentlich kürzer.

Somit steht in TC auch nur eine sehr kurze "Wartezeit". TC kann also in einer wesentlicher höheren Sequenz Aktionen (z.B. Weichen schalten) ausführen, da sowohl die Auslastung der Zentrale als auch der Anlagenbusse pro Aktion sehr viel geringer ist.

Anzahl Fahrstufen im Lok-Dekoder Systembelastung

Dieses Beispiel gilt gleichermaßen für alle 3 betrachteten Systeme und betrachtet die Problematik nur qualitativ.

• Aufgabe:

Es soll eine Lok aus der Fahrgeschwindigkeit Vg innerhalb eines Bremsbereichs von z.B. L = 30 cm auf die Kriechgeschwindigkeit Vk abgebremst werden, so daß mit Erreichen des Haltebereichs die Lok sofort anhalten (stoppen) kann.

• Gegeben:

Lok A mit 128 Fahrstufen Lok B mit 31 Fahrstufen Computersteuerprogramm - TrainController (TC) Zentrale des jeweiligen Systems, angeschlossen über eine serielle Schnittstelle an den PC

• Darstellung für Lok A:

TC berechnet nach Erkennen des Erreichens des Bremsbereichs anhand von Vg und der Länge L sowie der Zielgeschwindigkeit Vk und der Anzahl der Lok-Fahrstufen, wie oft eine Fahrstufenreduzierung an die Zentrale zu senden ist. Aus dieser Betrachtung ergibt sich auch die optimale zeitliche Verteilung.

In dieser Betrachtung gehen wir mal von 100 zu schaltenden Fahrstufen aus.

TC setzt also 100 Meldungen an die Zentrale ab und diese "übersetzt" diese Information in das entspechende Datenformat / Protokoll und schickt ebenfalls min. 100 Meldungen an den Lokdekoder. Bei einer schlechten Gleisverbindung sind es in der Regel mehr.

• Darstellung für Lok B:

Der erste Absatz von Lok A trifft genau so für Lok B zu.

Allerdings gehen wir hier mal von 25 zu schaltenden Fahrstufen aus.

Der dritte Absatz von Lok A trifft auch wieder für Lok B zu; allerdings werden min. nur 25 Meldungen gesendet.

• Ergebnis der "Spielerrei"

-- und das gilt sowohl für das Bremsen als auch Beschleunigen --

Für Lok A werden 4 mal mehr Befehlsübertragungen benötigt als für Lok B. Das System ist also wesentlich stärker belastet. Allerdings berücksichtigt TC diese Belastung und reduziert für starke Änderungen die Zahl der gesendeten Fahrstufen an Lok A. Man erhält mit TC etwa vergleichbares Verhalten bei starken Änderungen, bei langen Bremsrampen werden hingegen die feinen Abstufungen für Lok A benutzt. Ob das menschliche Auge im "normalen" Anlagen-Betriebsalltag einen wesentlichen Unterschied feststellen kann ??, daß muß jeder für sich herausfinden.

Allerdings ist davon auszugehen, daß zeitliche Engpässe aufgrund des obigen Effekts sehr wohl bemerkbar sind, wenn viele Zugbewegungen zeitlcih parallel stattfinden.

Beispiel >> Fahren / Multiprotokolle

Wird mit unterschiedlichen Protokollen gefahren, das geschieht bei Märklin bereits, wenn Motorola I / II und mfx (M4) eingesetzt wird, dann muß die Zentrale jeweils komplett die Gleistakte ändern als auch das Protokoll. Das alle kostet Zeit. Bei manuellem Betrieb von zwei Loks sicher kein Problem, jedoch mit z.B. TC und 15 Loks kann es zu welchen kommen (wobei die Zahlen nur die Unterschiede verdeutlichen sollen und keine absoluten Werte darstellen).

Entsprechendes gilt, wenn der Lok-Dekoder mit mehreren Protokollen betrieben werden kann. Dann muß der die entsprechende "Vorauswahl" treffen. Auch das kostet Zeit.

In all diesen Fällen, kann es -- wie die vielen Anfragen im TC-Forum zeigen -- unter den unterschiedlichsten Randbedingungen zu Problemen kommen; sie müssen aber nicht auftreten und vor allem sich nicht immer in der .

Auch der Betrieb mit SX2 wirkt sich, neben der längeren Übertragungszeit des Protokolls, auch durch die Lok-Verwaltung (Loks aktiv / passiv setzen) zeitlich recht ungünstig aus. Betreiber von SX2 Anlagen sollten dies entsprechend berücksichtigen.

Zusammenwirken mit dem Software Programm TrainController (TC)

TC kann, so zeigt es auch die weltweite Verbreitung mit sehr vielen Zentralen zusammenarbeiten. Mittels der Vielfalt der Einstellungsmöglichkeiten können auch einige zeitliche Probleme "umgangen" werden.

Wie und wann die Umsetzung von SX2 durch TC erfolgt wird sich wohl erst frühestens im Laufe des nächsten Jahres zeigen.

Sollten Funktionen nicht so ablaufen wie erwartet, so zeigt sich aufgrund des TC Forums, daß in aller Regel der Engpaß in der Hardware und bei den System- Lieferanten zu suchen ist.

Quellen für weitergehende Informationen

Die nachfolgend aufgelisteten Links sollen dem Leser die Möglichkeit geben weiter in diese Thematik einzuarbeiten. Insbesondere tiefer in die verschiedenen Techniken "einzusteigen".

--Ausschluß

 Da weder ich als Autor dieses Textes noch der Bereitsteller der TC-Wiki-Plattform, es in der
 Hand haben welche Inhalte jeweils hinter den Links stehen - bekanntlich ändern die sich über
 die Zeit -- ist der Leser / Nutzer selbst voll veranwortlich für die Nutzung der Links.
 Schadensansprüche, gleich aus welchem Grunde und an wen, werden vom Leser / Nutzer mit Betätigen
 der Links automatisch ausgeschlossen.
 Dem Richterspruch des OLG Hamburg folgend, distanziere ich mich (und auch der Betreiber dieser
 Plattform) von den Inhalten der verlinkten Seiten, inkl. von Folgeseiten.

• Datenformate (Märklin - DDC - Selectrix - u.a

http://www.digital-bahn.de/info_begriffe/protokoll.htm

• Multiprotokoll - Zentralen / Dekoder

http://www.digital-bahn.de/info_kompo/zentrale_multi.htm

• DCC

http://www.opendcc.de/index.html

 http://www.lokodex.de/mo/m_digital_dccprot01.htm
 http://www.steinhartw.de

• Märklin

http://de.wikipedia.org/wiki/M%C3%A4rklin_Systems

 http://www.stayathome.ch
 http://www.suter-meggen.ch/maerklin/digital/mfx_decoder/index.htm
 http://www.alice-dsl.net/mue473/index.htm

• Selectrix

http://www.steinhartw.de

 http://www.steinhartw.de/D&H%20Lokadressen/D&H%20Lokadressen%20Erfassung.htm
 http://de.wikipedia.org/wiki/Selectrix
 http://www.frank-keil.de/selectrix_/selectrix_.html
 http://www.uwe-magnus.de
 http://www.1zu160.net/digital/selectrix.php
 http://doehler-haass.de/cms
 http://doehler-haass.de/cms/media/pdf/FCC_Interface_Doku.pdf
        (aus diesem Dokument läßt sich auch das Gleisprotokoll herleiten !!!)

• weitere spezielle Informationen zu den einzelnen Produkten findet der Leser auf der jeweiligen

 HomePage der Hersteller / Distributoren:
 Aus Gründen der Neutralität werden hier keine Links bereit gestellt.

Fazit

Ich hoffe, daß diese Gegenüberstellung den Umsteigern von ANALOG auf DIGITAL eine grundsätzliche Hilfe zur Entscheidung für "IHR Digital System" gibt und allen anderen Lesern einige Anregungen zur Gestaltung ihrer Modellbahnanlage. Ferner mögen diese Hinweise auch im Falle von Problemen eine Hilfestellung zur Lösungsfindung geben.

Weblinks

• TC-wiki: Vergleichstabelle Digitalzentralen

--Jens Mohr 09:40, 17. Jul. 2011 (UTC) († 2023)

bearbeitet:Wohlmannstetter (Diskussion) 18:36, 10. Mär. 2021 (CET), Uslex (Diskussion) 14:35, 12. Feb. 2024 (UTC), Uslex (Diskussion) 10:42, 24. Aug. 2024 (CEST)