Zitat von Lokidokter im Beitrag #24

---

Aber ja: es fehlt tatsächlich ein Produkt, welches ermöglicht, aufgrund des Eintrages in CV8 (Herstellerkennung) das Decoderprofil auszulesen

---

Zitat von Stahlblauberlin im Beitrag #26

---

Zitat von Lokidokter im Beitrag #24

---

Aber ja: es fehlt tatsächlich ein Produkt, welches ermöglicht, aufgrund des Eintrages in CV8 (Herstellerkennung) das Decoderprofil auszulesen

---

Nur die Herstellerkennung wird da kaum helfen, es gibt Hersteller die schon 25 Jahre die gleiche Kennung haben... Gucke ich mir nur Tams an wird das schon lustig, bei allen anderen Herstellern sieht das nicht anders aus.
Da ist deutlich mehr Hirnschmalz/Software nötig, vor allem eine dicke Datenbank mit den Mappings aller Decoder die in den letzen 20-25 Jahren auf den Markt gekommen sind. Dann CV für CV lesen und über KI-Techniken anhand der Datenbank (welche CVs lesbar und damit vorhanden, Wertebereich, Herstellerkennung...) den Typ identifizieren...und selbst das wird nicht zu 100% klappen.

---

Also, meine Lösung dafür lautet JMRI mit dem Unterprogramm DecoderPro.
Geht mit sehr vielen Digitalzentralen und übersetzt für nahezu jeden Decoder die CVs in einer guten Anwendermaske und diese lassen sich damit sehr gut einstellen.

Ist Freeware und wirklich empfehlenswert.

Bei mir im Einsatz mit DCC++ auf einem Arduino + Motorshield - viel günstiger gehts kaum,

LG
Bernhard

Zitat von Lokidokter im Beitrag #27

---

Falls jemand von euch sich das zutraut: meine Kundschaft wäre dir sicher! Für so win Gerät inkl Programm würde ich ohne zu zögern 300€ auf den Tisch legen. Das allein ist schon weniger als eine MXULFA ohne Ladegerät und Software und einen ESU LoPro mit allem drum und dran…

---

Moin,
wenn eine KI-basierte Lösung in Betracht gezogen wird, sollte neben der Herstellerkennung auch der Decodertyp und die Softwareversion (ggf. mit Unterversion) berücksichtigt werden.
Zimo z.B. hat beim MX690 im Rahmen der Softwarepflege für den Decoder das Funktionmapping komplett umgestellt, was zur Folge hat, dass die KI das jeweilige Funktionsmapping vor und nach dieser Umstellung anhnad der auf dem Decoder vorhandenen Software bewerten muss. (Bei mir ist diese KI in meinem Gehirn, leider ohne USB Anschluss oder Netzwerkverbindung nach draußen).

Schöne Grüße
Johannes

Zitat von Lokidokter im Beitrag #27

---

Falls jemand von euch sich das zutraut: meine Kundschaft wäre dir sicher! Für so win Gerät inkl Programm würde ich ohne zu zögern 300€ auf den Tisch legen. Das allein ist schon weniger als eine MXULFA ohne Ladegerät und Software und einen ESU LoPro mit allem drum und dran…

---

Ich würde ja wohl nicht der einzige Kunde sein…

Ja, so eine USB Schnittstelle im Nacken wär schon was feines…

Na ja, KI ist hier ein hübsch modischer Begriff. Hier wird das eher auf eine Technik hinauslaufen die schon seit den 70ern des letzten Jahrhunderts bekannt ist.
Natürlich macht es Sinn soweit möglich Software-Version etc. auszulesen und auszuwerten. Das macht es einfach. Leider sind diese Informationen bei optimistischer Schätzung bei vielleicht einem Prozent aller im Umlauf befindlichen Decoder verfügbar...eher weniger.

Hallo Dok!

Zitat von Lokidokter im Beitrag #27

---

Da müsste ein unabhäbgiger Think Tank ran, und dann behaupte ich, wäre das mit einer Art Open Source Plattform, wie etwa einem Arduino/Raspberry Pi möglich. Kann ich das? Nein! Ich kriege mit meinem Arduino maximal eine Signalsteuerung hin… aber es soll ja auch talentierte Leute geben auf dieser Kugel…

---

ist doch ganz einfach:
Jeder decoderhersteller hat einen eigenen programmer, der im detail nur seine decoder bearbeiten kann. Da nennt man kundenbindung.
Wenn man so einen programmer gekauft hat, hofft der herstelller, dass auch nur noch seine decoder gekauft werden.

Die basis-dcc-cv 1 bis 6 und auch die motor cv in den 50gern kann ich aber mit meiner CS3 auch bei esu- oder zimo-decodernn auslesen und verändern.
Nur wenn es um sound aufspielen oder verändern geht, ist ein programmer des jeweiligen decoderherstellers notwendig.

Hubert

Was ist denn aus dem angekündigten Programmer von KM1 geworden? Der soll doch Decoder mehrerer Hersteller auslesen und bearbeiten können.
Wurde vor einiger Zeit als Ankündigung durch die Moba-Presse getrieben, seit dem habe ich nichts mehr davon gehört. Das Gerät würde die hier geforderten Anforderungen erfüllen wenn es das hält was versprochen wird und wenn er endlich erscheinen würde.

Gruß Uwe

Hallo,

naja, eine sehr große Aufgabe... und ich glaube es würde sich nicht lohnen.

Alle Decoder würde auch vergangene Digitalsysteme (FMZ, Zimo-alt, Kato, Conrad usw) bedeuten - wer will diese Arbeit leisten?

Vor allen Dingen gibt es auch zuviele Decoder die garnicht reagieren egal wie man sie auslesen möchte wo nur DIP-Schalter helfen.

Peter

Das Auslesen und Schreiben von Werten in die CVs eines Decoder ist ja nun echt kein Hexenwerk, meine 18 Jahre alte Eigenbau-Zentrale auf Basis eines kleinen PIC 16F628 kann CVs bis 999 lesen und schreiben, sogar dahingehend "komfortabel" das sie einen Ziffernblock hat. Nur muss ich mir halt die Bedeutung der CVs jenseits der genormten CVs und Bits aus den Anleitungen zusammensuchen (90% des Aufwandes) und mir dann die Werte erreichnen bzw. bei dieser Selbstbauzentrale kann ich auch Bits einzeln setzen, das gibt die "Bedienoberfläche" (2x16 Zeichen LCD) her.
Ein Universalprogrammer ist in der Hardware auch nicht mehr, einzig für MFX-Decoder ein RDS-Decoder mit drin und ein Railcom-Detektor damit man auf HW-Ebene alles erschlägt.
Das ist in der Umsetzung eher übersichtlich, aus verschiedenen Einzelprojekten das nötige zusammensammeln und in einen besser motorisierten Arduino (ESP32/RP2040) gebrannt. Das ist in ein paar Abenden geschafft.
ABER: 99,999% der Arbeit ist das Zusammensammeln der Informationen über die Decoder (CVs, Bedeutung, Wertebereiche, Abhängigkeiten...) und darüber eine ordentliche Bedienoberfläche zu stülpen mit der Einsteiger und Fortgeschrittene glücklich werden. Automatische Identifizierung des Decoders, Listen der CVs, möglichst gut sortiert nach Funktionen, mit Beschreibung etc. Die Meisten dieser Daten braucht man ja eh auch für die Identifikation der Decoder.
Hatte neulich das "Glück" mit einer CS3 einen DCC-Decoder parametrieren zu müssen, wenn man nur eben zwei Bits anpassen will ist man selbst mit einer LM2 schneller. Alles was mich daran hindert einfach einer Zentrale zu sagen das sie CV 78 des Decoders auf dem Programmiergleis den Wert 55 verpassen soll nervt mich.
Entweder die Zentrale erkennt von ganz alleine was da auf dem Gleis steht und zeigt mir übersichtlich an was bei diesem Decoder geht, auch einen Lenz-Decoder von 1998, oder sie lässt mich ohne weitere Umwege direkt die Nummer und den Wert des CVs angeben. Solche halbgar umgesetzten Komfortlösungen sind schlimmer als fehlende, die lösen bei mir regelmäßig Schlaganfälle aus. Je nach Gerät mit dem 5 oder 10kg Vorschlaghammer.

Zitat von Stahlblauberlin im Beitrag #38

---

Nur muss ich mir halt die Bedeutung der CVs jenseits der genormten CVs und Bits aus den Anleitungen zusammensuchen (90% des Aufwandes)

---

Zitat von Stahlblauberlin im Beitrag #38

---

ABER: 99,999% der Arbeit ist das Zusammensammeln der Informationen über die Decoder (CVs, Bedeutung, Wertebereiche, Abhängigkeiten...)

---

Meine Korrektur von 90% auf 99,99% erfolgte als ich mir einfach mal die Anleitung eines TAMS LD-G-5 genommen habe und die nötigen Daten dieses steinalten Einfachstdecoders zusammengestellt habe...
Vorgaben jenseits derer die die Decoderhersteller bezüglich der Anpassung insbesondere an die Motoren kann man sich aber sparen, da hängt auch einiges vom genauen Zustand von Lok und Motor selbst ab, inklusive der unvermeidlichen Herstellungstoleranzen. Von individuell umgebauten Loks mal ganz abgesehen...
Eine Beschränkung auf die Decoder muß reichen, auch noch jedes mögliche Modell mit aufzunehmen sprengt dann einfach jeden Rahmen.

Zitat von Stahlblauberlin im Beitrag #40

---

Vorgaben jenseits derer die die Decoderhersteller bezüglich der Anpassung insbesondere an die Motoren kann man sich aber sparen, da hängt auch einiges vom genauen Zustand von Lok und Motor selbst ab, inklusive der unvermeidlichen Herstellungstoleranzen. Von individuell umgebauten Loks mal ganz abgesehen...
Eine Beschränkung auf die Decoder muß reichen, auch noch jedes mögliche Modell mit aufzunehmen sprengt dann einfach jeden Rahmen.

---

Zitat von Hombre im Beitrag #28

---

Bei mir im Einsatz mit DCC++ auf einem Arduino + Motorshield - viel günstiger gehts kaum,

---

Zitat von Ralf9 im Beitrag #42

---

Weiß jemand zu was die 8 Bauteile sind, die mit SS14 beschriftet sind?

---

Hallo Ralf,

ich möchte Dich nicht im Regen stehen lassen.

Das SS14 Bauteil ist eine Diode wie z.B. diese:

Schottky-Diode 40V 1A

Antworten wie google selber usw. sind nicht zielführend und helfen leider nicht weiter.
Schade das es immer wieder geschrieben wird. Nicht jeder kennt sich mit elektronischen Bauteilen aus. Deshalb hier meine Hilfe, wobei ich auch eher Elektroniklaie bin.

Viele Grüße
Jürgen

Zitat von Eckhart im Beitrag #34

---

Das ist das Problem unserer Zeit! Alle suchen irgendwelche "anderen", die die Arbeit für sie erledigen! Nur eben selber richtig reinhauen und es selber reißen ...lernen, lernen, lernen, das wollen sie nicht...

Im Grunde genommen ist es bei meinem anderen Hobby, den Oldtimern, genau das selbe! Kaum ein Treffen, wo nicht irgendjemand einen "anderen" sucht, der ihm was schweißt; oder einen Zylinderkopf revidiert; oder auch beides ;) Oder die neue Garage mit Werkstatt, Grube und Hebebühne für die Schätzchen. Wer rechnet mir die Statik? Wer flechtet mir den Stahl für Bodenplatte mit Grube? Wer mauert und verklinkert mir die Garage? Wer errichtet mir zimmermannsmäßig den Dachstuhl?

Versucht doch mal selber euch die erforderlichen Kenntnisse anzueignen, um eure Visionen umzusetzen! Beim Oldtimer, beim Bauen, bei der Modellbahn, bei xxx!

---

Ich habe mal im Datenblatt vom L298 geschaut, beim L298 sind externe Freilaufdioden notwendig. Das passt dann mit den 8 Dioden.

Ich habe noch ein 12V Netzteil rumliegen, sind ca 11-12V ausreichend um einen DCC Decoder zu programmieren?

Für mich ist es ausreichend, wenn ich die CVs auslesen und schreiben kann. Was ich in welche CVs scheiben muss steht ja in der Decoderanleitung. Da ich keine Decoder mit Sound habe, ist das recht überschaubar.

Zitat von fromue im Beitrag #44

---

Antworten wie google selber usw. sind nicht zielführend und helfen leider nicht weiter.

---

Zitat von _Georg_ im Beitrag #47

---

Zitat von fromue im Beitrag #44

---

Antworten wie google selber usw. sind nicht zielführend und helfen leider nicht weiter.

---

Wenn ungefähr 14.100 Ergebnisse nicht zielführend sind...
Selbst ein Elektrolaie, soweit er lesen kann, findet als ersten Eintrag einen "zielführenden Hinweis".
Und das hat nix mit Elektronikwissen zu tun, sondern einfach nur lesen.

---

Zitat von Ralf9 im Beitrag #46

---

Für mich ist es ausreichend, wenn ich die CVs auslesen und schreiben kann. Was ich in welche CVs scheiben muss steht ja in der Decoderanleitung. Da ich keine Decoder mit Sound habe, ist das recht überschaubar.

---

Maurice:

Was genau kann denn das Sprog3, das eine beliebige standardkonforme Digitalzentrale in Verbindung mit JMRI DecoderPro nicht kann? Die Fähigkeit des einfachen Programmierens unterschiedlicher Decodermarken ist ja eher ein Merkmal der JMRI-Software als der Hardware. Das Sprog ist letztendlich auch nur eine Digitalzentrale mit PC-Anschluss, und den Zweck kann dann auch z.b. ein Arduino mit DCC++ EX erfüllen, und zwar zu einem Bruchteil der Anschaffungskosten, wenn es denn schon ein eigenständiges Gerät sein soll. Aber solange eine schon existente Zentrale von JMRI unterstützt wird, geht das genauso. Und ohne DecoderPro kann das Sprog auch nicht viel.