Hi,


ich steuere meine Moba mit einer Uhlenbrock Intellibox II. Die Anlage wird von einem Booster mit Strom versorgt, der von der IB II angesteuert wird.

Der Booster ist ein TAMS B4 (Anschluss via CDE) bzw. ein Railcom tauglicher Uhlenbrock Power Booster (Anschluss via Loconet-B).

Die Loks sind Märklin Loks, gekauft in den letzten 20 Jahren mit den entsprechenden Märklin Decoder-Generationen. Einige Loks habe ich als DELTA-Maschinen erworben und mit Zimo oder ESU Decodern digitalisiert. Diese Loks, wie auch mfx-Loks mit DCC-Option, werden mit DCC Protokoll angesprochen. Auf dem Gleis liegen also MM2 und DCC-Signale und MM-Signale für die digitale Weichensteuerung.

ESU, TAMS und Uhlenbrock bieten RAILCOM-Nachrüstsätze an, die zusätzlich zum bereits installierten Decoder eingebaut werden können, um "Alt-Systeme" RAILCOM-tauglich zu machen.

Ich würde gerne erste Tests starten um zu sehen wie sich dies -Betrieb von DCC-Decodern mit RAILCOM + MM-Decodern mit RAILCOM Nachrüst-Set - in der Betriebspraxis bewährt und ob dies nicht ein eleganter Weg sein kann auf einer Parkettbahn mit überschaubarem Verkabelungsaufwand mit Loconet-basierenden RAILCOM Detektoren u.a. eine Blocksteuerung zu realisieren.

Bevor ich mich selbst in für mich unbekanntes Gelände wage möchte ich gerne in die Runde fragen ob und wenn ja welche Erfahrungen mit RAILCOM Ausrüstung/Nachrüstungen in heterogenen, über die Jahre gewachsenen Digitalumgebungen vorliegen. Was klappt, was klappt nicht und was kommt eventuell zu Tage das man an dieser Stelle gar nicht vermutet hätte.

Hallo Helmut,

MM-Decoder mit einem Railcom-Sender auszustatten macht keinen Sinn.
Der Railcom-Sender kann nur nach einem DCC-Paket seine Daten senden.

Grüße
Stephan

Auch brauchst du für eine Blockstreckensteuerung kein RailCom, da es ja nur um den Belegtzustand eines Blocks geht.
Railcom wäre nur notwendig wenn du Adresse, Geschwindigkeit, QoS und Aufgleisrichtung zusätzlich möchtest.

Hallo Stephan,

Zitat

---

Hallo HeMM-Decoder mit einem Railcom-Sender auszustatten macht keinen Sinn.
Der Railcom-Sender kann nur nach einem DCC-Paket seine Daten senden.

---

Ja, es müssen DCC-Signale auf dem Gleis liegen, damit die Zentrale überhaupt Lücken schneiden kann, aber in welche Lücke ein Sender dann seine Nachricht schreibt, ist Sender und Empfänger egal.

@Helmut: funktioniert, der Aufwand lohnt sich aber nicht für Loks mit Delta-Decoder, sondern nur für Loks, die man nur sehr schwierig mit einem RailCom fähigen DCC-Decoder ausrüsten kann, z.B. Loks mit kombinierter Sinussteuerplatine. Bei fast allen Delta-Loks ist es besser und nur wenig teurer, den vorhandenen Decoder durch einen DCC-Decoder zu ersetzen, ggf. auch gleich den Motor durch einen HLA (oder einen Faulhaber) umzurüsten.

mfx-Decoder müßten bei Deiner Zentrale ja eh unter DCC oder MM betrieben werden, da bekommt der RC-Sender dann die gleiche Adresse verpasst (per POM! ).

Das Ganze funktioniert aber nur mit lokalen RC-Detectoren und da benötigst Du für jeden Block natürlich wieder ein eigenes Kabel auf dem Teppich.

MfG

vik

Hi Helmut,

ich kann aus eigener Erfahrung besteuern, dass:

- Weichen mit 74460 Dekoder nicht mehr, oder kraftlos mit gebrumme umschalten

- Lok mit älteren MM-Dekodern auch probleme haben (kraftlos, mache auch gar nicht ansprechbar, und noch mehr Lichtflackern wie sonst schon, wenn die Beleuchtung gegen Lokmasse geschaltet ist (Übliche Schaltung bei Dekodern mit NEM 651 Schnittstelle oder Dekoder der C80, Delta und C90 Generation).


Daher lasse ich mich zu der Aussage hinreißen, dass die Nutzung von Railcom auf einer Modellbahn, wo außer DCC Komponenten auch MM Komponenten Verbaut/genutzt werden, nicht zur allgemeinen Erbauung beiträgt.

Erst wenn die Anlage vollkommen MM-Freie Zone ist, würde ich es Wagen, an die Nutzung von Railcom nachzudenken.



Viele Grüße, Michael

Hallo,

Zitat von Michael Knop im Beitrag #5

---

Daher lasse ich mich zu der Aussage hinreißen, dass die Nutzung von Railcom auf einer Modellbahn, wo außer DCC Komponenten auch MM Komponenten Verbaut/genutzt werden, nicht zur allgemeinen Erbauung beiträgt.

Erst wenn die Anlage vollkommen MM-Freie Zone ist, würde ich es Wagen, an die Nutzung von Railcom nachzudenken.

---

Hi,

ich habe basierend auf Euren Aussagen heute abend mal einen ersten Test gemacht, wie der momentan auf der Anlage befindliche Lok- und Wagenpark auf eine aktivierte Option RAILCOM im TAMS-B4 Booster reagiert.

Ein erstes Fazit:

Bei der Zuverlässigkeit der Weichenschaltungen (C-Gleis Weichen mit Orginal Marklin MM C-Gleisdecoder), ob jetzt "per Hand" oder in Fahrstrassen , gesteuert durch die IB II via TAMS-B4, konnte ich keinen Unterschied zu Zustand ohne RAILCOM feststellen.

Die auf der Anlage befindlichen Loks mit Märklin MM Decodern der Baujahre 1998 bis 2018 (für den 5- Poler Hochleistungsantrieb, C-Sinus Classic, Glockenanker) liefen ohne erkennbare Probleme.

Die Funktionsdecoder zur Steuerung der Wagenbeleuchtung zeigten keine Auffälligkeiten, die nachgerüsteten DCC-Decoder von ESU in verschiedenen Loks liefen erwartungsgemäß ohne Probleme.

Nur ein Märklin Multiprotokoll-Decoder der neuesten Genration, serienmäßig verbaut in der 218 Touristik-Lok #39219, zeigte nach Aktivierung von RAILCOM eine Fehlfunktion. Statt wie programmiert auf die DCC-Adresse 28 reagierte er nur auf die MM-Adresse 21 und konnte nur die Reset auf Auslieferungszustand (CV8= und eine Neuprogrammierung wieder unter DCC angesprochen werden. Nach Deaktivierung der Analog-Erkennung in der CV50 (CV50=4) trat der Fehler bisher nicht wieder auf.

Ich werde die Kompatibilitätstests des Mixed Enviroment aus den Decodergenerationen der letzten 20 Jahre (von Märklin, Zimo und ESU) mit weiteren Loks in nächster Zeit fortsetzen und bei Auffälligkeiten hiervon berichten.

Hi,

ich habe in den letzten Tagen weitere Loks von Märklin aus den letzten 20 Jahren bei aktivierten RAILCOM-Cutout am TAMS-B4 Booster getestet. Als Command-Station diente eine IB II, sofern vom Decoder nicht unterstützt wurden die Märklin Loks mit MM Protokoll der IB II angesteuert.

Die Lok-Modelle mit klassischen MM-II Decodern (mit Mäuseklavier) haben keine Probleme mit dem RAILCOM-Cutout.
Ich habe dies an den Modellen BR-101 #37374, BR-143 #37430, BR-152 #37350 und BLS-465 #39609 getestet.

Die Lok-Modelle mit mfx/MM Decodern haben Probleme mit dem RAILCOM-Cutout. Die Änderung von Fahrstufen oder das Auslösen von Funktionstasten erfolgt immer wieder verzögert oder wird "übersehen".
Ich habe dies an den Modellen BR-139 #37405, BR-275 Railion Italia # 37200, BR-648 #37736, BR-120 #37530, BR-212 #37007 getestet.
Eins Ausnahme von dieser "Regel" bildet das Model der BR-189 #39890 das ohne Probleme funktioniert. Ist in diesem Modell ein ESU-OEM mfx/MM Decoder verbaut ? Der Decoder hat ausser einem Lok-Pfiff keine Soundfunktionen und erinnert in seinem Funktionsumfang an die klassischen MM-II Decoder.

Die Lok-Modelle der aktuellen Generation mit mfx/MM/DCC Decodern haben keine Probleme mit dem RAILCOM-Cutout wenn man bei aktiviertem DCC-Protokoll in der CV50 den Wert "4" (DCC only) setzt.
Ich habe dies an den Modellen BR-120 #37529, BR-218 #39219 und SBB-620 # 37326 getestet.

Hallo Helmut,

Zitat

---

ich habe in den letzten Tagen weitere Loks von Märklin aus den letzten 20 Jahren bei aktivierten RAILCOM-Cutout am TAMS-B4 Booster getestet. Als Command-Station diente eine IB II, sofern vom Decoder nicht unterstützt wurden die Märklin Loks mit MM Protokoll der IB II angesteuert.

Die Lok-Modelle mit klassischen MM-II Decodern (mit Mäuseklavier) haben keine Probleme mit dem RAILCOM-Cutout.
Ich habe dies an den Modellen BR-101 #37374, BR-143 #37430, BR-152 #37350 und BLS-465 #39609 getestet.

Die Lok-Modelle mit mfx/MM Decodern haben Probleme mit dem RAILCOM-Cutout. Die Änderung von Fahrstufen oder das Auslösen von Funktionstasten erfolgt immer wieder verzögert oder wird "übersehen".
Ich habe dies an den Modellen BR-139 #37405, BR-275 Railion Italia # 37200, BR-648 #37736, BR-120 #37530, BR-212 #37007 getestet.
Eins Ausnahme von dieser "Regel" bildet das Model der BR-189 #39890 das ohne Probleme funktioniert. Ist in diesem Modell ein ESU-OEM mfx/MM Decoder verbaut ? Der Decoder hat ausser einem Lok-Pfiff keine Soundfunktionen und erinnert in seinem Funktionsumfang an die klassischen MM-II Decoder.

Die Lok-Modelle der aktuellen Generation mit mfx/MM/DCC Decodern haben keine Probleme mit dem RAILCOM-Cutout wenn man bei aktiviertem DCC-Protokoll in der CV50 den Wert "4" (DCC only) setzt.
Ich habe dies an den Modellen BR-120 #37529, BR-218 #39219 und SBB-620 # 37326 getestet.

---

Ist auch meine Erfahrung.
mfx-Decoder - nicht die Zentrale - "überschreiben", natürlich nur bei eingeschaltetem mfx, unbeirrt und sehr ignorant die RailCom-Lücke, glücklicherweise nicht jede.

MfG

vik

Hallo Helmut,

Zitat von brettsh im Beitrag #8

---

Hi,

ich habe in den letzten Tagen weitere Loks von Märklin aus den letzten 20 Jahren bei aktivierten RAILCOM-Cutout am TAMS-B4 Booster getestet. Als Command-Station diente eine IB II, sofern vom Decoder nicht unterstützt wurden die Märklin Loks mit MM Protokoll der IB II angesteuert.

Die Lok-Modelle mit klassischen MM-II Decodern (mit Mäuseklavier) haben keine Probleme mit dem RAILCOM-Cutout.
Ich habe dies an den Modellen BR-101 #37374, BR-143 #37430, BR-152 #37350 und BLS-465 #39609 getestet.

Die Lok-Modelle mit mfx/MM Decodern haben Probleme mit dem RAILCOM-Cutout. Die Änderung von Fahrstufen oder das Auslösen von Funktionstasten erfolgt immer wieder verzögert oder wird "übersehen".
Ich habe dies an den Modellen BR-139 #37405, BR-275 Railion Italia # 37200, BR-648 #37736, BR-120 #37530, BR-212 #37007 getestet.
Eins Ausnahme von dieser "Regel" bildet das Model der BR-189 #39890 das ohne Probleme funktioniert. Ist in diesem Modell ein ESU-OEM mfx/MM Decoder verbaut ? Der Decoder hat ausser einem Lok-Pfiff keine Soundfunktionen und erinnert in seinem Funktionsumfang an die klassischen MM-II Decoder.

Die Lok-Modelle der aktuellen Generation mit mfx/MM/DCC Decodern haben keine Probleme mit dem RAILCOM-Cutout wenn man bei aktiviertem DCC-Protokoll in der CV50 den Wert "4" (DCC only) setzt.
Ich habe dies an den Modellen BR-120 #37529, BR-218 #39219 und SBB-620 # 37326 getestet.

---

Hi,

nachdem bei den Tests ein Teil der von Märklin verbauten Decoder inkompatibel zum Railcom Cut-out ist habe ich darauf verzichtet den Erfahrungsgewinn zu vertiefen.

Ich überlege ob es sinnvoll ist die fraglichen Decoder durch Railcom kompatible Modelle zu ersetzen oder auf ein Identifikationsverfahren auszuweichen das unabhängig vom Digitalprotokoll arbeitet (LISSY, Transponder-Technologien .... oder was die digitale Zukunft sonst noch bringt).

Als Parkettbahner drängt kein Bedürfnis nach automatisiertem Anlagenbetrieb nach einer schnellen Lösung, es ist eher der digitale Spieltrieb der hin und wieder hochkommt ...

Hallo Helmut,

Zitat von brettsh im Beitrag #11

---

nachdem bei den Tests ein Teil der von Märklin verbauten Decoder inkompatibel zum Railcom Cut-out ist

---

Zitat von brettsh im Beitrag #11

---

es ist eher der digitale Spieltrieb der hin und wieder hochkommt ...

---

Hi,

als das mfu-Modul von Uhlenbrock vor Jahren angeündigt wurde habe ich bei meinem Moba-Händler ein Exemplar vorbestellt. Diese Vorbestellung habe ich inzwischen aus folgenden Gründen storniert:

Aktuelle Märklin Loks können auch mit DCC gesteuert werden wenn man Funktionen jenseits dessen nutzen will was das MM-Protokoll in diesen Modellen unterstützt. Diese Option nütze ich und kann die Modelle ohne Probleme steuern. An die eingeschränkte Funtionalität der Modelle mit mfx/MM only Decoder habe ich mich inzwischen weitgehend gewöhnt und plane dort wo es mich auch heute noch nervt, einen mm/DCC/(mfx) fähigen Decoder von ESU einzubauen.

Das mfu-Modul bedingt einen Update des Intellibox II Software. Da möchte ich erst mal sehen wie sich die Codequalität der neuen Version auf die Betriebsstabilität der IB II auswirkt. Hat die mittlerweile 10 Jahre alte IB II Hardware ausreichend Reserven um bei aktiven mfu-Module 3 Protokolle (MM, mfx, DCC) gleichzeitig und fehlerfrei für die Anlage zu generieren ?

Ich steuere meine Parkettbahn mit IB II und einen über CDE-Interface angeschlossenen B-4 Booster von TAMS. Dieser Booster versorgt die gesamte Anlage. Das mfu-Modul bedingt das ich neben einem an die IB II angeschlossenen Programmiergleis ein kurzes "mfu-Gleis" zur Identifikation der mfx-Modelle und davon getrennt die über IB II->CDE->B4 gesteuerte Anlage betreiben muss. Da möchte ich mich erst mal auf einer Messe mit Uhlenbrock über diese Konfiguration unterhalten nachdem Uhlenbrock das Produkt zum Vertrieb freigegeben hat.