[Fleetworker]

Moin, Moin Zusammen,

Ich hatte mich zur Zeit meiner letzten Antwort in diesem Thread (viewtopic.php?f=7&t=123822) vor ziemlich genau einem Jahr entschlossen,
Märklin-Dekodern wegen solcher Ärgernisse den Rücken zu kehren.
Ich war mit den Sounddecodern und dem gesamten Umfeld (Hard- und Software) aus Ulm sehr zufrieden und
als eigentlicher Märklin-Hardcore-Fan ziemlich enttäuscht.
Als nun Märklin den neuen Programmer und die neuen Dekoder angekündigt hatte, war mein Entschluss schnell gefasst.
Das "Zeug" musst Du haben. Märklin verdient eine 2. Chance.
Also habe ich mir den neuen mDP (Art.-Nr. 60971) und einen mSD3 (Art.-Nr. 60975) zugelegt.
Gleich vorne weg: Und zum zweiten Mal enttäuscht.
Warum?
Zuerst sah das Alles ziemlich gut aus.
Aber bei näherer Betrachtung und nachdem die erste Aufregung über das neue Produkt verpflogen war, wurde "das Gesicht" immer "länger".
Doch der Reihe nach.

mDT3 heruntergeladen und installiert (Probleme mit WIN-32Bit/64Bit 7, 8, 10 in MultiUser-Konfiguration zählen hier nicht )
Hardware eingesteckt, neuen Dekoder via Adapter-Platine aufgesteckt.
mDT3 gestartet, neues Projekt ausgewählt.
Wegen der mitinstallierten Treiber gab es keine Probleme. Der Programmer wurde sofort gefunden und erkannt.
Soundbibliothek aktualisiert (mDT3 => Hilfe => Soundbibliothek aktualisieren).
Eigenes Projekt "BR01" mit Sound aus Bibliothek programmiert und gespeichert.
Ergebnis:
Also genau der selbe (nicht der gleiche ) Fehler, wie früher.

okay, da gibt es doch das Projekt zur BR 01 zum Herunterladen (BR01.mdtp).
Also BR01.mdtp im mDP heruntergeladen.
Hey, funktioniert
und geöffnet.
Beim Sound nachgesehen und dort ist unter Sound-Auswahl => Fahrgeräusch zu finden: "Dampf/BR 015 Luckemeier"

Diesen Sound gibt es in der Soundbibliothek nicht.
Und einige andere Sounds im Projekt stammen lt. Bezeichnung auch nicht von der BR01.
@Märklin: Du schummelst

Übrigens Soundbibliothek.
Die Soundbibliothek zum Herunterladen von der Mä-Homepage http://www.maerklin.de/de/service/downloads/soundbibliothek/ist ausgepackt knapp 430 MB groß (13.718 Dateien).
Die Soundbibliothek, die auf dem USB-Stick ist, der in der CS2 steckt, ist erheblich umfangreicher: ~640 MB (24.9898 Dateien).
Nach Update gestern 7.4.16, 20:00 Uhr.
Uuups, und da sind auch die o. g. fehlenden Dateien drin....

Zurück zum mDP/mDT3/mSD3.

Dann griff "Murphy" ein.
Durch eine unachtsame Bewegung mit der Maus berührte das Mauskabel den mDP samt Adapterplatine.
Folge: sowohl mDP, als auch Adapterplatine verloren jegliche Verbindung.
Hatte ich die Teile nur unzureichend zusammengesteckt? Nein, die Verbindungen sind so locker

Update 1:
Irrtum, die Verbindung zwischen Programmer und Adapterplatine ist nicht locker, wenn man es richtig macht:



Verbindung zusammendrücken
(In der Bedienungsanleitung steht das nicht drin. Bei meinem Exemplar rastet die Adapterplatine beim Einstecken nicht ein)




Und nicht nur das. Auch der Abstand zum Boden( in diesem Fall mein Tisch) ist groß genug, um für Verbindungsprobleme zu sorgen.
Bei meinem Notebook sind das immerhin 5 Millimeter "Luft".
NoProblem, in der Bastelkiste gibt es bestimmt eine 5-Millimeterleiste in ausreichender Länge
Aber dann fiel mir mit Erschrecken ein, dass ich normalerweise meinen MoBa-Pc für Dekoder-"Spielereien" benutze.
Und da beträgt der Abstand zum (FußBoden immerhin 19 cm.
/Ironie an:
Das ist schnell mit 12,66666 x Art.-Nr. 56295 ausgeglichen.
/Ironie aus.

Was hat sich Märklin dabei bloß gedacht.

Ich habe auch den Soundprogrammer (Art.-Nr. 60801). Da war ein USB-Kabel dabei. Geht also doch....

Fazit für mich:
Für einen stabilen Betrieb sind weitere Hardware-Anschaffungen (entweder USB-Kabel oder passende Unterlagen) zu tätigen.
Darüber hinaus ist die Soundbibliothek in eigener, undokumentierter und damit eigener Gefahr, zu vervollständigen.
"Out-of-theBox" ist anders
Da sind von Märklin noch Hausaufgaben zu machen.

Ich habe Verständnis dafür, dass die mSDs der ersten Generation sich nicht mit dem mDP programmieren lassen.
Das mDT3 ist, soweit ich das beurteilen kann, ein gelungenes Stück Software (Für das nächste Update schlage ich vor, dass die CVs bei
den einzelnen Eingabefelder angegeben werden und CV-Liste gedruckt oder gespeichert werden kann).

Aber was nützt das Alles, wenn die mechanischen Instabilität und die durchaus leicht zu vermeidenden Bibliotheksfehler das
Gesamtpaket "in den Keller" reissen.
Märklin kann doch "Stabil". Siehe Teststand, M- K- C-Gleise, Loks und und und

Mit nachdenklichen Grüßen

Fleetworker

[Stadtbahner68]

Hallo Fleetworker,

deine mechanischen Eindrücke kann ich leider nur bestätigen, bei mir sind sogar die beiden Gehäusehälften des Sticks auseinander gefallen... Nun ja... ich kann mit leben, aber Premium ist anders.....

Hat bei dir die Kombination vom Start weg funktioniert? Ich sitze hier jetzt schon eine Woche, und hab das ganze gerade 2 mal zum laufen bekommen, sonst komm immer dieses "keine Antwort von COMx"

Und das, obwohl ich so ziemlich alles was nicht als COM benötigt wird runter geschmissen habe....

Ich raufe mir echt schon die Haare, denn die Software verspricht einiges. Schade das der Spaß schon an der Schnittstelle scheitern kann....Da hätten die Jungs aus Göppingen ruhig was "Idiotensicheres" (wo ich mich eindeutig mit einschließe) liefern können....

Gruß

Stadtbahner68

[Fleetworker]

Hallo Stadtbahner,
sorry für die späte Rückmeldung.
Bin im Urlaub und erst heute (endlich ) mal kurz online.
Das der mDP den Com-Port manchmal nicht findet, liegt m. E. unter anderem an ganz trivilen Kontakt-Problemen.
Die großen USB-Stecker sind nun mal ein wenig wackelig. Seit dem ich ein Verlängerungskabel nutze, habe ich weniger bis gar keine Problemem mehr.
Eine andere Ursache sehe ich darin, dass die Software es nicht so mag, wenn der mDT an verschiedenen Ports betrieben wird. Es scheint also, als ob die Suchroutine Schwierigkeiten hat oder einfach etwas länger braucht.
Das Beste ist, für den mDP immer den selben Port zu nutzen.
Ansonsten hatte ich keine Schwierigkeiten wie Bugs oder Fehlfunktionen.
Einzig das immer noch bestehende Problem der in der Soundbibliothek fehlenden Sounddateien ärgert mich immer noch.
Im April letzten Jahres hatte dazu etwas geschrieben:
(http://stummiforum.de/viewtopic.php?f=7&t=123822


Wenn Du weiterhin Probleme mit den COM-Ports hast, liegt u. U. ein Problem bei Windows.
Ich helfe Dir gerne, wenn ich am Freitag wieder zu Hause bin.

Gruß
Fleetworker

[aftpriv]

Hallo Stadtbahner und Fleetworker,

ich bewundere Eure Leidenstoleranz. Es wird die Tante aus GP aber sicher freuen solche treue Kunden zu haben und dabei mitzubekommen das sie weiter murxen können ohne nennenswerten Kundenverlust. :

Ich hätte an Eurer Stelle sicher schon den Decoderhersteller gewechselt!

Gruß

Alf

[rmayergfx]

@Alf

spar dir das doch einfach. Es gibt so viele unterschiedliche PC-Systeme und Konfigurationen, das kann kein Hersteller alles testen. So manches mal sitzt auch das Problem auch vor dem Bildschirm.
Grundsätzlich sollte man z.B. die Gerätetreiber immer als Administrator installieren, sofern es kein MSI-File für die Installation gibt. Und natürlich auch alle Virenscanner und Firewall vor der Installation deaktivieren, sofern man sicher ist, das die Datei aus einer vertrauenswürdigen Quelle stammt. Das erspart schonmal in 99% der Fälle unnötigen Frust bei der Installation.

Windows und USB-Gerätetreiber sind was ganz besonderes. Je nach Gerät wird es von Windows beim Wechsel des Ports einfach mal neu Installiert. Daher ist es sinnvoll immer den gleichen Port zu nutzen und die Software erst nach dem Einstecken des USB-Gerätes zu starten. Also Stick rein, kurz warten und dann erst die Software starten. So mancher Treiber hat auch einen Bug, also immer mal nachsehen ob es vom Hersteller für das eingesetzte System vielleicht schon längst einen aktualisierten Treiber gibt. Ach und dann war da ja noch das klitzekleine Problem mit USB 3.0 und den tollen Einstellungen im Bios...Legacy ja/nein/beides. Hmmm warum kann der Chipsatz von Hersteller A nicht mit B ? Mehr als einmal durfte ich schon feststellen, das sich USB 2.0 Geräte erst wieder sauber an Geräten mit integriertem USB 3.0 Chipsatz unterhielten, wenn diese über einen USB 2.0 Hub angeschlossen wurden.

Und wenn ich mir da andere Hersteller von Decodern ansehe, dann läuft es dort auch nicht rund, .net Framework, USB Treiber.... mit Blick nach Ulm gerichtet. Anderer Hersteller gleiche Probleme... oooops.

mfg

Ralf

[khpmueller]

Zitat von rmayergfx

---

Und wenn ich mir da andere Hersteller von Decodern ansehe, dann läuft es dort auch nicht rund, .net Framework, USB Treiber.... mit Blick nach Ulm gerichtet. Anderer Hersteller gleiche Probleme... oooops.

---

Hallo Ralf,

ich weis nicht was du treibst! Ich habe weder mit dem Esu Programmer noch mit dem Teil von Doehler&Haass unter Window 7 irgendwelche Probleme!

Auch mit dem mDT und den mSD gab es keine Probleme. Wenn Märklin die Soundbibiothek "gepflegt" und weiter entwickelt hätte, wäre ich auch nicht wieder zu ESU zurück gegangen bzw. hätte mir die Doehler&Haass Decoder nicht "erschlossen".

Der mSD/3 mit Tool(s) ist bis jetzt leider nur ein Schuß in den Ofen

Nette Grüße
KHPM

[rmayergfx]

Ich habe keinerlei Probleme damit, Toi toi toi, dreimal auf Holz geklopft.
Aber es gibt genügend Kollegen die es nicht oder mit Problemen ans laufen bekommen haben.
Gibt sowohl hier als auch im ESU Forum genügend Einträge mit Problemen das es bei verschiedener Hardware nicht läuft.

Programmierung und Tools/Sounds ist eine Sache, da wird bestimmt noch nachgebessert.
Nichtfunktion des Programmers per USB eine andere und da sind so viele Faktoren ausschlaggebend, das man nicht
generell dem Hersteller immer die Schuld zuweisen kann. Und da ist es egal ob da Märklin Esu oder was auch immer draufsteht.

Es soll ja auch durchaus Leute geben, die nicht so audiophil und mit den Sounds von Märklin durchaus zufrieden sind.
Der Markt ist groß genug und für jeden etwas dabei. Und jedes hat seine Vor- und Nachteile.

mfg

Ralf

[kukuk]

Zitat von rmayergfx

---

Nichtfunktion des Programmers per USB eine andere und da sind so viele Faktoren ausschlaggebend, das man nicht
generell dem Hersteller immer die Schuld zuweisen kann. Und da ist es egal ob da Märklin Esu oder was auch immer draufsteht.

---

ESU und Märklin verwenden den gleichen Serial-zu-USB Chip/Hersteller mit dem gleichen Treiber. Von daher ist es egal, ob die Lösung von Märklin oder ESU genommen wird, das Teil, der den meisten Ärger macht, ist identisch.
Vorwerfen kann man beiden Herstellern aber, das sie noch immer auf die unsägliche Serial-zu-USB Lösung setzen, weil es für sie einfacher zu programmieren ist, anstett endlich direkt USB zu verwenden. Dann würde der Konverter und damit eine Problemquelle wegfallen.

Grüße,
Thorsten

[aftpriv]

Zitat von rmayergfx

---

spar dir das doch einfach.

---

Hätte ich natürlich machen können, war mir aber ein Bedürfnis. Ich habe aber damit die unfertigen Sounddateien gemeint

Zitat von rmayergfx

---

Es gibt so viele unterschiedliche PC-Systeme und Konfigurationen, das kann kein Hersteller alles testen. So manches mal sitzt das Problem auch vor dem Bildschirm....
... oooops.

---

Ja, meistens als Programmierer

Zitat von Thorsten

---

ESU und Märklin verwenden den gleichen Serial-zu-USB Chip/Hersteller mit dem gleichen Treiber. Von daher ist es egal, ob die Lösung von Märklin oder ESU genommen wird, das Teil, der den meisten Ärger macht, ist identisch.
Vorwerfen kann man beiden Herstellern aber, das sie noch immer auf die unsägliche Serial-zu-USB Lösung setzen, weil es für sie einfacher zu programmieren ist, anstett endlich direkt USB zu verwenden. Dann würde der Konverter und damit eine Problemquelle wegfallen.

---

Hierzu gebe ich aber trotdem meinen Senf dazu (hoffentlich ist er nicht zu scharf):
vielleicht wissen die noch nicht das Seriell aus ist und kaum noch ein Gerät darüber verfügt.
Aber, das was in der Computertechnik (aber auch in der Konsumerelektrik/-elektronik) so abläuft ist eine Schande für alles Ingenieurtum.
Ich bin Maschinenbauer, wenn ich einen so unfertigen Mist an die Kunden bringen würde, wäre ich schon längst entlassen und auf Harz4 oder Ähnlichem.

Gruß

Alf

PS: es heißt doch immer der Computer soll der Menscheit dienlich sein und nicht die Taschen der Heuschrecken füllen

[rmayergfx]

Definition USB = Universal Serial Bus

[aftpriv]

Zitat von rmayergfx

---

Definition USB = Universal Serial Bus

---

Meine Definition Seriell : Serielle Schnittstelle (===>: https://de.wikipedia.org/wiki/Serielle_Schnittstelle)

Gruß

Alf

[TT800]

Zitat von aftpriv

---

Aber, das was in der Computertechnik (aber auch in der Konsumerelektrik/-elektronik) so abläuft ist eine Schande für alles Ingenieurtum.
Ich bin Maschinenbauer, ...

---

Dieses Outing erklärt so manches. Das erinnert mich an manche Diskussion Maschinbauer vs. Elektroniker bei unserem Stammtisch. Das endet dann immer mit "Schuster, bleib bei Deinen Leisten!"

[khpmueller]

Hallo Leute,

jetzt begreift es doch endlich, Märklin ist in diesem Fall ein Dilettant. Der mSD ist ja nicht von vorgestern, sondern nur eine Generation vor dem mSD/3, zudem Pinkompatibel!

Somit müßte es aus Sicht von dem mDT/3 Tool überhaupt kein Handlingsproblem geben, wenn die Programmierer der Sache gewachsen wären!

Aber auch hier zeigt es sich, wie bei anderen Firmen, dass es an der Software hapert. Der mSd war/ist vom Hardwaredesign nicht schlecht, war durchaus seiner Zeit angemessen, aber Märklin hat schon bei ihm nicht alle Features offen gelegt, geschweige denn, dass Futter (Soundbibiothek) entsprechend gepflegt, so das der Anfangserfolg verpuffte! Und auch zB. der Lichtblitzbug beim Fahrrichtungswechsel, wenn die Beleuchtung gedimmt ist, wurde bis jetzt nicht behoben!

Was in dieser Situation eine neue Hardware (mSD/3) bringen soll, wenn man die gleichen Fehler macht, ist mir schleierhaft! Der mSD/3 ist von der Hardware durchaus ein Sprung nach vorne, aber war nützt es dem Kunden wenn das "drumherum" (Programmiertool, Soundbibiothekt) zu wünschen übrig läßt? Zum Beispiel, wie soll ich einen eigenen Motorsound effektiv komponieren, wenn es keinen Simulator in der Software gibt und ich gezwungen bin das Ergebnis immer auf dem Decoder zu verifizieren?

Nette Grüße
KHPM

[rmayergfx]

Stimmt doch gar nicht,

die Hardware vom mSD3/mLD3 hat intern eine andere Schnittstelle, die es erlaubt die Daten wesentlich schneller übertragen zu können.
Dafür wurde dann noch der Decoder Programmer 60971 entwickelt. Beide Decoder mögen eine Pin kompatible mtc nach aussen führen, das war es aber auch schon. Ich habe mich auf der Messe lange mit den Entwicklern unterhalten warum das so ist, ich hatte genau die gleichen Gedanken, das müsste doch passen, aber dem ist nicht so.

mfg

Ralf

[st-oldie]

Hi Thorsten,

Zitat von kukuk

---

ESU und Märklin verwenden den gleichen Serial-zu-USB Chip/Hersteller mit dem gleichen Treiber. Von daher ist es egal, ob die Lösung von Märklin oder ESU genommen wird, das Teil, der den meisten Ärger macht, ist identisch.
Vorwerfen kann man beiden Herstellern aber, das sie noch immer auf die unsägliche Serial-zu-USB Lösung setzen, weil es für sie einfacher zu programmieren ist, anstett endlich direkt USB zu verwenden. Dann würde der Konverter und damit eine Problemquelle wegfallen.

---

Kann man vorwerfen. Ist aber sehr verständlich. Und die Alternative aufwändig und möglicherweise fehlerhafter.

Welche Geräteklasse sollte Märklin denn dann verwenden? Es würde dann nur 0xFF herstellerspezifisch übrigbleiben. Und dann müßte Märklin auich den USB Treiber mitliefern. Zum einen ist das ein deutlich höherer Aufwand für Märklin. Und möchte wirklich jemand sich die damit verbunden möglichen Fehler einhandeln, wenn jetzt schon über Fehler geschimpft wird?

Um beliebige produktspezifische Daten zu übertragen, ist USB nach seriell immer noch das einfachste. Auch wenn es die Industrie nicht wahrhaben möchte und die Schnittstellen vergessen möchte. Seriell ist immer noch das einfachste, um mit einem Gerät Kontakt aufzunehmen. speziell bei der Entwicklung von Embedded Systems.

Tschüß
Michael

[bertr2d2]

Hallo,

IMHO ist es eine logische Konsequenz, einen USB2Serial Chip zu verwenden, da die verwendeten Renesas-MCUs in den mSD3/mLD3 seriell programmiert werden. Siehe:
http://people.redhat.com/dj/m32c/
http://people.redhat.com/dj/m32c/flash-guide.pdf

Es macht wenig Sinn, hier irgend einen weiteren USB-Controller zu nehmen und dort eine USB2Serial Wandlung vorzunehmen. Dann müsste man auch noch signierte Treiber anbieten etc. pp.

FTDI Chips (zumindest die Originalen) sind sehr gute Chips. Wenn man wegen der Probleme jemanden an den Pranger stellen will, dann sollte man sich Mircosoft vornehmen

Anders sieht es natürlich bei der Sound-Software an sich aus. Hier muss sich M*rklin der Kritik stellen und nachbessern. Auch der physikalische Aufbau scheint von M*rklin bzw. dem beauftragten Unternehmen nicht ideal zu sein.

Gruß

Gerd

[rmayergfx]

Dem gibt es eigentlich nichts mehr hinzuzufügen. Vielleicht überarbeitet Märklin in der Zukunft ja doch mal die Sounddatenbank, die Grundlagen mit der neuen Hardware bietet ja wesentlich mehr Spielraum.

mfg

Ralf

[Schmalspurbahn]

Schade, wenn ich so hier querlese, dann kann man mit dem mDP3 lediglich die neuen mSD3/mLD3-Decoder programmieren. Bei Decodern der alten Genaration lasssen sich noch nicht mal die CV-Werte/MFX-Einstellungen auslesen und ändern, von Soundprojektupdates ganz zu schweigen.

Da hat Märklin leider eine Chance verpasst. Wäre es wirklich zu viel Aufwand gewesen, den mDP3 bzw. die Software mDT3 so zu gestalten, dass man wahlweise einen mSD/mLD bzw einen mSD3/mLD3 programmieren kann?

So würde ich mir den mDP3 kaufen und trotzdem sämtliche mfx-Decoder NICHT (!) programmieren können. Nur neue mSD3/mLD3-Decoder könnte ich damit bearbeiten.

Hatte ich den Kauf des mDP3 schon fest eingeplant, habe ich ihn nun ad Acta gelegt. Da kann ich auch beim Fremdfabrikat bleiben und deren Programmer und folglich auch deren Sounddecoder benutzen. Bleibt also weiter, auf eine günstige, gebrauchte CS2 zu warten, um meine mfx-/mSD-Decoder zu programmieren. Aber die Preise für gebrauchte 60213/60214/60215 werden wohl erst signifikant fallen, wenn die CS3/CS3plus endlich verfügbar ist.

[rmayergfx]

Das geht doch, es können auch Projekte für die alten Märklin mSD und mLD erstellt, und direkt an die CS2 übes Netzwerk übertragen werden.
Beim Starten der Software wirst du gefragt ob Du ein Projekt für einen mLD/mSD Nachrüstdecoder oder ein mLD/mSD Nachrüstdecoder der 3ten Generation erstellen möchtest.
http://stummiforum.de/viewtopic.php?t=12...rt=125#p1550981

Zitat von TT800

---

Zwei Umstände sind aber zu beachten:
- für mLD und mSD kann man im mDT3 keine Vorlagen von der 3. Generation verwenden, sondern nur die für mLD und mSD; sollte eigentlich klar sein. Nach meinen Recherchen wird so ein falsches Projekt in der CS2 beim Updateversuch aber gar nicht angeboten. Aber vielleicht gibt es da Ausreißer.
- der mDP-Stick kann keine mLD und mSD lesen oder beschreiben; passiert aber auch nichts, wenn man es probiert.

---

mfg

Ralf

[supermoee]

Hallo,

Ich habe schon mehrere Projekte für mSD Dekoder mit dem mDT3 programmiert und mit der CS draufgespielt.

Gruss

Stephan

[kleiner Rainer]

Zitat von Schmalspurbahn

---

Schade, wenn ich so hier querlese, dann kann man mit dem mDP3 lediglich die neuen mSD3/mLD3-Decoder programmieren. Bei Decodern der alten Genaration lasssen sich noch nicht mal die CV-Werte/MFX-Einstellungen auslesen und ändern, von Soundprojektupdates ganz zu schweigen.

Da hat Märklin leider eine Chance verpasst. Wäre es wirklich zu viel Aufwand gewesen, den mDP3 bzw. die Software mDT3 so zu gestalten, dass man wahlweise einen mSD/mLD bzw einen mSD3/mLD3 programmieren kann?

...

---

Ja, es wäre ziemlich viel Aufwand geworden. Ich beschreibe hier mal die Unterschiede der beiden Decodergenerationen, soweit mir bekannt:

Die bisher verfügbaren mSD bestehen im Grunde aus zwei getrennten Einheiten, die relativ wenig voneinander wissen, die sich aber zufälligerweise auf derselben Leiterplatte befinden, nämlich dem Decoderteil und dem über SUSI angebundene Soundteil.

Der Decoderteil kann über eine mfx-Protokollerweiterung programmiert und ausgelesen werden. Soll der Soundteil (also das SUSI-Soundmodul) programmiert werden, so reicht der Decoderprozessor die über diese mfx-Erweiterung empfangenen Daten "häppchenweise" über die SUSI-Schnitte an den Soundteil weiter. Das dauert bekanntlich ziemlich lange, denn eine sichere Datenübertragung übers Gleis in die Lok ist auf 40 bis 50 kBit pro Sekunde begrenzt, mehr ist einfach bei dieser unsicheren Verbindung nicht drin - man erinnere sich an die alten Telefonmodems von vor der DSL-Zeit, die im Tonfrequenzbereich arbeiteten, da war das genauso. Abkürzen läßt sich das etwas mit dem Soundprogrammer 60801, der das Soundmodul unter Umgehung des Flaschenhalses namens Gleis direkt über SUSI mit Daten befüllt. Leider ist SUSI ziemlich unidirektional - den Decoder kann man darüber nicht nach seinen mfx-Einstellungen fragen, das gab der SUSI-Standard damals einfach nicht her, m.W. ist das trotz einiger zwischenzeitlich erfolgten Protokollerweiterungen immer noch so. Ebenso ist der SUSI-Soundteil nur über die bekannten CVs befragbar - darüber Sounddaten auslesen zu wollen, entspricht dem Versuch, das Treppenhaus von außen über den Briefkastenschlitz streichen zu wollen

Wenn man jetzt an die mfx-Datensätze im Decoderteil ran will, braucht man also im Programmer eine Zentrale mit Gleisendstufe und mfx-Auswertung, was ungefähr dem Inhalt der Gleisbox zur MS2 entspricht - auch von den Kosten her!
Dazu noch ein USB-Interface mit galvanischer Trennung zum PC, das wird teuer. Schneller wird die Programmierung der Sounddaten aber dadurch auch nicht - der Flaschenhals "Gleis" ist ja immer noch da.

Beim mSD/3 sieht die Sache ganz anders aus: hier gibt es die Trennung zwischen Decoder- und Soundteil nicht mehr, das macht alles ein - übrigens ziemlich leistungsfähiger - Controller mit genügend seriellen Schnittstellen und Speicher bis der Arzt kommt. Es liegt daher nahe, den PC mittels eines USB-zu-seriell-Wandlers direkt mit dem Decoderprozessor reden zu lassen. Damit sind dann Datenraten von jenseits 1 MBit machbar (so behauptet jedenfalls mein Oszi). Man merkt as auch daran, wie ratz-fatz der Decoder mit allen Daten (also nicht nur Sound) befüllt ist. Das mit dem bisher verwendeten 8-Bitter machen zu wollen, ist wegen der Beschränkungen der Hardware (2 kbyte RAM, ungepufferter UART mit max. 230kBit/sec) einfach nicht drin. Netterweise ist das "alte" Update-Verfahren immer noch im mSD/3 enthalten, nur wird der Soundspeicher jetzt nicht mehr über die SUSI-Schnitte angesprochen.

Aus meiner Sicht also ein durchaus zukunftssicherer Ansatz, der nur etwas durch das nicht ganz triviale Handling der Schnittstellenabbildung im USB-Teil des Betriebssystems gebremst wird. Aber tröstet Euch - in anderen technischen Hobbies kämpft man auch mit den Tücken serieller Datenübertragung via USB, auch dort sind die Foren voll mit Klagen über wandernde COM-Schnittstellen, gefakte USB-Chipsätze und unsichtbare USB-Peripherie...

Alternativen zur Abbildung der seriellen Schnittstelle über USB sehe ich eigentlich nicht - HID ist in der pro Zeiteinheit übertragbaren Datenmenge limitiert und verlagert das ziemlich komplexe Handling des Datentransfers in das Peripheriegerät. USB-Massenspeicher ist genau das - und nicht mehr. Abgesehen davon habe ich was läuten hören, daß Kleinstweich bei der Nutzung seiner Betriebssystemroutinen fürs Ansprechen von Massenspeichern via USB gern Lizenzgebühren sehen möchte...

So, das war jetzt mehr Text als ursprünglich gedacht, aber das Thema ist bei näherer Betrachtung nicht ganz trivial.

Schönen Abend noch,

Rainer

[rmayergfx]

Danke für die detailierte Beschreibung. Genau dies wurde mir am Stand des mLP auch erklärt. Wenn man sich weiter entwickeln möchte müssen halt irgendwan drastische Schritte gemacht werden und die alten Zöpfe ab.
Ich erinnere mich noch gut an den Aufschrei den es gab, als ein gewisser Hersteller, der ewig Verfechter der PowerPC Prozessoren war, diese mit einem Ruck ersetzte durch Intel Prozessoren.
Was gab es damals für Diskussionen. Märklin macht es im Prinzip genauso. Und ich bin mir sicher das es einfach nur noch etwas Zeit benötigt bis sich die neue Prozessorstruktur sich großflächig verteilt hat und genügend Erfahrungen vorhanden sind. Nur sollte Märklin dann auch für die anspruchsvolleren Kunden endlich mal die Möglichkeiten ausschöpfen und die Soundfiles überarbeiten.

mfg

Ralf

[Schmalspurbahn]

Zitat von kleiner Rainer

---

Ja, es wäre ziemlich viel Aufwand geworden. Ich beschreibe hier mal die Unterschiede der beiden Decodergenerationen, soweit mir bekannt:

---

Hallo Rainer,
Vielen Dank für die fundierten Hintergrundinfos. Das erklärt die Grüne ganz gut. Wobei man auch sagen muss, dass es auch von anderen Herstellern Decoder-Programmiergeräte gibt, die sowohl eine SUSI-Schnittstelle als auch einen Gleisanschluss etc. enthalten und trotzdem nicht teurer sind als der kleine USB-Stick von Märklin.

Es wäre also durchaus möglich gewesen, einen Programmer zu entwickeln, mit dem man
1. mSD-/mLD-Decoder per mfx auslesen und programmieren kann
2. mSD-Decoder mit neuen Soundprojekten per SUSI versehen kann
3. mSD3/mLD3-Decoder im schnellen Direktzugriff vollständig (mfx/CVs und Sound) programmieren kann

Ja sicherlich, das wäre ein paar Euro teurer geworden, hätte die Gewinnmarge etwas gedrückt, aber wäre für die Kunden ein sehr guter Übergang von der alten in die neue Decoder-Generation gewesen: Das alte bewahren und das neue Fördern!

Gerade für Märklin-Kunden, die keine CS2/CS3 haben, gibt es bisher keine Möglichkeit, die mfx-Decoder zu programmieren. Mit dem mDP3 geht das nun immer noch nicht. Der mDP3 ist also keine Lösung für diese Kunden. Wenn ich nun aber sowieso eine CS2/CS3 kaufen muss, um meine Bestandsdecoder zu programmieren, dann kann ich mir auch den Kauf des mDP3 sparen.

[TT800]

Zitat von Schmalspurbahn

---

Es wäre also durchaus möglich gewesen, einen Programmer zu entwickeln, mit dem man
1. mSD-/mLD-Decoder per mfx auslesen und programmieren kann
2. mSD-Decoder mit neuen Soundprojekten per SUSI versehen kann
3. mSD3/mLD3-Decoder im schnellen Direktzugriff vollständig (mfx/CVs und Sound) programmieren kann

---

Eigentlich geht es ja am Thema dieses Threads vorbei, wenn wir hier über mLD und mSD diskutieren, aber unkommentiert kann man im Zusammenhang diese 3 Punkte auch nicht lassen.

@ 1. Nachdem ich den mDP-Adapter etwas "unter die Lupe" genommen habe, ist mir klar geworden, dass solche verständlichen Wünsche einen Mehraufwand verursachen würden, der zwei Geräten entsprechen würde. Die mXD3 werden vom mDP weder über Schienen- noch über SUSI-Schnittstelle angebunden. Daher ist eine mXD-Anbindung physikalisch unmöglich.
Zweifelsohne könnte man einen zweiten Adapter entwickeln, doch stellt sich die Frage, ob sich der je amortisieren würde. Man müsste nämlich in der mDT3-Software (immerhin kostenlos und nicht nur für den mDP verwendbar) genau das ergänzen, was die CS2-Software im Update/Flashprozess Richtung Schiene tut. Wer sollte diese Entwicklungskosten für eine "alte" und daher nicht mehr käufliche Decodergeneration bezahlen?

Zitat

---

Gerade für Märklin-Kunden, die keine CS2/CS3 haben, gibt es bisher keine Möglichkeit, die mfx-Decoder zu programmieren. Mit dem mDP3 geht das nun immer noch nicht. Der mDP3 ist also keine Lösung für diese Kunden. Wenn ich nun aber sowieso eine CS2/CS3 kaufen muss, um meine Bestandsdecoder zu programmieren, dann kann ich mir auch den Kauf des mDP3 sparen.

---

Teilweise richtig, weil das Wort "programmieren" zu ungenau ist. Wir unterscheiden das sehr wohl auf verschiedenen Wegen mögliche "Schreiben" von CV-Bytes (üblicherweise "programmieren" genannt) und das "Flashen" ganzer Datenpakete inkl. CV-Werten bei den verschiedenen Updateprozessen und beim Ändern von Soundprojekten.
Aus der Sicht der "Bestandsdecoder" bringt der mDP3 nichts - was aber auch immer kommuniziert wurde. Warum er aber bei den aktuellen Nachrüstdecodern und hoffentlich auch bei den kommenden Seriendecodern nützt, hat ja "kleiner Rainer" erklärt.

@ 2. Diesen Programmer gibt es unter dem Namen mSP (60801), der mit dem mDT (ebenfalls eine Gratis-Software) ohne CS2 benützt werden kann.

@ 3. Das geht doch. Wo steckt hier das Problem?

[Schmalspurbahn]

Zitat von TT800

---

@ 2. Diesen Programmer gibt es unter dem Namen mSP (60801), der mit dem mDT (ebenfalls eine Gratis-Software) ohne CS2 benützt werden kann.

@ 3. Das geht doch. Wo steckt hier das Problem?

---

Ja klar, @2 und @3 gehen, aber jedes eben nur für sich und mit eigener Hardware.

@1+@2+@3 mit einem Gerät gehen nicht mit dem mDP3, nur mit der CS2/CS3.

Also ist der mDP3 für Kunden, die auch ältere Decoder haben, leider nutzlos. Das ist das "Problem".