Danke Kersten, habe ich oben in die Liste mit aufgenommen.

Hallo Walter,
[quote="walther matthias" post_id=2288562 time=1620221215 user_id=26280]
Das mit den Umsetzer ist aber dann wider der gleiche Umstand , sobald Windows mal wieder ein Update macht geht es unter Umständen nicht mehr und die suche nach Treibern geht von vorne los, genau das wollte ich vermeiden mit der MC2. [/quote]
Deshalb habe ich ein Windows in einer virtuellen Maschine. Die hat nur Zugriff auf mein lokales Netzwerk.

Hallo Tobias,

wie ich geschrieben habe, ist die Sache mit dem Umsetzer eine Zwischenlösung, bis alle Anbieter von PC-Steuerungen die MC2 über TCP direkt unterstützen. Die Umsetzer sollen auf keinen Fall die Dauerlösung sein. Und wie Du aus der Liste ja sehen kannst, haben schon 3 PC-Steuerungen entsprechende Anpassungen für die MC2 gemacht.

Viele Grüße Dirk

Hallo Stummis,

gibt's noch ein paar Infos zur neuen Zentrale. Ich hatte ein bisschen mehr erwartet.
Ist das Protokoll DCC-A von Anfang an mit dabei? Gibt es ein Handbuch als PDF.
UND UND UND.

Gruß
Andreas

Hallo,

Zitat

---

gibt's noch ein paar Infos zur neuen Zentrale. Ich hatte ein bisschen mehr erwartet.

---

wie? Was genau fehlt Dir?

alle Deals incl. technischer Daten, Schnittstellenbeschreibung, GUI-Beschreibung und Making-off zur MC2 gibt es auf der [url= https://tams-online.de/epages/642f1858-c...EasyControl/mc2]Tams Webseite[/url]. Jeweils „mehr…“ anklicken.
das GUI kannst Du hier schauen: http://tams.homelinux.net/
im GUI ist DCC-A gelistet: http://tams.homelinux.net/protocol.html . Die GUI Hilfe sagt: DCC-A ermöglicht die automatische Anmeldung von Fahrzeug- und Zubehör-Decodern bei der Zentrale. Das Verfahren ist derzeit experimentell und noch nicht vollständig implementiert (Stand: März 2021).
Handbuch gibt es hier: http://tams.homelinux.net/documents/mc2_Handbuch.pdf

Grüße Dirk

Zitat

---

Hallo Stummis,

gibt's noch ein paar Infos zur neuen Zentrale. Ich hatte ein bisschen mehr erwartet.
Ist das Protokoll DCC-A von Anfang an mit dabei? Gibt es ein Handbuch als PDF.
UND UND UND.

Gruß
Andreas

---

Hi Andreas,

auf der Homepage von TAMS hast Du scheinbar noch nicht geschaut - dort findet sich das Handbuch und auch sonst viele Informationen zur MC²



Viele Grüße, Michael

Hallo Michael,

auch hier wirst du bezüglich Infos zur neuen Zentrale fündig:
https://www.bing.com/search?q=lmdfdg&for...D74747A8C834A68

Gruß
Georg

Hallo zusammen,

Zitat

---

auch hier wirst du bezüglich Infos zur neuen Zentrale fündig:

---

Immer diese Besserwessis

Zitat

---

https://www.bing.com/search?q=lmdfdg&for...D74747A8C834A68

---

Also, unter diesem Link finde ich aber keine Infos zur MC2.


Was mich viel mehr interssiert:

Ich finde ( auch bei Meta-Suchmaschinen ( versuche die Datenkrake zu vermeiden, nun gut klappt micht immer )) aktuell nichts zu DCC-A.

Hat das was mit RailCom zu tun . . . oder ist das schon wieder ein neuer Standard ? flaster:

"DCC Anmeldung" führt mich beim Suchen allerdings zum Anmeldeformular des Deutschen Camping Clubs . . . . . . da wollte ich eigentlich nicht hin.

MfG
Oliver

Zitat

---

Hat das was mit RailCom zu tun . . . oder ist das schon wieder ein neuer Standard ? flaster:

"DCC Anmeldung" führt mich beim Suchen allerdings zum Anmeldeformular des

---

Es ist ein weiterer Vorschlag zur automatischen Anmeldung von DCC-Decodern, nachdem RailCom-plus vom Nordamerikanischen Markt nicht akzeptiert wurde. Ziel soll sein, außer der Adresse, auch die wesentlichen Eigenschaften des Decoders, z.B. auch die gemappten Funktionen/Funktionstastenbelegungen des Decoders in die Zentrale/Bedieneinheit einlesen zu können.

MfG

vik

Zitat

---

Es ist ein weiterer Vorschlag zur automatischen Anmeldung von DCC-Decodern, nachdem RailCom-plus vom Nordamerikanischen Markt nicht akzeptiert wurde. Ziel soll sein, außer der Adresse, auch die wesentlichen Eigenschaften des Decoders, z.B. auch die gemappten Funktionen/Funktionstastenbelegungen des Decoders in die Zentrale/Bedieneinheit einlesen zu können.

---

Welcher decoder unterstüzt DCC-A?


Klaus

Hallo Stummis,
Ich werde langsam anscheinend Alt.
Bis gestern wurde ich bezüglich Bedienanleitung für die mc2 und auch übers DCC-A Protokoll nicht fündig. Nicht bei Tams und sonst wo .

Mfg
Andreas

Hallo Klaus,

Zitat

---

Zitat

---

Es ist ein weiterer Vorschlag zur automatischen Anmeldung von DCC-Decodern, nachdem RailCom-plus vom Nordamerikanischen Markt nicht akzeptiert wurde. Ziel soll sein, außer der Adresse, auch die wesentlichen Eigenschaften des Decoders, z.B. auch die gemappten Funktionen/Funktionstastenbelegungen des Decoders in die Zentrale/Bedieneinheit einlesen zu können.

---

Welcher decoder unterstüzt DCC-A?


Klaus

---

Ich glaube nicht, dass es da schon etwas zu kaufen gibt. Der Vorschlag ist m. W. noch nicht mal förmlich verabschiedet...

MfG

vik

Zitat

---

Hallo Stummis,
Ich werde langsam anscheinend Alt.
Bis gestern wurde ich bezüglich Bedienanleitung für die mc2 und auch übers DCC-A Protokoll nicht fündig. Nicht bei Tams und sonst wo .

Mfg
Andreas

---

Hi Andreas,

nein - die Infos sind dort schon "länger" online - nur sind sie nicht ganz so einfach zu finden.

Wenn man aber einmal auf der MC² Seite ist, liegt alles offen da.



Vieel Grüße, Michael

Zitat

---

Was mich viel mehr interssiert:

Ich finde ( auch bei Meta-Suchmaschinen ( versuche die Datenkrake zu vermeiden, nun gut klappt micht immer )) aktuell nichts zu DCC-A.

Hat das was mit RailCom zu tun . . . oder ist das schon wieder ein neuer Standard ? flaster:

---

Guten Tag,

in einer herstellerübergreifende Zusammenarbeit und mit der OpenSource-Gemeinde aus der BiDiB & Tools e.V. Ecke wurde eine schnelle, performante Anmeldung entworfen, die ohne weitere Hardwareänderung auf DCC und Railcom aufsetzt. Die Ziele sind:

• Automatische Anmeldung von Dekodern
• Schnelle Übermittlung von Fahrzeugdaten (Funktionsbelegung, Infos zur GUI-Darstellung, Motorwerte, usw.)
• Dekoderupdate ohne spezielles Programmiergerät
• Offengelegtes Verfahren, schnell und auch auf kleinen Prozessoren zu implementieren.

Zitat

---

Leider sind (aus meiner technischen Sicht) solche Abstimmungs- und Normentscheidungsprozesse immer etwas zäh, aber ich hoffe, dass wir das bald zu einer offizellen Norm kommen.

---

Noch ein Norm von Railcommunity.
Und wenn die Hersteller wider zu Hause ist, kochen sie seiner eigenen Suppe....



Klaus

Hallo,

Zitat

---

Zitat

---

Ich finde... aktuell nichts zu DCC-A.

Hat das was mit RailCom zu tun . . . oder ist das schon wieder ein neuer Standard ? flaster:

---

wurde eine schnelle, performante Anmeldung entworfen, die ohne weitere Hardwareänderung auf DCC und Railcom aufsetzt. Die Ziele sind:

• Automatische Anmeldung von Dekodern
• Schnelle Übermittlung von Fahrzeugdaten (Funktionsbelegung, Infos zur GUI-Darstellung, Motorwerte, usw.)
• Dekoderupdate ohne spezielles Programmiergerät
• Offengelegtes Verfahren, schnell und auch auf kleinen Prozessoren zu implementieren.

---

RCN-218 - https://www.opendcc.de/info/dcc/dcc_anmeldung2.html
d. h. wenn der Decoder genug Speicher hat lassen sich prinzipiell alle bisher gebauten Zentralen und jeder bisher ausgeliefert Decoder - zumindest die, die bereits DCC und Railcom beherrschen - auf DCC-A updaten, sofern der jeweilige Hersteller mitspielt?

MfG

vik

Zitat

---

Hallo,

Zitat

---

Zitat

---

Ich finde... aktuell nichts zu DCC-A.

Hat das was mit RailCom zu tun . . . oder ist das schon wieder ein neuer Standard ? flaster:

---

wurde eine schnelle, performante Anmeldung entworfen, die ohne weitere Hardwareänderung auf DCC und Railcom aufsetzt. Die Ziele sind:

• Automatische Anmeldung von Dekodern
• Schnelle Übermittlung von Fahrzeugdaten (Funktionsbelegung, Infos zur GUI-Darstellung, Motorwerte, usw.)
• Dekoderupdate ohne spezielles Programmiergerät
• Offengelegtes Verfahren, schnell und auch auf kleinen Prozessoren zu implementieren.

---

d. h. wenn der Decoder genug Speicher hat lassen sich prinzipiell alle bisher gebauten Zentralen und jeder bisher ausgeliefert Decoder - zumindest die, die bereits DCC und Railcom beherrschen - auf DCC-A updaten, sofern der jeweilige Hersteller mitspielt?

MfG

vik

---

Moin Vik,
Ich verstehe das so, dass es rein Zentralenseitig zu updaten ist. Die Decoder brauchen kein Änderungen, so sie denn DCC und Railcom können.

Hallo, [quote="Modellbahn Tamm" post_id=2291761 time=1620976018 user_id=26236]

Zitat

---

d. h. wenn der Decoder genug Speicher hat lassen sich prinzipiell alle bisher gebauten Zentralen und jeder bisher ausgeliefert Decoder - zumindest die, die bereits DCC und Railcom beherrschen - auf DCC-A updaten, sofern der jeweilige Hersteller mitspielt?

---

Moin Vik,
Ich verstehe das so, dass es rein Zentralenseitig zu updaten ist. Die Decoder brauchen kein Änderungen, so sie denn DCC und Railcom können.
[/quote]
Hauptsache, man muss nicht alle in der Anlage verbauten lokalen Railcom-Detectoren auswechseln, um die bisherigen RailCom-Rückmelde-Funktionalitäten uneingeschränkt weiter nutzen zu können!
Eigentlich benötigt man sowas wie DCC-A nur auf Anmeldegleisen, dh. i.d R. auf einem Abschnitt auf dem man z.B. auch programmiert. Auf der restlichen Anlage verursacht der mit der Anmeldung verbundene Informationsaustausch doch nur unnötigen Traffic.

MfG

vik

Hallo Stummis,

Danke für Eure Beiträge zu DCC-A. Die Info von H. KUFER und Vik hatte ich gesucht und vermißt. Jetzt wird es ein wenig klarer. Es ist die erste Info zu diesem Thema die ich erhalten habe.
Danke und ein schönes Wochenende.
ANDREAS

Hallo,

eine Sammelantwort zu aufkommenden Fragen:

Zitat

---

Noch ein Norm von Railcommunity.
Und wenn die Hersteller wider zu Hause ist, kochen sie seiner eigenen Suppe....

---

Ich finde die Arbeit der Railcommunity sehr wichtig und gut. Wenn ich mir ansehe, wie oft da die NMRA-Spezifikationen unklar oder gar in sich widersprüchlich sind ... es ist einfach gut, wenn das auf Linie gezogen wird. Und das mit der eigenen Suppe ist ein Problem, das man überall findet - außer es gibt eine strenge Zulassungsprüfstelle (die wir der bei der Modellbahn halt nicht haben). Umso wichtiger ist es, Konsens vorher herzustellen.

Zitat

---

d. h. wenn der Decoder genug Speicher hat lassen sich prinzipiell alle bisher gebauten Zentralen und jeder bisher ausgeliefert Decoder - zumindest die, die bereits DCC und Railcom beherrschen - auf DCC-A updaten, sofern der jeweilige Hersteller mitspielt?

---

Ja, es war uns extrem wichtig, dass wir das sehr einfach halten, besonders auf Dekoderseite. Es gab ausführliche Diskussionen - im Prinzip haben wir um jedes Bit gerungen. Der Prove-of-Concept hatte übrigens kleine Prozessoren mit 16k Flash mit dabei - einfach um zu zeigen, es geht mit kleinem Aufwand.

Zitat

---

Ich verstehe das so, dass es rein Zentralenseitig zu updaten ist. Die Decoder brauchen kein Änderungen, so sie denn DCC und Railcom können.

---

Nein, Dekoder werden für neue Funktionen auch neue Firmware brauchen. Von nix kommt nix. Aber es ist eben so, dass der Overhead für DCC-A nicht der Riesenaufwand ist und es sich je nach vorhandener Kapazität noch in die bisherige Plattform einbringen läßt. Auch der Codierungsaufwand ist überschaubar.

Zitat

---

Hauptsache, man muss nicht alle in der Anlage verbauten lokalen Railcom-Detectoren auswechseln, um die bisherigen RailCom-Rückmelde-Funktionalitäten uneingeschränkt weiter nutzen zu können!
Eigentlich benötigt man sowas wie DCC-A nur auf Anmeldegleisen, dh. i.d R. auf einem Abschnitt auf dem man z.B. auch programmiert. Auf der restlichen Anlage verursacht der mit der Anmeldung verbundene Informationsaustausch doch nur unnötigen Traffic.

---

Bisherige Detektoren können verbleiben und funktionieren weiterhin. Der Code-Bereich von DCC-A liegt auf einem Bereich außerhalb der Lokadressen, ein lokaler Detektor darf dort nicht auswerten.

DCC-A ist auch auf sehr kleinen 'Fußabdruck' in der eh schon knappen DCC-Bandbreite getrimmt. Von der DCC-Bandbreite her gesehen spielt es keine Rolle, ob man das nur auf einem Gleis macht oder anlagenweit.

Hallo,

Zitat

---

Ja, es war uns extrem wichtig, dass wir das sehr einfach halten, besonders auf Dekoderseite. Es gab ausführliche Diskussionen - im Prinzip haben wir um jedes Bit gerungen. Der Prove-of-Concept hatte übrigens kleine Prozessoren mit 16k Flash mit dabei - einfach um zu zeigen, es geht mit kleinem Aufwand.

---

Der Clou, insbesondere für Trix- und Minitrix-Anwender, wäre wenn sich die mLDs und mSDs auch railcomfähig und damit ebenfalls DCC-A fähig machen lassen würden, aber ob Märklin das kann? Dürfte Märklin das rechtlich eigentlich, wenn sie denn überhaupt wollten?

MfG

vik

Zitat

---

Dürfte Märklin das rechtlich eigentlich, wenn sie denn überhaupt wollten?

---

Ja. Neben diversen technische Argumenten ist es eben die mangelnde Offenheit, die bisher die Verbreitung von Verfahren behindert haben.

Zitat

---

Der Clou, insbesondere für Trix- und Minitrix-Anwender, wäre wenn sich die mLDs und mSDs auch railcomfähig und damit ebenfalls DCC-A fähig machen lassen würden, aber ob Märklin das kann? Dürfte Märklin das rechtlich eigentlich, wenn sie denn überhaupt wollten?

---

Hallo vik,
Märklin hat aus seiner Sicht alles getan. Sie haben mfx öffentlich gemacht. Jetzt sind die anderen dran. Nicht Tante M, denn sie sind ja Marktführer. So denken sie auch, wenn ich nur an das ausführliche Interview in der DiMo denke, ist alles klar.
Da können wir bis zum Sankt Nimmerleins Tag warten.
Wenn sie in ihre Loks nicht immer ihren Dekoder einbauen würden...

Hallo,

Zitat

---

wenn ich nur an das ausführliche Interview in der DiMo denke, ist alles klar.
Da können wir bis zum Sankt Nimmerleins Tag warten.
Wenn sie in ihre Loks nicht immer ihren Dekoder einbauen würden...

---

Ist zwar vielleicht etwas OT,
https://www.vgbahn.de/downloads/dimo/202...n-Interview.pdf (insbesondere Seite 34+35) ich hatte eher den Eindruck, dass die beiden Interviewpartner von Märklin, die Möglichkeiten, die eine Railcomunterstützung hinsichtlich der lokalen Rückmeldung - gerade auch für die CS3 (ggf. auch CS2) - bieten würde, bis dahin gerade gar nicht auf dem Schirm hatten, sondern ausschließlich auf den Wettbewerb bei der Anmeldeprozedur fokussierten.

Und bezüglich der Anmeldung erfüllt mfx ja auch die Anforderungen durchaus. Wer nicht gerade mfx+ nutzt, benötigt mfx ausschließlich bei der Anmeldung (und vielleicht beim Programmieren... ). Aber für eine lokale Rückmeldung ist mfx offensichtlich auch nach fast 20 Jahren nicht nutzbar/geeignet.

MfG

vik

Hallo vik,
da kann man sehen wie unterschiedlich wir die gleiche Aussage interpretieren.
Mein EIndruck bleibt, dass man sieht, das man bei Märklin ein gutes System hat, aber die Anforderung zu wissen, wo ist Lok 1234, nicht als Anforderung zu sehen.
Dass das ein Featur ist, was hauptsächlich Modellbahner wollem, die eine Anlage haben ist verständlich.
Die Teppich und Schachtelbahner scheinen kein Interesse zu haben, wobei ich bezweifele, das Märklin wirklich weiss, was ihre kunden wollen.
Wenn man sich die Produktpalette in den letzten 5 Jahren anschaut, wird offensichtlich in großem Umfang Sound gekauft, sonst gäbe die Neuheiten auch anders.
Das wäre alles nicht schlimm, hätte Märklin ja nur Märklin. Man hat nun das Pech sich an einem Markt orientieren zu sollen, der heterogener ist.
Außerdem denkt man in Komplettsystemen. Auch die Aussage, das man 10€ pro Gleisabschnitt mehr benötigt ist nicht richtig.
Das stimmt nur, wenn ich die Komponenten zusätzlich habe.
Es würde ausreichen Railcom in die Lokdecoder zu integrieren. Mehr nicht. Vielleicht noch in die CS3/CS4.
Oder Fahrzeuge anbieten, die keine Decoder haben und das den Kunden zu überlassen.
Aber es scheint wie in der Autobranche zu sein, dass sich über überteuerte Extras mehr Deckungsbeitrag erzielen lästt. Und in der Fertigung ist es deutlich einfacher nur ein Produkt herzustellen.
Wenn man sich Pko anschaut renn die auch in die Richtung alles zu separieren. Jetzt muss man sich mit den neuen smartdecodern rumschlagen.
Ich habe die V60 mit Sound gekauft. Nie wieder. Soviele Bugs und schlecht dokumentiert. So war es am Anfang. Immerhin gibt es die Modelle noch ohne Decoder.
Möchte die Branche überleben (Corona ist da die Ausnahme) muss die Zusammenarbeit zwischen den Herstellern vergrößeert werden.
Immerhin ist die Tams MC2 die erste Zentrale, an die ich verschiedene Welten anschliessen kann.
Abwärtskompatibel ist ja sehr wichtig. Wir wollen ja alle unsere Loks auch in zwanzig Jahren noch fahren.
Die neue Tams MC2 ein Schritt in die richtige Richtung.
Nur das kein Mißverständnis aufkommt: mfx/mfx+ ist nicht schlechter oder besser als DCC.
Der Märklinkunde kennt halt kein Railcom und die Möglichkeiten, die es bietet.
Ich baue gerade eine BiDiB-Anlage und da helfen mir zwei Freunde (Märklinisten) und die fragen sich, warum die CS3 nicht weiß, was wo auf der Schiene steht.
Das will ich auch.
Dann muss man Märklin schreiben, warum das mit ihrer Zentrale nicht geht und wann das kommt.
So jetzt habe ich genug geschwallt.
Ich wünsche euche einen schönen Sonntag und eine Stummifreie Woche, ach ja lesen kann man ja noch.
Bin mal gespannt wie das "neue" Forum aussieht und was es kann, aber das ist eine andere Geschichte....