• Hallo TT-Modellbahner, schön, dass du zu uns gefunden hast.
    Um alle Funktionen nutzen zu können, empfehlen wir dir, dich anzumelden. Denn vieles, was das Board zu bieten hat, ist ausschließlich angemeldeten Nutzern vorbehalten. Du benötigst nur eine gültige E-Mail-Adresse und schon kannst du dich registrieren.
    Deine Mailadresse wird für nichts Anderes verwendet als zur Kommunikation zwischen uns.
    Die Crew des TT-Boardes

Digital PIKO PSD 4.1 mit JMRI - DecoderPro programmieren / konfigurieren

Dr. Ulfi

Foriker
Beiträge
146
Reaktionen
79 2
Ort
Troisdorf
Zum Titel: Das Einstellen von CV als Programmieren zu bezeichnen ist etwas übertrieben. Daher bevorzuge ich den passenderen Begriff des Konfigurieren.

Die Unterstützung der Piko Smart Decoder ist in JMRI - DecoderPro bisher sehr unzureichend implementiert. Dabei ist JMRI - DecoderPro eine recht brauchbare Alternative zum (derzeit nicht lieferbaren) Piko Smart Programmer. Daher habe ich mir mal die Mühe gemacht die Decoder Dateien für die Piko Sound Decoder zu überarbeiten. Begonnen habe ich mit dem PSD 4.1 für die Soundloks BR 55 #46440 Next 18, BR 130 #46442-Plux16 und die BR 119 #46443-PluX22, also Decodertypen der Spur TT. Weitere Decodertypen könnten folgen. Nun suche ich noch jemanden, der mir beim Testen und auch verbessern helfen würde, bevor ich diese Decodertypen in JMRI einbinden lasse. Wenn also jemand Interesse hat oder auch schon eigene Entwicklungen gemacht hat, kann sich gerne melden.

Aktuell arbeite ich am PSD XP 5.1 für die BR83.10. Hier sind noch einige Punkte offen, die Dokumentation ist leider sehr zurückhalten.

Abendliche Grüße
Ulrich
 
Dafür sind doch laut DCC nur CV7 = Version und CV8 = Herstellerkennung vorgesehen. Bei dem PSD XP 5.1 ist CV8 = 162. Leider nutzt Piko die CV7 für die Firmware-Version, andere Hersteller nehmen es für den Decoder-Typ.
 
...nutzt Piko die CV7 für die Firmware-Version, andere Hersteller nehmen es für den Decoder-Typ...
lt. RCN-225 ist CV7 die "Decoder Versionsnummer" - was das aber genau heißt, scheint wirklich frei wählbar zu sein.
Genügend herstellerspezifische CVs gibt es auch, so dass sich jeder Hersteller darin verwirklichen kann.

Zimo (im Handbuch beschrieben):
CV7 SW-Hauptversion
CV65 SW-Subversion
CV250 Decodertyp

ESU macht es noch wilder (auf der HP unter FAQ zu lesen):
in CV7 steht z.B. 81 für LS3.5, 255 für LS4, ??? für LS5 - also eher die Decodergeneration
CV288 Firmware Major version
CV287 Firmware Minor version
CV285+286 Firmware Built-Number
CV261-264 Decodertyp

Vielleicht gibt es bei/von Piko auch noch eine Beschreibung wie/wo das bei denen verschlüsselt ist?
Mal direkt beim Support anfragen?
 
Leider habe ich keine CV finden können, die den Decodertyp bei Piko ausgibt. Da aber die CV7 bei Piko 4.1 erst mit 30 beginnt, zumindest bei den mir bekannten Typen, und der XP 5.1 derzeit noch unter Version 10 ist, kann DecoderPro damit die beiden Decodertypen unterscheiden. Welchen genauen Loktyp man programmieren will, muss man jedoch noch manuell auswählen.

Wenn die erste Version von DecoderPro mit den Piko Decoder Files zum Download bereitsteht, kann ich bei Interesse gerne noch weitere Sound-Loks hinzufügen.
 
Mit JMRI 5.3 lassen sich jetzt PIKO Decoder PSD 4.1 und PSD XP 5.1 programmieren. Auch der Lichtdecoder der BR 83.10 wird unterstützt, so das die Funktionstasten für die Führerstands- und die Fahrwerksbeleuchtung geändert werden können.
 
Hallo Dr. Ulfi, JMRI benutze ich auch. Aber das ist ja nur die halbe Wahrheit, denn die eigentliche Kommunikation mit dem Decoder läuft über die Zentrale. Hier benutze ich einen Locobuffer von RR-Cirkit und eine Digitrax DCS50. Leider tut sich diese Zentrale bei einigen Decodern schwer, unter anderen einigen Uhlenbrocks und Tran/CT-Decodern. Pikos habe ich deshalb gar nicht erst versucht. Wie sieht denn deine Arbeitsumgebung aus?
Gruß, Meyer.motzen
 
Ich habe die z21, die kann Railcom. So ist es möglich vernüftig über POM (lesen und schreiben) zu programmieren. Und das Eeinlesen der CVs ist viel schneller. Außerdem habe ich auch noch eine DCC++EX Zentrale, die unterstützt jedoch leider kein Railcom. Auch heute ist das noch eine sehr preisgünstige Alternative und für einen Test- und Programmierkreis die optimale Lösung. Damit konnte ich bisher jeden Decoder programmieren. Außerdem kann man damit sehr preiswerte Gleis-Besetz-Meldungen realisieren.

Gruß Uli
 
Zurück
Oben