SUSI Technische Erkenntnisse und Fallstricke

    • Offizieller Beitrag

    Hallo Modellbahner


    Im Zusammenhang mit unserem kleinen Projekt BR50 Adapterplatine bin ich gezwungenermaßen auch mit den SUSI-Spezifikationen der verschiedenen Decoderhersteller in Kontakt gekommen. Wie ich befürchtete sind die Unterschiede zwischen den Takt- und Datenraten unter den Herstellern sehr verschieden. Da ich einige Überraschungen während der Entwicklung erlebt habe, will ich diese Erkenntnisse hier sammeln um meinen potenziellen Mitstreitern in der Programmierung von Microcontrollern von vorneherein einigen Ärger zu ersparen.
    Vorneweg sei gesagt, dass auch ich in die Falle getappt bin. Und das wider besseren Wissens. Da könnte man sich ein silbernes Monogramm in den Allerwertesten beißen.... :evil:


    ACHTUNG: Wer jetzt denkt, dass die Hersteller der Decoder etwas falsch gemacht haben, der irrt!! Alle Parameter aller Hersteller liegen in der Toleranz der RCN-600, aber genau das ist das Problem.

    HINWEIS: Diese Erkenntnisse beruhen auf meinen eigenen Messungen und subjektiven Wahrnehmungen. Ich übernehme also keine Gewähr auf Richtigkeit und Vollständigkeit der gemachten Angaben. Auch dient dies keiner Qualitätsprüfung der genannten Decoder und Hersteller oder läßt eine Aussage darüber zu.


    Dieser Thread wird also sehr technisch werden, ich werde trotzdem versuchen mit der Sprachauswahl so zu bleiben das auch der Nichtelektroniker einigermaßen folgen kann. -unver-


    Im Rahmen unseres Projektes hatte ich Decoder der Firmen TAMS, ESU, Uhlenbrock, Lenz und D&H im Test auf der Lokplatine. (Alle mit PluX16/22 Schnittstelle. Außer dem ESU LokSound der zusätzlich in der Variante 21MTC vorliegt) Alle aus der aktuell laufenden Produktion, also von der Ladentheke auf die Prüfstand. Die genaue Typenbezeichnung der einzelnen Decoder schenke ich mir, da meine Messungen ergeben haben, dass die angewandten Verfahren der SUSI-Datenübertragung innerhalb der Decoderfamilien offensichtlich gleich sind und sich nur durch den Hersteller unterscheiden.


    In diesem ersten Teil beschäftige ich mich mit den Datenübertragungsraten und Formaten sowie den daraus resultierenden Konsequenzen für den Decoderbau. In der Betrachtung liegt der Schwerpunkt auf dem Taktsignal (ZBCLK), welches die Datenübernahme (ZBDATA) am SUSI-Decoder (Soundmodul etc.) steuert. Die Daten sind gültig, wenn die Flanke des Taktsignals abfällt. (5V -> 0V) Just in diesem Moment muß der SUSI-Decoder den Eingang für die Daten lesen und bekommt eine logische eins oder eine null als Ergebnis. Die Länge des Taktsignals, oder besser der zeitliche Abstand zwischen zwei fallenden Flanken, ist für die Verarbeitungsmethode im SUSI-Decoder von ausschlaggebender Wichtigkeit. Ich will die beiden in Frage kommenden Methoden im folgenden etwas näher beleuchten.


    Hardwarelösung:
    Bei dieser Variante nutzt man die in den meisten Microcontrollern eingebaute und vorhandene universelle serielle Schnittstelle. Diese arbeitet mit einem fest auf dem Chip verbauten Schieberegister welches die zeitliche Übernahme zwischen Takt und Daten ohne Zutun übernimmt. Ist ein gültiger Datensatz empfangen wird dieser in einen vorher definierten Speicherbereich verschoben und steht dem Anwenderprogramm zur Auswertung zur Verfügung.
    Vorteil: Damit sind hohe Taktraten möglich bis zu 1MHz und damit hohe Datenraten. Das Anwenderprogramm braucht sich "nur" um die Auswertung der eintreffenden Daten zu kümmern. Das ganze funktioniert auch noch, wenn sich die Taktrate während der Übertragung ändert.
    Nachteil: Diese Variante belegt am Microcontroller minimum 3 bei einigen Typen 4 /IO-Ports, die bei den meisten Controllern auch noch an bestimmten Pin's anliegen müssen. Dies kann zu Problemen im Leiterplattendesign führen. (Im Datenblatt des Microcontrollers nachzulesen) Für einen reinen SUSI-Decoder werden aber nur effektiv 2 gebraucht. Außerdem erfordert diese Variante einen schaltungs- oder zumindest softwaretechnischen Kunstgriff wenn der SUSI-Decoder über CV's programmiert werden soll. Gilt es doch die Datenleitung nach Empfang einer CV kurz auf Masse (Acknowledge) zu ziehen. Das bedeutet in diesem Fall entweder die softwaretechnische Umkonfiguration für die Dauer des Acknowledge und anschließende Rückkonfiguration oder aber einen zusätzlichen Ausgang der das erledigt. (Dies sind nur mögliche Szenarien)


    Softwarelösung:

    Diese Variante empfängt die Daten durch ein vom Anwender geschriebenes Decoderprogramm. Realisieren kann man das, wenn man am Takteingang lauscht und bei einer fallenden Flanke bei ZBCLK einen Interrupt auslöst. Dieser Interrupt unterbricht sofort das laufende Anwenderprogramm und schaut am Dateneingang ZBDATA nach welches Signal da anliegt. (Eins oder Null) Dieses Signal wird dann per Anwenderprogramm in ein softwaretechnisches Schieberegister geschrieben und nach Empfang eines vollständigen Datenpaketes zur Weiterverarbeitung bereit gestellt. Dieses Verfahren wird auch häufig als "Bit banging" bezeichnet.
    Vorteil: Es werden maximal 2 Pins am Controller benötigt deren Position auch meistens frei wählbar ist. Ein Acknowledge läßt sich ebenfalls leicht realisieren ohne den Controller komplett umzukonfigurieren. Auf Besonderheiten im Takt oder Datensignal kann leicht reagiert werden.


    Nachteil: Die maximale Taktrate und damit verbundene Datenrate ist auf wenige kHz beschränkt. Die im Controller benötigte Programmausführungszeit und der Reaktionszeiten an den universellen I/O-Pins (Latenzzeit) führt dazu, dass das Auswerteprogramm einfach nicht mehr hinterher kommt.



    Zusammenfassung:

    Wie man an den weiter unten gezeigten Oszillogrammen erkennen kann, ist es zwingend erforderlich die Hardwarelösung zur SUSI-Decodierung heranzuziehen. Trotz der genannten Nachteile ist damit die Kompatibilität zu den meisten Decoderherstellern gewährleistet. An dieser Stelle bin ich bei unserem Prototypen gescheiter, da ich die Softwarelösung eingebaut habe. Da ich bisher ausschließlich ESU-Decoder verbaut habe habe ich mir auch gleichzeitig den Decoder mit den längsten Taktraten ausgesucht. Gelernt habe ich daraus, zuerst einmal der Norm in der schärfsten aller Möglichkeiten, in diesem Falle der geringsten Taktrate und nicht meinen Messergebnissen zu vertrauen.

    Wie dem auch sei Uhlenbrock und ESU-Decoder funktionieren mit der Softwarelösung, alle anderen nicht!


    ESU Lokpilot V4 und Loksound V4 in PluX22 und 21MTC



    Wie man sehen kann überträgt ESU ein komplettes Datenwort in einem Stück. Bei einer Periodendauer von 260µs pro Takt genügend Zeit um darauf per Software zu reagieren. Die Frequenz liegt dabei bei etwa 3,8kHz.



    Uhlenbrock PluX16 und PluX22 Adapter ohne Sound



    In diesem Falle ist sogar zwischen jedem Datenbyte (8Bit) noch eine anständige Pause.Die Periodendauer ist etwas kürzer als bei ESU aber mit 200µs und einer Frequenz von 5kHz immer noch sehr gemütlich.



    Lenz PluX22 ohne Sound



    Hier wird es relativ schnell. Die Periodendauer liegt bei 20µs und die Frequenz bei 45kHz. Die RCN-600 schreibt Größer gleich 20µs und kleiner gleich 1000µs Periodendauer vor. Passt also Haargenau.



    D&H PluX22 ohne Sound



    Ähnlich wie bei Lenz jedoch ohne Pause zwischen den beiden Bytes. Das geht bei der Übertragung eines Wortes noch prima, da in den Empfangspuffer z.B. meines Controllers immer zwei Bytes passen. Bin gespannt, wie das bei der CV-Programmierung läuft, da werden dann 3 Bytes übertragen.



    Damit möchte ich den ersten Teil der Info abschließen und hoffe, dass es dem Einen oder Anderen hilft.



    Mit freundlichen Modellbahnergrüßen


    Thomas



    ESU Loksound und Lokpilot V4 PluX22 und 21MTC

  • Hallo Thomas
    Wenn ich das soweit richtig verstanden habe, dann sind der D&H und Lenz in den Bildern "nur" zur Verdeutlichung der Unterschiede aufgeführt und Du hast im Moment zwei Decoderfamilien/Hersteller, die Funktionieren.
    Nähmlich Esu und Uhlenbrock?


    Die von Dir beschriebene Hardwarelösung bezieht sich auf die beiden PIC's auf Deiner Platine - korrekt? Und damit auch Verbunden die nicht lösbare Herausforderung 4 spezifische IO's an einer definierten Stelle zu platzieren? Das Projekt ist doch recht komplex...


    LG,
    Axel

    • Offizieller Beitrag

    Moin Axel,


    der Reihe nach. Im Moment laufen beide Decoder mit der Softwarelösung und es kommen aufgrund des Timings nur ESU und Uhlenbrock in Frage. Es ist richtig, dass sich die Hardwareänderung auf die beiden PIC's bezieht, aber das ist auf keinen Fall unlösbar. Es erfordert aber ein Redesign des Platinensatzes und damit einer neuen Revision. Eingänge sind auf beiden PIC's noch genügend vorhanden, so dass sich am Funktionsumfang nichts ändern wird. (Es bleiben sogar noch zwei freie übrig!) Aber wir sind im Prototypenstadium!!!! Das dabei was schief geht ist eigentlich klar, spannend ist immer nur an welcher Stelle im Projekt der Gizmo wohnt und wie viele Kumpel er bei sich hat. Wir haben ihn gefunden, er wohnt alleine und ihm gekündigt Die Zwangsräumung folgt in Kürze. :)


    Ich habe mit der Adapterplatine des Platinensatzes und mit einem auf einem Steckbrett aufgebauten 16F690 einen Versuch der neuen Hardwarelösung gefahren. Ich kann sagen, dass zumindest LENZ schon daran läuft. Ich kann alle Daten empfangen. Was ich noch testen will ist die Methode das Acknowledge zu senden wenn CV's programmiert werden sollen.Wie das gehen könnte habe ich ja oben beschrieben. Da ich schon mal so weit bin bietet sich förmlich an einen "Sniffer" zu programmieren, der mir alle empfangenen Befehle auf den PC überträgt. Deshalb bin ich jetzt sehr entspannt. Im Grunde bin ich, wie gesagt selbst Schuld an der Sache und es hätte von vorneherein ausgeschlossen werden können. Aber, so ist das Leben.


    Mit freundlichen Modellbahnergrüßen
    Thomas

    • Offizieller Beitrag

    Hallo Modellbahner,



    ich möchte mir heute erlauben, einen etwas tieferen Einblick in die serielle Datenübertragung der SUSI-Schnittstelle zu geben.
    Ich war mir zu Beginn des Fadens nicht sicher ob es für Euch von Interesse ist hier so weit einzusteigen, aber die Zugriffe und Likes
    haben mich den Mut fassen lassen etwas weiter einzusteigen. Vorab möchte ich Euch auf einen kleinen Ausflug in die Grundlagen
    der Digitaltechnik mitnehmen. Aufbauend darauf will ich dann das SUSI-Protokoll darstellen.
    Wer etwas mit den Begriffen „Bit“, „byte“, „Word“ anfangen kann,der kann diesen Teil ruhig überspringen und direkt zum Abschnitt
    der Decodierung der SUSI Datenpakete gehen.



    Sicherlich ist jedem bekannt, dass Informationen in der Digitaltechnik in Form von „Einsen“ und „Nullen“ übertragen und verwendet werden.
    Zumindest hat jeder schon einmal davon gehört und gelesen.Diese „Einsen“ und „Nullen“ stellen dabei die kleinste Informationseinheit dar.
    Diese kleinste Informationseinheit nennt man Bit. So ein Bit kann zwei Zustände annehmen, nämlich die oben erwähnte „Eins“ oder „Null“
    oder „Strom An“ und „Strom Aus“.


    Das folgende Bild zeigt diesen Zusammenhang anhand einer einfachen Lampenschaltung, so wie sie jeder mehrfach im Haus hat.




    Diese beiden Zustände kann man folgendermaßen zusammenfassen.

    "Eins" =Strom „An“ =High = true.
    „Null“ = Strom „Aus“ = Low = false.



    Die Begriffe High und Low werden meist in der Elektronik verwendet, wenn es um messbare Pegel an einem Bauteil geht.
    True und False dagegen in der Programmierung bei der Bildung und Abfrage von logischen Zuständen.



    Dezimales und duales Zahlensystem


    Wie jeder sehen kann ist ein einziges Bit nur in der Lage zwei Zustände zu übertragen.Oder andersherum gesehen nur zwei Zahlen,
    nämlich 1 und 0. (Das kommt uns in der Computertechnik wie gerufen, kann der Computer doch auch nur Strom An von Strom Aus unterscheiden.)
    Dieses Zahlensystem nennt man auch Dualsystem, da es wie gesagt mit nur zwei Zahlen auskommt.Jeder von uns rechnet aber jeden Tag
    im Dezimalsystem. Das Dezimalsystem kennt neben 0 und 1 noch die Zahlen 2 bis 9. Das Dezimalsystem ist für uns so selbstverständlich,
    dass wir locker im Kopf den Übertrag bilden können, ist eine Zahl einmal größer als neun. Im Dualsystem verhält es sich exakt genauso wie im
    Dezimalsystem, nur dass der Übertrag nicht bei der Zahl 9, sondern bei der Zahl 1 entsteht.


    Beispiel: Im Dezimalsystem ständen auf meinem Einkaufszettel 2 Eier. Im Dualsystem dagegen 10 Eier. ?(


    Das stellt sich die Frage was zu tun ist, um neben Eiern zum Beispiel die Geschwindigkeit einer Lok im Bereich von 0-127 im Computer
    verständlich darzustellen? Wir brauchen also ein Verfahren, um die Dezimalzahlen in Dualzahlen umzuwandeln oder einen Konverter.
    Da ich hier keine Mathematikstunde geben möchte, belassen wir es bei einem kleinen Beispiel.Wer da tiefer einsteigen möchte,
    das Netz ist voll von Tutorien.


    Der Einfachheit halber gehen wir gedanklich den umgekehrten Weg. Nehmen wir an, wir möchten die Lokfahrstufe die in einer Dualzahl
    dargestellt ist im Dezimalsystem wissen. Oben sprach ich davon, dass bei einer Zahl größer als Eins ein Übertrag stattfindet.
    Dazu hat jede Stelle in einer Dualzahl einen entsprechenden Stellenwert im Dezimalsystem. Der Stellenwert errechnet sich aus dem
    vielfachen des Exponenten der Zahl 2. Der Exponent gibt also gleichzeitig die Position des einzelnen Bits bei 0 beginnend an.
    Addiert man jetzt die entsprechenden Stellenwerte zusammen, kommt man auf den Wert im Dezimalsystem.
    Hört sich kompliziert an, ist aber simpel. Das folgende Beispiel soll es verdeutlichen:



    Um die Dualzahl jetzt umzuwandeln, addiert man einfach alle dezimalen Stellenwerte (zweite Reihe) unter denen
    eine 1 in der Dualzahl steht (dritte Reihe). Man sagt auch: Nur die gesetzten Bit’s addieren.


    1 + 8 + 16 = 25 = Wert der Lokfahrstufe



    Wer möchte, kann ja jetzt mal mit den Zahlen spielen und nachschauen welche größte Dezimalzahl sich mit den 8 Stellen (Bits)
    der Dualzahl darstellen lässt. Um mehrere Bits zusammenzufassen hat man sich etwas einfallen lassen und Gruppen einzelner Bits
    mit Sammelbegriffen versehen.Es gibt noch mehr Bezeichnungen aber für unsere weiteren Betrachtungen sind nachfolgend aufgeführte Begriffe ausreichend.


    BYTE (8Bit)
    Eine Zahl die in 8 einzelnen Bits, so wie in unserem Beispiel, dargestellt wird nennt man auch ein Byte.Mit einem Byte (8Bit) kann ich alle Zahlen zwischen 0 und 255 darstellen.


    WORT (16Bit) (engl. Word)
    Zwei Byte ergeben ein Wort.Mit einem Wort (16Bit) können alle Zahlen zwischen 0 und 65.535 dargestellt werden.


    DOPPELWORT (32Bit) (engl. Double)
    Mit einem Doppelwort lassen sich alle Zahlen zwischen 0 und 4.294.967.295 darstellen


    Programmierer arbeiten zusätzlich (eigentlich meistens) mit einem weiteren Zahlensystem. Dieses Zahlensystem nennt sich Hexadezimalsystem und hat als Basis den Wert 16.
    „Zufällig“ entspricht das genau der größten darstellbaren Zahl von 4Bit im Dualsystem.Das Hexadezimalsystem ist deshalb unter Programmieren das Zahlensystem
    schlechthin, weil es große Zahlen recht kompakt darstellen kann. Für uns reicht es zu wissen, dass es das gibt, auch wenn ich weiter unten damit arbeite.


    Wer wissen möchte wie die Zahlen in den unterschiedlichsten Zahlensystemen aussehen, der kann die Taschenrechner-App z.B. von Windows verwenden.
    Dieser lässt sich in einen Programmierer Modus umschalten und konvertiert alle Zahlen in die verschiedensten Zahlensysteme. Kreuz und quer nach Belieben.
    (Gibt es auch auf MAC und Linux).


    Das Bild zeigt unsere Lokfahrstufe „25“ von oben in den verschiedenen Zahlensystemen.



    Mit diesen Grundlagen bewaffnet stelle ich Euch demnächst das SUSI-Protokoll im Detail vor.


    Bis dahin wünsche ich wieder viel Spaß beim Lesen.


    Mit freundlichen Modellbahnergrüßen
    Thomas



    • Offizieller Beitrag

    Hallo Modellbahner,


    Nach unserem kleinen Ausflug in die Grundlagen der Digitaltechnik haben wir jetzt das Handwerkszeug parat
    um uns an die Betrachtung des SUSI-Protokolles und dessen Entschlüsselung zu begeben.


    Mir geht es hauptsächlich darum dem geneigten Leser die Funktionsweise dieser recht einfachen, aber universellen Datenübertragung
    näher zu bringen.Das beim SUSI-Bus verwendete Verfahren nennt man synchrone serielle Schnittstelle (engl. Synchronous Serial Interface SSI).
    Diese Technik ist weit verbreitet und findet z.B. in der Antriebstechnik eine wichtige Verwendung. Besonders Wegmessysteme bzw.
    Winkelgeber an Servomotoren arbeiten damit. Wen wundert es also, dass die meisten Microcontroller mit einer solchen Schnittstelle ausgestattet sind.


    Wie funktioniert das jetzt:
    Zuerst einmal brauchen wir mindestens zwei Leitungen um eine solche Schnittstelle aufzubauen. Eine Leitung die den Takt angibt und eine Leitung
    die die Daten überträgt. Wer jetzt fragt wer den Takt angibt hat richtig erkannt, dass diese Schnittstelle eine sogenannte Master/Slave Schnittstelle ist.
    Das heißt im gesamten Bus muss mindestens ein Master, oder Taktgeber, vorhanden sein. Die Anzahl der Slaves, also derjenigen die am Bus
    lauschen, kann von System zu System unterschiedlich sein.


    In der RCN-600, also der Vorschrift die die SUSI-Schnittstelle definiert, dürfen maximal 3 Slaves im System vorhanden sein.
    Der Master ist dabei immer unser Lokdecoder und als Slaves kommen meistens Soundmodule oder z.B. unser Platinensatz in Frage


    (Anm: Der Vollständigkeit halber sei gesagt, dass man rein Theoretisch beliebig viele Slaves am SUSI-Bus betreiben könnte aber
    diese wären dann aber bis auf 3 nicht mehr über CV’s programmierbar. Das soll uns aber hier nicht verwirren und kann vorerst wieder vergessen werden.)


    Master, Takt, Slave???…. Der Reihe nach.
    Wie bereits oben gesagt ist der Lokdecoder unser Master im System. Seine Aufgabe ist es jetzt bei der Datenübertragung diese beiden Leitungen
    entsprechend synchron mit den richtigen Signalpegeln zu versorgen.Für jedes zu übertragende Bit muss der Master einen Taktimpuls erzeugen.
    Dazu legt der Master die Taktleitung auf 5Volt (high) und versorgt gleichzeitig die Datenleitung mit dem entsprechenden Datensignal. Ein einzelnes
    SUSI Datenpaket besteht aus 16Bit’s. Das bedeutet, dass der Master 16 Taktimpulse erzeugen muss um diese 16Bit’s zu übertragen. Um einen
    Datensatz vom nächsten zu unterscheiden werden per Definition Pausen in den Takt eingebaut.Also: 16 Takte, Pause, 16Takte, Pause usw.
    Die Pause wird vom Slave überwacht und unter anderem zur Synchronisation des Datenstromes herangezogen.


    Sehen wir uns dazu das folgende Bild eines Datensatzes aus einem ESU Loksound V4 an.



    Wenn man beide Signale mit dem Oszilloskop betrachtet, dann kann man die 16Takte (Gelbe Linie) und die zugehörigen Daten (blaue Linie) sehen.
    Davor und dahinter ist die Pause zu sehen. (Flache Linie)



    Flankengesteuert?? Was ist das jetzt schon wieder?
    Wenn wir uns die Gelbe Linie mit den 16 Takten genauer ansehen, dann besteht so ein Takt aus einer steigenden Flanke, also da wo die
    Spannung von 0V nach 5V ansteigt, einem oberen flachen Teil bei dem die Spannung für eine gewisse Zeit 5V hat, einer fallenden
    Flanke wo die Spannung von 5V nach 0V fällt und einem unteren flachen Teil bei dem die Spannung 0V hat. Diese Abfolge vom
    Beginn der steigenden Flanke bis zum Beginn der nächsten steigenden Flanke nennt man Periodendauer. Diese ist genau doppelt
    so lange wie der Taktimpuls selbst.


    Wenn wir uns das Oszillogramm anschauen, dann sehen wir, dass so eine Periode etwa 260µs dauert. Die Frage ist, wann
    sind die Daten denn nun gültig und wann können wir sicher sein, dass wir die richtigen Daten lesen? Dazu gibt uns die RCN-600
    wieder eine Antwort. Bei der fallenden Flanke des Taktimpulses müssen die Daten gültig sein und dürfen vom Slave gelesen werden.
    D.h. unser Decoder als Master muss dafür sorgen, dass während der fallenden Flanke die Daten gültig (stabil in ihrem Pegel) sind.


    Beim nächsten Bild habe ich mal diese fallenden Flanken mit den zugehörigen Daten zusätzlich dargestellt. (Orange senkrechte Linien)





    Die orangenen Linien mit den Zahlen 0 bis 15 zeigen eine fallende Flanke an. In der Verlängerung zu der in blau dargestellten
    Datenleitung kann man ablesen, ob da eine 1 (5V) oder eine 0 (0V) empfangen wurde.


    Anmerkung am Rande: Die Datenleitung ist im Gegensatz zur Taktleitung im Ruhemodus immer auf 5V. Dies hat mit

    dem „Acknowledge“ bei der CV-Programmierung zu tun und soll uns hier nicht weiter interessieren.

    Von links (Befehlsbyte) nach rechts (Datenbyte):
    0 0 1 0 0 1 0 0____1 1 0 0 0 0 0 1


    Die linken 8 Bit entsprechen dabei der Dezimalzahl 36 oder 0x24hex. (Jetzt kommt die hexadezimale Zahl ins Spiel, wenn
    auch nur dem Vergleich mit der RCN-600 dienend.) Die rechten 8 Bit entsprechen der Dezimalzahl 193 oder 0xC1hex.


    Und was hat der Decoder jetzt gesendet?



    Das Befehlsbyte:
    Um herauszufinden was der Inhalt des Datenpaketes ist nehmen wir uns die RCN-600 auf Seite 9 zur Hand und sehen uns zuerst
    das linke Byte genauer an. In diesem Byte steht der Wert d36 oder 0x24hex. Auf der Seite 9 finden wir unter dem Befehlsbyte die
    0x24 wieder und der Eintrag sagt uns, dass mit diesem Datenpaket die „Ist“ Lokfahrstufe mitgeteilt wird.


    Auszug aus der RCN-600:



    Das Datenbyte:
    Ich habe die Beschreibung des Datenbytes oben mal rot umrandet. Dort haben wir die Werte G0 bis G6 und R. Die Beschreibung sagt
    uns, dass in den Bits G0 – G6 die normierte linearisierte Istgeschwindigkeit übertragen wird. Das sind jetzt 7 statt 8 Bits. Wer noch
    einmal im ersten Teil nachschaut, der wird feststellen, dass man mit 7 Bits alle Zahlen zwischen 0 und 127 darstellen kann. 7 Bits
    reichen also für die Übertragung der Geschwindigkeit vollkommen aus. In unserem Beispiel oben ist das gerade die Fahrstufe 65.
    Das mit R gekennzeichnete Bit zeigt uns an, in welcher Richtung die Lok fährt. In unserem Fall 1, also vorwärts.


    Anmerkung: Wer jetzt fragt, wie man an ein einzelnes Bit innerhalb eines Bytes kommt, dem sei gesagt, dass man das über ein
    Verfahren, welches sich „ausmaskieren“ nennt, schafft. Das ist allerdings Software und hier vorerst nicht wichtig.


    Wie viele Datenpakete werden denn da jetzt so gesendet?
    Der SUSI-Bus überträgt während dem Normalbetrieb kontinuierlich die in der RCN-600 genannten Datenpakete (außer CV-Pakete, die
    nur bei der Programmierung). Es ist allerdings zulässig, das nicht alle möglichen Daten vom Decoderhersteller gesendet werden.
    Dumm ist dabei nur, dass man das nicht in der Beschreibung nachlesen kann.Sicher ist z.B. dass weder ESU noch Uhlenbrock mit den
    mir vorliegenden Decodern die Funktionstatsten größer 28 übertragen. Auch wenn z.B. Rocrail diesen Befehl gültig absetzen
    kann und die RCN-600 bis F60 geht!
    Interessant und auch zulässig, ist die Priorisierung der Datenpakete. So kann man feststellen, dass während der Beschleunigung
    der Lok, fast ausschließlich die „IST“-Lokfahrstufe und die Laststufe gesendet werden, wohl um den Sound so dynamisch wie möglich zu gestalten.
    Nur beim Einschalten werden alle unterstützten Befehle viermal auf den Bus gelegt. Das ist zumindest bei den von mir getesteten
    ESU und Uhlenbrock Decodern der Fall.




    Und woher weiß der Klugsch.. das?
    Nun, mein Oszilloskop verfügt über ein paar Features, die es mir erlauben so ein Datensignal zu analysieren. Es hat für die verschiedensten seriellen
    Protokolle einen eingebauten Decoder.


    Außerdem kann ich dem Gerät noch sagen, in Abhängigkeit vom empfangenen Datenpaket, wann es triggern soll. (Also wann es ein Bild des
    Signals aufnehmen soll) Kommt kein Bild, dann ist was falsch eingestellt oder der Befehl wird nicht gesendet. Der Rest ist Fleißarbeit mit Methode.




    Bis hierhin ist wieder einmal alles gesagt und ich wünsche wieder viel Spaß beim Lesen.


    Mit freundlichen Modellbahnergrüßen
    Thomas

  • Sicher ist z.B. dass weder ESU noch Uhlenbrock mit den
    mir vorliegenden Decodern die Funktionstatsten größer 28 übertragen. Auch wenn z.B. Rocrail diesen Befehl gültig absetzen
    kann und die RCN-600 bis F60 geht!

    Moin,


    der SUSI-Master muss ja irgendwo her seine Daten bekommen um sie auf dem SUSI-Bus senden zu können.
    Die Funktionen F29 bis F68 haben wir erst vor 2 Jahren in die RCN-212 im DCC-Protokoll aufgenommen.
    In der RCN-600 sind die Befehle für F29 bis F68 bei SUSI erst seit Dezember 2018 drin. Ganz so schnell malen Modellbahn-Digital-Mühlen nicht.
    Hier muss man sich sicherlich noch ein bis zwei Jahre in Geduld üben, bis die neuen Befehle ihren Weg in Zentralen, Decoder und SUSI-Module gefunden haben.
    Viele Grüße,
    Heiko

    • Offizieller Beitrag

    Hallo Heiko,


    Vielen Dank für die kritische Rückmeldung. Das die beiden Decoder die Funktionstasten größer 28 nicht unterstützen sollte ja keine Kritik, sondern nur eine Feststellung sein. Das ist mir offensichtlich nicht gelungen. Schau Dir mal von ESU den neuen Lokprogrammer 5 an. Dort werden erstmals die Funktionstatsten bis 32 angeboten. Diese funktionieren auf dem Loksound 4 und dem Uhlenbrock nicht. (Das hat mich erst auf die Idee gebracht das mal zu versuchen) Ich hätte auch nichts anderes erwartet und finde das auch nicht schlimm. Ich habe mir jetzt mal einen Loksound 5 bestellt, um zu sehen, ob diese dort funktionieren.
    In diesem Zusammenhang möchte ich ausdrücklich nochmal auf diesen Satz hinweisen.

    HINWEIS: Diese Erkenntnisse beruhen auf meinen eigenen Messungen und subjektiven Wahrnehmungen. Ich übernehme also keine Gewähr auf Richtigkeit und Vollständigkeit der gemachten Angaben. Auch dient dies keiner Qualitätsprüfung der genannten Decoder und Hersteller oder läßt eine Aussage darüber zu.

    Ich werde in Zukunft sehr genau darauf achten keine Schlussfolgerungen mehr zu veröffentlichen, besonders dann nicht, wenn diese den/die Hersteller negativ erscheinen lassen könnten. Versprochen!
    Nur noch eine kleine Info. Rocrail, besonders die Embedded Version, und die OpenDCC-Zentrale sind quelloffen. Ich werde mich deshalb nicht rechtfertigen, lasse aber solche Informationen in Zukunft in der Werkstatt. Auch versprochen.


    Nicht böse sein, aber ich hab das Gefühl mit erhobenem Zeigefinger für vermeintlich schlechte Eigenschaften diverser Decoder gerügt, oder soll grundsätzlich diskreditiert werden. Überzeuge mich vom Gegenteil, aber so kommt es bei mir an. Ich wiederhole nochmals. Es ist nicht meine Absicht und wird es auch in der Zukunft nicht sein ein Ranking der Hersteller darzustellen. Dieser Thread sollte einzig dem interessierten Modellbahner dienen.


    Ich bin gerne bereit die Beitragsreihe und diesen Thread durch Rainer löschen zu lassen. Ich brauche das nicht, da ich weiß wie es funktioniert.


    Mit freundlichen Modellbahnergrüßen
    Thomas

  • Hallo!
    Thomas S
    Das mit der Anzahl der Funktionstasten ist different zu sehen.
    Der Sounddecoder ESU M4V5 hat ja beispielsweise in der V60 vom selben Hersteller 31 Funktionen.
    Das ging aber mit der Intelibox II nur bis zur Funktion 28 zu schalten.
    Erst nach dem Decoder Update funktionierte es über F28.
    Soviel ich verstanden habe hat Märklin zwar das mfx offengelegt; jedoch nur bis 12 Funktionen.
    Mit freundlichen Grüßen und immer allzeit gute Fahrt mit der Modelleisenbahn

    • Offizieller Beitrag

    Nicht böse sein, aber ich hab das Gefühl mit erhobenem Zeigefinger für vermeintlich schlechte Eigenschaften diverser Decoder gerügt, oder soll grundsätzlich diskreditiert werden. Überzeuge mich vom Gegenteil, aber so kommt es bei mir an. Ich wiederhole nochmals. Es ist nicht meine Absicht und wird es auch in der Zukunft nicht sein ein Ranking der Hersteller darzustellen. Dieser Thread sollte einzig dem interessierten Modellbahner dienen.


    Ich bin gerne bereit die Beitragsreihe und diesen Thread durch Rainer löschen zu lassen. Ich brauche das nicht, da ich weiß wie es funktioniert.

    Hi Thomas,


    nicht beirren lassen und fortfahren. Die Prämissen zu Deinen Ausführungen sind klar formuliert. Mir helfen Deine Beitrage ungemein, mein bisheriges Wissen oder besser gesagt mein bisheriges Verständnis für die "digitalen Zusammenhänge" zu erweitern. In diesem Sinne: weiter so.


    Gruß Rainer :thumbup:

  • Hallo Zusammen
    ich finde es bedenklich, wenn man auf dem Niveau, was Thomas hier an den Tag legt, waage die Angst haben muss, das ein Hersteller das als Negativ empfinden könnte.
    Es ist alles in allem sehr sachlich, ohne Polemik und und ohne Anschuldigungen oder Empfehlungen negativer Art.


    Ein Hersteller hat meiner Meinung nach damit zu leben, das man ihn mit Anderen vergleicht und das man auf fehlende oder unvollständige Implementationen der Norm hinweist.
    Wenn wir schon in der Digitalisierung und Globalisierung leben, dann hat man als Konsument die Freiheit das offenzulegen, was man herausfindet und global zu Vergleichen, was es gibt.Andersherum steht es jedem Hersteller frei, ein Heer von Influencern und Bloggern zu beschäftigen, die das Gegenteil promoten.
    Es kann doch nur dienlich sein, wenn man solche Unterschiede von Esu und Uhlenbrock sieht und die dann auch noch verstehen kann. Beide in der Toleranz - die Einen oben, die Anderen unten.
    Alles OK. Mir wäre "open source" und eine Referenz-Implementation in C am allerliebstern.


    Also bitte weiter solche internen Dinge posten, denn ich weiss es NICHT und ich lerne hier sehr viel! Insel-Wissen hilft niemandem.


    LG,
    Axel

  • Also bitte weiter solche internen Dinge posten, denn ich weiss es NICHT


    Moin Leute
    Das meine ich auch! Darüber hinaus sehe ich hier im sehr informativen und arbeitsintensiven Faden keine Rüge oder andere …“Misstöne“. ;)
    Auch bei Heiko nicht. Das kann auch am fortgeschrittenen Alter liegen.


    Was mich nachdenklich macht ist, dass scheinbar zwischen den Zeilen gelesen und interpretiert wird. Das sollten wir, wie bislang auch, weiterhin anderen überlassen.
    Hier gilt der Satz: schade um jedes (auch geschriebene) Wort.
    Noch dürfen wir hinschreiben was wir meinen und wenn es mal Müll sein sollte kann man ja sachlich fachlich aufklären. Hier habe ich verstanden, dass etwas genutzt wird was (noch?) nicht von allen Herstellern unterstützt wird, aber zukünftig genutzt werden kann/sollte.
    meint mit LG
    :matrose: Friedrich

    • Offizieller Beitrag

    Moin zusammen, moin Heiko,


    vielleicht habe ich überreagiert. Ich habe sehr, sehr schlechte Erfahrungen mit der Wahrheit gemacht. Da Du Mitglied eines Lobbyverbandes bist und in der Art wie Du das gefragt hast, sah ich einfach sich das Ganze wiederholen und ich bekam die Panik. Das ist jetzt viele Jahre her, sitzt aber offensichtlich noch tiefer als ich dachte. Solltest Du dich angegriffen fühlen, dann entschuldige ich mich dafür.


    Gruß Thomas

  • Hallo Zuammen
    Ich habe leider die Sourcen von Rocrail und OpenDCC nicht, aber ich habe bei JMRI nachgeschaut und alle anderen Quellen durchforstet die ich kenne, wo F28, F29 oder höher gelistet sind.
    Leider ist bei allen bei F28 schluss. F60 wird wie von Euch zitiert erst in den Specs/Normen verwendet.


    Das ist halt das dumme an Foren, dass man kein Gespräch führt, wo man den Anderen sehen und höhren kann... .


    LG,
    Axel

  • Hallo Thomas,


    in Bezug auf Deinen Beiträgen #8 und #14 würde ich es als bedauerlich empfinden, wenn Du Dich nicht mehr traust fundierte Kritik in Form von Klartext zu äussern. Die in der Politik und Gesellschaft in letzter Zeit aufgekommenen indirekten Denk- und Redeverbote sind eigentlich ein Machtmittel und sollten in diesem Forum keinerlei Anwendung finden.
    Meine zuweilen auch recht deftige Kritik an der hiesigen Modellbahnindustrie habe ich meistens in Form von Umbauten geäussert. Ich selber scheue dabei auch nicht vor Negativaussagen und Vergleichen zurück.


    :offtopic: Des weiteren beobachte ich auch das Geschehen und die Entwicklung ausserhalb des deutschen Modellbahnhorizonts. Wenn ich dann hier etwas äussere oder zeige, löst das oft Unglauben, Ignoranz und nicht wahrhaben wollen aus.

  • Hallo Lutz K
    Da der in Deinem Artikel betroffene Autor offensichlich schlechte Erfahrungen sammeln mußte, empfehle ich das Mittel der
    Verfremdung oder Überhöhung.
    MfG
    PS Frage: Welches Buch würdet ihr als Reiselektüre empfehlen,
    Bertold Brecht "Hundert Gedichte"
    Karl Kraus "Anderthalb Wahrheiten Aphorismen"