Zitat von vikr im Beitrag #50

---

Hallo Ralf,

Zitat von Stummilein im Beitrag #49

---

die eigentliche Fragestellung habe ich immer noch nicht verstanden.

---

ich auch nicht. Eine Präzisierung vom TE wäre vielleicht wirklich ganz hilfreich.

MfG

vik

---

Hallo zusammen,

das bereits angesprochene Laufzeitverhalten halte ich fuer sehr wichtig,

• wie skalieren die Protokolle (z.B. Betrieb mit 5 bzw. 50 Decodern)
• die zu erwartende Latenz in kleinen und grossen Umgebungen (z.B. Verzoegerung beim aktivieren des Lok-Pfiffs bei kleiner/grosser Umgebung)

Hallo fschum,

Bei Verwendung von langen Adressen benötigt ein DCC Kommando im Schnitt ungefähr 6,5 ms. Ganz genau kann ich es nicht sagen, da eine '1' 104 µs eine 0 dagegen 208 µs benötigt. Daher habe ich wo nicht anders möglich mit 152 µs Durchschnitt gerechnet. Pro DCC-Kommando können mehrere Befehle übertragen werden. In der Praxis erfolgt dies jedoch nicht. Also kommen Befehle für Fahren und Lok-Funktionen ansteuern getrennt. Da beides benötigt wird, gegen wir mal von ungefähr 13 ms pro Lok aus. Hier ist auch die Austastlücke für Railcom schon mit drin.

Bei mfx ist jedes Bit 100 µs lang. Fahr- und Funktionskommandos können kombiniert werden. Dies wir in der Praxis auch genutzt. Für eine Lok ergeben sich somit 4,7 ms. Hier ist aber der Rückmeldekanal noch nicht mit drin, der in zyklischen Abständen mit einem speziellen Kommando angesteuert wird. Erfolgt eine solche Abfrage ist man im günstigsten Fall (1-Bit Rückmeldung) mit 19 ms dabei. Wie oft das passiert, habe ich aus den mir zur Verfügung stehenden Unterlagen nicht herausfinden können.

Halten wir zusammenfassend einmal fest:
DCC pro Lok: 13 ms
mfx pro Lok: 4,7 ms

Die zu erwartende Latenzzeit hängt aber weniger vom verwendeten Protokoll, als von der Intelligenz der Zentrale ab. Hier ist die Priorisierung von Änderungen auf dem Bus wichtig. Viele Zentralen, wie auch die CS2, gehen die Loks einfach der Reihe nach durch. Eine Änderung wird einmalig sofort übertragen. Im Idealfall bekommt der Dekoder den Fahrbefehl also innerhalb weniger Millisekunden. Manche Zentralen priorisieren neue Fahr und Funktionsbefehle. Zudem werden bereits mehrfach übertragene Kommandos nicht in jedem Zyklus gesendet. Durch diese Optimierung funktionieren gute DCC-Zentralen mit vielen angemeldeten Loks oft besser als die CS2.

Abschließend kann ich nur betonen, dass es bei den Protokollen keinen Gewinner gibt. DCC und mfx sind bei Modellbahnern gleichermaßen im Einsatz. Sogar ein Gemischtbetrieb beider Protokolle ist möglich. Aus technischer Sicht ist für mich DCC mit Railcom interessanter, da es mit geeigneten Rückmeldern eine Lokalisierung der Lok auf den Rückmeldeabschnitten ermöglicht.

Gruß
Hagen

Hallo Werner,

Zitat von werner1952 im Beitrag #51

---

was können die beiden Protokolle im Vergleich und was nicht?

---

Hallo Werner,

Herr Krauss hat eine Beschreibung des mfx und mfx+ Schienenformats als PDF herausgebracht.
Link zur PDF-Datei

Alternativ eine Vergleichsbeschreibung von Sven Brand

Welches Protokoll für wen besser ist, ist die gleiche Frage nach der besten Zentrale für jemanden.

Es ist wie mit allen Dingen in unserem Universum:
Es gibt absolut nichts, was nur Vorteile oder nur Nachteile hat!

Hallo und guten Morgen,

ich denke es gibt sehr wohl deutliche Protokollunterschiede. Die Frage ist, ob diese fuer einen relevant werden oder nicht. Ich halte beispielsweise den im Protokoll eingebetteten Rueckmelde-Kanal fuer einen grossen und ggf. entscheidenden Unterschied.

• DCC/Railcom erzeugt nach jedem Befehl ein ~500us Rueckmelde-Fenster in dem ein Decoder 36-Bits uebertragen kann (wenn wir nur Kanal-2 betrachten)
• Mfx sieht erstmal kein generelles Rueckmeldefenster vor sondern nur bei speziellen Befehlen. Das Rueckmeldefenster betraegt ~12.8ms pro Bit! Um ebenfalls 36-Bit zu uebertragen wuerde, ein Mfx Befehl ~460ms (36x12.8ms) dauern.

Hallo Frank,

Zitat von fschum im Beitrag #56

---

Ich halte beispielsweise den im Protokoll eingebetteten Rueckmelde-Kanal fuer einen grossen und ggf. entscheidenden Unterschied.

---

Zitat von fschum im Beitrag #56

---

• DCC/Railcom erzeugt nach jedem Befehl ein ~500us Rueckmelde-Fenster in dem ein Decoder 36-Bits uebertragen kann (wenn wir nur Kanal-2 betrachten)
• Mfx sieht erstmal kein generelles Rueckmeldefenster vor sondern nur bei speziellen Befehlen. Das Rueckmeldefenster betraegt ~12.8ms pro Bit! Um ebenfalls 36-Bit zu uebertragen wuerde, ein Mfx Befehl ~460ms (36x12.8ms) dauern.

---

Zitat von fschum im Beitrag #56

---

Anders formuliert, ein kontinuierlicher Datenstrom vom Decoder zur Zentrale ist mit Mfx heute nicht sinnvoll realisierbar.

---

Hallo Vik,

ich stimme Dir zu, 36-Bit pro Frame sind nicht besonders viel und es hat schon was von "Haeppchen". Aber damit kann man schon was anfangen.

--> Unten mein (selbstbau) DCC Decoder der zahlreiche Telemetriedaten kontinuierlich sendet, wenn er seine Runden dreht.

Ich selbst habe sehr viel Spass daran, diese Daten auf meinem PC zu sammeln und zu visualisieren. Ich verstehe aber auch, wenn andere Modellbahner sagen, sowas brauche ich nicht. Mit Mfx koennte ich das vermutlich nicht hinbekommen.



Bild-1: Sollgeschwindigkeit, Istgeschwindigkeit, Motorstrom




Bild-2: Spannungen Schiene links/rechts und Decoder Temperatur

Hallo Frank,

Zitat von fschum im Beitrag #58

---

Unten mein (selbstbau) DCC Decoder der zahlreiche Telemetriedaten kontinuierlich sendet, wenn er seine Runden dreht.

---

Zitat von vikr im Beitrag #59

---

... aber was ist, wenn Du 60 Deiner Decoder gleichzeitig auf der Anlage hast und alle sollen z. B. ihre Daten senden?

---

• Downstream only (ohne Meldekanal)
• Downstream+Upstream (mit Meldekanal)

Ich habe ein wenig in dem oben verlinktem MFX Dokument gelesen und muss mich korrigieren,

Zitat von fschum im Beitrag #56

---

Mfx sieht erstmal kein generelles Rueckmeldefenster vor sondern nur bei speziellen Befehlen. Das Rueckmeldefenster betraegt ~12.8ms pro Bit! Um ebenfalls 36-Bit zu uebertragen wuerde, ein Mfx Befehl ~460ms (36x12.8ms) dauern.

---

In dem Dokument steht auf Seite 26, dass die automatische Anmeldung eines Decoders bei Mfx ca. 10-15 Sekunden benoetigt. Mache ich einen Reset auf die Zentrale dauert es dann etwa 1-2 Minuten bis sich beispielsweise 7 Decoder neue angemeldet haben? Da wird DCCA deutlich schneller sein. Mein Prototyp braucht 2-3 Sekunden um 7 Decoder neu anzumelden. In der Spalte "Logon" kann man sehen wann die DCC Decoder ins System eingebucht wurden. Das geht Schlag-auf-Schlag.



Allerdings ist DCCA noch sehr neu und es wird sicher die eine oder andere Kinderkrankheit haben. Die Anmeldung bei Mfx gibt es schon deutlich laenger und hat zumindest die Praxistauglichkeit unter Beweis stellen koennen. Dieses muss DCCA erst noch liefern.

Hallo Frank,

Zitat von fschum im Beitrag #61

---

Es fahren nie 60 Decoder gleichzeitig. Es fahren vielleicht 10 und 50 stehen. Unter diesen Umstaenden funktioniert das oben beschriebene System ohne seine Eigenschaften zu aendern.

---

Zitat von vikr im Beitrag #63

---

Zitat von fschum im Beitrag #61

---

Es fahren nie 60 Decoder gleichzeitig. Es fahren vielleicht 10 und 50 stehen. Unter diesen Umstaenden funktioniert das oben beschriebene System ohne seine Eigenschaften zu aendern.

---

bei mir haben die meisten Loks - i.d.R. auch wenn sie stehen, das Licht an - und ggf. sogar den Sound. Sie sind damit grundsätzlich auch permanent im Refresh-Zyklus ...

---

Zitat von hb059 im Beitrag #64

---

Stehende Loks, ... werden von modernen Zentralen im Refreshzyklus herunterpriorisiert.

---

Hallo
wird die Diskussion nicht viel zu akademisch ?

Ich finde es ist völlig egal was da wirklich auf der Leitung passiert, welche Modulationen, wie lange eine Rückmeldung dauert etc.

Wenn Vorteile / Nachteile eines der Systeme den Ausschlag geben sollen, welches System man sich zulegen möchte, dann gibt es aus meiner Sicht nur zwei Entscheidungen

• ich entscheide mich für ein proprietäres System eines Herstellers, der nach eigenem Gutdünken jederzeit daran Änderungen vornehmen kann
  Zweitanbietern ist es schwer die Funktionalitäten zu bieten, da das Protokoll nicht öffentlich ist
• ich entscheide mich für ein offenes System, deren Spezifikation öffentlich zugängig ist
  Jeder der möchte und die Kapazität hat, kann Produkte mit diesem Protokoll auf den Markt bringen

(ich habe in den 60er Jahren den Absprung geschafft und meine Loks in die Hamo Versionen umgebaut oder ausbuchsen lassen

Hallo Frank,

du schreibst in #65

Zitat von fschum im Beitrag #65

---

Genau das ist der Punkt. Bei DCC/Railcom werden alle Lok-Befehle vom Decoder bestaetigt. Die Zentrale weiss also, ob der Decoder den Befehl empfangen hat und muss diesen danach nicht mehr zwingend wiederholen. Das gilt insbeondere fuer stehende Loks. Bei fahrenden Loks gibt es die (leidigen) Kontaktprobleme die ggf. einen Decoder Neustart ausloesen. Darum ist der Refresh dort notwendig.

---

Hallo Werner,

Zitat von Sx2Fan im Beitrag #67

---

Wenn ich diese Aussage korrekt interpretiere, dann bedeutet dies, dass die Lokdecoder im RailCom Channel 2 explizit rückmelden, was sie empfangen haben und bestätigen nicht einfach durch ein simples Ack oder eine sonstige Antwort (Gleissignalqualität, Betriebszeit, etc.), die in keiner Korrelation mit den empfangen Daten steht, dass sie irgendwas empfangen haben.

---

Ein Dekoder antwortet auf Railcom Channel2 wenn er das DCC-Paket fehlerfrei erhalten hat, also die Prüfsumme stimmt, und es auch an ihn adressiert war. Es steht dem Dekoder frei, ob er mit einem einfachen Acknowledge antwortet, oder ob er gleich noch Daten (Gleisqualität, aktuelle Geschwindigkeit, ...) mitsenden will. Jede Rückmeldung auf Channel 2 gilt als Empfangsbestätigung des vorangegangenen DCC-Pakets.

Jetzt stellt sich natürlich die Frage, ob dieses Paket auch vom Dekoder umgesetzt werden kann. Diese ist allerdings rein akademisch. Die Zentrale sollte schon wissen, wie viele Fahrstufen ein Dekoder hat und welche Funktionen schaltbar sind. Laut Norm besteht die Möglichkeit, mit einem ACK gefolgt von einem NACK im selben Channel 2 Paket zu antworten. Diese Antwort bedeutet, dass der Dekoder das Paket fehlerfrei empfangen hat, dieses aber nicht umsetzen kann. Ich habe dieses Verhalten jedoch in freier Wildbahn noch nicht beobachten können.

Als lokales Rückmeldeprotokoll fällt mit noch S88.2 von Lokstoredigital ein. Dieses mit normalen S88N-Rückmeldern kompatible Protokoll ist leider nicht offengelegt.

Gruß
Hagen

Hallo Werner,

Zitat von Sx2Fan im Beitrag #67

---

- Welche Zentralen in Kombination mit welchen Belegt-/Rückmeldern und welchen Bussystemen unterstützen zusammen mit welchen Lokdecodern, das von dir dargelegte Verfahren?

---

Hallo Hagen,

Zitat von hb059 im Beitrag #69

---

Ein Dekoder antwortet auf Railcom Channel2 wenn er das DCC-Paket fehlerfrei erhalten hat, also die Prüfsumme stimmt, und es auch an ihn adressiert war. Es steht dem Dekoder frei, ob er mit einem einfachen Acknowledge antwortet, oder ob er gleich noch Daten (Gleisqualität, aktuelle Geschwindigkeit, ...) mitsenden will. Jede Rückmeldung auf Channel 2 gilt als Empfangsbestätigung des vorangegangenen DCC-Pakets.

---

Hallo vik,

ich würde das nicht als Schönheitsfehler, sondern als Protokolldefinition bezeichnen. Die Channel 2 Antwort bezieht sich immer auf das direkt davor empfangene DCC-Paket. Da der lokale Detektor eh mitliest ist es kein Problem. Die Zentrale weiß es was sie gerade gesendet hat. Ein dortiger globaler Detektor hat also keine Schwierigkeiten, die Antwort zuzuordnen.

Die Bestätigung von DCC-Befehlen funktioniert nach meinem Dafürhalten eh am besten mit dem globalen (zentralen) Detektor. Ist da noch ein Bus dazwischen, dauert es zu lange bis die Zentrale die Bestätigung bekommt.

Anwendungsfälle für globale Railcom-Detektoren (in der Zentrale):

• Loksuche / Aufgleissuche (Channel 2, bei DCC-A in Kombination mit Channel 1)
• CV lesen/schreiben (Channel 2)
• DCC-Kommandobestätigung (Channel 2)

• Loksuche (Channel 1)
• Ortsbestimmung einer Lok inkl. Richtung (Channel 1 und Channel 2)
• CV lesen/schreiben (Channel 2)
• Gleis/Empfangsqualität (Channel 2)

Hallo Hagen,

Zitat von hb059 im Beitrag #72

---

ich würde das nicht als Schönheitsfehler, sondern als Protokolldefinition bezeichnen. Die Channel 2 Antwort bezieht sich immer auf das direkt davor empfangene DCC-Paket. Da der lokale Detektor eh mitliest ist es kein Problem. Die Zentrale weiß es was sie gerade gesendet hat. Ein dortiger globaler Detektor hat also keine Schwierigkeiten, die Antwort zuzuordnen.

Die Bestätigung von DCC-Befehlen funktioniert nach meinem Dafürhalten eh am besten mit dem globalen (zentralen) Detektor. Ist da noch ein Bus dazwischen, dauert es zu lange bis die Zentrale die Bestätigung bekommt.

---

Zitat von hb059 im Beitrag #72

---

Anwendungsfälle für globale Railcom-Detektoren (in der Zentrale):

• Loksuche / Aufgleissuche (Channel 2, bei DCC-A in Kombination mit Channel 1)
• CV lesen/schreiben (Channel 2)
• DCC-Kommandobestätigung (Channel 2)

Anwendungsfälle für lokale Railcom-Detektoren (am Belegtmelder):

• Loksuche (Channel 1)
• Ortsbestimmung einer Lok inkl. Richtung (Channel 1 und Channel 2)
• CV lesen/schreiben (Channel 2)
• Gleis/Empfangsqualität (Channel 2)

Beides kann natürlich auch in Kombination betrieben werden.

---

Hallo Vic,

Zitat von vikr im Beitrag #73

---

leider dauert es selbst bei mittleren Anlagen mit 20 bis 30 Loks schon u. U. sekundenlang, bis ein Decoder sein ACK senden kann, weil er erst dann wieder im Queu adressiert wird.

---

Hallo Vik,

auch auf die Gefahr hin, dass dies hier eine Diskussion von nur drei Leuten wird, möchte ich dir gerne antworten. :)

Zuerst noch mal kurz zur Railcom Antwort allgemein: Hinter jedem DCC Paket erfolgt eine knapp 500 µs lange Railcom-Austastlücke. Dort darf auf Channel 1 jeder Dekoder seine Adresse rausgeben, der gerade Lust dazu hat. Deshalb ist Channel 1 für globale Melder in der Regel nicht nutzbar. im zweiten Teil der Railcom-Austastlücke muss der vorher im DCC-Paket adressierte Dekoder antworten. Einem adressierten Dekoder steht somit immer sofort einen Antwortkanal zur Verfügung. Er muss nicht warten. Es gibt keinen Jitter. Die Antwort auf Channel 2 kann dem vorausgegangenen DCC-Paket klar zugeordnet werden.

Zum zweiten Teil deiner Frage:
Eine ESU Zentrale funktioniert als globaler Railcom-Detektor hervorragend. Als lokale Detektoren verwende ich LoDi-8GBMs über S88.2 an einem LoDi-S88-Commander. Eine ESU Zentrale verwende ich nicht, weiß aber, dass die Kombination funktioniert.

Gruß
Hagen

Hallo Hagen,

Zitat von hb059 im Beitrag #75

---

Eine ESU Zentrale funktioniert als globaler Railcom-Detektor hervorragend. Als lokale Detektoren verwende ich LoDi-8GBMs über S88.2 an einem LoDi-S88-Commander. Eine ESU Zentrale verwende ich nicht, weiß aber, dass die Kombination funktioniert.

---