Übersetzungen exportieren

Einstellungen

Gruppe

Sprache

Format

Für die Offline-Übersetzung exportieren

Im systemeigenen Format exportieren

Im CSV-Format exportieren

{{DISPLAYTITLE:Digital systems... a comparison}}<languages/>
{{TC7891011gsb}}
__NOTOC__

Model railway digital systems... a comparison; but no comparisons or evaluations.

<span id="Digitalsysteme_..._eine_Gegenüberstellung"></span>
== Digital systems... a comparison ==

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Das richtige Digitalsystem? ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Aus den vielen Anfragen und Beiträgen aus dem Forum: Railroad & Co, Freiwald Software (Egmating)
habe ich entnommen, daß viele Modellbahner, die neu in das digitale Zeitalter eintreten oder eine Umstellung / Erweiterung vor haben, unsicher sind, welches digitale System und welche Komponenten denn nun "die richtigen" seien.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Ferner habe ich den Eindruck gewonnen, daß bei bestimmten Betriebssituationen Probleme auftauchen, die sinnvoll nur unter Berücksichtigung der Kenntnisse der / des digitalen Systems(e) gelöst werden können.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Bei all dem wurde und werde ich an meine eigene Zeit erinnert, als ich vom analogen System auf das digitale umgestiegen bin.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Diese Gegenüberstellung soll die reinen technischen Daten und Fakten, wie sie von den Herstellern in ihren Datenblättern bzw. in den Normen definiert sind ergänzen.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Ich betone ausdrücklich, daß dieser Beitrag kein Vergleich über "für und wider" darstellen und auch kein System bewerten soll.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Der Leser soll diese Informationen mit aufnehmen und hoffentlich erfolgreich in seine Lösungsfindung einbeziehen.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Betrachtete Digitalsysteme ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Am Markt werden eine Reihe von digitalen Systemen angeboten.
Ich will hier nur die betrachten, die am häufigsten im oben erwähnten Forum vertreten sind;
hierzu zählen ...
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
* DCC
* Märklin mit seinen Varianten
* Selectrix (SX)
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
In dieser Abhandlung wird der Stand der Systeme betrachtet, wie er (bei mir) im August 2011 vorlag. Spätere Entwicklungen müssen jeweils nachgetragen werden.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Digitalsystem - Architekturen ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Historische Betrachtung ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Meines Wissens und meiner Erinnerung nach brachte die Fa. Märklin als erstes ein "komplettes" Digitalsystem für Modellbahnanlagen auf den Markt, welches als '''"Motorola I"''' bekannt wurde.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Es folgten über die Jahre die Nachfolger '''"Motorola II"''' und '''"mfx"'''.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Märklin führte sein digitales System unter dem Marketingaspekt ein: Zwei Drähte genügen zum Betreiben der Anlage. Kein "Drahtverhau" mehr, wie bei analogen Anlagen.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Als Drähte fungierten weitestgehends die Schienen, sie sind die Verbindung zwischen Zentrale und jeweiligen Dekodern (Zentrale >> Lok- / Schalt- Dekoder).
Für die Rückmeldung (Besetztmeldung), die später mit dem PC-Anschluß hinzu kam, wurde eine zusätzliche separate Kommunikationsstrecke eingeführt, der "s88 - Bus" (Melde-Dekoder >> Zentrale).
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Die technischen Details des Märklinsystems wurden ofiziell nie offengelegt.
Technisch interessierte Nutzer ermittelten "rückwärts" (re-engineering) die Protokolle für "Motorola I / II und mfx" und konnten somit Selbsbauprodukte realisieren.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
-- Die Fa. ESU, Ulm welche wohl maßgeblich an der Entwicklung von "mfx" mitgewirkt hat, vertreibt mit der Zentrale "ECOS" ein Produkt, welches auch das Protokoll "mfx" ausführen kann; dort wird dieses aber aus Schutzgünden "M4" Protokoll genannt --
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Man kann unter diesen Randbedingungen die Märklinsysteme als "geschlossene Systeme" einstufen.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Aufgrund dieser "Abschottung" entwickelte die Zubehörindustrie (Fa. Lenz), wohl im Zusammenwirken mit anderen Modellbahnherstellern", das digitale System "DCC", welches genormt wurde und bei dem alle technischen Daten "offen liegen" und kostenlos einzusehen sind.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Die Fa. Trix, seinerzeit noch juristisch eigenständig, entwickelte zusammen mit industrieller Unterstützung das digitale System "Selectrix".
Dieses System ist ebenfalls genormt und alle Informationen / Daten liegen offen vor.
Zwischenzeitlich wurde das System in punkto zusätzlicher Lok-Adressen / Funktionen weiterentwickelt.
Dieses neue Selectrix-System ist mit dem Vorgänger "aufwärts kompatibel" und wird als Selectrix "SX II" (SX2) bezeichnet. 
Im weiteren Verlauf wird das "ursprüngliche" Selectrix - System nur als Selectrix (SX) bezeichnet. Heute findet man z.T. zur Unterscheidung auch "SX I" (SX1) in der Literatur.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
'''DCC''' und '''Selectrix''' lassen sich als "offene Systeme" bezeichnen, da - wie bereits erwähnt - alle Systemdaten offen gelegt sind.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Spezifische Entwicklungshintergründe ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Märklin mit seinen Systemen als auch DCC wurden auf dem Hintergrund der "Spielzeugindustrie" entwickelt.
Dies bedeutet, alle bisherigen Tasten, Schalter, Trafo - Funktionen sollten in eine Zentrale integriert werden. Die Peripherie, d.h. die Dekoder sollten so einfach und damit so preiswert als irgend möglich sein.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Die Anbindung an einen PC kam eigentlich erst später hinzu und stand nicht im Fokus der ersten Entwicklungen.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Somit lassen sich diese beiden Systeme als "zentralistische Systeme" definieren.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Bei der Entwicklung von Selectrix wurde, wohl durch die industriellen Erfahrungen mit verteilten Systemen, ein gänzlich anderer Ansatz gewählt.
Im Selectrix-Verbund sollten auch die peripheren Komponenten soviel "Intelligenz" als irgend möglich besitzen, um ein "verteiltes System" aufbauen zu können.
Dieser Ansatz erforderte auch ein komplett anderes Kommunikationssystem (Bussystem). Bei Selectrix kann jeder Busteilnehmer mit jedem anderen Daten / Informationen austauschen; eine Einschränkung ist hier nur bei den Lok-Dekodern (beim Fahren) gegeben.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Dies ist bei den beiden vorgenannten Systemen nicht möglich, dort gibt es nur eine Richtung von der Zentrale zu den Dekodern (Peripherie);(ausgenommen das im Moment auf den Markt kommende RailCom Verfahren bei DCC > siehe weiter unten; als auch "mfx" hier gibt es eine Gegenrichtung Lokdekoder -> Zentrale).
Bei diesen beiden Merkmalen ist die Gegenrichtung der Kommunikation aber nur auf den Lok-Dekoder begrenzt und eben nicht allgemein gültig wie bei Selectrix (>> ein großer und wesentlicher technischer Systemunterschied).
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Selectrix fällt damit in die Kategorie: "dezentrale oder verteilte Systeme" .
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Und ihre Auswirkungen ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Letztendlich ist es unter Berücksichtigung des vorgenannten nicht verwunderlich, daß sich ganz unterschiedliche Kommunikationsstrukturen entwickelten, sowohl auf der Hardware-Seite als auch auf der Software-Seite in Form der Protokolle.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Während Selectrix mit einem Bussystem und einem Protokolltyp für Fahren, Schalten und Melden auskommt, werden bei DCC und Märklin jeweils 2 Bussysteme und Protokolltypen benötigt; eines für Fahren und Schalten und eines für Melden.
SX2 benötigt in Bezug auf die Kommunikation mit dem Lok-Dekoder einen zweiten Protokolltyp.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Werden bzw. sollen noch Handregler zur Steuerung der Anlage mit eingebunden werden, dann benötigt man bei Märklin bzw. DCC in aller Regel ein drittes Bus- und Protokoll- System; Selectrix hingegen benötigt kein weiteres Bussystem.
Mit SX2 kommen, wegen der unterschiedlichen Realisierungen durch die einzelnen Hersteller, in den Zentralen u.U. auch zusätzliche Schnittstellen und / oder Geräte auf den Markt, so daß die Handregler / Bedieneingaben auch das SX2 Protokoll bedienen können.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Hinweis: ein Selectrix-Handregler kann immer nur zu einem Zeitpunkt auf einen der SX-Busse der Anlage zugreifen. Sollen andere SX Busse bedient werden, dann muß der Handregler umgesteckt oder mittels eines elektronischen Schalters umgeschaltet werden
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
== Unterschiedliche, offen gelegten Bus-Systeme / Protokolle ==
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Diese Protokoll (ohne RailCom) ist so gestaltet, daß man von einem "Standard-Anteil" und
  einem "offenen Anteil (Erweiterungen)" sprechen kann.
  Durch diesen gewählten Aufbau lassen von den einzelnen Herstellern relativ einfach spezifische
  Produktergänzungen in das System einfügen.
  Im Ergebnis ergibt dies unterschiedlich lange Protokolle und damit unterschiedlich lange
  Übertragungszeiten.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Selectrix ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Das Selectrix (SX1) Protokoll, bestehehnd aus einem "Adress-Byte" und einem "Funktions-Byte",
  hat einen starren, festen Rahmen.
  Aus diesem Grunde ist auch jede Übertragunszeit gleich lang und es läßt sich daraus ableiten wie
  oft innerhalb eines Busses jeder Busteilnehmer innerhalb einer definierten Zeitperiode
  angesprochen wird.
  Die Flexibilität bei diesem Bussystem liegt darin, daß das Busprotokoll (einzelne Bit) selbst
  keiner Dekoder-Funktion zugeordnet ist.
  Die Funktion des einzelnen Bits ergibt sich aus dessen logischer Zuordnung zu der / Dekoder
  Funktion / Funktionen.
  So kann das gleiche Bit bei einem Dekoder als Ausgang "S" schalten interpretiert werden und beim
  anderen als Meldereingang "M" gesetzt werden > die Zentrale wertet dies dann aus.
  Wiederum kann das gleiche Bit ein Teil einer Bitkombination sein, die eine bestimmte Meldung
  übermittelt; z.B. Fahrstufe; etc.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Mit Einführung von SX2 kommt ein zweites Protokoll zur Ansteuerung (im Moment nur) der Lok-
  Dekoder hinzu.
  Ziel von SX2 ist es den Adress- und den Funktions- Bereich (Zusatzfunktionen) zu erweitern.
  Da die neuen Lok-Dekoder aus dem Hause Doehler & Haas, München so programmiert (konfiguriert)
  werden können, daß sie entweder als Selectrix (1 / 2), DCC, Märklin - Dekoder operieren,
  wird eine Präambel benötigt, die vor jedem neuen Protokoll dem Dekoder mitteilt für welchen
  Operationsmode und damit "Lok-Dekoder-Typ" die folgende Information gedacht ist.
  Der Präambel folgen dann 5 weitere Bytes, welche die Adresse und alle Funktionen zum Inhalt haben.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Diese zeitlich verlängerte Übertragungsdauer, im Vergleich zu SX1, hat zur Folge, daß die
  bisherigen Zeiten für ein "refreshen" keine Gültigkeit mehr besitzen.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Ferner kommt die Herausforderung hinzu, daß nicht alle theoretisch möglichen Lokadressen ständig
  aktualisiert werden können.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Auf einer Anlage können die bisherigen "SX1 - Loks" (mit ihren bisherigen Adressen) neben neuen
  "SX2 - Loks" betrieben werden.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Es wird sich zeigen, welche Varianten am Markt angenommen werden.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Märklin ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
== System- und Kommunikations- Strukturen ==
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== zentralistische Systeme ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Fahren und Schalten ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Von der Zentrale werden alle Einstellbefehle codiert über diesen Bus übermittelt.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Nähere techn. Informationen über die Busse und ihre Protokolle können über die Links (unten) abgerufen werden.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Melden ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Diese Funktion wurde erst mit der Erweiterung der "PC-Steuerung" notwendig.
Sie ist quasi das "Auge des Modellbahn-Steuerungsprogramms, hier von TrainController (TC).
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Das Prinzip des Meldens ist die Erkennung eines Stromflusses, ausgelöst durch ein Fahrzeug, welches sich in einem Überwachungsbereich (Gleisabschnitt) befindet.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Märklin ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Die beiden unterschiedlichen Ansätze brachten am Markt auch unterschiedliche Dekodertypen hervor.
Diese sind jeweils über unterschiedliche Bussysteme mit der Zentrale verbunden.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
== Identifikation von Lok-/Fahrzeug- Adressen ==
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Märklin ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
== Dezentrale Systeme ==
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
In diesem Beitrag wird in diesem Abschnitt nur das Selectrix-System betrachtet.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Fahren, Schalten und Melden ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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 !!
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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 !!!).
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Über diese Busse werden auch die logischen Schaltkreise der Dekoder versorgt !!, während Spannungen zum Schalten, etc. separat dem Dekoder zuzuführen sind.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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).
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Konfigurierungshinweis für SX-Besetztmelder ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Selectrix II --- und die neue Lok-Adressierung ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Aber wie kann dann das alte Prinzip mit annähernd gleichen Zyklen in der Dekoderkommunikation eingehalten werden ??
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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".
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Beispiel ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Identifikation von Lok-/Fahrzeug- Adressen ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
''Diese Identifikations-Methode ist etwas "tricki".''
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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ß !!
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Der hierbei entstehende kleine Stromfluß (bei SX I ca. 1-2 mA; bei SX II ca. 5 mA) wird vom Melder erkannt und ausgewertet.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Wie erfolgt nun die Zuordnung zur Lok-Dekoder-Adresse ??
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
'''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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
'''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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
'''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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Multiprotokoll-Zentrale und Dekoder ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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".
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
'''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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
== Einsatz auf Modellbahn-Anlagen ==
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Labor v.s. Anlage ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Es wird keinen Zweifel geben, daß diese Multiprotokoll-Systeme in den Labors der einzelnen Hersteller einwandfrei arbeiten.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Dies insbesondere dann, wenn zentralistische Systeme wie DCC und Märklin mit komplett unterschiedlichen Gleis-Signalen / Busprotokollen zusammen als Multiprotokoll - System betrieben werden.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Beispiel Schalten ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
'''Aufgabe:''' Schalten einer Weiche von TC heraus.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
'''Lösung:''' Märklin / DCC
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
TC sendet über den Bus PC <> Zentrale eine Meldung zum Schalten der Weiche x in Stellung r.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Die Zentrale muß diese Meldung aufnehmen und in drei Aktionen zerlegen ..
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
# Meldung an zugehörigen Weichendekoder senden mit dem Inhalt Ausgang (= Weiche x) einzuschalten (Stromfluß > Magnetartikel Spule)
# Zeit für Dauer der Einschaltung der Spule setzen und abfragen, wann diese abgelaufen ist
# Meldung an zugehörigen Weichendekoder senden mit dem Inhalt Ausgang (= Weiche x) auszuschalten (kein Stromfluß > Magnetartikel Spule)
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Diese Reserve wird in der Praxis benötigt, da davon auszugehen ist, daß eine Busübertragung wegen Störungen auch wiederholt werden muß.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Es können auch sonstige Aktivitäten "dazwischen kommen".
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
'''Lösung:''' Selectrix - TC sendet über den Bus PC <> Zentrale eine Meldung zum Schalten der Weiche x in Stellung r.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Die Zentrale muß diese Meldung aufnehmen und in eine Aktionen zerlegen ..
# Meldung an zugehörigen Weichendekoder senden mit dem Inhalt Ausgang (= Weiche x) auf Stellung r zu schalten.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Der SX-Weichendekoder nimmt diese Meldung auf und zerlegt diese in die Aktionen ....
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
# Ausgang (= Weiche x) einschalten (Stromfluß > Magnetartikel Spule)
# Zeit für Dauer der Einschaltung der Spule setzen und abfragen, wann diese abgelaufen ist
# Ausgang (= Weiche x) ausschalten (kein Stromfluß > Magnetartikel Spule)
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
===Anzahl Fahrstufen im Lok-Dekoder Systembelastung===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Dieses Beispiel gilt gleichermaßen für alle 3 betrachteten Systeme und betrachtet die Problematik nur qualitativ.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
* Aufgabe:
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
* Gegeben:
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
* Darstellung für Lok A:
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
In dieser Betrachtung gehen wir mal von 100 zu schaltenden Fahrstufen aus.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
* Darstellung für Lok B:
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Der erste Absatz von Lok A trifft genau so für Lok B zu.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Allerdings gehen wir hier mal von 25 zu schaltenden Fahrstufen aus.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Der dritte Absatz von Lok A trifft auch wieder für Lok B zu; allerdings werden min. nur 25 Meldungen gesendet.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
* Ergebnis der "Spielerrei"
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
-- und das gilt sowohl für das Bremsen als auch Beschleunigen --
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Allerdings ist davon auszugehen, daß zeitliche Engpässe aufgrund des obigen Effekts sehr wohl bemerkbar sind, wenn viele Zugbewegungen zeitlcih parallel stattfinden.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
===Beispiel >> Fahren / Multiprotokolle===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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).
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Entsprechendes gilt, wenn der Lok-Dekoder mit mehreren Protokollen betrieben werden kann. Dann muß der die entsprechende "Vorauswahl" treffen. Auch das kostet Zeit.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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 .
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
===Zusammenwirken mit dem Software Programm  TrainController (TC)===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Wie und wann die Umsetzung von SX2 durch TC erfolgt wird sich wohl erst frühestens im Laufe des nächsten Jahres zeigen.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
==Quellen für weitergehende Informationen==
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
Die nachfolgend aufgelisteten Links sollen dem Leser die Möglichkeit geben weiter in diese Thematik einzuarbeiten.
Insbesondere tiefer in die verschiedenen Techniken "einzusteigen".
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
--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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
* Datenformate (Märklin - DDC - Selectrix - u.a
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
http://www.digital-bahn.de/info_begriffe/protokoll.htm
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
* Multiprotokoll - Zentralen / Dekoder
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
http://www.digital-bahn.de/info_kompo/zentrale_multi.htm
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
http://www.opendcc.de/index.html
  http://www.lokodex.de/mo/m_digital_dccprot01.htm
  http://www.steinhartw.de
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
* Märklin
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
* Selectrix
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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 !!!)
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
* 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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
=== Fazit ===
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
== Weblinks ==
</div>

<div lang="de" dir="ltr" class="mw-content-ltr">
*TC-wiki: [[Special:MyLanguage/Vergleichstabelle Digitalzentralen|Vergleichstabelle Digitalzentralen]]
</div>

:--[[Special:MyLanguage/Benutzer:Jens Mohr|Jens Mohr]] 09:40, 17. Jul. 2011 (UTC) († 2023)
:bearbeitet:[[Special:MyLanguage/Benutzer:Wohlmannstetter|Wohlmannstetter]] ([[Benutzer Diskussion:Wohlmannstetter|Diskussion]]) 18:36, 10. Mär. 2021 (CET), [[Special:MyLanguage/Benutzer:Uslex|Uslex]] ([[Benutzer Diskussion:Uslex|Diskussion]]) 14:35, 12. Feb. 2024 (UTC), [[Special:MyLanguage/Benutzer:Uslex|Uslex]] ([[Benutzer Diskussion:Uslex|Diskussion]]) 10:42, 24. Aug. 2024 (CEST)

[[Kategorie: Hardware{{#translation:}}]]
[[Kategorie: Software{{#translation:}}]]
[[Kategorie: Betriebssystem{{#translation:}}]]
[[Kategorie: Digitalsystem{{#translation:}}]]
[[Kategorie: Analogmodus{{#translation:}}]]
[[Kategorie: Melder{{#translation:}}]]
[[Kategorie: DCC{{#translation:}}]]
[[Kategorie: MFX{{#translation:}}]]
[[Kategorie: Selectrix{{#translation:}}]]
[[Kategorie: Märklin{{#translation:}}]]
[[Kategorie: Decoder{{#translation:}}]]

Übersetzungen exportieren

Navigationsmenü

Seitenaktionen

Seitenaktionen

Meine Werkzeuge

Navigation

Suche

Tools

Werkzeuge