Hallo,
Zitat
Jetzt verstehe ich die Threads die besagen, man bräuchte für Zimo Dekoder einen Doktortitel. Ich habe zwar einen, aber verstehen tu ich trotzdem nichts. Anscheinend reicht MAschinenbau nicht aus
Mit Atomphysik hätte es vielleicht geklappt
Das ist keine Erfindung von ZIMO, sondern der NMRA.
Fast alle DCC-Decoder mit diesem Funktionsumfang bedienen sich derselben standardisierten Technik, bekannt als "Function Mapping".
Dann gibt es jene Ausreisser wie Lenz und ESU, die die ganze Geschichte dadurch komplizieren, dass sie Hundertschaften von CVs verschleissen für ein paar simple Einstellungen (ESU), oder Funktionen in unauflösbare, willkürlich gewählte logische Abhängigkeiten zwängen (Lenz).
Dann gibt`s noch den amerikanischen Sounddecoder-Hersteller QSI, der
für einen Sounddecoder ein 180-bis 200-seitiges Handbuch schreiben muss und darüber hinaus den Entwickler Gerry Pruss abgestellt hat zur Beantwortung von Kundenfragen bezüglich Decodereinstellungen, der auf der entsprechenden Yahoo! users group noch weitere ergänzende Dokumentationen hinterlegt.
Gegen diese drei Mitbewerber ist ZIMO ein "piece of cake".
Das Gegenbeispiel, wie man es auch nicht machen soll, liefert Märklin mit seiner rudimentären Volltext-Menü-Führung, die den User im Unklaren darüber lässt, was z.B. wohl unter "Regelungseinfluss" zu verstehen ist, wenn man über die Register gehen muss (Siehe entsprechenden Thread). Alles dazu angetan, den Kunden möglichst auf die eigenen überteuerten Produkte festzulegen (Märklin mfx ist nun mal teurer als ESU/ESU mfx).
Und zum x-ten Mal: Wer sich nicht durch die Bits und Bytes prügeln will,
findet reichlich computer-gestützte Hilfe, z.B. ZIMO PFuSch, JMRI DecoderPro, ESU LokProgrammer sowie deutschsprachige Programmier-Programme, einige davon, z.B. JMRI (englisch, deutsch rudimentär), als Freeware.
Gruss,
Manfred