Ich habe eine Frage die mich beschäftigt:
Warum trennt man bei den Dekodern nicht die Steuerung von den Leistunsteilen ?
Es gibt genug kurzschuss- und thermisch-abgesichere kleine Endstufen. Die kann man für Sound, Motoren und LEDs verwenden.
Aber vielleicht wird das eh so gemacht und ich schreib hier ins blaue
Beim Motor scheitert es in der Regel an der Möglichkeit die Gegen-EMK vernünftig zu messen. Bei den Funktionsausgängen wäre das wohl eher denkbar, dort ist es dann eher eine Kostenfrage.
Im Zuge einiger Anpassungen an die RCN/NMRA Normen wird dies die letzte Software Version sein mit der
Kurzer Abstecher. Kann das von mir hier beschriebene Phänomen damit zu tun haben?
Zimo auf Messen angesprochen auf das zauberte nur ein großes Fragezeichen in die Gesichter der Mitarbeiter
LG, Manfred
Hm, klingt aufs erste nicht danach. Das Problem war soweit ich mich erinnere dass die "Sets-CVs" innerhalb der .zpp Datei verschoben waren. Das fiel lange Zeit nicht auf weil die MS-Decoder erst im Zuge eines Firmware Updates die "Sets" bei jedem Soundload aktiviert haben und nicht erst wenn man CV265 schreibt.
Achso herum. Ok.
Ja ich frag so doof weils, soweit ich mich erinnere, um den Jahreswechsel 24/25 rum eine Zeit gab wo ZSP teil-defekte .zpp Datein erzeugt hat bei denen der CV8=8 Reset zu einer Verschiebung der CVs führte. 
Es ist eine Roco 50.35 (70288) mit Sound ehemals ab Werk. Da habe ich den Reset gemacht.
Seit der Intermodellbau 2026 ist ZSP01005 drauf.
Hab da jetzt ein paar mal hintereinander CV8=8 gschrieben und kann ad-hoc keine Probleme feststellen. (Decoder Version von der ZIMO Homepage)
Bei mir war der Sound bei CV8 = 8 weg.
Weißt du zufällig welches Soundprojekt da genau drin steckt?
Falls nein kannst du bitte CV254-257 auslesen?
Entschuldig'n der Herr, I miassat do eigentlich sitzn.
Hilfe beim neuen HO einrichten
Nachdem ich letztens im RocRail Forum einen Thread zu einem "DCC Sniffer" beobachtet hab wundert mich auch dass der ganze Spaß so stabil läuft wie es das tut... aber gut, da stecken ja auch Jahr(zehnte?) drin.
Solange niemand gewillt ist sich an echter OSS Software zu beteiligen wird sich die Ist-Situation aber halt auch nicht ändern.
Kritikfähig zu sein gehört meiner Ansicht nach zu den Skills eines guten Software-Entwicklers. Natürlich kann ma ab und zu mal etwas heiß laufen, es is halt einfach unendlich zach sich wo reinzuknien und dann immer und immer wieder nur das negative Feedback zu hören... aber so is das einfach in dem Bereich. Über Dinge die funktionieren regt sich keiner auf.
Danke, schau ich mir kommende Woche mal an
v0.7.1 ist online
Hier mal eine Wireshark Aufzeichnung zw. einer echten Z21 und DecoderPro
image.png
DecoderPro scheint auf die LocoNet Rückmeldung zu warten... sonst läufts beim CV Schreiben ins Timeout. Selbes Problem eben beim Fahrpult. Wieso man das so programmiert hat weiß ich nicht, jedenfalls sorgts halt für Probleme solange meine Zentrale kein LocoNet spricht.
Ja, auch hier. Nicht Z21 Protokoll 
ZCS und die Z21 App haben auch keine Probleme mit dem OpenRemise... :p
Ok, ich habe mich nicht ganz eindeutig ausgedrückt.
Ich rede vom Z21 Protokoll und dessen (fragwürdiger?) Implementierung in DecoderPro. Das hat mit BiDiB natürlich nichts zu tun.
Z"!?
DecoderPro benötigt zum PoM CV Schreiben und fürs Fahrpult aus irgendeinem Grund LocoNet. Solangs das nicht gibt kann das auch nicht funktionieren.
Nix tu Sonntag
Das was das MXULF unter dem Menüpunkt "PowerCycle" macht, macht das OpenRemise immer. Da gehts darum ob der Bootloader durch CV Lesen oder durch einen Reset angesprungen wird.
