Ich möchte hier Piko ein Lob für die BR 50 in Spur G aussprechen, was mich dazu veranlasst hat auch noch die BR 95 bei Bessere Preise zu kaufen.
Bessere Preise ist wirklich sehr günstig nur bei Problemen reagieren sie sehr spät und Verweisen auf den Service des Herstellers.
Und der ungeliebte Laden ist wegen Corona auf unbestimmte Zeit geschlossen.
Aber Piko hat aus zwei verschiedenen Abteilungen auf meine Fragen geantwortet.
Die 50er ist unglaublich und der Sound so realistisch das meine Frau die Bahnlinie nach einer Dampflok abgesucht hat.
Mit der CS2 habe ich 15 von 25 Funktionen und iCS3 nteressanterweise 17 Funktionen
Aber das ist sicher die Schuld von Lizenzen Märklin.
Doch wenn Uhlenbrock einen MFX Dekoder baut, dann hat doch Märklin Interesse eine Zentrale hierfür zu verkaufen.
Also Bitte Märklin Freigabe aller Funktionen , DCC funktioniert bei der 50 er nicht.
Probiere es mit der 95.
Bei H0 Habe ich die 181 und die Taigatrommel.
Auswechseln der Pantografen nicht möglich
Lautstärke mit CS 2und 3 nicht möglich. Uhlenbrock wollte viele Möglichkeiten schaffen aber mit Märklin unmöglich.
Bitte Piko und Uhlenbrock
Änderung dieser CVs wie es ESU auch kann.
Und einen einfachen Austausch der Panthographen
Piko hat doch super Entwickler in Spur G
Dann sollte H0 und Uhlenbrock doch auch besser werden ,da ja schon Herr Richter von Uhlenbrock zu Piko gekommen ist.
Ich würde mir noch eine BR 01 in Spur G wünschen.
Gruss Klaus

Hallo Klaus
Schuld daran ist die rudimentäre Implementierung von MFX durch durch Uhlenbrock/Piko. MFX wurde durch Märklin/Esu entwickelt. Der Schutz ist nun abgelaufen, aber Märklin/Esu wollen natürlich ihre eigenen Decoder verkaufen und veröffentlichen daher den Quellcode nicht. Auch D&H hat sich (am Anfang?) schwer getan mit MFX, Siehe Diskussion um die Roco Br 85.

Wenn du den original Sounddecoder von Piko gekauft hast, dann kann er laut dieser Anleitung dcc [url= https://www.piko-shop.de/is.php?id=24868]klick[/url].
Wichtig ist, dass du alle anderen Protokolle an der Zentrale abschaltest, da an MS/CS 2/3 MFX und MM Priorität vor DCC haben.

Zitat

---

Hallo Klaus
Schuld daran ist die rudimentäre Implementierung von MFX durch durch Uhlenbrock/Piko. MFX wurde durch Märklin/Esu entwickelt. Der Schutz ist nun abgelaufen, aber Märklin/Esu wollen natürlich ihre eigenen Decoder verkaufen und veröffentlichen daher den Quellcode nicht. Auch D&H hat sich (am Anfang?) schwer getan mit MFX, Siehe Diskussion um die Roco Br 85.

Wenn du den original Sounddecoder von Piko gekauft hast, dann kann er laut dieser Anleitung dcc [url= https://www.piko-shop.de/is.php?id=24868]klick[/url].
Wichtig ist, dass du alle anderen Protokolle an der Zentrale abschaltest, da an MS/CS 2/3 MFX und MM Priorität vor DCC haben.

---

Hallo Alexander,

ich hätte da gern ein paar Belege.
Erstens: wieso ist "der Quellcode" von mfx nicht veröffentlicht? Es gibt seit Jahren eine Internetseite, wo das Protokoll eingehend beschrieben ist.
Zweitens: die Roco-85 hat meines Wissens keinen D&H-Decoder, sondern einen zimo.

Meiner Ansicht nach hat hier Piko, möglicherweise mit Schützenhilfe von Uhlenbrock, halbe Arbeit geleistet. Dafür die Schuld nun Märklin in die Schuhe zu schieben ist - *räusper* sag ich wohl mit Blick auf die Netiquette nicht laut.

Wenn dein Radio den WDR nicht empfängt, dann kann das natürlich auch nur am WDR liegen...

kurze Ergänzung:

die Roco Dampflok der BR 85 hatte und hat einen Zimo Decoder ( ZIMO MS 450 P 22 ). Ich hatte im Jahr 2017 die Roco Lok erworben, toller
Sound , alles prima , nur kein mfx Protokoll drauf.

Darauf hin hatte Zimo mir - und allen anderen 85 `Besitzern - über einen numerierten Serienbrief kostenlos einen 2. Sounddecoder nach-
geliefert. Ein toller Service von Zimo, gut gemacht.

Das mfx Protokoll ist meines Wissens offen und kann heute nach Ablauf der Schutzzeit von jedem Decoderhersteller aufgespielt werden.
Seit der Zusammenarbeit von Piko mit Uhlenbrock und seit dem Smartdecoder 4.1 habe ich keine AC Lok mehr bei Piko gekauft, sondern ich
erwerbe die DC analog Variante und baue mir meinen Decoder nach Wahl selbst ein. Noch ein Schleifer drunter und fertig.

Die besten Piko AC Soundloks waren z.B. die E 41 , die V 200 , da wurden noch Sounddecoder OEM verbaut, der Hersteller war ESU.
Bin mal gespannt, wie der Mann mit der Brille reagiert, irgendwann muss doch auch in Sonneberg jemand merken, dass AC Loks mit
dem Uhlenbrock Decoder sich im Fachhandel in den Regalen " stapelnd " liegen bleiben.

Gruss - Elokfahrer160 / Rainer

Zitat

---

Die besten Piko AC Soundloks waren z.B. die E 41 , die V 200 , da wurden noch Sounddecoder OEM verbaut, der Hersteller war ESU.
Bin mal gespannt, wie der Mann mit der Brille reagiert, irgendwann muss doch auch in Sonneberg jemand merken, dass AC Loks mit
dem Uhlenbrock Decoder sich im Fachhandel in den Regalen " stapelnd " liegen bleiben.

Gruss - Elokfahrer160 / Rainer

---

Da bin ich auch durchaus gespannt. Die Frage ist aber: Ist das wirklich der Fall, oder gehen wir nur davon aus? Ich kann mir vorstellen, dass auch hier die breite Masse einfach kauft und keine Fragen stellt, so wie der Märklin Sound ja auch genügend Käufer findet, obwohl hier immer wieder diskutiert wird, wie die Firma davon überhaupt irgendwas verkauft bekommt.

Von Allen Dekoderherstellern scheint mir Zimo wirklich am kundenfreundlichsten zu sein. Bei der Aktion Gratisdekoder wäre natürlich interessant, wie viel da von ihnen selbst und wie viel von Roco ausging. Man wird es wohl nie erfahren, aber für den Kunden ist es natürlich eine spitzen Lösung gewesen, weil es letztlich quasi 80€ Rabatt auf das Produkt entsprach.

Hallo Rainer
Die BR 85 von Roco habe ich zirka 2 Wochen
Habe auf DCC programmiert
Konnte alle Einstellungen von meiner Roco BR 23 übernehmen, da auch Zimo
Brauche ja wegen Bogobit Bremseinstellungen
Ist eine tolle Lok und fährt auf K Gleis sehr gut.
Dachte erst ein rotes Schlusslicht wäre defekt.
Bei der Reichsbahn war das so.

Hallo , Klaus

es freut mich, dass dir deine BR 85 von Roco genausoviel Fahrspass bereitet , wie mir meine BR 85, ist eine tolle Lok geworden, das Warten
hat sich gelohnt.

Da ich ja nun einen Sounddecoder (der ohne mfx) übrig habe , überlege ich mir die Anschaffung einer weiteren , soundlosen BR 85, um dann
dort den Zimo Sounddecoder einzubauen. Bei einigen Händlern gibt es BR 85 Modelle von Roco schon im Abverkauf.

Ich habe auch Zimo Sounddecoder in E Loks werkeln , so im SBB Krokodil (Roco 79249) und in einigen BLS Loks der Re 4/4, der Sound
klingt jedenfalls sehr realistisch , besser als der aus Göppingen.

tönende Grüsse - Elokfahrer160/Rainer

Zitat

---

Erstens: wieso ist "der Quellcode" von mfx nicht veröffentlicht? Es gibt seit Jahren eine Internetseite, wo das Protokoll eingehend beschrieben ist.

---

Merkst Du es nicht selber? "Quellcode" != "Protokoll"

Der Quellcode ist, was dann als Programm auf dem Decoder läuft. Also etwas handfestes. Das Protokoll ist, wie der Decoder kommunizieren sollte. Also ein Beschreibung. Meistens verhält sich der Code nicht exakt so wie im Protokoll beschrieben, deswegen ist es immer von Vorteil für eine eigene Implementierung, direkten Zugriff auf dem Original-Quellcode zu haben.

Grüße,
Thorsten

Zitat

---

Mit der CS2 habe ich 15 von 25 Funktionen und iCS3 nteressanterweise 17 Funktionen
Aber das ist sicher die Schuld von Lizenzen Märklin.
Doch wenn Uhlenbrock einen MFX Dekoder baut, dann hat doch Märklin Interesse eine Zentrale hierfür zu verkaufen.
Also Bitte Märklin Freigabe aller Funktionen , DCC funktioniert bei der 50 er nicht.

---

Hallo Klaus,

ich kann mir kaum vorstellen, dass Piko einen Dekoder ohne DCC liefert. Leider konnte ich weder auf der Piko Homepage noch im downloadbaren Lok - Heft Informationen darüber finden, was der Dekoder für Protokolle unterstützt. Wahrscheinlich bin ich blind.

Der Punkt ist, dass der Uhlenbrock Dekoder eben nicht mfx kann, sondern irgendwas hingemurkstes bekommen hat. Ausser einer halbherzigen mfx Anmeldung kann der Dekoder nichts, was dem mfx Protokoll nahe kommt. Der Dekoder unterstützt keine mfx Programmierung, kein Mapping und nichts. Willst du auch nur die Lautstärke ändern, musst du das unter DCC mit primitiver CV Programmierung machen.

Dafür kann Märklin nichts, da sind nur Ulhlenbrock / Piko für die halbherzige Umsetzung verantwortlich.

Piko hätte lieber das Geld in die Motorregelung investieren sollen.

Gruss

Stephan

Zitat

---

Zitat

---

Erstens: wieso ist "der Quellcode" von mfx nicht veröffentlicht? Es gibt seit Jahren eine Internetseite, wo das Protokoll eingehend beschrieben ist.

---

Merkst Du es nicht selber? "Quellcode" != "Protokoll"

Der Quellcode ist, was dann als Programm auf dem Decoder läuft. Also etwas handfestes. Das Protokoll ist, wie der Decoder kommunizieren sollte. Also ein Beschreibung. Meistens verhält sich der Code nicht exakt so wie im Protokoll beschrieben, deswegen ist es immer von Vorteil für eine eigene Implementierung, direkten Zugriff auf dem Original-Quellcode zu haben.

Grüße,
Thorsten

---

Hallo Thorsten,

erst mal packe ich eine Ladung Freundlichkeit für dich ein; dein Ton läßt an der Stelle zu wünschen übrig.

Zweitens: wenn ich deine Ausführung wörtlich nehme, dann gibt es keinen "Quellcode von mfx". Denn mfx ist die "Sprache", in der der Decoder mit der Zentrale kommuniziert. Der Quellcode legt fest, was der Decoder damit macht - übrigens unabhängig davon, ob die Kommunikation in MM oder DCC oder mfx stattfindet. Ich könnte ja jetzt auch sagen, "merkst du es nicht selber?" Aber das Niveau liegt mir nicht.

Drittens: welcher Decoderhersteller hat den Quellcode seiner Decoder offengelegt? Ich bitte um Belege.

Viertens könnte dich dieser Thread interessieren. viewtopic.php?t=956 Ist schon uralt, aber amüsant zu lesen. Findet man übrigens ziemlich schnell, wenn man nach "Quellcode mfx" sucht.

Zitat

---

Der Quellcode ist, was dann als Programm auf dem Decoder läuft. Also etwas handfestes. Das Protokoll ist, wie der Decoder kommunizieren sollte. Also ein Beschreibung. Meistens verhält sich der Code nicht exakt so wie im Protokoll beschrieben, deswegen ist es immer von Vorteil für eine eigene Implementierung, direkten Zugriff auf dem Original-Quellcode zu haben.

---

Nein.
Erst kommt die Spezifikation (= Protokoll) dann die Implementierung (diverse Codes auf verschiedenen Geräten), sonst können die Programmierer gleich einpacken.

Und Märklin hat den Standard letztes Jahr zur Nutzung freigegeben ("Fits mfx"). Das muß nicht heißen daß jedes Detail veröffentlicht wurde (jedes Protokoll hat ein paar Hintertürchen und Geheimnisse) aber zumindest was man zum täglichen Betrieb braucht liegt offen.

Daß die Decoderhersteller das noch nicht (ganz) implementiert haben liegt einfach an den Entwicklungskapazitäten. Die Softwareabteilung eines Decoderherstellers darfst Du dir nicht unbedingt als Großraumbüro vorstellen ...

Zitat

---

Zitat

---

Der Quellcode ist, was dann als Programm auf dem Decoder läuft. Also etwas handfestes. Das Protokoll ist, wie der Decoder kommunizieren sollte. Also ein Beschreibung. Meistens verhält sich der Code nicht exakt so wie im Protokoll beschrieben, deswegen ist es immer von Vorteil für eine eigene Implementierung, direkten Zugriff auf dem Original-Quellcode zu haben.

---

Nein.
Erst kommt die Spezifikation (= Protokoll) dann die Implementierung (diverse Codes auf verschiedenen Geräten), sonst können die Programmierer gleich einpacken.

---

Ich mache den Job seit 25 Jahren, ich habe noch nie erlebt dass die Implementierung in allen Details exakt der Spezifikation entsprochen hat. Egal in welchem Software-Bereich. Oft entdeckt man erst während der Implementierung, dass die Spezifkation so gar nicht machbar ist. Oder in der Implementierung schleichen sich Fehler ein. Und meistens wird die Spezifikation während der Implementierung noch angepaßt und ist nicht immer Eindeutig.

Zitat

---

Und Märklin hat den Standard letztes Jahr zur Nutzung freigegeben ("Fits mfx"). Das muß nicht heißen daß jedes Detail veröffentlicht wurde (jedes Protokoll hat ein paar Hintertürchen und Geheimnisse) aber zumindest was man zum täglichen Betrieb braucht liegt offen.

Daß die Decoderhersteller das noch nicht (ganz) implementiert haben liegt einfach an den Entwicklungskapazitäten. Die Softwareabteilung eines Decoderherstellers darfst Du dir nicht unbedingt als Großraumbüro vorstellen ...

---

Genau, Märklin hat letztes Jahr die Spezifikation frei gegeben, aber nicht den Code. Da kann man nur hoffen, dass die Märklin Entwickler und die Dritt-Hersteller beide keine Fehler machen, weil wenn einer einen Fehler macht, hilft Dir die ganze Spezifikation nicht, es kommt trotzdem zu Inkompatibilitäten. Von daher ist es immer sehr hilfreich, eine Referenzimplementierung zu haben und nicht nur ein Dokument, von dem man nicht weiß, wie genau es wirklich ist und wie die Unklarheiten im Dokument gemeint sind. Und ja, Spezifikationen enthalten immer Unklarheiten, niemand kann eine Spezifikation schreiben, die alle Details wirklich bedenkt und eindeutig ist.

Grüße,
Thorsten

Zitat

---

Zweitens: wenn ich deine Ausführung wörtlich nehme, dann gibt es keinen "Quellcode von mfx". Denn mfx ist die "Sprache", in der der Decoder mit der Zentrale kommuniziert. Der Quellcode legt fest, was der Decoder damit macht - übrigens unabhängig davon, ob die Kommunikation in MM oder DCC oder mfx stattfindet. Ich könnte ja jetzt auch sagen, "merkst du es nicht selber?" Aber das Niveau liegt mir nicht.

---

Also erstmal, der Quellcode legt nicht fest, was der Decoder damit macht, der Decoder bekommt den Quellcode niemals zu Gesicht. Der Entwickler übersetzt den vorher in Binärcode, und der wird dann auf den Decoder geladen.

Und natürlich gibt es Implementierungen des MFX Protokolls, einmal die "Client" Seite im Decoder, einmal die "Server" Seite in der Zentrale. Und für Implementierungen gibt es immer Quellcode, niemand implementiert direkten Binärcode.
Und was bitte ist den wohl der Code, der die MFX Befehle von der Zentrale decodiert und in Befehle für den Ablaufprozeß des Decoders umwandelt? Richtig, Binärcode, den ein Compiler aus Quellcode erzeugt hat.

Zitat

---

Drittens: welcher Decoderhersteller hat den Quellcode seiner Decoder offengelegt? Ich bitte um Belege.

---

Wo habe ich geschrieben, das ein Decoderhersteller seinen Quellcode offen gelegt hat? "Ich bitte um Belege"!

Bevor Du über andere "herziehst" solltest Du bitte erstmal selber genau lesen. Ich habe lediglich geschrieben, das, wenn man ein Protokoll implementiert, es hilfreich ist, den Original-Quellcode zu haben. Nicht das den jemand veröffentlich hat. Allerdings ist es in anderen Bereichen üblich, eine Referenzimplementierung mit seinem Protokoll zu veröffentlichen, wenn man möchte, das möglichst viele Leute das Protokoll verwenden. Das hilft ungemein.

Grüße,
Thorsten

Erst mal: Hallo!

So viel Zeit sollte sein, oder? Aber das fängt ja an, zur Gewohnheit zu werden bei dir, daß du es an Freundlichkeit fehlen läßt.

Zitat

---

Wo habe ich geschrieben, das ein Decoderhersteller seinen Quellcode offen gelegt hat? "Ich bitte um Belege"!

---

Du hast es nicht geschrieben, Kollege [user]Kugellager[/user] hat beklagt, daß Märklin das nicht tut, und auf meine Anfrage an ihn hast du geantwortet und dir damit den Schuh angezogen:

Zitat

---

MFX wurde durch Märklin/Esu entwickelt. Der Schutz ist nun abgelaufen, aber Märklin/Esu wollen natürlich ihre eigenen Decoder verkaufen und veröffentlichen daher den Quellcode nicht.

---

Wohlgemerkt meint Kollege Kugellager den Quellcode von mfx. Insofern war dein Anraunzen von wegen "Quellcode betrifft nicht mfx, sondern den Decoder" nicht an mich zu richten, sondern an Kollege Kugellager.
Aber weil du dich da so einfach eingemischt hast, hab ich dich glatt mit Kollege Kugellager verwechselt und gedacht, da antwortet mir der, an den ich die Anfrage gestellt habe.

Nächstes Mal hör / lies doch bitte genau hin, worum es überhaupt geht, bevor du dich in ein Gespräch erwachsener Leute einmischst, dann vermeidest du auch, an den Leuten vorbeizureden. Und wenn eine Frage nicht an dich gestellt ist, überleg auch, ob es nötig ist, daß du dich mit einer Antwort einmischst und vordrängelst. Eigentlich reicht mir in der Hinsicht, was meine Töchter regelmäßig bieten.