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....
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.
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