Zitat von supermoee im Beitrag #23

---

Zitat von drum58 im Beitrag #15

---

Hallo Stephan,
der entscheidende Unterschied ist, dass Brawa dokumentiert, Märklin hingegen den Kunden absichtlich dumm hält, damit er nicht fremdgeht (also einen anderen Decoder nutzt).

---

Hallo Werner
Verstehe das nicht ganz. Märklin hat doch die Lok inkl. Dekoder verkauft und hat das Geld verdient. Was interessiert Märklin, wenn ein Kunde danach "fremdgeht"? Deine Argumentation mit der Absicht hält nicht.
Gruss
Stephan

---

Hallo Werner,
soweit ich mich erinnere ist das Problem mit dem Esu LokSound, dass es Esu nicht erlaubt eine SUSI-Funktion fahrtrichtungsabhängig zu schalten. Das ist ein Mangel des Esu-Decoders, kein Mangel der SUSI-Implementierung von Märklin.

LG
Lauenstein

Zitat von drum58 im Beitrag #26

---

sondern sogar durch geschicktes Design verhindert wird, dass der (schon bezahlte) Decoder gegen ein anderes Fabrikat getauscht wird. Und das soll keine Absicht sein?
Wird auch nicht besser, wenn ESU (z.B. in LS-Loks) und inzwischen PIKO das nachmachen.

---

Übrigens reicht ein Blick in das frei erhältliche mDecoderTool3 um zu sehen, dass beim Decoder-Projekt des Schosch (39027) F1 u.a. auf SUSI F0 gemapped ist. Ebenso kann man dort sehen, dass SUSI F0 nur bei Vorwärtsfahrt aktiv ist.

Wenn nun ESu auch im Jahr 2023 beim LokSound 5 nicht in der Lage ist, eine SUSI-Funktion in Abhängigkeit von der Fahrtrichtung zu schalten, dann ist das ein schwerer Mangel der Esu Decoderfirmware, aber hat rein gar nichts mit irgendwelchen Verschwörungen zu tun.

LG
Lauenstein

Zitat von Lauenstein im Beitrag #29

---

Wenn nun ESu auch im Jahr 2023 beim LokSound 5 nicht in der Lage ist, eine SUSI-Funktion in Abhängigkeit von der Fahrtrichtung zu schalten, dann ist das ein schwerer Mangel der Esu Decoderfirmware, aber hat rein gar nichts mit irgendwelchen Verschwörungen zu tun.

---

Zitat von Dampfstoß im Beitrag #30

---

Zitat von Lauenstein im Beitrag #29

---

Wenn nun ESu auch im Jahr 2023 beim LokSound 5 nicht in der Lage ist, eine SUSI-Funktion in Abhängigkeit von der Fahrtrichtung zu schalten, dann ist das ein schwerer Mangel der Esu Decoderfirmware, aber hat rein gar nichts mit irgendwelchen Verschwörungen zu tun.

---

Naja Moment: Nicht der Decoder schaltet die SUSI-Ausgänge richtungsabhängig sondern das macht das SUSI-Modul. Der Decoder muss das Richtungsbit in den Geschwindigkeitsbefehlen übermitteln und das Erweiterungsmodul schaltet dann entsprechend. Macht der Decoder das nicht, dann kann das Modul die Richtung nicht feststellen und das Schalten der Ausgänge funktioniert dann nicht.

---

Hallo,

inzwischen ist SUSI ja standardisiert ("genormt"): RCN-600 (und RCN-601).
https://www.railcommunity.org/index.php?...id=49&Itemid=61
Hersteller, die sich bei aktuellen und zukünftigen Produkten daran halten, können - statt einer eigenen Dokumentation - einfach darauf verweisen. Bei früher erschienene Produkten, sollte man als Modellbahner auf die gesonderte Dokumentation achten oder ggf. diese Produkte vielleicht sogar besser meiden.

Irgendwie sollte aber auch klar sein, dass sich ältere Implementierungen von SUSI, noch nicht an die erst kürzlich konsentierten Standards halten können/konnten.
Von Märklinmitarbeitern kennt man die Äußerung, wir halten uns an Standards, weil wir sie i. d. R. selbst gesetzt haben. Aber wie man an DCC sieht, hält sich Märklin durchaus auch an von Mitbewohnern erarbeitete Standards!

MfG

vik

Zitat von Lauenstein im Beitrag #31

---

Nein, das SUSI-Modul hat indiesem Fall einen Ausgang, der über SUSI F0 angesprochen wird. Der Decoder schaltet den SUSI-Ausgang bei Decoder-F0 vorwärts ein und bei Decoder-F0 rückwärts aus.

Das SUSI-Modul wertet in diesem Fall keine Fahrtrichtung aus, weil der Ausgang vom Decoder geschaltet wird.

---

Zitat von Lauenstein im Beitrag #25

---

Hallo Hubert,

Zitat von hu.ms im Beitrag #24

---

Wenn nur verstärkt die susi-elektronik eingesetzt wird, wird dies erheblich schwieriger da neben den decododern auch platinen getauscht werden müssen mit umfangreicher neuverkabelung.

---

i.d.R. kann die SUSI-Platine von jedem Decoder unterstützt werden, der sich an die SUSI-Norm hält. Ein Austausch der Lokplatine ist daher nicht notwendig.
LG Lauenstein

---

Hallo Hubert,

Zitat von hu.ms im Beitrag #34

---

Dann liegt es am hersteller der lok und am hersteller des decoders, dass sie alles sauber dokumentieren was wie funktionert damit man den decoder entsprechend dem modell einstellen kann.
Genau das kann ich aber z.b. bei mä 39520 nicht feststellen. Deshalb bleibt meine vermutung des konkurrenzausschlussversuchs bestehen.

Hubert

---

Geht doch :-)

Zitat von Dampfstoß im Beitrag #33

---

Wie soll das gehen? SUSI ist in der Standard-Definition eine Ein-Richtungs-Schnittstelle (sonst wäre es SUSI BiDi). Der Decoder sendet Geschwindigkeiten und Funktionen und zwar immer und routet diese einfach vom DCC durch. Das SUSI Modul sieht die Funktion F0 und eine Geschwindigkeit, in der das Richtungsbit gesetzt ist oder nicht. Wenn der Decoder die Funktion F0 selber von der SUSI-Schnittstelle ´runter nimmt, weil er rückwärts fährt, dann ist das nicht der Norm entsprechend. Der Decoder darf die Nummer der gesendeten Funktuionen einschränken, um SUSI Datenverkehr zu sparen, aber wenn DCC eine der zum Senden erlaubten Funktion aktiviert, muss diese auch als aktiv auf dem SUSI erscheinen, so lange sie im DCC aktiv ist. Das hat so rein gar nichts mit der Richtung zu tun, die gerade anliegt. Dann hat ESU in der Tat was verpeilt.

---

Ja, habe ich verstanden. Ist aber normwidrig. Zumindest bis jetzt. Damit überlagert ein decoderinternes Mapping das des externen Moduls. Das ist blöd.

Edit: Insofern macht ESU das richtig und Märklin nimmt wieder eine Sonderstellung ein. Richtungen werden über das betreffende Bit kodiert und nicht über separat per Richtung zu- oder weggeschaltete Funktionen. Ein SUSI-Modul MUSS die Fahrtrichtung auswerten können.

Hallo,

Zitat von Dampfstoß im Beitrag #38

---

Ja, habe ich verstanden. Ist aber normwidrig. Zumindest bis jetzt. Damit überlagert ein decoderinternes Mapping das des externen Moduls. Das ist blöd.

Edit: Insofern macht ESU das richtig und Märklin nimmt wieder eine Sonderstellung ein. Richtungen werden über das betreffende Bit kodiert und nicht über separat per Richtung zu- oder weggeschaltete Funktionen. Ein SUSI-Modul MUSS die Fahrtrichtung auswerten können.

---

Das sagt die Norm:

Die Datenbytes sind im Grundsatz von den DCC-Befehlen der [RCN-212] und [RCN-214]
abgeleitet. Dies ermöglicht eine sehr einfache Weiterleitung von DCC-Befehlen an Slave-
Module.

Da steht nichts von Mapping im Decoder. Da steht auch nicht, dass der Decoder das nicht vor der Ausgabe mappen darf. Aber was nicht ausdrücklich erlaubt ist, ist mit Vorsicht zu genießen.
Das Modul in der Lok muss das Richtungsbit auswerten und entsprechend handeln können. Wenn ich keinen Märklin-Decoder drin habe, sollte das Modul trotzdem in der Lage sein, bei einem Fahrtrichtungswechsel die Lichter passend zu schalten. Dafür gibt es dann im Modul ein Mapping. Auch dieses kann, je nach Hersteller, komplexe Möglichkeiten bieten. Die maximale Kompatibilität erreicht man, wenn der Decoder eben nicht mappt, sondern alle Befehle unverändert durchreicht. Das mag Märklin vielleicht anders sehen. Wenn sie nicht wollen, dass ein Decoder eines anderen Herstellers in ihren Fahrzeugen verwendet werden kann, dann sollen sie diesen doch komplett auf die Platine integrieren und die Schnittstelle ´rauswerfen. Dann werden sie schon sehen, wie die Kunden damit umgehen.

Zitat von Dampfstoß im Beitrag #40

---

Das sagt die Norm:

Die Datenbytes sind im Grundsatz von den DCC-Befehlen der [RCN-212] und [RCN-214]
abgeleitet. Dies ermöglicht eine sehr einfache Weiterleitung von DCC-Befehlen an Slave-
Module.

Da steht nichts von Mapping im Decoder. Da steht auch nicht, dass der Decoder das nicht vor der Ausgabe mappen darf. Aber was nicht ausdrücklich erlaubt ist, ist mit Vorsicht zu genießen.
Das Modul in der Lok muss das Richtungsbit auswerten und entsprechend handeln können.

---

Hallo zusammen,

interessant wie ein Thema mal wieder in "Märklin gegen den Rest der Welt" (oder umgekehrt) abdriftet.

Ausgangspunkt war die Frage von Hubert, was von immer mehr SUSI-Lösungen gehalten wird. Dabei ging es nicht um irgendeine konkrete Lok oder Firma.

Ich bin wie Hubert der Meinung, dass SUSI in den meisten Fahrzeugen nicht erforderlich ist, wenn man Decoder mit entsprechender Schnittstelle verwendet und die Schnittstelle auch ausnutzt.
Und wenn man SUSI nutzt, dann gehört das sauber und allgemeinverständlich dokumentiert, ein Verweis auf eine Norm hilft nicht weiter und ein bestimmtes Tool das die entscheidenden Informationen verschleiert oder gleich gar nicht anzeigt hilft da auch nicht. Das ist eben kein Märklin-Thema, Brawa oder Piko sind da genauso beteiligt, mit dem Unterschied, dass Brawa in der Anleitung dokumentiert und Piko (zumindest früher) auf Anfrage wenigstens die Doku herausrückt.

Übrigens ging es beim Schorsch (damaliger Post von Stephan/digitalo) gerade nicht um einen ESU-Decoder, sondern um einen von ZIMO, der aber auch nicht in der Lage ist das Licht sauber anzusteuern nur weil man das völlig unsinnig über SUSI statt ganz einfach und normgerecht über F0f und F0r macht.

Gruß
Werner

@Lauenstein Wenn es so wäre wie Du sagst, würde kein einziges Soundmodul keines Herstellers funktionieren. Ich bin ´raus aus dieser Diskussion.

Hallo Werner,

Zitat von drum58 im Beitrag #42

---

Und wenn man SUSI nutzt, dann gehört das sauber und allgemeinverständlich dokumentiert, ein Verweis auf eine Norm hilft nicht weiter und ein bestimmtes Tool das die entscheidenden Informationen verschleiert oder gleich gar nicht anzeigt hilft da auch nicht.

---

Zitat von drum58 im Beitrag #42

---

Übrigens ging es beim Schorsch (damaliger Post von Stephan/digitalo) gerade nicht um einen ESU-Decoder, sondern um einen von ZIMO, der aber auch nicht in der Lage ist das Licht sauber anzusteuern nur weil man das völlig unsinnig über SUSI statt ganz einfach und normgerecht über F0f und F0r macht.

---

Hauptsache Märklin kann alles und die anderen können nix. Freu Dich und lass uns in Ruhe!

Über Susi wir im Prinzip, wie schon X-fach geschrieben, im großen und ganzen nur der DCC-Datenstrom durchgereicht. Damit hat dann der/die Slave-Decoder klarzukommen. Die Auswertung obliegt dann dem Slave-Decoder. Diese werden typischerweise über eigene CVs konfiguriert, diese sind dann vom jeweiligen Hersteller zu dokumentieren. Machen MäTrix das nicht ist das für mich ein Argument diesen Hersteller zu meiden.
Aber: Bei einem simplen Decodertausch sollte eigentlich gar nichts passieren, wie gesagt: Susi reicht nur durch, der ja schon konfigurierte Susi-Decoder sollte das ohne Änderungen weiterhin auswerten. Hab bei einem Susi-Soundmodul mit F-Ausgängen diese in der Konfiguration auf die gleiche Funktion wie einen der Decoder-Ausgänge gelegt, die haben anstandslos parallel gearbeitet. Hintergrund war hier ein gegrillter F-Ausgang am Decoder, allerdings habe ich den in der Konfiguration des Decoders nicht deaktiviert oder sonst wie umkonfiguriert.

Zitat von Lauenstein im Beitrag #27

---

soweit ich mich erinnere ist das Problem mit dem Esu LokSound, dass es Esu nicht erlaubt eine SUSI-Funktion fahrtrichtungsabhängig zu schalten. Das ist ein Mangel des Esu-Decoders, kein Mangel der SUSI-Implementierung von Märklin.

---

Zitat von Dampfstoß im Beitrag #45

---

Hauptsache Märklin kann alles und die anderen können nix. Freu Dich und lass uns in Ruhe!

---

Moin

Rosarot ist doch ne schöne Farbe für ne Brille ...
Die Fa. Zimo hat mir versichert, das SuSi-CVs 1:1 durchgereicht werden. Herr Henning hat einen Sound zum Schorsch online gestellt, der von Zimo mittlerweile zurück gezogen wurde wegen Inkompatibilität mit der aktuellen MSxxx-Decoder-Firmware.
Ich hab meinen Decoder von Henning direkt, mit von ihm angepasster Firmare. Das File funktioniert genau wie das von ESU auch ... bei Fahrt rückwärts bleibt das Licht am Kessel an wenn es mit F0 aktiviert wurde.
Auf der Tenderplatine sind 2 fette SMD-Dioden, ich vermute die schalten Lv/r mit dem mSD³-Decoder richtungsabhängig zu oder ab.

@Lauenstein
Meine Frage ... weshalb sollte ich micht einer Software herumärgern, die ich nicht brauche? Die Dokumentatation heißt deshalb Dokumentation, weil außenstehende damit nachvollziehen können was der in Verkehrbringer damit erreichen will/wollte und es nachvollziehbar für den Nutzer ist. Ist das nicht der Fall ... kann mans mit aufs Häuserl nehmen.

Bei Produkten die wir in Verkehr bringen kann jeder nachvollziehen was er tun muss damit es funktioniert. Das erwarte ich auch von anderen Protagonisten.

Bis dahin

Zitat von Lauenstein im Beitrag #48

---

Aber beim Thema SUSI ist es nunmal so, dass Märklin SUSI besser unterstützt als Esu oder ZIMO und da eben gerade extrem flexibel ist. Das kann man denke ich auch eingestehen. Esu, ZIMO, D&H können viele andere Dinge besser als Märklin, das steht ja gar nmicht zur Diskussion.

---