Hallo,
"Plug'n'play" ist schon ein Gedanke, der bei mfx mitspielt, verglichen mit DCC. Eine mfx-Lok stelle ich aufs Gleis, räume die Schachtel beiseite, und die Lok ist bei der mfx-Zentrale mit Namen und allen Funktionstasten angezeigt. Der DCC-Kollege hat da noch ein paar Minuten vor sich, um die Datenkarte für die Lok in die Zentrale zu bringen. Und während Villariba noch programmiert, spielt Villabajo schon mit der neuen Lok. Oder so.
Nun sendet eine mfx-Lok an die Zentrale, übers Gleis. Aber wie oft? Dann, wenn die Zentrale es anfordert. Und Esu-ECOS-Besitzer wissen, wie lange es dann dauern kann, einen größeren Fuhrpark anzumelden (Märklin kann das schneller, aber Zeit braucht es auch). Das ist für eine Rückmeldung nicht brauchbar, die ja dann auch noch zwingend eine Lokalisierung beinhalten müßte.
Eine dauernde Rückmeldung übers Gleis macht meines Wissens niemand. Railcom braucht immer eine zusätzliche Leitung, Lissy auch. Und von der einfachen binären Rückmeldung des s88 sagen so viele, daß sie einfach nicht ausreiche...
Nun gut, wenn man von den 30 Jahre alten Komponenten der alten Märklin-Reihen ausgeht, stimmt das ja auch. Aber moderne s88N-Geräte sind schneller und auch sicherer und können eine kleine bis mittlere Anlage sehr gut versorgen. Da könnte eine auf dem Gleis "entgegen der Fahrtrichtung" 
gesendete Rückmeldung gar nicht mithalten. Bei anderen Rückmeldemethoden mit mehr Information im Datenpaket schon mal gar nicht.
Die einzigen, für die eine Rückmeldung ohne eigene Kabel wirklich einen Vorteil brächte, sind Teppich- und Modulbahner. Die sind aber längst auf ganz anderen Wegen, oder nutzen halt die Rückmeldung über die bestehenden Bus-Systeme.
Zitat
Ein Nutzung der mfx-Austastlücke (Rückmeldelücke) dürfte durch DIY-Projekte wohl sehr schwer zu realisieren sein, ob der mfx-Hersteller hier eine Marktlücke sieht, kann ich nicht bewerten.
Eine railcom-ähnliche Nutzung der Austastlücke für Rückmeldungszwecke wäre vielleicht denkbar, die Auswertung müßte dann aber lokal geschehen und über ein gesondertes Bus-System an die Zentrale vermittelt werden. Hier bietet sich in der Märklin-Welt der CAN-Bus an.
Und da täten sich unheimliche Möglichkeiten auf, die aber in der Praxis kaum jemand wirklich braucht... etwa, daß Fahrbefehle für die Lok x oder y nicht zentral ins Gleis eingegeben werden, sondern von den Versorgungs- und Rückmeldeeinheiten, und zwar nur da, wo die Lok gerade ist. Das Gleisprotokoll würde damit deutlich entlastet, weil in jedem Abschnitt nur die Befehle für die dort befindlichen Decoder ins Gleis gegeben würden.
Jede Versorgungseinheit würde zu einer Satelliten-Zentrale, die die über den CAN sehr schnell gesendeten Befehle mithört und nur die aufgreift, die für die bei ihr gemeldeten Decoder wichtig sind. Wenn ich das CDB-System richtig verstanden habe, funktioniert dort die Weichenverwaltung so ähnlich. Allerdings wechseln Weichendecoder selten den Ort.
Das Gleis wäre dann nicht mehr Hauptträger der Datenübertragung, sondern nur noch der letzte Abschnitt; die Übertragung an sich erfolgte durch den CAN-Bus.
Viel Spaß beim Entwickeln...
Die Schwierigkeit liegt hier vermutlich darin, daß es im Protokoll bisher nicht vorgesehen ist, Loks lokal auszulesen. Das müßte in eine neue Version des Protokolls eingearbeitet werden.
Solange das nicht geschieht, bleiben auch für DIY-Projekte alle Türen verschlossen, denn was es nicht gibt, kann man auch nicht ausnutzen. Damit Märklin in so eine lokale Auslesung Zeit (und damit Geld) investiert, müßten sie nicht nur eine Marktlücke sehen, sondern einen Nutzen. Vielleicht wäre da in Verbindung mit mfx+ was denkbar, daß die Lok sich am Wasserkran bzw. an der Tankstelle "vorstellt" und dann die Füllstände aufgefüllt werden.
Die Erwartungen von Modellbahnern, denen s88 nicht reicht, werden für sich allein - fürchte ich - einen solchen Entwicklungsaufwand nicht rechtfertigen.
Und nun noch eins.
Es gibt viele Kollegen, die DCC als einziges Protokoll nutzen. Das macht es einfacher, Dinge wie Railcom zu implementieren, die andere Protokolle stören können.
mfx ist von Anfang an dafür ausgelegt, im Verbund mit anderen Protokollen genutzt zu werden, zumindest mit MM. Mit DCC funktioniert es auch.
Auf dieses Zusammenspiel sind auch Timings des Protokolls ausgelegt, wie die "Austastlücke" zur Lokanmeldung. Eine Weiterentwicklung des Protokolls darf hier nicht zu Störungen der anderen Protokolle führen. Das macht die Sache nicht einfacher...
t: 
