THEMA: Technisches zu Multiprotokoll-Formaten wie RMX

Hallo Jens,

vielleicht verstehen wir auch jeweils etwas anders unter "Gleissignal", aber ein "erweiterter SX-Datenrahmen" und ein "formatunabhängiges RMX-Protokoll" scheinen mir eben nicht das Gleiche zu sein. Daß der einzelne Datensatz, den der Decoder dann verstehen und befolgen muß, der jeweiligen Norm entsprechen - und damit gleich sein - muß,  ist mir schon klar. Aber das Gleissignal - also die Gesamtheit der Datensätze, ihre Anordnung, Wiederholrate und Strukturierung - ist doch nicht die gleiche?

Mein Wissensstand ist folgender: das Standard-Selextrix-Format unterstützt gar kein DCC. Dann gab es Sx-Versionen, die zusätzlich 16 DCC-Loks erlauben und die FCC kann nun gar 32. RMX ist ein ganz anderer Ansatz, der 103 Systemkanäle vorsieht, die dann nach Belieben für Sx, Sx2 oder DCC-Decoder verwendet werden können. Einschränkung bei beiden: sie können keine DCC-Zubehördecoder ansprechen.

Auf der anderen Seite gibt es Nicht-Selectrix-Zentralen (Intellibox und die ECoS), die zunächst einmal DCC/Märklin-Multiprotokoll-Zentralen sind, aber auch Sx1-Lokdecoder ansteuern können. Außerdem haben sie den vollen DCC-Umfang, können also auch Zubehördecoder steuern. Offenbar sind diese Protokolle wieder völlig anders als FCC oder RMX aufgebaut.

Verstehe ich das richtig, daß die Fähigkeit der FCC, 32 DCC-Loks ansprechen zu können, darauf beruht, daß sie sich weitere 16 DCC-Plätze vom SX 1-Bus holt und diese irgendwie auf den SX 0-Bus überträgt? Sind zusätzlich 16 DCC-Loks die technische Obergrenze pro erweitertem SX-Bus?

Viele Grüße

Markus

Das ist falsch.
Die Wiederholrate ist immer noch die gleiche, wie bei reinem SX .
Die zusätzlichen Informationen werden in die Lücken bzw. ungenutzten Räume des SX Signals per Multiplexing gepackt.
Ich empfehle die Seiten dazu von Rautenhaus bzw. mdvr.de zu lesen.


Jürgen H.

Auch das ist falsch.
SX konnte von Anfang an DCC mit 14 Fahrstufen bedienen.

Jürgen H.

Hallo Jürgen,

heißt das, daß die Stärz ZS1 und die digirail MC2004 (die beide kein DCC unterstützen) keine vollständigen Selectrix-Zentralen sind? Kann ich mir nicht so recht vorstellen.

Viele Grüße

Markus

Hallo Markus,

schau diese Seite und die folgenden einfach einmal an:

http://www.rautenhaus-digital.de/themen/rmx-system.html

http://www.rautenhaus-digital.de/themen/rmxphilosophie.html

http://www.rautenhaus-digital.de/themen/rmxfaq.html

Ich selbst habe mich damals aktiv für die RMX entschieden.

Grüße
Christian

Hallo,

vielen Dank für Euere Informationen, das bringt doch etwas mehr Licht ins Dunkle.
Ich habe schon einiges gelesen und bin der Meinung dass wohl DCC zum fahren und SX zum melden die ideale Kombi ist. Und wenn ich erst mal mit einer kleinen Übungs- Test-  Digitalanlage beginne sollte doch die preisgünstige FCC reichen.

Grüßle Helmut

DieTrixzentrale konnte in den 1990er Jahren DCC mit 14 Fahrstufen und etwas eingeschränkter Adressevergabe.
Damals nannte man das noch Lenz.
Vielleicht hat es rechtliche Probleme gegeben und man hat es rausgeworfen.Wer weiß ?

Jürgen H.

Hallo,
wird eher technische / finanzielle Gründe gehabt haben. Ein DCC-Protokoll ans Gleis zu bringen ist durch das notwendige Priorisieren deutlich aufwändiger als bei SX. Sowohl auf Seite der Hardware (braucht mehr Rechenleistung und Speicher) als auch auf Seiten des Herstellers (muss es implementieren). Während bei SX einfach stur ein Befehl nach dem anderen gesendet wird, muss die Zentrale bei DCC, salopp gesagt, mitschreiben, welche Loks aktiv sind, welche Befehle zu senden sind und diese noch nach Wichtigkeit etc. sortieren. Da Stärz und Müt nicht gerade als DCC-Freunde bekannt sind, werden die sich den Aufwand einfach geschenkt haben. Zielgruppe für die Geräte waren eben reine SX-Fahrer.

Viele Grüße
Carsten

Hallo,

wie lange kann es eine kleine Firma durchhalten, sich vehement der Marktentwicklung zu widersetzen?

Grüße, Peter W.

Hallo,

Jürgen, bezüglich der SX-Bus Erweiterung empfehle ich Dir nochmals nachzulesen. Etwa hier: http://www.norbert-martsch.de/index.php/selectrix/selectrix-system/
Die SX1 Datenrahmenwiederholung reduziert sich so von 13,x auf bis zu ,3,5 Mal pro sec.

Richtig ist, das das SX-System datentechnisch solide ist und der SX-Bus zum Schalten UND Melden von Anfang an fester Bestandteil des Systems war. Allerdings genügt die Übertragungsrate des SX-Busses heute nicht mehr den gestiegenen Anforderungen. Für RailCom reicht der Durchsatz nicht aus.

Auch ich fahre SX mit FCC und Mini-FCC. Ich bin zufrieden. Nichts desto trotz ist das System nicht mehr State oft Art - ebensowenig wie DCC. Die Bedienung über Adressengabe der Loks via Nummern (ob im Kopf oder per Datenbank) ist finstersten Steinzeit. Lok aufs Gleis und mein Regler zeigt an, was sie alles kann - das wäre Fortschritt. Aber so diskutieren wir über das Für und Wider veralteter Technik und es bleibt ein Gebastel. Die Hersteller haben nichts verstanden und wundern sich, warum die Kids lieber virtuell mit ihren aktuellen Smartphones fighten anstatt sich für eine steinzeitliche Moba zu interessieren, wo sich die Erimiten in den Foren verbal die Köpfe einhauen, welche Steinzeitkeule wohl  besser ist.....

Jens

Solide? Ein elektrisches "Durcheinander" ist das (T0, T1 Spannnugsschnittstelle, D Stromschnittstelle) und auf Protokollebene gibt es keine Prüfbits. Es wird bzw. wurde sogar als Vorteil promoted, dass der Decoder keine Prüfsumme errechnen müsse, was ihn überfordern würde. Sehr witzig.

Signalpegel ist 5 V asymmetrisch TTL oder CMOS (je nach Gerät und verwendeter Bauteile) mit einem Störabstand von <= 1,6 V. Genaue Schaltschwellen sind nicht definiert, es gibt keine gültige Norm für den SX Bus. Die Pegel hängen davon ab, welcher Chip am Eingang des jeweiligen Gerätes sitzt. Eine offizielle Applikationsschaltung gibt es nicht, dennoch kupfert einer vom anderen immer die gleiche Eingangsschaltung mit den Komparatoren ab.


Das trifft den Nagel auf den Kopf: Bis auf mfx gab es seit Jahrzehnten keine Innovation mehr auf dem Protokollsektor. DCC, MM, SX, FMZ sind wirklich alt.

es grüßt der DCC Eremit
Peter W.

Durch wirfst da wohl was durcheinander.
Der SX Datenrahmen bleibt immer bei 13 Wiederholungen pro Sekunde.
Andernfalls wäre es kein SX mehr.
Der Inhalt, sofern der nicht SX betrifft ändert sich datenmengenabhängig und es kann bei den einfachen SX/DCC Zentralen (FCC und ein Nahöstlicher Hersteller)  zu anderen Wiederholraten kommen.

Bei RMX  :


Ich empfehle nochmals, da zu lesen, wo Hersteller schreiben, denn die sollten schon wissen, was sie produzieren.



Das halte ich für nicht zutreffend.
Jedes vernünftige Steuerprogramm bietet den oben gewünschten Komfort nach einmaliger Eingabe einer Lok in eine Datenbank.
Dann kann die Lok munter per Smartphone auf der Anlage verschoben werden.
Für mangelndes Interesse an der Moba durch die heutige Wischgeneration kann man viele Gründe finden, das Gleisprotokoll ist ganz sicher keiner.
Ansonsten gäbe es bei Märklin mit MFX sicher höhere Absatzzahlen.


Jürgen H.

@ Jürgen

Äpfel und Birnen: Jens und Du reden offensichtlich von verschiedenen Sachen, er von der Sx-Buserweiterung, Du vom RMX-System. So wie ich die Infos von Norbert Martsch und Rautenhaus verstehe, sind das zwei technisch sehr unterschiedliche Lösungen. Die Sx-Buserweiterung packt zum Basis-Sx1-Datenrahmen zusätzliche Informationen für Sx2- und DCC-Decoder mit dazu. Je mehr Nicht-Sx1-Loks dabei sind, desto mehr Daten werden versendet, d.h. ich halte es für völlig nachvollziehbar, daß bei voller Auslastung von 16 zusätzlichen (Sx2 und/oder DCC-) Loks mehr Zeit vergeht, bis der normale Sx1-Datenrahmen erneut durchlaufen wird. RMX hat dagegen nichts zusätzliches zum Sx1-Datenrahmen ergänzt, sondern 112 "Systemkanäle" (davon von 103 für Lokadressen nutzbar) geschaffen, die je nach Bedarf mit einem Sx1, Sx2 oder DCC-Datensatz gefüllt werden. Da RMX 0 offenbar auch einen höheren Datendurchsatz als Standard-Selectrix hat (wie sie das technisch gemacht haben, keine Ahnung), bleibt bei RMX (anders als bei der Sx-Buserweiterung) die Lastunabhängigkeit erhalten.

Ich fand diese Infos jetzt alle sehr hilfreich. Was ich aber immer noch nicht verstehe ist, wie die FCC 32 statt 16 zusätzliche Loks in ihr Gleissignal einfügt. Ist das eine doppelte Sx-Buserweiterung? Damit würden dann wohl die Refresh-Zeiten weiter sinken, wenn alle 32 Zusatzansteuerungen genutzt werden, oder?

Viele Grüße

Markus

Hallo Markus,
Der SX-Anteil am Gleis dürfte gleich bleiben, es dauert nur länger, bis DCC/SX2-Daten (erneut) gesendet werden. Aus diesem Grund bin ich auch der Meinung, dass man, will man rein DCC fahren, besser keine SX-Zentrale verwendet, weil dort sonst die SX-Daten sinnlos das Gleis "vollmüllen" und man die Sendezeit besser komplett für DCC frei hat.

Viele Grüße
Carsten

Hallo Jürgen,

genau das ist der Knackpunkt: die erstmalige Eingabe einer Lok in eine Datenbank ist alles andere als komfortabel. Weiterhin braucht man erstmal ein Steuerprogramm, was längst nicht alle Digital-Hersteller anbieten. Und dann ist jede Lösung selbstverständlich proprietär, d.h. mein Datenbankeintrag nutzt mir nix, wenn ich meine Lok auf eine andere Anlage stelle, oft sogar schon, wenn ich nur einen anderen Handregler nehme.

Ich bin nicht nur in Spur N unterwegs, sondern auch H0-Teppichbahner. Am Wochenende habe ich mir eine neue Lok in der Z21-App angelegt. Das dauert seine Zeit: Lokbildchen suchen, herunterladen und eintragen, die Betriebsnummer und den Loknamen eingeben, eine lange DCC-Adresse vergeben (bedienungsunfreundlicher geht's kaum mehr mit drei nötigen, nicht selbsterklärenden Einträgen in CV 17, CV 18 und CV 29), in diesem Fall 15 Lokfunktionen zuordnen, mit Symbolbild und Kurzinfo versehen... Ja, klar - anschließend ist das Komfort pur, aber den habe ich mir selber hart erarbeitet. Da gefallen mir die Märklin-Lösungen wie mfx oder die Lokkarten deutlich besser.


Naja, Märklin ist zumindest in Europa Marktführer. Und Trix H0 wird seit einiger Zeit massiv märklinisiert. Wenn N historisch nicht anders gewachsen wäre, würde Märklin vermutlich versuchen, mfx bei auch Minitrix einzuführen.

Viele Grüße

Markus

Hallo Carsten,

in der Tat, das hat Jens womöglich mißverständlich formuliert. Der gesamte Sx1-Datenrahmen wird auch bei der Sx-Buserweiterung sicher zeitlich wie inhaltlich unverändert wiedergegeben, aber die Zeit bis zur erneuten Versendung dauert eben länger, je nachdem, wieviele Sx2 und DCC-Loks sich dazwischenschieben.

Viele Grüße

Markus

Hallo,


Der Knackpunkt dabei ist, dass es noch keiner geschafft hat einen mfx Decoder im Spur N Formfaktor aufzubauen - nicht mal ESU.

Grüße, Peter W.

Hallo Markus,
soweit ich das verstanden habe, eben gerade nicht. Die Wiederholung der SX-Daten ist fix und muss zeitlich so erfolgen. Ansonsten verliert man ja z.B. auch die ach so hoch gepriesene Echtzeitfähigkeit. Grob gesagt werden stattdessen die DCC-Daten ausgetauscht, die gesendet werden. Um es mal zu skizzieren, auch wenns technisch falsch ist:
SX-Daten | DCC von SX-Bus 1 | SX-Daten | DCC von SX-Bus 2 | SX-Daten | DCC von SX-Bus 1 | ...

Dabei kann zwischen den SX-Daten immer nur eine bestimmte Menge DCC/SX2 gesendet werden.

Viele Grüße
Carsten

Hallo Peter,
warum ist das eigentlich so? Was haben die denn an zusätzlicher Hardware drauf?

Viele Grüße
Carsten

Hallo Carsten,

ich weiß es nicht warum das so ist. Das weiß vermutlich nur der Hr. Lindner.

Grüße, Peter W.

Nachtrag: Am Fr ist Zimo-Stammtisch, da kann ich ja mal in die Runde fragen. Vielleicht weiß es Onkel Hübsch.

Grüße, Peter W.

Folks!
mfx Empfang ist keinerlei Herausforderung für einen Decoder. Da wo's problematisch wird ist das Senden der RDS Daten. Dazu braucht man genaues Timing das führt heutzutage noch immer zur Verwendung eines Quarzes. Die Resonatoren in den Prozessoren sind da zu ungenau. Die Quarze waren bis vor kurzem für N Decoder einfach zu groß.
Welch Problem das darstellt zeigt der Anfang der MTX/MTC Schnittstelle. ESU hat damals Platz schaffen müssen und hat daher die Treibertransis der Funktionsausgänge vom Decoder auf die Lokplatine geschoben. Lindner hat ja den Normvorschlag ursprünglich gemeinsam mit Märklin in Göppingen mit verstärken Ausgängen geschrieben siehe NMRA Norm aus den frühen 2000'er Jahren. Dann eben wegen Platzproblemen in H0 umgesattelt auf Logikpegel um die RDS HW unterbringen insbesondere Quarz und so.

Heutzutage gibt's Quarze in Baugröße 0402 somit sehr N tauglich, was man sonst noch zum Senden der Rückmelde Info braucht, insbesondere Kondensatoren die schnell viel Platz brauchen, weiß ich nicht. Könnt' aber auch heute noch ein Thema für N Decoder sein.

Zu den Mischbetrieben: egal welche Datenformate gemischt werden es gibt immer starke Funktionalitätseinschränkung. In den Decodern gibt's CVs die eigentlich festlegen welches Protokoll der Decoder benutzen soll, das wird aber faktisch nicht benutzt. In der Praxis geht's fast immer in die Richtung das wenn mehrere Protokolle am Gleis sind jenes bevorzugt wird das die meiste Funktionalität bringt.
Mein Rat ist da simpel nur auf _ein_ Gleisprotokoll zu setzen. Man hat ja die Auswahl. Unangenehm wird's wenn der bevorzugte Hersteller / Datenformat mit dem technischen Fortschritt nicht Schritt hält z.B. Sounddecoder Rückmeldesysteme udglm. Das zwingt dann früher oder später zu einer Komplettumstellung mit entsprechenden Kosten. Wobei wie immer je später man wechselt um so teurer wird's.
-AH-

Hallo Carsten,

ich weiß auch nicht, wie das konkret gelöst ist. Zumindest würde es meine 32/16-Frage klären, wenn die weiteren 16 Nicht-Sx2-Loks vom zweiten SX-Bus geholt werden. Nur: warum kann ein Bus nicht 32 Zusatz-Datensätze erzeugen?

Was die Zeitverzögerung angeht: nicht nur Herr Martsch, sondern auch Rautenhaus behauptet (siehe dritter Link in #5), daß bei der Sx-Buserweiterung die Refresh-Zyklen sinken, wenn Sx2/DCC-Daten dazukommen. Oder hat Sx1 soviel "Luft" zwischen den Datenpaketen, daß man die DCC-Informationen einfach dazwischenmogeln kann, ohne Zeit zu verlieren? Und warum sollte es schlimm sein, wenn darunter die Echtzeitfähigkeit leidet? Ein paar Dutzend Millisekunden hin oder her sollten bei einer Moba nun wirklich keine Rolle spielen

Viele Grüße, Markus

Guten Morgen,

Ich definiere jetzt einfach Mal:

Der Sx-Gleisausgang ist extern und NICHT gleich dem Sx0- Bus.

Die SX-Busse werden bei der FCC zur internen Verarbeitung verwendet. Hier werden die Nicht-SX-Daten zwischen die SX-Datenrahmen gepackt. Euch ein dcc-Datenpaket hat eine bestimmte Maximalgröße - wenn man die Maximale Funktionsanzahl pro Adresse begrenzt. Das führt dann im Maximalfall zu einer bestimmten Datenmenge, die auf dem SX-Bus untergebracht werden muss.
D&H hat sich hier dafür entschieden, pro SX-Bus maximal 16 DCC(SX2) Datenpakete unterzubringen. Soweit mir bekannt ist, wird die Wiederholrate am Sx-Bus nicht reduziert, was nur für einen begrenzten Platz zwischen den SX-Datenpaketen ausreicht.
Will man nun mit der FCC eine 17. DCC/SX2-Lok ohne PC fahren, muss man einen Handregler (Mobilestatio1) am SX1-Bus anschließen. Mit dieser kann man max 16 DCC/SX2-Loks fahren und SX-Weichen und Signale schalten.

Der Gleisausgang ist - wenn man es so will - nicht SX-Konform. Hier wird die Wiederholrate der SX-Datenrahmen abhängig von der Nicht-SX-Datenmenge reduziert. Hier könnte Mann auch mehr dcc-Informationen dazupacken, aber die interne Verarbeitung der FCC gibt das nicht her.

Die RMX geht einen anderen Weg bei der internen Verarbeitung und hebt hier quasi die Begrenzung auf, in dem ein formatunabhängiges Protokoll verwendet wird, bei dem das Format lediglich eine  gespeicherte Information ist. Der Gleisausgang erzeugt aus diesem Protokoll lastabhängig das Gleissignal.

Um die vermeintlich verlorene Echtzeitfähigkeit aufzugreifen: Auch eine reduzierte Wiederholrate führt zu verlässlichen Übertragungszeiten. Ein voll ausgelastet dcc-System kommt nicht annähernd an 3,5 fache Wiederholung Ran, wenn 100Loks gleichzeitig angesteuert weden. Allerdings bewegen wir uns hier auf eher theoretischen Boden, der für die Meisten von uns nicht von Bedeutung ist.

Das die Definition von SX mit seinem Signalaufbau ebenfalls nicht heutigen Standards entspricht, dürfte in Anbetracht seines Alters klar sein.

Jens