Decoderadresse, Vergabe nicht möglich: Unterschied zwischen den Versionen
Aus RailRoad&Co.-Wiki
Zur Navigation springenZur Suche springen
Uslex (Diskussion | Beiträge) KKeine Bearbeitungszusammenfassung |
Uslex (Diskussion | Beiträge) KKeine Bearbeitungszusammenfassung |
||
Zeile 2: | Zeile 2: | ||
__NOTOC__ | __NOTOC__ | ||
== Weichendecoder über Rocomotion programmieren == | == Qdecoder Weichendecoder über Rocomotion programmieren == | ||
=== Vergabe nicht möglich? === | === Vergabe nicht möglich? === | ||
Zeile 29: | Zeile 29: | ||
[[Kategorie:Hardware]] | [[Kategorie:Hardware]] | ||
[[Kategorie:Roco]] | [[Kategorie:Roco]] | ||
[[Kategorie: QDecoder]] |
Version vom 12. Februar 2022, 18:12 Uhr
Qdecoder Weichendecoder über Rocomotion programmieren
Vergabe nicht möglich?
Ich selbst und auch schon andere Kollegen haben die Erfahrung gemacht, dass das Programmieren einer bestimmten Decoderadresse nicht möglich ist. Die Ursache liegt an der unterschiedlichen Berechnung der Decoderadresse.
Bei Decodern mit 4 Adressen
- gewünschte Adresse = 5
- da 5 nicht ohne Kommastelle durch 4 teilbar ist, muss die Zahl "1" abgezogen werden, dann wird durch "4" geteilt - ergibt die "1" zu dieser muss wieder eine "1" hinzugezählt werden, ergibt die endgültige Zahl Zwei als Decoderadresse
- gewünschte Adresse = 9
- 9 weniger 1 = 8 / 4 = 2 + 1 ist Drei als Decoderadresse
- Die Firma AMW Hübsch bietet hier eine Umrechnungsapplikation.
- 9 weniger 1 = 8 / 4 = 2 + 1 ist Drei als Decoderadresse
Bei Decodern mit 8 Adressen
- die erste Adresse muss durch "8" ohne Kommastelle teilbar sein.
- zu dieser Adresse wird dann die "1" hinzugezählt, dieser Wert ist zu programmieren.
Diese Vorgehensweise nur bei Verwendung in bestimmten Hardwarekonstellationen notwendig.
Quelle: Forum
Wohlmannstetter 10:26, 14. Apr. 2013 (CEST)