THEMA: RailCom ZIMO Decoder Aufgleisrichtung wechselt nicht?

Hallo Frank,

funktioniert bei deinem Decoder RailCom an sich (z.B. über POM CVs lesen)? Ist in CV28 und CV29 RailCom aktiv? Mit CV28=3 und CV29=10 wäre die Vorraumsetzung dafür erfüllt.

Sobald irgendein RailCom-Paket vom Decoder ausgesendet wird, misst das Gleisabschnittsmodul die Stromrichtung und weiß dadurch wie die Lok drauf steht. Dadurch muss sich bei jeden Decoder der RailCom aussendet auch die Aufgleisrichtung ändern, wenn die Lok am Gleis um 180° gedreht wird.

LG
Markus

Hallo Markus

Ich habe ein sehr ähnliches Problem wie Frank, das eventuell die gleiche Ursache hat.  
Von allen meinen vielen Decodern mit Railcom werden nur drei nicht oder nur mit minutenlanger Wartezeit erkannt. Alle drei sind von Zimo:
- FLM-187, MX658, FW 37.8
- FLM-01.10, MX648C, FW 35.2
- Kato-Re620, MX633, FW 40.7
Per Railcom kann ich bei diesen Loks CVs problemlos und sofort POM lesen und schreiben (DR5000-Tool, D&H-Programmer).
Alle anderen Zimo- und D&H-Decoder melden sich sofort und richtig herum an.
Hardware: DR5000, DR5088RC (umgebaut auf 5,6-Ohm-Widerstände gemäß Karst Drenths Tipp), beide auf aktuellster FW.
Software: TC 9g

Ein Gespräch mit allen Zimo-Experten auf der Messe in Dortmund hat keinen Lösungsansatz gebracht. Der Tipp, die FLM-Werksloks mittels der Z21 auf eine neue FW zu bringen, konnte noch nicht getestet werden.

Dietrich
PS: Ich habe gerade die 187 aufgegleist. Nach einiger Zeit hat sie sich angemeldet. Ich habe sie dann herum gedreht und dann CV5 per POM gelesen und geschrieben. Auch nach 20 Minuten hat sich das Bild noch nicht herum gedreht.

Hallo Frank,

verzeihe, Dein Problem habe ich nur halb verstanden. Aber wäre es auch möglich dass es am Rückmeldemodul liegt ? Tritt das Problem auf der ganzen Anlage auf, oder nur an bestimmten Stellen ?
Oder gar an der Kombination Lok / Decoder / Rückmelder ? Ändert sich was, wenn Du andere Rückmeldeabschnitte (eines anderen Rückmeldemoduls) oder anderen Decoder in die Lok einbaust bzw. den Decoder in eiine andere Lok verbaust ? (- stochern im Nebel ... )

Viele Grüße, Joni

Hallo

Das sehe ich genauso. Allerdings erwarte ich, dass das bei Loks mit WERKSSound der Fall ist und auch beim Lok- und beim Decoderhersteller getestet wurde. Es funktioniert auch bei der Mehrzahl meiner Fleischmann-Loks, nur diese zwei wollen nicht richtig.

Noch eindeutiger ist der Fall bei der Kato-Lok. Hier stammt die Austausch-PLATINE komplett von Zimo.

Dietrich

Hallo Frank,


Speziell bei der HT Variante sind keine Entstör-Elemente vorhanden, die zwischen Motor und Gleis liegen.

Bei Next18 werden zum einen die Lichter direkt vom Pluspol des Decoders versorgt (belastet V+) und zum anderen wären da noch die unverstärkten Ausgänge - die Schaltung belastet VCC mit unbekannten Strömen.

Jetzt erhebt sich die Frage ob der Decoder im Moment der Railcom Aussendung die GPIOs abschaltet und wenn ja, auf welchen Zustand: LOW oder hochohmig (Z)?

Warum dabei die Polung der Lok eine Rolle spielt verstehe ich in Unkenntnis der internen Railcom Schaltung noch nicht.

Vielleicht kann zumindest Markus von Zimo in diese Richtung forschen. Bei DH liegt der Kreis innerhalb des ASIC.

Grüße, Peter W

Hallo

Ich habe inzwischen etwas weiter geforscht.
Bei den beiden Fleischmann-Loks mit Werkssound (FLM-187, MX658, FW 37.8 und FLM-01.10, MX648C, FW 35.2) habe ich die Firmware auf 40.20 upgedatet. Die Loks werden nun beide schneller erkannt (einige Sekunden statt vorher Minuten), auch mit richtiger Aufgleisrichtung. Wenn ich die Lok auf dem selben Belegtmelder umdrehe wechselt die Aufgleisrichtung NICHT. Stelle ich die Lok auf einen anderen Belegtmelder, zeigt dieser (nach einigen Sekunden Wartezeit) sofort die richtige Aufgleisrichtung an. N.B.: ALLE anderen Loks werden SOFORT (binnen zwei Sekunden) erkannt, beim Umdrehen auf dem SELBEN Belegtmelder wechselt die Richtung sofort.

Dann habe ich speziell nochmals meine FLM- und HTR-Vectrons (alle mit DH18A) angeschaut: ALLE diese Loks werden SOFORT (binnen zwei Sekunden) erkannt, beim Umdrehen auf dem SELBEN Belegtmelder wechselt die Richtung sofort.
N.B.: - Bei den MEISTEN FLM-Loks sind die Kondensatoren zwischen Gleis und Motor entfernt.
Bei ALLEN HTR-Loks sind die Motor-Kondensatoren entfernt.

Dietrich
Für den Platinen-Decoder der Kato-Re620 habe ich leider keine Update-Möglichkeit.

Hallo Frank und Markus

Ich habe nun noch etwas intensiver getestet und noch ein drei weitere "drehunwillige" Loks (alle mit FLM-Werkssound) gefunden:  
- 220 (Taigatrommel), MX648C, FW 34.4
- Re460, MX648, FW 32.8
- 245, MX648C, FW 35.2

Ich habe alle drei mit der Z21 auf FW 40.20 upgedatet. Das hat an der "Drehunwilligkeit" nichts geändert. (Wenn ich die Lok auf dem selben Belegtmelder umdrehe wechselt die Aufgleisrichtung NICHT. Stelle ich die Lok auf einen anderen Belegtmelder, zeigt dieser (nach einigen Sekunden Wartezeit) sofort die richtige Aufgleisrichtung an. Siehe #10)

Zur Kato-Re620 aus #2: Wider Erwarten konnte ich sie mit der Z21 updaten. Gleiches Ergebnis: Es hat an der "Drehunwilligkeit" nichts geändert.

Zum FLM-Vectron (SBB und BLS, erste FLM-Chassis-Bauform mit Fünfpol-Motor!): Beide sind mit DH18A FW 3.12. Erkennung und Richtung funktionieren problemlos. Welche FLM-Chassis-Bauform hast du? (oder Artikelnummer).

Dietrich

Hallo Frank

- Fleischmann 739283 Vectron ist "Mit neuem Motor und überarbeitetem Getriebe". Von dieser zweiten Version habe ich noch keine Lok zum Probieren.
- HTR-Vectron habe ich mit Werkssound aus dem Flixtrainset  95005S, MS590, FW 4.99. Ich habe diesen nun auch noch etwas genauer getestet: Meldet sich sofort mit richtiger Richtung an. Nach dem Umdrehen wird diese Änderung NICHT erkannt. Hier ist wohl das Fehlerbild wie bei dir.
Damit habe ich jetzt auch sieben "Problemloks", alle mit Zimo-Decodern unterschiedlicher Bauart. Alle D&H-Loks (>70) funktionieren bei mir.

Dietrich  

Hallo,

das System Railcom scheint ja unter den Modellbahnern nicht gerade weit verbreitet zu sein da sich bisher nur Frank und Dietrich mit diesem Probleme zu Wort gemeldet haben. Bei den Herstellern sieht es offenbar ähnlich aus und die Funktion Railcom wird nicht oder zumindest nicht ausreichend getestet. Zimo wirbt selbst damit das seit 2004 Railcom möglich sei:

http://www.zimo.at/web2010/newsitems/Railcom-Zeitalter_news.htm

Das jetzt, nach fast 20 Railcom, solche Probleme auftauchen, kann ich fast nicht glauben. Da hätten sich doch sicher viel mehr andere Railcon-Nutzer zu Wort gemeldet. Aber ich glaube Frank und Dietrich schon das die Problematik real existiert. Ich bin mal gespannt ob das ein Fehler in der Firmware und/oder in der Hardware ist...

Grüße
Markus

Hallo,

würde gerne helfen, aber leider kann ich weder bei der LRC120 von Lenz noch bei der z21 noch beim Piko Programmer die Polarität der RC Aussendung abfragen.

Grüße, Peter W.

Hallo

Ich habe jetzt noch einen Test gemacht, den ich mit den Zimo-Experten an Stand auf der Messe in Dortmund vereinbart habe:
Decodertausch zwischen FLM-187 (MX658) und -147 (DH18A). Beide sind weitgehend baugleich, nur die Fahrzielanzeige-LEDs sind nur bei der 147 bestückt. Ich habe auch nach "Stör"kondensatoren gesucht, aber bei diesen Loks gibt es offenbar keine.
Ergebnis:
- DH18A funktioniert in beiden Loks problemlos
- MX658 funktioniert in beiden Loks mit dem bekannten Problem

Also liegt es offensichtlich nicht an den Platinen. Das zeigt bei mir auch der Vergleich der HTR-Vectrons.

Dietrich

Hallo Dietrich,

das ist ja schon was. Dann kann es eigentlich nur eine Abweichung bei Zimo sein. Entweder bringen sie den erforderlichen Strom in einer Richtung nicht (vielleicht irgendwelche Transistoren offen?) oder die Bitrate passt nicht gut genug zum Empfänger (OSCCAL?).

Grüße, Peter W

Hallo Frank

Hier gibt es wohl ein Missverständnis. Der Weg des Stroms ist in beiden Aufgleisrichtungen exakt gleich, nur die Richtung ist unterschiedlich. Außerdem fließen bei der Rückmeldung viel kleinere Ströme, als beim Fahren.

Meine beiden verglichenen HT-Vectrons haben leicht unterschiedliche Platinen ("VERT 2017" mit DH18A  und "VERT 2018" mit MS590). Ich habe noch einen unverbauten MS590 da, den werde ich morgen mit der VERT 2017 testen, um die Platine auszuschließen.

Eventuell könnte es helfen, wenn Anwender mit anderen RC-Belegtmeldern (Roco oder Blücher) auch mal testen könnten.

Dietrich

Hallo

Diesen Test habe ich jetzt gemacht.
- Vorher: HT-Vectron mit Platine "VERT 2017"  und DH18A meldet sich sofort an, nach dem Umdrehen wechselt das Symbol sofort die Richtung.
- Nachher: HT-Vectron mit Platine "VERT 2017"  umgebaut auf MS590 (FW 4.225) meldet sich sehr verzögert an, nach dem Umdrehen wechselt das Symbol NICHT die Richtung.

Damit ist eindeutig geklärt, dass die Platine keine Rolle spielt. Das ist nun für Hobbytrain- und Fleischmann-Loks durch Decodertausch eindeutig geklärt. Bei beiden Herstellern geht es bei mir um Loks, die bereits ab Hersteller mit Zimo-Sounddecodern geliefert wurden.  

Dietrich

Hallo Dietrich,

ein Jahr zu spät, aber:

hattest Du bei Deinen problematischen Zimo-Decodern mal RailCom Kanal 2  in CV 28 testweise ausgeschaltet(CV28=1)?

Mit den Firmware-Versonen 40. xx wurde die dynamische Kanal 1 Abschaltung gemäß RCN-217 eingeführt. Diese kann man bei den MX-Decodern mit FW 40.xx bisher leider nur Ausschalten in dem man Kanal 2 komplett ausschaltet.
Das liegt daran, dass Bit 2 in CV28 für OW benutzt wurde und daher - falls gelöscht - nicht RCN-217 konform die dynamische Ausschaltung unterdrückt.

MfG

vik

Das stimmt nicht. Dieses Feature gibt es weder in MX- noch in MS-Decodern.

Hallo vik (Realname fände ICH toll!)

Diverse Tests mit Kanal 1 und 2 ein/aus in Decoder (neueste FW) und Belegtmelder habe ich gemacht. Ergebnis: Kanal 2 im Belegtmelder einschalten verbessert die Erkennung etwas.

Kontakt zu Karst x (Entwickler des BM und Chef von Ya...) brachte nach einigen kurzen Tests seinerseits die Aussage, dass an der Zimo-FW etwas zu tun sei.

Kontakt zu Zimo zeigte große Hilfsbereitschaft, aber mit dem Problem, die Hardware zu besorgen. Letztlich haben wir es dann so gelöst, dass ich meinen BM ausgebaut habe und Zimo für Tests zur Verfügung gestellt habe. Ich habe ihn nun wieder zurück und gerade wieder eingebaut. Allerdings konnte ich noch keine großen Tests damit machen. Es gibt Hinweise von Zimo für Verbesserungen, denen muss ich jetzt nachgehen. Dann werde ich näher darüber berichten.

Dietrich

Hallo,

meine Fleischmann 7370011 aus 2023 (218 o/b) ist auch von dem Problem betroffen. Liefert über Railcom keine Adresse und auch keine Richtung, auch nicht nach längerer Zeit. Die üblichen CVs alle schon gecheckt, Fahreigenschaften sonst absolut ok, aber ohne Railcom für mich unbrauchbar. Decoder sollte Zimo MS590 N18 sein.

Laut Zimo HP gabs am 31.07.2024 eine aktualisierte FW 4.254, im Changelog steht aber nur "MN Decoder DCC Empfang / RailCom > verbessert ". Hat das schon jemand mit dem MS590 N18 getestet?

Cheers, Steffen

https://www.zimo.at/web2010/support/MS-MN-Decoder-SW-Update.htm

Hallo Steffen,

Ich habe die 7370011 vor kurzem gekauft. Ich da demnächst mal schauen, ob die Richtung doch korrekt angezeigt wird, teste momentan sowieso mit den Roco 10808 Rückmeldern. Bin aber erst wieder in 2 Wochen an der Anlage

PS:
Im Zusammenhang mit der Z21 ist mir aufgefallen, dass nach dem Einschalten es keine Rückmeldungen gibt, bevor ein Loksignal gesendet wird. Anscheinend gibt es per Default keine RailCom Lücke. Und wenn mehrere Loks mit RailcomDecoder in einem Abschnitt stehen, dann gibt es meist nur von der ersten eine Rückmeldung, es sei denn, alle Loks werden angesteuert.

Hallo,

das ist bei DCC normal, wenn ein Decoder keine Befehlstelegramme von der Zentrale erhält, kann er auch nicht in der anschließenden Railcom Lücke seine  Daten übermitteln.

Zentralen, die Liste der aktiven Adressen mittels Batterie gepuffert speichern, wie es z.B. Lenz tut, sind da im Vorteil.

Grüße, Peter W

RailCom Nachrichten gibt es bei MS/N Decodern erst wenn
- der Decoder adressiert wurde oder
- in CV12 nur DCC eingeschaltet ist

Hallo

Wie soll denn dann ein frisch aufgegleistes Fahrzeug erkannt werden?

:-? Dietrich

In dem man CV12 programmiert.

Das kann man falsch verstehen.... Ist da gemeint
Oder? Und?

Grüße,
Harald.

Wenn Du mit "adressiert" mindestens einen DCC Befehl meinst: Dann geht das so leider auch nicht, auch nicht mit CV12=4.

Daher nochmals zurück zu meiner Frage: Hat irgendjemand das aktuelle FW Update in Bezug auf RC getestet?

Bzw. @ Vincent Hamp: Wurde in dem FW Update zu dem Thema überhaupt etwas gemacht, was das Problem lösen könnte?

Cheers, Steffen

Stimmt, mein Post war nicht eindeutig. Hab ihn editiert. Ansonsten sind mir aktuell keine RailCom Probleme bekannt.

Ja ich ... und RC funktioniert m.E. so wie es soll.



RC Kanal-2 meldet keine Adressen, sondern Antworten auf Befehle an den Decoder. Die Antworten koennen im einfachsten Fall ein ACK sein (=ja, habe den Befehl verstanden) aber auch Gleisspannung, Temperatur, QoS usw. Die Adresse ergibt sich implizit ueber den DCC Befehl. Wenn eine Antwort auf einen Befehl an Adresse 47 kommt, dann ist da wohl ein Decoder mit der Adresse 47.

Wird ein Decoder von der Zentrale nicht angesprochen, kann er auch nicht Antworten.

Eine Richtung 'meldet' ein Decoder ebenfalls nicht, sondern die Richtung ist schlicht die Polaritaet seines Railcom Signals und entspricht somit der Aufgleisrichtung.

VG,
Frank

Hallo Frank,




Hattest du vorher Probleme mit RC und sie wurden durch das Update behoben?

Ich kann die Fleischmann 218 mit Zimo MS590 N18 ohne Probleme über die von mir eingestellte Adresse steuern und fahren, auch die Sound- und Lichtfunktionen funktionieren einmwandfrei. Nur wird mir über den GBM keine Adresse und keine Polarität zurückgemeldet, sobald ich die Lok aufs Gleis stelle oder damit fahre. Bei meinen ganzen anderen Loks funktioniert das ohne Probleme, und da sind einige mit Zimo Decodern dabei. Nur bei eben dieser Lok kommt gar nichts zurück. Eine verlässliche Steuerung und Einmessung mit Lodi/iTrain ist so nicht möglich.

Ich habe die Lok beim Händler auch schon gegen ein anderes Exemplar getauscht, das Problem ändert sich aber nicht.

Cheers, Steffen

Hallo Steffen,

Nein, ich hatte derartige Probleme bislang nicht ... aber diese Lok im speziellen, besitze ich nicht.

Wenn Du schreibst, es wird keine Adresse/Polaritaet angezeigt, dann schliesse ich daraus, dass die Lok garnix sendet. Die Frage stellt sich nach dem Warum. Den Decoder wuerde ich, gemaess dem Gesetz der grossen Zahlen, ausschliessen. Denn wenn dieser Decoder Aerger machen wuerde, haette Zimo davon sicherlich Wind bekommen.

In der Betriebsanleitung der Lok steht keine Silbe ueber RC ... das stimmt mich nachdenklich.

Evtl. liegt es an der Lok(-platine) und diese hat bespeilsweise Drosseln in den Gleiszuleitung derart diminsioniert, dass das hochfrequente RC Signal nicht durch kommt. Nicht sehr wahrscheinlich, aber im Bereich des moeglichen.

Hallo

Ich habe jetzt meine FLM-211 mit Werks-MS590 auf 4_254 upgedatet.

Meine DR5088 erkennt die Lok weiterhin nicht. Auch nicht wenn adressiert = gefahren wird.

CV 12=4 (nur DCC) hat nichts verändert.

Dietrich

Hallo,

wie es mir erscheint haben Steffen und Dietrich dasselbe Problem. Beide haben eine FLM Lok mit MS590. Zufall oder etwa eine Systematik dahinter?

Nur zur Sicherheit die Frage ... welche Werte stehen in CV28 und CV29?

VG,
Frank

Hallo

- CV28=3
- CV29=46

Dann habe ich noch mit einem Liliput-628 getestet: Wird schnell erkannt, auch Wechsel der Aufgleisrichtung.
- MS590 Next18 OHNE FW-Update, mit Zimo-628-Soundprojekt
- CV12=127
- CV28=67 (! Kommt das aus dem Sound-Projekt? Der MS590 unterstützt Bit 6 nicht.)
- CV29=42

Daraufhin habe ich in der Flm-211 auch diese drei CVs geändert, zuerst einzeln, dann alle drei: Keine Änderung, Lok wird weiterhin nicht erkannt, weder beim Aufgleisen, noch beim Fahren oder Umdrehen. Wenn ich mit dem DR5000-Zentralentool CVs per Railcom auslese, erfolgt MANCHMAL eine Lokerkennung. Dieses Railcom-Auslesen benötigt auch oft mehrere Versuche bei der 211. Beim L-628 geht es immer sofort.

Da beide Fahrzeuge den gleichen Decoder haben, scheint wohl auch das Leiterplattendesign des Herstellers einen Einfluss auf die Funktion zu haben.

Dietrich  

Hallo,



Aktuell
CV28=3
CV29=42
Und alle möglichen Werte ausprobiert, kein Erfolg.

Ich habe mal versucht, das Problem einzugrenzen und die Platine der Railcom Problemlok Fleischmann 7370011 (218 o/b, oben auf dem Foto) aus 2023 mit der optimal mit RC funktionierenden Fleischmann 724302 (218 verkehrsrot, Sylt Shuttle, unten auf dem Foto) aus 2022 verglichen.

Die Platine ist optisch völlig identisch ist, auch die Chargennummer 06/6616-0111. Der Decoder hat einige unterschiedlich beschriftete Bauteile verschiedener Hersteller auf der Platine, was aber erstmal nicht ungewöhnlich ist. Ist laut Aussage vom Zimo Support auf den damaligen Corona-Chipmangel zurückzuführen.

Fakt ist aber, wenn ich den Decoder der verkehrsroten 218 in die RC Problemlok o/b 218 stecke, funktioniert diese einwandfrei und meldet sich sofort mit korrekter Adresse und Polarität an.

Stecke ich den Decoder aus der RC Problemlok in die (vorher funktionierende) verkehrsrote 218, tut sich genau: Nichts. Fährt zwar, der keine RC Adresse und Polarität.

An den CVs liegt es nicht, ich habe alle in Frage kommenden CVs getestet. SW Version des funktionierenden Decoders: 4.225, RC Problemdecoder 4.229.

Scheint wohl doch der Decoder zu sein, was auch die Vermutung des Zimo-Supports ist, mit dem ich eben telefoniert habe. Der Decoder wird sich nachher auf den Weg nach Wien machen.

Cheers, Steffen

Die von Gleis_1 zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login

Hallo,

es kam auch in anderen Branchen vor dass in der Chip-Krise gezwungener Maßen eine Hardware verbaut werden musste welche nicht identisch war und nicht zu 100% zur vorhandenen Firmware passte da man keine oder zu wenig Vorlaufteit zum Testen hatte. Dazu kommt dass man zu dieser Zeit viele Tage im Homeoffice verbringen musste. Wenn man das rechtzeitig bemerkte konnte man vor der Auslieferung mit einem Update das kompensieren. Je nachdem wann und ob man bei Zimo wieder zum ursprünglichen Chip zurück gekehrt ist trifft es eben mehr oder weniger Kunden. Und offenbar nur die Nutzer des optionalen Railcom. Bin mal gespannt wie Zimo hier reagiert. Alle bemängelten Decoder austauschen oder eine passende Firmware schreiben?

Grüße
Markus

Hallo,

kann theoretisch auch ein Bestückungs- oder Lötfehler sein. Wenn gar keine RC Daten zurück kommen, ist in dem Schaltkreis ein Problem zu suchen. Zimo wird es bestimmt heraus finden.

Bei RC Problemen empfehle ich die simple Railcom Anzeige von Lenz oder ähnliches RC Display zu benutzen. Da kann man sehen ob die Zahl in der Anzeige überhaupt aufleuchtet und stabil bleibt oder flackert, je nachdem wie herum man die Lok aufgleist.

Grüße, Peter W

Sicherlich etwas mehr als ein simples Display und vermutlich nur was fuer Bastler ... aber ich hatte vor einiger Zeit einen DCC/Railcom logger entwickelt der mir bei solchen Problemen immer gute Dienste leistet.

https://rtb4dcc.de/blog/dcc_logger/

VG,
Frank

Hallo

Ich benutze das Digikeijs-Tool zum DR5088RC. Da sehe ich genau das Gleiche wie in #41 beschrieben.

Dann ist es wohl Chargenabhängig!? Ob ich mir einen Decodertausch zwischen 211 und 628 antue, weiß ich noch nicht.

:-? Dietrich

Bevor man hier weiter Gerüchte schürt vielleicht eine kurze Klarstellung:
Wenn wir bei ZIMO Bauteile verschiedener Hersteller nutzen, dann sind diese zu 100% kompatibel und qualitativ gleichwertig. Wir haben unterschiedliche Revisionen der gleichen Decoder-Typen, aber diese Revisionen werden in der Regel dann gemacht wenn etwa ein Flashbaustein nicht mehr lieferbar ist. Genau jene Situation ist auf dem von Gleis_1 geposteten Foto zu sehen. "ISSI" und "Winbond" sind zwei Hersteller von NOR-Flashes die von unseren Decoder-Typen unterstützt werden.

Für mich wäre prinzipiell spannend ob RailCom an anderen Belegtmeldern oder einer Zentrale einwandfrei funktioniert. Meiner Erfahrung nach muss man sich beim DR5088RC nämlich entscheiden ober man lieber Belegt- oder RailCom-Meldungen haben will. Siehe dazu auch hier: https://www.stummiforum.de/t223848f5-Digikeijs...esung-fuer-mich.html

Hier von Hr. _Drent_h_ salopp auf ZIMO zu verweisen ohne dies wohl
a) überhaupt getestet zu haben noch
b) mit uns in Kontakt getreten zu sein
finde ich übrigens höchst unprofessionell.

Bei den kleinen Spur N MS-Decodern wurde nie ein anderer Prozessor verwendet und die RailCom-Schaltung hat sich bei überarbeiteten Hardware-Revisionen auch nie geändert. Wir mussten bei diesen Decodern „nur“ auf ein anderes Flash, einen anderen Spannungsregler und ein anderes Bauteil in der Motor-H-Brücke umstellen.

LG
Markus

Wenn der Fehler so wie in #42 beschrieben mit wandert dann ist es der Decoder (inkl seiner Firmware). Ich denke Zimo wird es herausbekommen woran es liegt. Gut wenn der Kunde mehr als ein Modell zum Gegentesten hat.

Grüße,
Harald

Hallo,

wenn auch das CV Lesen schlecht bis gar nicht funktioniert, dann ist möglicherweise der Rückmelde-Strom (= zu geringer Spannungsabfall am Detector) oder das Timing grenzwertig.

Grüße,
Peter W.

Hallo Vincent

Der Fall von Steffen #42 ist mit anderen Belegtmeldern und anderer Zentrale.

Das ist nicht so. Nach dem Widerstands-Umbau ist die Empfindlichkeit brauchbar (ca. 2 mA). Die Railcom-Erkennung funktioniert weiterhin problemlos mit allen D&H-, ESU- oder Minitrix-Decodern. Näheres dazu kann dir Herr Holub sagen. Er hat bei ZIMO die Tests mit meinem umgebauten DR5088RC gemacht.

Solche Aussagen hier zu treffen ist auch nicht sonderlich professionell.
a) Ich hatte Kontakt zu KD wegen des Problems aufgenommen, ihm auch meine Anlagenbeschaltung mit Bildern übermittelt und seine Fragen dazu beantwortet. Er HAT mit Fleischmann- und Roco-Loks mit ZIMO-Werksdecodern getestet (siehe #26), sowohl mit umgebauten als auch mit nicht umgebauten DR5088RC. Daraufhin hat er sich geäußert: "Scheint die Lösung ein Update vom Zimo Decoder zu sein."
b) "Kontakt" ist eine zweiseitige Angelegenheit. Ich habe dem ZIMO-Team angeboten, den Kontakt herzustellen. Das wurde aber nicht gewünscht, man werde bei Bedarf selber Kontakt aufnehmen.

Mir bleibt nur festzustellen:
- Ich bin dem ZIMO-Team dankbar für die durchgeführten Test mit meinem Equipment. Das hat auch für mich zu zusätzlichen Tipps geführt, wie ich meinen Aufbau noch verbessern kann. Insbesondere das Anschließen des K-Kabels zur Anlage direkt am Eingang des Moduls statt am Ausgang hat eine Verbesserung gebracht.

- Sicher ist das Modul DR5088RC vom Design her nicht perfekt. Allerdings treten meine Erkennungs-Probleme nur mit ZIMO-Decodern auf.  

Dietrich

Ja ich erinnere mich, der Detector wurde von unserem Entwicklungsleiter untersucht. Unserer Ansicht nach sind die 2mA für die RailCom Erkennung allerdings zu empfindlich. Ein Firmware Update des Decoders können wir daher auch nicht in Aussicht stellen, da sich dieses Problem nicht mit Software beheben lässt.

Jetzt habe ich mal getestet. Meine erst sehr kürzlich gekaufte Fleischmann 7370011 liefert an den Roco 10808 die Adresse und Richtung zurück.

Gruss,
Steffen

Das wäre ja auch zu erwarten, bei dem Preis. Die DK Sachen, hmmm.

Grüße, Peter W

Hallo,

Update: Nach ziemlich genau 2 Wochen kam gestern mein MS590N18 aus Wien zurück. Und er funktioniert jetzt einwandfrei! Sofort nach dem Aufgleisen wird die Adresse und die Richtung über Railcom korrekt angezeigt

Auf dem Begleitschreiben steht "Software Update, Test OK". Der Decoder scheint wohl nicht getauscht worden zu sein, die FW bekam ein Update von 4.229 auf 4.254. Wahrscheinlich hat das mein Problem gelöst.

Ich freu mich, dass es zu einem guten Ende kam. Dafür ein herzliches DANKE an Zimo. Toller und schneller Support!

Cheers, Steffen

Hallo Steffen,
das freut mich für dich, wäre jetzt interessant zu erfahre ob/was Zimo geändert hat oder nicht ich habe nämlich das gleiche Problem mit einem MS590N18. Der Decoder läuft sehr gut, nur RailCom meldet so gar nichts zurück.
Eventuell kann Vincent hier weiterhelfen, was denn Zimo gemacht bzw. nicht gemacht wurde.
Die FW bekam auch ein Update von 4.229 auf 4.254.

Gruß
Günter

Grüß euch

Ja das lässt sich machen.
- 4.231.1 enthielt einen Bugfix für einen Livelock durch den diverse ID7 Nachrichten nicht mehr ausgesendet wurden
- 4.231.3 enthielt einen Bugfix dass das letzte Stopbit in Kanal 2 nicht sporadisch abgeschnitten wird
- 4.243.3 enthielt einen Bugfix dass POM Rückmeldungen ausschließlich auf POM Pakete geschickt werden

lg
Vincent