Loksound - Einmessen - Auswirkung auf Bremsverhalten: Unterschied zwischen den Versionen

Aus RailRoad&Co.-Wiki
Zur Navigation springenZur Suche springen
KKeine Bearbeitungszusammenfassung
Zeile 15: Zeile 15:
Jens Mohr hat eine Begründung: [[Medium:TC-Wissen_Kommunikation-WiKi.pdf|TC-Wissen_Kommunikation-WiKi.pdf]] geliefert, Kapitel 8.2.3 (Seite 30).
Jens Mohr hat eine Begründung: [[Medium:TC-Wissen_Kommunikation-WiKi.pdf|TC-Wissen_Kommunikation-WiKi.pdf]] geliefert, Kapitel 8.2.3 (Seite 30).


Bedingt durch die relativ schlechte Kontaktsituation (Rad - Schiene), verglichen mit festen Verbindungen, muß davon ausgegangen werden, daß es mehrerer Versuche bedarf bis eine Nachricht von der Zentrale zu einem Lokdekoder durchkommt, d.h. von diesem fehlerfrei "gelesen" wurde.
Bedingt durch die relativ schlechte Kontaktsituation (Rad - Schiene), verglichen mit festen Verbindungen, muß davon ausgegangen werden, daß es mehrerer Versuche bedarf bis eine Nachricht von der Zentrale zu einem Lokdecoder durchkommt, d.h. von diesem fehlerfrei "gelesen" wurde.


Handelt es sich bei diesem Dekoder um einen Multi - Protokoll und Multi - Funktions und Sound - Dekoder, so haben wir es mit einer recht umfangreichen internen Programmierung (Firmware) zu tun.
Handelt es sich bei diesem Decoder um einen Multi - Protokoll und Multi - Funktions und Sound - Decoder, so haben wir es mit einer recht umfangreichen internen Programmierung (Firmware) zu tun.
Es ist davon auszugehen, daß es einer ganzen Reihe von Abfragen und Entscheidungen bedarf, bis die jeweils zuständige SW-Routine (vergl. Bus - Nachricht) aktiviert wird und alles abarbeiten kann.
Es ist davon auszugehen, daß es einer ganzen Reihe von Abfragen und Entscheidungen bedarf, bis die jeweils zuständige SW-Routine (vergl. Bus - Nachricht) aktiviert wird und alles abarbeiten kann.


Zeile 28: Zeile 28:
Ferner läuft diese interne Bearbeitungszeit "gegen" die Weg-Zeit-Berechnung in TC.
Ferner läuft diese interne Bearbeitungszeit "gegen" die Weg-Zeit-Berechnung in TC.


Ist der Dekoder mit seinen Einstellungen zeitlich zu langsam, dann kommt es zu einer realen Wegverlängerung beim Bremsen und Halten.
Ist der Decoder mit seinen Einstellungen zeitlich zu langsam, dann kommt es zu einer realen Wegverlängerung beim Bremsen und Halten.
Eine immer wieder im TC Forum beschriebene Situation, die insbesondere bei Sound-Dekodern zu beobachten ist.
Eine immer wieder im TC Forum beschriebene Situation, die insbesondere bei Sound-Decodern zu beobachten ist.


=== Fazit für den Einmeßvorgang ===
=== Fazit für den Einmeßvorgang ===


'''Dekoder sollten deshalb bei dem Einmeßvorgang so betrieben werden, wie dies auch später auf der Anlage der Fall ist.'''
'''Decoder sollten deshalb bei dem Einmeßvorgang so betrieben werden, wie dies auch später auf der Anlage der Fall ist.'''


Diese Anforderung gilt auch für die Meßstrecken. Liegen diese in ihren realen Längen zu weit auseinander, dann kommt es ebenfalls zu Abweichungen.
Diese Anforderung gilt auch für die Meßstrecken. Liegen diese in ihren realen Längen zu weit auseinander, dann kommt es ebenfalls zu Abweichungen.

Version vom 3. Juli 2022, 14:07 Uhr

Verwendung
thumbs


Soundloks Einmessen

Frage

Sehr häufig beklagen Modellbahner, dass Loks mit Sounddecoder (Soundlok) trotz genauem Einmessen nicht am gewünschten Haltepunkt stehen bleiben. So zum Beispiel hier im Forum.

Einmessen mit eingeschaltetem Sound

Wenn man üblicherweise mit Sound fährt, dann sollte auch das Einmessen mit eingeschaltetem Sound durchgeführt werden.

Begründung

Jens Mohr hat eine Begründung: TC-Wissen_Kommunikation-WiKi.pdf geliefert, Kapitel 8.2.3 (Seite 30).

Bedingt durch die relativ schlechte Kontaktsituation (Rad - Schiene), verglichen mit festen Verbindungen, muß davon ausgegangen werden, daß es mehrerer Versuche bedarf bis eine Nachricht von der Zentrale zu einem Lokdecoder durchkommt, d.h. von diesem fehlerfrei "gelesen" wurde.

Handelt es sich bei diesem Decoder um einen Multi - Protokoll und Multi - Funktions und Sound - Decoder, so haben wir es mit einer recht umfangreichen internen Programmierung (Firmware) zu tun. Es ist davon auszugehen, daß es einer ganzen Reihe von Abfragen und Entscheidungen bedarf, bis die jeweils zuständige SW-Routine (vergl. Bus - Nachricht) aktiviert wird und alles abarbeiten kann.

Auch hier benötigt jeder SW-Befehl eine Reihe von Taktzyklen des μ-Processors. Die interne Geschwindigkeit ist also abhängig von dem μ - Processor (Typ), der Art der Programmierung und dem Umfang der Funktionen.

Reale Fahrzeit läuft "gegen" interne Bearbeitungszeit

Somit läuft auch hier die reale Fahrzeit "gegen" die interne Bearbeitungszeit. Ferner läuft diese interne Bearbeitungszeit "gegen" die Weg-Zeit-Berechnung in TC.

Ist der Decoder mit seinen Einstellungen zeitlich zu langsam, dann kommt es zu einer realen Wegverlängerung beim Bremsen und Halten. Eine immer wieder im TC Forum beschriebene Situation, die insbesondere bei Sound-Decodern zu beobachten ist.

Fazit für den Einmeßvorgang

Decoder sollten deshalb bei dem Einmeßvorgang so betrieben werden, wie dies auch später auf der Anlage der Fall ist.

Diese Anforderung gilt auch für die Meßstrecken. Liegen diese in ihren realen Längen zu weit auseinander, dann kommt es ebenfalls zu Abweichungen.

Weblinks


-- 18:37, 20. Okt. 2014‎ Wohlmannstetter
bearbeitet: Uslex (Diskussion) 09:36, 14. Jun. 2022 (CEST)
Abgerufen von „https://tc-wiki.de/index.php?title=Loksound_-_Einmessen_-_Auswirkung_auf_Bremsverhalten&oldid=9169“