MäTrix Decoder 60996 - Erfahrungen? Railcom unter mfx!

#51 von vikr , 21.09.2023 11:22

Hallo,

Zitat von bleudeur im Beitrag #50
ist bekannt, was der neue Decoder auf Kanal 2 alles unterstützt? Nur Ack (=Adressmeldung) oder auch PoM, Rückmeldung tatsächliche Geschwindigkeit, etc.?

Du meinst jetzt im reinen DCC-Modus?
Ja man kann per PoM auf jeden Fall alle CVs auslesen.
QoS und Geschwindigkeitsmeldung habe ich nicht wirklich drauf geachtet, aber soweit ich mich erinnere tauchten da tatsächlich im z21-maintenancetool in der Tabelle des Railcom-Monitors irgendwelche Werte auf....

MfG

vik

#52 von Flo_85 , 21.09.2023 12:14

Zitat von vikr im Beitrag #43
Noch besser wäre es natürlich, wenn auch in (zwischen) den mfx-Paketen der Zentrale zukünftig solche "RC- Lücken" wären.

Das wäre aber alles andere als Normgerecht. Und die Decoder würden, wenn RC korrekt implementiert ist, diese Lücke wohl auch gar nicht als Railcom Lücke erkennen. Denn die RC Lücke beginnt 29µs nach dem Endebit einer DCC Nachricht. So ist es in der Norm definiert und danach müssen sich die Decoder richten. Um das zu realisieren was du möchtest müsste man nach jeder mfx Nachricht eine DCC Nachricht senden - das kann auch eine Dummynachricht sein - um danach eine korrekte RC Lücke einzubauen. Das hat aber zum einen den Nachteil das man sehr viel Bandbreite am Gleis verbraucht und zum anderen das nur Kanal 1 genutzt werden kann - denn Kanal 2 darf nur jener Decoder nutzen der in der davorliegenden DCC Nachricht angesprochen wurde - und das ist bei einer Dummynachricht keiner.

Eine inkorrekte Lücke hinter einer mfx Nachricht könnten Decoder auch als Analogsignal interpretieren und - sofern aktiviert - in den Analogmodus wechseln.

#53 von vikr , 21.09.2023 14:39

Hallo Flo,

Zitat von Flo_85 im Beitrag #52
Das wäre aber alles andere als Normgerecht

von welcher Norm sprichst Du?

Die RailCom-Lücke ist bisher nur innerhalb des DCC-Protokolls definiert und dort innerhalb der Präambel eines DCC-Paketes und zwar nach dem Paket_End_BIT des vorherigen DCC-Paketes, nicht nur bei einem Umschalten in ein anderes Protokoll.
Wenn ein mfx-Decoder in einer Multiprotokoll-Umgebung in die Railcom-Lücke innerhalb einer DCC-Nachrichten-Sequenz etwas hineinschreibt, ist das sehr unüblich, allerdings auch nirgends verboten. So funktionieren die sogenannten Sende Module (ESU, Lenz, Tams) ebenfalls. Im Kanal 1 macht das keine, oder zumindest keinerlei zusätzlichen Probleme. Im Abschnitt eines RailCom-Detektors darf sich nur ein Decoder befinden, damit Kanal-1-Nachrichten korrekt erkannt werden können. Für Kanal-2-Nachrichten gilt das nicht. Hier würde der mfx-Decoder gewissermaßen in Konkurrenz mit den Railcom-fähigen DCC-Decoder um die RailCom-Lücken während der DCC-Pakete treten.

Wenn es eine mfx-Norm gäbe, könnten natürlich u. U. auch in die mfx-Pakete entsprechende 440 Microsekunden lange Lücken geschnitten werden. Eine andere Frage ist, ob diese Lücken für bisherige RailCom-Detektoren und die bisherigen Railcom-fähigen Decoder erkennbar und nutzbar wären.

Mir ist das an einem 60996 Märklin-Decoder aufgefallen, der zunächst in einer Lok als reiner DCC-Decoder mit Aktivierung von Railcom (Deaktivierung von mfx) konfiguriert worden war und an einer ECoS betrieben wurde. Dort verhielt er sich völlig normenkonform. Insbesondere konnte die DCC-Adresse im Gleisbild der ECoS mit angeschlossenem ECoS-Detektor angezeigt werden.
Nach Reaktivierung von mfx im Decoder hatte ich erwartet, dass - wie bei den ESU-Decodern - das Senden von Railcom-Nachrichten unterdrückt wird. Um so überraschter war ich, dass der Decoder auch im mfx-Betrieb weiter RailCom-Kanal-1 Nachrichten schrieb, sich also wie ein mfx-Decoder mit zusätzlich eingebautem Sendemodul verhält.

Es verstößt also weder gegen die bisherige DCC/Railcom-Norm, noch gegen eine - zumindest bisher (noch) nicht existierende - mfx-Norm.
Nochmal: Der Kanal 1 innerhalb von Railcom-Lücken ist gemeinfrei nutzbar mit dem Nachteil, dass man dort u.U. gar nichts versteht, wenn im selben lokalen Detektorabschnitt mehrere gleichzeitig senden. Das war aber schon immer so.

MfG

vik

#54 von Flo_85 , 21.09.2023 17:38

Zitat von vikr im Beitrag #53
von welcher Norm sprichst Du?

Von jener für Railcom. Also die RCN-217.

Zitat von vikr im Beitrag #53
Für Kanal-2-Nachrichten gilt das nicht. Hier würde der mfx-Decoder gewissermaßen in Konkurrenz mit den Railcom-fähigen DCC-Decoder um die RailCom-Lücken während der DCC-Pakete treten.

Genau das verbietet die Norm für Railcom, es darf nicht einfach jeder Decoder in einer x belibigen RC Lücke Kanal 2 nutzen, sondern nur jener der in der DCC Nachricht zuvor angesprochen wurde. Da ein mfx Decoder aber nie eine an ihn adressierte DCC Nachricht erhält, darf er auch nie im Kanal 2 senden. Siehe 4.1 der Norm:

"Der Decoder darf keinesfalls antworten, wenn
er nicht adressiert wurde oder der Befehl an die Broadcast-Adresse 0 gesendet wurde."

#55 von vikr , 21.09.2023 17:40

Hallo Florian,

Zitat von Flo_85 im Beitrag #54
Genau das verbietet die Norm für Railcom, es darf nicht einfach jeder Decoder in einer x belibigen RC Lücke Kanal 2 nutzen, sondern nur jener der in der DCC Nachricht zuvor angesprochen wurde. Da ein mfx Decoder aber nie eine an ihn adressierte DCC Nachricht erhält, darf er auch nie im Kanal 2 senden. Siehe 4.1 der Norm:

"Der Decoder darf keinesfalls antworten, wenn
er nicht adressiert wurde oder der Befehl an die Broadcast-Adresse 0 gesendet wurde."

Genau deshalb wurde Kanal 2 vermutlich bei den neuen mSDs auch von Märklin im mfx-Betrieb abgeschaltet!

Das gilt aber eben nicht für Kanal 1!
Zur Erinnerung, in Kanal 1 plaudert der Decoder ungefragt (unadressiert) kontinuierlich seine Adresse aus (wenn Kanal 1 erstmal grundsätzlich eingeschaltet ist und auch nicht nach einer Qittierung wieder automatisch ausgeschaltet wird, damit ein anderer Decoder auf Kanal 1 erhört werden kann) . Auch die automatische Kanal-1-Ausschaltung über CV 28 Bit 2, scheint Märklin - im reinen DCC-Betrieb - RCN-217 konform implementiert zu haben....

MfG

vik

#56 von Flo_85 , 22.09.2023 17:24

Zitat von vikr im Beitrag #55

Das gilt aber eben nicht für Kanal 1!

Schon, nur der Nutzen des Kanal 1 ist doch arg beschränkt. Selbst mit Local Detectoren kann man Decoder damit nur erfassen wenn kein 2. Deocder mit RC im Abschnitt ist. Reicht also gerade für rudimentärste Adresserfassung. Und dafür dann eine eigene Austastlücke nach Mfx Nachrichten? Für mehrere Decoder in einem Abschnitt oder POM-Lesen, ACK senden etc. braucht es eine Kanal 2 Auswertung.

Es gäbe ja noch eine andere Möglichkeit: Nachdem Märklin ja jetzt DCC und RC in den Decodern hat könnte man noch DCC-A für die automatische Plug an Play Anmeldung implementieren - dann brauchts für zukünftige Modelle gar kein mfx mehr und die volle RC Funktionalität ist auch gegeben.

Aber das wäre wohl schon eine kleine Sensation wenn Märklin es zulässt das man eine Roco, Brawa etc. Lok genauso leicht, und vor allem ohne Einschränkungen wie bei Fits mfx, in die eigene Welt integrieren lässt wie die eigenen Modelle.

#57 von vikr , 23.09.2023 18:04

Hallo Florian,,

ich finde das schon mal einen guten Kompromiss, den Märklin da - anscheinend ganz beilãüfg gefunden hat.
Technisch hätte man das schon vor knapp zwanzig Jahren so lösen können. Um es zu vermarkten, hätte man sich halt zwingend irgendwie mit Lenz einigen müssen.
Hätte Märklin das schon in ihren ersten mLDs/mSDs seit 2011 technisch berücksigt, könnte man jetzt - nach Auslaufen der Patente -- einfach mit einem Firmware-Update alle bisher ausgelieferten mXDs, zumindest alle als Nachrűst-Decoder ausgelieferten mXD3 railcomfähig machen.

MfG

vik

#58 von Railwolf , 25.09.2023 21:44

Zitat von Flo_85 im Beitrag #56
Es gäbe ja noch eine andere Möglichkeit: Nachdem Märklin ja jetzt DCC und RC in den Decodern hat könnte man noch DCC-A für die automatische Plug an Play Anmeldung implementieren - dann brauchts für zukünftige Modelle gar kein mfx mehr und die volle RC Funktionalität ist auch gegeben.

Aber das wäre wohl schon eine kleine Sensation wenn Märklin es zulässt das man eine Roco, Brawa etc. Lok genauso leicht, und vor allem ohne Einschränkungen wie bei Fits mfx, in die eigene Welt integrieren lässt wie die eigenen Modelle.

Hallo Flo,

was du da erwartest, ist nicht "Roco oder Brawa in die Märklin-Welt integrieren", sondern "Märklin an Lenz/ESU anpassen". Das ist ungefähr so wahrscheinlich, wie ein iPhone mit Android-Betriebssystem.
Roco oder Brawa (die beide keine eigenen Decoder herstellen, sondern zukaufen) werden in die Märklin-Welt integriert, indem man ihnen einen mfx-tauglichen Decoder (also nicht piko...) einsetzt.

Außerdem ist mfx nicht so obsolet, wie es einige Kollegen ansehen, denn mfx ist bei weitem nicht nur die automatische Anmeldung. Die interessiert eigentlich nur am Rande - viel interessanter ist es, einen Decoder mit mfx statt mit CV-Nummernorgien einzustellen. Spielewelt hab ich nie ausprobiert, interessiert mich auch nicht, scheint aber ein wichtiges Element für viele Kunden zu sein, und das kann DCC nicht heute, nicht morgen und nicht nächstes Jahr.

#59 von Flo_85 , 26.09.2023 10:32

Zitat von Railwolf im Beitrag #58

Roco oder Brawa (die beide keine eigenen Decoder herstellen, sondern zukaufen) werden in die Märklin-Welt integriert, indem man ihnen einen mfx-tauglichen Decoder (also nicht piko...) einsetzt.

Nur das halt alle mfx fähigen Decoder die nicht von märklin oder ESU kommen mit Einschränkungen belegt sind. Umgekehrt ist das nicht der Fall.

Zitat von Railwolf im Beitrag #58
... viel interessanter ist es, einen Decoder mit mfx statt mit CV-Nummernorgien einzustellen.

Ob man den Decoder über CVs oder eine grafische Oberfläche einstellt hat doch nichts mit dem Protokoll zu tun. Man kann auch DCC Decoder programmieren und einstellen ohne eine CV wissen zu müssen.

Zitat von Railwolf im Beitrag #58
Spielewelt hab ich nie ausprobiert, interessiert mich auch nicht, scheint aber ein wichtiges Element für viele Kunden zu sein, und das kann DCC nicht heute, nicht morgen und nicht nächstes Jahr.

Auch das ist nichts was irgendwie vom Protokoll abhängig wäre - das ist eine Sache der Steuerung. Roco hat auch soetwas in der z21 App.

#60 von Railwolf , 27.09.2023 13:20

Zitat von Flo_85 im Beitrag #59
Zitat von Railwolf im Beitrag #58

Roco oder Brawa (die beide keine eigenen Decoder herstellen, sondern zukaufen) werden in die Märklin-Welt integriert, indem man ihnen einen mfx-tauglichen Decoder (also nicht piko...) einsetzt.

Nur das halt alle mfx fähigen Decoder die nicht von märklin oder ESU kommen mit Einschränkungen belegt sind. Umgekehrt ist das nicht der Fall.

Das ist ja nebensächlich. Es geht um deine Denkrichtung. Die ist falsch herum. Komponenten aus System A werden in System B integriert, indem die Komponenten an System B angepaßt werden, und nicht indem System B sich auf System A umstellt. Aus ganz praktischer Erfahrung kann ich dir sagen: wenn du dich in einem Ort integrieren willst, dann lernst du die Sprache, gegebenenfalls auch den örtlichen Dialekt, und trinkst das Bier, das da alle trinken. Du wirst nicht erwarten, daß die Leute dort deinen Dialekt lernen, und wirst auch nicht versuchen, einen Kölner zum Altbier zu bekehren.
Wer sich also in die Märklin-Welt integrieren will, lernt mfx und erwartet nicht von der Märklin-Welt, Railcom+ zu verwenden. Wer Loks anderer Hersteller in die Märklin-Welt integrieren will, baut einen mfx-tauglichen Decoder ein.

Zitat von Flo_85 im Beitrag #59
Zitat von Railwolf im Beitrag #58
... viel interessanter ist es, einen Decoder mit mfx statt mit CV-Nummernorgien einzustellen.

Ob man den Decoder über CVs oder eine grafische Oberfläche einstellt hat doch nichts mit dem Protokoll zu tun. Man kann auch DCC Decoder programmieren und einstellen ohne eine CV wissen zu müssen.

Doch, das hat in dem Fall schon mit dem Protokoll zu tun. Für DCC geht das nur mit Computerprogrammen (im weiteren Sinn), die eine grafische Oberfläche darstellen und dann, decoderspezifisch, in CV übersetzen. In der mfx-Welt ist das integriert - hast du eine mfx-Zentrale und einen mfx-Decoder, dann brauchst du dir gar keine Gedanken zu machen. Und wenn du einen mfx-Decoder von einem anderen Hersteller benutzt - der ist auch so programmierbar. (Außer bei piko, aber deren "mfx-fähig" ist ja auch eine abmahnfähige Werbelüge.) Außerdem kommunizieren mfx-Decoder anders mit der Zentrale und können darum mehr Informationen als nur Zahlen zurückgeben.
Ich hab mir DCC-A angeguckt - das ist eine Art PlugIn in DCC, um nach 15 Jahren eine Funktionalität der CS2 in DCC zu implementieren, von der die DCC-Jünger seit 15 Jahren sagen, wie unnötig sie doch sei... genau wie damals, als mfx auf einmal 14 Funktionen schalten konnte. "Braucht man nieeee!" haben die DCCler gesagt. Wie sich die Dinge wiederholen.
Aber DCC-A ist ein PlugIn. Das können nur wenige, und da muß man's auch erst ins System nachrüsten. Bei mfx ist es von Anfang an angelegt.

Zitat von Flo_85 im Beitrag #59
Zitat von Railwolf im Beitrag #58
Spielewelt hab ich nie ausprobiert, interessiert mich auch nicht, scheint aber ein wichtiges Element für viele Kunden zu sein, und das kann DCC nicht heute, nicht morgen und nicht nächstes Jahr.

Auch das ist nichts was irgendwie vom Protokoll abhängig wäre - das ist eine Sache der Steuerung. Roco hat auch soetwas in der z21 App.

Ach ja?
Lies mal hier:
https://www.maerklin.de/de/produkte/prod...n-steuerung/mfx

Zitat
Die Daten über den Füllstand der Betriebsstoffe werden übrigens in der Lok abgespeichert. Wird die Lokomotive beispielsweise im Verein oder bei einem Freund auf dessen Central Station mit Firmware-Version 2.5 angemeldet, stehen die Daten auch dort nach der Anwahl des gewünschten Spielmodus direkt wieder als Ausgangszustand zur Verfügung.

Das ist nicht "Sache der Steuerung", sondern Sache der Kommunikation zwischen Zentrale und Decoder - also Protokoll.

Es sagt ja keiner, daß DCC schlecht ist. Aber hört doch bitte endlich auf, so zu tun, als wäre DCC der einzige Heilsbringer. DCC ist nicht die römische Kirche, und Modellbahn ist keine Religion!

#61 von Flo_85 , 27.09.2023 14:15

Zitat von Railwolf im Beitrag #60

Komponenten aus System A werden in System B integriert, indem die Komponenten an System B angepaßt werden, und nicht indem System B sich auf System A umstellt.
Wer sich also in die Märklin-Welt integrieren will, lernt mfx und erwartet nicht von der Märklin-Welt, Railcom+ zu verwenden.

Das was du hier verlangst funktioniert nicht solange Märklin die dafür notwendigen technischen Informationen fast vollständig unter Verschluss hält!

Mal abgesehn davon erwarte ich nicht das Märklin RC+ verwendet - was im Übrigen ein Feature von ESU ist - sondern habe lediglich in den Raum geworfen das es mit den neuen Decodern die Möglichkeit gäbe DCC-A zu implementiern (da ist nicht das gleiche) - und das auch mit dem Zusatz das ich es für nicht sehr wahrscheinlich halte.

Zitat von Railwolf im Beitrag #60
Außerdem kommunizieren mfx-Decoder anders mit der Zentrale und können darum mehr Informationen als nur Zahlen zurückgeben.

Sorry, aber du solltest dir mal anschauen wie Digitaltechnik funktioniert. Dort läuft alles über 2 Zahlen: 0 und 1 - auch bei mfx. Als was diese Zahlen letztendlich interpretiert werden ist Sache der Software.

Genau wie bei DCC-Decodern und zig anderen elektronischen Produkten sind auch bei mfx alle in Prozessoren gespeicherte Informationen nichts anderes als eine Zahlenfolge von 0en und 1sen. Völlig egal ob es sich dabei um irgendwelche Krafstofffüllstände oder Informationen zur Konfiguration sind. Das sind alles in Speichern abgelegt Bits und Bytes - also Zahlen.

Der Unterschied, am Beispiel der Programmierung, zwischen DCC und mfx ist das Märklin die Zahlenwerte im Hintergrund nicht direkt zugänglich macht während man bei DCC diese Werte auch direkt lesen und schreiben kann, mit jedem Gerät das Servicemode oder POM Programmierung unterstützt.

Oder bei der Spielewelt: Ob man den Krafstofffüllstand (oder anderen Informationen) jetzt per POM in den Decoder schreibt und per RC liest oder über mfx macht für die Funktionalität ansich keinen Unterschied. Es ist da wie dort einen Zahlenwert der im Speicher des Prozessors abgelegt ist.

#62 von vikr , 27.09.2023 15:56

Hallo,,

Zitat von Railwolf im Beitrag #60
Es geht um deine Denkrichtung. Die ist falsch herum.

???

Zitat von Railwolf im Beitrag #60
Wer sich also in die Märklin-Welt integrieren will, lernt mfx und erwartet nicht von der Märklin-Welt, Railcom+ zu verwenden. Wer Loks anderer Hersteller in die Märklin-Welt integrieren will, baut einen mfx-tauglichen Decoder ein.

ich weiß nicht! Beschreitet Märklin selbst - seit 2008 mit der Integration von DCC in die CS2 und seit 2011 in das eigene Decoder-Portfolio - nicht den umgekehrten Weg? Jetzt auch noch konsequenterweise dazu Railcom! "Weil es der internationale Markt anscheinend so will"?

MfG

vik

Beiträge:	6.428
Registriert am:	23.10.2011
Gleise	M, C u. K.
Spurweite	H0, N
Stromart	Digital, Analog

Beiträge:	1.217
Registriert am:	06.04.2017
Gleise	Roco Line
Spurweite	H0
Steuerung	BiDiB/iTrain
Stromart	Digital

Beiträge:	6.428
Registriert am:	23.10.2011
Gleise	M, C u. K.
Spurweite	H0, N
Stromart	Digital, Analog

Beiträge:	1.217
Registriert am:	06.04.2017
Gleise	Roco Line
Spurweite	H0
Steuerung	BiDiB/iTrain
Stromart	Digital

Beiträge:	6.428
Registriert am:	23.10.2011
Gleise	M, C u. K.
Spurweite	H0, N
Stromart	Digital, Analog

RE: MäTrix Decoder 60996 - Erfahrungen?

RE: MäTrix Decoder 60996 - Erfahrungen?

RE: MäTrix Decoder 60996 - Erfahrungen?

RE: MäTrix Decoder 60996 - Erfahrungen?

RE: MäTrix Decoder 60996 - Erfahrungen?

RE: MäTrix Decoder 60996 - Erfahrungen?

RE: MäTrix Decoder 60996 - Erfahrungen?

RE: MäTrix Decoder 60996 - Erfahrungen?

RE: MäTrix Decoder 60996 - Erfahrungen?

RE: MäTrix Decoder 60996 - Erfahrungen?

RE: MäTrix Decoder 60996 - Erfahrungen?

RE: MäTrix Decoder 60996 - Erfahrungen?

Bitte geben Sie einen Grund für die Verwarnung an

Beiträge:	2.668
Registriert am:	08.07.2019
Gleise	alle Arten von Skipiste
Spurweite	H0
Steuerung	tams RedBox
Stromart	AC, Digital