[inet_surfer88]

Hallo,

ich habe vor einigen Jahren meine eigene C-Bibliothek für Mikrocontroller geschrieben um Selectrix-kompatible Geräte (Lichtdecoder, Handregler) bauen zu können.
An der neuen Anlage verwende ich die aktuell ausschließlich für selbstgebaute Lichtdecoder. Das ist aktuell kein Problem und wird auch in Zukunft kein Problem werden, da der Bus für die Steuerung dauerhaft in reinem SX1 arbeiten wird.

Jetzt mache ich mir Gedanken darüber für den Bahnhof meiner Nebenbahn ein kleines Gleisbildstellpult mit integriertem Fahrregler zu bauen. Als Zentrale verwende ich die ZS2+ von Stärz. Diese ist aktuell auf reines SX1 eingestellt, kann aber auch SX2 und DCC. Ich würde mir für die Zukunft gerne einen gemischten Betrieb für DCC und SX1 offen halten. Die Zentrale und auch meine Software (iTrain) können das. Lediglich mein Handregler den ich bauen will kann das nicht, ohne das ich meine Bibliothek um die DCC-Funktionalität erweitere.

Ich habe die Info gefunden das die DCC-Pakete einfach zwischen die 16 Grundrahmen des Selectrix-Protokolls eingeschoben werden. Mehr Infos habe ich dazu nicht gefunden. Hat jemand hierzu Infos die er herausgeben kann oder Tipps wo man an die Infos kommen kann, sofern überhaupt veröffentlicht?

Mich würde vor allem Interessieren wie das Datenpaket auszusehen hat. Entspricht es in dem Fall 1:1 dem Protokoll von DCC auf dem Gleis so wie es bei Selectrix ist? Und falls ja, wie muss das implementiert werden. Muss z.B. nach einem SX-Paket bestehend aus Sync-Gruppe mit den 7 Datenkanälen eine kleine Pause gemacht werden, oder wird eine spezielle Bitfolge gesendet um den Teilnehmern zu signalisieren das jetzt ein DCC-Paket kommt?

Über Infos würde ich mich freuen. Falls ich keine zuverlässigen Infos bekomme werde ich mir den Aufwand einer Handreglerentwicklung sehr wahrscheinlich sparen, da ich mir nicht die Möglichkeit nehmen will in Zukunft DCC-Loks zu fahren. Bei der Wahl der Steuerung habe ich jetzt überall darauf geachtet das es funktioniert.


Gruß Rüdiger

[Sx2Fan]

Hallo Rüdiger,

auf der D&H Homepage, leider recht versteckt in der SITEMAP findet man Links zur Thematik
System-Spezifikation mit folgenden Themen:
- System-Spezifikation / Steckersystem
- System-Spezifikation / Bus-Signale
- System-Spezifikation / Bus-Protokoll
- System-Spezifikation / Kanalmodell
- System-Spezifikation / Gleis-Signale
- System-Spezifikation / SX1-Programmierung
- System-Spezifikation / SX2-Programmierung

Nachfolgend der direkte Link zu der System-Spezifikation
https://doehler-haass.de/cms/pages/system-spezifikation.php

und hier noch der, zu Beschreibung des erweiterten SX-Kanalmodells
(Protokoll mit SX2, DCC, MM, SX2-POM und DCC-POM kurze u. lange Adresse)
https://doehler-haass.de/cms/pages/syste...kanalmodell.php

Wie der Übergang am Gleis zwischen SX-Signalen und DCC-Signalen und vice versa aussieht ist unter
http://jochens-moba.vze.com/ bzw. http://tm320-totoro.b.la9.jp/index2.htm
und dort unter
<Digital> => "Zentrale MiniFCC" => nach unten scrollen und "Page 6" wählen
(leider funktioniert der direkte Link http://tm320-totoro.b.la9.jp/moba/digita...cc/minifcc6.htm nicht)
dargestellt.

Beste Grüße
Werner

[inet_surfer88]

Hallo Werner,

vielen Dank für die Infos. Das auf der Homepage von D&H haben die wirklich gut versteckt.
Ich habe es jetzt mal auf die Schnelle überflogen und denke das hilft mir auf jeden Fall weiter. Mit den Infos ist es denke ich möglich meine Bibliothek in Zukunft zu erweitern und damit steht dem Bau des Stellpultes mit integriertem Handregler erst mal nichts mehr im Weg. Im ersten Schritt erst mal nur mit der alten Bibliothek und SX1, momentan reicht es ja aus. Im zweiten Schritt wird es dann erweitert auf DCC-Funktion.


Gruß Rüdiger

[inet_surfer88]

Hallo zusammen,

ich habe mir die Infos jetzt in Ruhe angeschaut. Der prinzipielle Aufbau der Daten ist mir jetzt soweit klar. Ich denke mit den Infos kann ich meine Bibliothek soweit erweitern das ich die Fahrstufe einer angemeldeten DCC-Lok auslesen und verändern kann. Das hilft schon mal weiter.

Allerdings ist mir eines noch nicht klar. Wenn alle SX2- bzw. DCC-Loks Fahrstufe 0 haben und keine Funktion eingeschaltet ist, dann werden nur die Präambel an den Grundrahmen angehängt, es folgen keine Daten. Wenn mein Handregler jetzt eine Lok steuern möchte, dann sendet er eine Präambel und laut Doku erweitert dann die Zentrale automatisch diesen Grundrahmen um die Daten und der Handregler kann dann Adresse und Fahrstufe senden.

Aber woher weis der Handregler bei welcher Rahmenadresse er die Präambel senden darf? Er könnte jetzt schauen bei welcher Rahmenadresse noch keine Daten angehängt sind und beim nächsten Durchlauf diese verwenden. Aber was passiert wenn dann 2 Regler gleichzeitig die zuvor "freie" Rahmenadresse verwenden? Wird diese Wahrscheinlichkeit ignoriert, da es sehr selten vorkommen wird oder gibt es eine Art Mechanismus, mit dem der Handregler weis wann er senden darf? Diese Info habe ich jetzt nicht gefunden.

Weiterhin beschreibt das Dokument das Anhängen von max. 16 SX2- bzw. DCC-Loks. Nach jeder Rahmenadresse eine Lok. Mit der ZS2+ gibt es die Möglichkeit 32 SX2- bzw. DCC-Loks zu steuern. Werden dann einfach 2 Erweiterungen an eine Rahmenadresse angehängt?


Gruß Rüdiger

[Sx2Fan]

Hallo Rüdiger,

da hast du ein potentielles Problem bei der SX-Buserweiterung gut erkannt. Um die Buserweiterungen einwandfrei handhaben zu können, ist es erforderlich, dass die Geräte die D-Leitung (also ihre normale Sendeleitung zur ZE) bidirektional bedienen können. Das bedeutet sie müssen die Fähigkeit haben, sowohl schreibend als auch LESEND auf die D-Leitung zu zugreifen. Das ist nichts grundlegend Neues. Diese Anforderung gilt auch für alle Geräte, die die Moba-Uhrzeit vom SX-Bus verwenden möchten. Anders gesagt, alle Geräte, die das Uhren-Signal am SX-Bus generieren oder auswerten können, können das.

Wie erkennt nun z.B. ein Handregler, ob eine Buserweiterung tatsächlich noch frei ist, wo doch alle Präambel-Bits von der ZE auf der T1-Leitung auch dann noch mit „0“ ausgegeben werden, wenn zwar eine Adresse, aber noch keine weiteren Daten in der Buserweiterung enthalten sind? Die Buserweiterung damit aber grundsätzlich schon in Verwendung ist.

Nun zunächst einmal muss ja der Handregler, der diese Buserweiterung ursprünglich mal initiiert hat dafür sorgen, dass diese von der ZE nicht automatisch wieder geschlossen wird. Genau dies würde die ZE aber tun, wenn alle Bits im Datenteil „0“ wären (purge). Stimmt nicht ganz, denn die ZE würde es sogar auch dann tun, wenn dort nur noch das Fahrtrichtungsbit gesetzt ist!

Um das Schließen der Buserweiterung zu verhindern, muss ein Gerät die Präambel-Bits also zyklisch schreiben (auf der D-Leitung ausgeben) und damit der ZE kenntlich machen, dass diese Erweiterung weiterhin in Verwendung ist.

Ein weiterer Handregler, der auf der Suche nach einer noch freien Buserweiterung ist, findet diese indem er sucht in welchem SX-Frame alle Präambel-Bits aktuell noch 0 sind. Dafür muss er aber von der D-Leitung lesen, da die ZE die Präambel-Bits ja erst dann auf die T1-Leitung spiegelt, wenn min. 1 Bit (Achtung: Fahrtrichtungs-Bit zählt hier nicht) gesetzt ist.

Ja gut, aber wie ist es nun, wenn zufällig 2 Handregler exakt zum selben Zeitpunkt eine Erweiterung anfordern und sich damit für dieselbe, bisher noch freie Erweiterung entscheiden? Nun die potentielle Kollision kann nun dadurch erkannt werden, dass die Handregler nach jedem geschrieben Bit unmittelbar wieder zurücklesen, ob dieses auch auf dem Bus angenommen wird bzw. durchkommt.

Eine log. 1 wird auf dem SX-Bus durch einen 5V Pegel (> ~3V) repräsentiert. Eine log. 0 durch 0V (< ~2V). Nehmen wir also mal an, ein Handregler gibt für eine bestimmte Bit-Position innerhalb der Präambel oder der nachfolgenden Adresse eine 0 aus, während der andere versucht exakt an dieser Stelle eine 1 zu generieren. Der eine zieht die Datenleitung also runter Richtung 0V während der andere versucht diese auf 5V anzuheben. Die Hardware der Busbeschaltung ist so ausgelegt, dass das Herunterziehen Richtung 0V gegenüber dem Anheben auf 5V dominiert. Der Handregler, der gerade eine 0 schreibt gewinnt also.

Da beide Regler den Signalpegel, den sie auf der D-Leitung ausgeben unmittelbar auch wieder lesend auswerten, können sie erkennen, ob das Bit (ihr Bussignal) auf dem Bus durchkommt oder nicht. Erkennt ein Handregler jetzt, dass sein Bit am Bus nicht angenommen wurde, bricht er seine Schreiboperationen in dieser Buserweiterung unmittelbar ab. Er kann dann direkt damit beginnen, nach der nächsten noch freien Buserweiterung zu suchen und diese für sich ergreifen.

Beste Grüße
Werner

[Sx2Fan]

Hallo Rüdiger,

noch eine Anmerkung zu deiner Frage

Zitat

---

...Mit der ZS2+ gibt es die Möglichkeit 32 SX2- bzw. DCC-Loks zu steuern. Werden dann einfach 2 Erweiterungen an eine Rahmenadresse angehängt?

---

Ich habe keine Ahnung, wie es die ZS2+ macht. Grundsätzlich wäre das von dir vermutete Vorgehen denkbar. Die D&H FCC macht dies indem sie an jeden ihrer beiden SX-Buslinien jeweils 16 Buserweiterungen anhängt. Dies wird von dem Stärz WLAN-SX-Adapter auch unterstützt. Das bedeutet, wenn man diesen mit beiden SX-Buslinien also SX-Bus0 und SX-Bus1 der FCC verbindet, dann hat man über WLAN und die Smartphone App Zugriff auf alle 32 Buserweiterungen der FCC. Von und zur FCC laufen dies dann aber aufgeteilt auf die o.g. beiden Buslinien.

Beste Grüße
Werner

[inet_surfer88]

Hallo Werner,

zunächst einmal vielen Dank für deine Mühe mit der ausführlichen Erklärung. Große Klasse,
Und jetzt zeigt es sich das es gut war vor dem Bau eines neuen Handreglers mal nachzufragen. Im ersten Schritt will ich ja einfach meine alte Bibliothek verwenden, später dann die Bibliothek erweitern und dann die Firmware updaten. Jetzt kann ich gleich die Hardware so bauen das vom D-Bus gelesen werden kann. Das kann die Hardware so wie ich sie derzeit baue nicht. Das werde ich als erstes ändern, damit ich zur Buserweiterung kompatibel bin

Ich habe gerade mal nachgeschaut. Der Stärz Handregler ist laut Anleitung zur FCC kompatibel. Da er allerdings nur an einen Bus angeschlossen wird könnte er dann ja nur 16 statt 32 DCC-Loks adressieren. Könnte aber schon sein, in der Anleitung habe ich hierzu keine Angabe gefunden. Aber das lässt sich auch herausfinden wenn ich mit der Programmierung für die neue Bibliothek loslege. Ich kann dann einfach mal 32 DCC-Loks an der ZS2+ aktivieren und die Bits zwischen 2 Sync-Gruppen zählen. Dann sieht man gleich was los ist.


Nochmals Danke und Gruß
Rüdiger

[Sx2Fan]

Hallo Rüdiger,

leider habe ich in meinem letzten Post vergessen zu erwähnen, dass der SX-WLAN-Adapter in den SX-Buserweiterungen der FCC bei SX2 32 Fkt. bzw. bei DCC 28 Fkt. zusammen mit der App und vermutlich auch mit der Roco wlanMAUS unterstützt. Warum ist das in diesem Kontext interessant?

Nun, dies ist nur möglich, da die FCC mit aktueller Firmware die Buserweiterungen noch um weitere 16 Bit ergänzt und so in Summe die Übertragung von 32 Funktionsbits für SX2/DCC auf den beiden SX-Buslinien offeriert. Damit ist dort aber auch bereits festgelegt, wie diese Bits zu interpretieren sind. Ein zusätzlicher Bereich für weitere SX2/DCC-Daten müsste bei der FCC somit um weitere 16 Bit (24 Bit falls man die Trenn-Bits mitzählt) nach hinten geschoben werden.

Ich kenne die ZS2+ nicht und weiß nicht wie viele Zusatzfunktionen diese unter SX2/DCC anbietet. Ich vermute aber mal, dass man kompatibel zur D&H FCC und zu seinem eigenen SX-WLAN Adapter bleiben möchte und wahrscheinlich pro SX Frame ebenfalls nur eine Verlängerung für SX2/DCC Daten nutzt.

Die immer wieder als Negativpunkt ins Spiel gebrachte Beschränkung auf max. 16 aktive SX2/DCC Adressen pro Bus ließe sich zudem leicht eliminieren. Die Zentrale müsste dafür eine Buserweiterung generell vom SX-Bus nehmen, wenn sie erkennt, dass diese von keinem Handregler mehr benutzt wird (Präambel-Bts werden von keinem Gerät mehr beschrieben).

Aktuell macht sie dies ja auch schon aber leider nur dann, wenn alle Daten „0“ sind. Natürlich müsste die ZE Datenpaket, die noch Nutzdaten enthalten nach wie vor zyklisch am Gleis ausgeben. Das sollte aber kein Problem sein. Die Zeiten in denen der SX-Bus und das Gleissignal aus Gründen der Performance und dem Umstand das Ganze relativ simpel zu halten, Takt und Bit/Daten synchron sein mussten sind vorbei. Wird das Zusammenspiel SX-Bus und DCC-Gleissignal in einer ZE effizient realisiert, dann muss man sowieso davon abweichen. Im Grunde warte ich darauf, dass einer der Anbieter die Thematik der SX-Bus Administration noch mal angeht.

Beste Grüße
Werner

[inet_surfer88]

Hallo,

ich habe noch ein wenig weiter geforscht. In der Anleitung der Stärz Zentrale habe ich den Hinweis gefunden das für die Verwendung der 32 DCC-Loks die Handregler das "Multiplexen auf dem erweiterten SX-Rahmen" beherrschen müssen. In den Steuerprogrammen soll dann nicht die ZS2 sondern "FCC" als verwendete Zentrale ausgewählt werden. Aufgrund diesen Hinweises gehe ich davon aus, das die ZS2 zur FCC kompatibel ist.

So langsam hat mich das Fieber jetzt doch gepackt. Vielleicht erweitere ich meine Bibliothek früher als geplant.
Ich will jetzt erst mal noch ein paar angefangene Projekte fertig machen. Danach gehe ich das Thema eventuell an und werde als erstes einen Testaufbau machen der mir von einer definierten SX-Gruppe alle Bits einfach auf ein Display ausgibt. Dann habe ich die Anzahl der Bits und die Bitfolge. Wenn ich zuvor an der Zentrale 32 Loks aktiviere und nacheinander alle 16 Grundrahmen mitschreibe dann habe ich eigentlich alles was ich brauche. Dank der oben verlinkten Infos von der D&H-Homepage kann ich die Daten interpretieren. Aber wie bereits geschrieben werde ich erst mal die Angefangenen Baustellen zu Ende bringen. Kann also noch einige Wochen (Monate) dauern.


Gruß Rüdiger

[Sx2Fan]

Hallo Rüdiger,

du schreibst

Zitat

---

ich habe noch ein wenig weiter geforscht. In der Anleitung der Stärz Zentrale habe ich den Hinweis gefunden das für die Verwendung der 32 DCC-Loks die Handregler das "Multiplexen auf dem erweiterten SX-Rahmen" beherrschen müssen. In den Steuerprogrammen soll dann nicht die ZS2 sondern "FCC" als verwendete Zentrale ausgewählt werden. Aufgrund diesen Hinweises gehe ich davon aus, das die ZS2 zur FCC kompatibel ist.

---

Interessante Info. Wo genau kann man das nachlesen? Ich konnte bei Stärz in den Anleitungen zu den Varianten der Zentralen leider nichts Entsprechendes finden. Hast du einen Link zu der Anleitung, in der du den Hinweis entdeckt hast?

Keine Frage, das kann man prinzipiell so machen. Bei der Kompatibilität zu den bisherigen, mir bekannten Komponenten, die in der Lage sind das erweiterte SX-Busprotokoll zu nutzen (TRIX MS, Control Handy und Lok Control 2000 mit Update Chip, HR2010 und HR4000, BTA2 und BTMS), sehe ich da aber schon potentielle Probleme. Diese Geräte gehen nicht davon aus, dass in der SX-Buserweiterung Multiplex-Betrieb verwendet wird. Das können sie auch gar nicht, da dies, zumindest nach dem was mir bekannt ist, so nicht definiert wurde/ist.

Damit stellt sich mir die zentrale Frage, wie verhalten sich diese Geräte im Zusammenspiel mit dem „neuen“ Multiplex-Betrieb? Wie also werden die Buserweiterungen jetzt administriert/gemanagt?

Nehmen wir mal an die ZS2+ eröffnet, die zweite Ebene des Multiplex-Betriebs zu dem Zeitpunkt, wenn erst alle SX-Buserweiterungen der ersten Ebene belegt sind. Bis zu diesem Zeitpunkt sicher kein Problem, denn es gibt ja noch keine Differenz zu dem, was üblich ist bzw. als Standard festgelegt wurde.

Jetzt, nachdem die zweiten Ebene geöffnet wurde, gibt die ZE zyklisch alternierend in der ersten Ebene die 16 bereits belegte Buserweiterungen aus und in der zweiten dann 16 freie Buserweiterungen (Präambel-Bits alle 0). Frage was machen die bekannten Geräte jetzt, wo „ihre“ Buserweiterung plötzlich verschwunden ist, im nächsten Zyklus aber wieder auftaucht? Kommen die damit klar? Könnte sein, muss aber nicht.

Noch eine Überlegung. Wie verhalten sich die Geräte, wenn in der ersten Ebene eine kurze DCC-Adresse z.B. 17 mit 28FS angesprochen wird und in der zweiten Ebene „ihre“ lange DCC-Adresse z.B. 1704 mit 128FS liegt? Werten sie allzeit die Präambel und die Adresse korrekt aus, um zu erkennen, ob sie ihre Daten an der richtigen Stelle einfügen? Kann sein, muss aber nicht.

Bin gespannt, zu welchen Ergebnissen du bei deinen Tests kommst.

Beste Grüße
Werner

[inet_surfer88]

Hallo Werner,

hier nur schnell der Link.
Seite 7 rechte Spalte, der Punkt "Optimiertes Protokoll derZS2+"
https://www.firma-staerz.de/downloads/Ze...5_19_Mai_05.pdf


Den Rest was du schreibst muss ich mir noch in Ruhe durchlesen.


Gruß Rüdiger

[inet_surfer88]

Hallo zusammen,

lange hat sich hier nichts mehr getan. Die Protokollerweiterung liegt derzeit aus Eis, da ich im Moment schon mit dem Protokoll ohne Protokollerweiterung zu kämpfen habe. Ich will die Funktionalität meiner vorhandenen und funktionierenden SX-Bibliothek verbessern und auf die Protokollerweiterung vorbereiten. Allerdings ist das derzeit eine größere Aufgabe als gedacht. Scheint ein Timingproblem zu sein, aktuell gibt es ab und an Übertragungsfehler. Aber ich arbeite dran. Danach soll es auch mit der Protokollerweiterung weiter gehen.

Derzeit habe ich allerdings eine andere Frage. Wie kann ich im Selectrix-System einen Nothalt (Gleisspannung aus) auslösen? Die Info ob die Gleisspannung eingeschaltet ist frage ich derzeit über das Gleisbit ab, welches in jedem SX-Rahmen übertragen wird. Zusätzlich gibt es die Info in der Adresse 109 Bit 7. Das werte ich derzeit aber nicht aus.

Wie realisiert man aber nun offiziell einen Notstop? Das Bit in der Adresse 109 überschreiben oder das Gleisbit im SX-Rahmen überschreiben?


Danke und Gruß
Rüdiger

[Sx2Fan]

Hallo Rüdger,

schön zu lesen, dass du noch am Ball bist/bleibst.

Die Adresse/der Kanal 109 stand in der ursprünglichen Version, wie alle anderen Adressen/Kanäle auch zur freien Verfügung. Fahrregler wie Combi Control oder Lok Control hatten, wegen ihrer auf 2 Stelle begrenzten Adresseingabe, darauf keinen Zugriff. Funktionsdecoder und Belegtmelder konnten aber sehr wohl auch auf die Adressen 100..111 eingestellt werden und auch das Interface hatte Zugriff auf diesen Adressbereich.

Mit der Einführung der Geräteversion 2000 wurden einige Adressen/Kanäle im Bereich 100..111 für Systemdienste reserviert. Soweit ich mich erinnere waren dies die Adressen/Kanäle 104..111. Im Zuge dieser Maßnahmen wurde die Adresse/der Kanal 109 für die Administration von Statusinformationen (Gleisspannung ein/aus, Programmiermodus aktiv, Ready für Lesen/Schreiben im Prog.-Modus, Kurzschluss am Gleisausgang der ZE und diverse Programmierstati) verwendet. Dies geschah, damit andere Geräte am Bus bei Bedarf auf entsprechende Daten reagieren können. Über Funktionsdecoder, die auf die Adresse 109 eingestellt sind könnten damit z.B. dezentral LEDs oder Lampe ansteuern werden, die den Status der Gleisspannung oder einen Kurzschluss signalisieren oder ob gerade eine Programmierung abläuft.

Kurzum der Status-Kanal 109 ist mehr zum Lesen/Auswerten als zum Beschreiben gedacht und wenn ich mich recht erinnere, dann lässt er sich bei der FCC auch gar nicht beschreiben. Deshalb und um auch weiterhin kompatibel zu dem ursprünglichen SX-System und Geräten zu bleiben, muss die Anforderung Gleisspannung ein/aus von Geräten am SX-Bus in das entsprechende Bit im Sync-Kanal geschrieben werden! Die FCC z.B. spiegelt den aktuellen Status dann in den Status-Kanal/die Adresse 109.

Beste Grüße
Werner

[inet_surfer88]

Hallo Werner,

Schön das du hier auch noch mit dabei bist. Erst mal danke für die schnelle Rückmeldung. Ich habe das Schreiben im entsprechenden bit im Sync-Kanal umgesetzt. Hat 5 Minuten gedauert und funktioniert perfekt. So langsam wird es.

Ich werde mich die nächsten Tage mal mit ein paar Details melden zu dem was ich gerade mache und zu den aktuellen Problemen die das ganze zeitlich etwas aus dem Ruder laufen lassen.

Gruß Rüdiger

[inet_surfer88]

Hallo zusammen,

heute will ich mal einen kleinen Überblick über den aktuellen Stand geben.

Meine bisherige SX-Bibliothek, welche ich vor einigen Jahren mal geschrieben hatte, wertete immer nur eine Adresse gleichzeitig aus. Welche Adresse ausgewertet werden soll musste der Funktion am Anfang übergeben werden. Bei meinen ersten Schaltungen reichte das vollkommen aus. Aber mit dem Entwickeln meiner Beleuchtungssteuerung mussten die Platinen mehrere Adressen auswerten. Also Adresse übergeben, Daten auswerten, nächste Adresse übergeben, usw. Dadurch dauerte es zum Teil etliche Zyklen, bis alle Adressen ausgewertet waren.
Das habe ich bei meiner neuen Version mittlerweile geändert. Es werden generell alle Adressen ausgewertet und in einem Array gespeichert. Somit steht jederzeit der jeweils aktuelle Wert von allen Adressen zur Verfügung. Beim Schreiben der Adresse verfahre ich genau so. Es muss also keine Adresse mehr übergeben werden. Die Info wird einfach an die entsprechende Stelle im Array geschrieben bzw. aus der entsprechenden Stelle im Array gelesen (etwas vereinfacht geschrieben). Hiermit bin ich jetzt eigentlich zufrieden.

Jetzt gibt es aber noch einen Punkt der nicht gerade der SX-Norm entspricht aber bisher auch keine Probleme bereitet hat. Ich möchte es aber eigentlich trotzdem Normgerecht anpassen.
Die Abtastung des Signalpegels soll eigentlich in der Mitte des Taktsignales erfolgen. Bisher mache ich das mit der ansteigenden Taktflanke per Interrupt. Alle Versuche das ganze über einen Timer zu realisieren scheiterten bisher. Das Problem ist mein Controller. Es ist ein 8 Bit ATMEGA Controller, welcher nicht mit seinen max. 20Mhz, sondern nur mit 8MHz läuft. Das erspart mir ein Quarz, die 8MHz werden intern erzeugt. Aus heutiger Sicht würde ich mir das Quarz nicht mehr sparen. Aber selbst wenn er mit 20MHz takten würde, wird es vermutlich nicht reichen. In meinem aktuellen Projekt (Fahrpult) muss der Controller noch als I2C-Slave arbeiten. Die Interrupts von dem SX-Takt und dem I2C hauen sich gegenseitig auf die Finger, ich habe es nur mit sehr viel Mühe hinbekommen das es jetzt läuft. Und das obwohl ich aktuell noch auf die steigende Flanke abfrage was wesentlich ressourcenschonender ist als mehrmals per Timerinterrupt abzufragen und die Taktmitte zu nehmen.

Derzeit prüfe ich den Einsatz einen STM32 oder eines ESP32.
Der ESP32 liegt zu Testzwecken bereits auf dem Basteltisch. Der soll auf längere Sicht in meinem Stellpultprojekt den Raspberry PI ersetzen, da ein ESP32 in diesem Projekt einfacher zu handhaben ist. Bei der Gelegenheit werde ich mit dem auch mal das Auswerten des SX-Signales testen.
Weiterhin will ich mir noch ein STM Demoboard zulegen und das SX-Signal hiermit auswerten.

Wenn es mir gelingt das Signal mit diesen beiden Controllern zuverlässig in der Taktmitte auszuwerten während die Controller noch ein wenig Reserve für andere Aufgaben haben, dann wird es mit dem implementieren der Protokollerweiterung weiter gehen.
Es kann also noch eine ganze Weile dauern, bis es mit der Protokollerweiterung weiter geht. Aber so lange ich nicht Normgerecht abtaste will ich hier erst mal noch nicht weiter machen.


Ich werde auf jeden Fall weiter berichten, auch wenn es noch eine Weile dauert.

Wer sich in der Zwischenzeit für das Stellpult interessiert kann mal hier nachschauen.
Mit der Bahn ins Feriendorf - Nebenbahnstellpult (18)


Gruß Rüdiger