April 2004
Es wird schon lange über Selectrix II (SX2) gesprochen. Da soll der Adressbereich auf 5000 Adressen erweitert werden,
die Fahrstufen auf 127 erhöht werden. Warum geschieht nichts?
Nun habe ich Versuche durchgeführt, das Selectrixprotokoll zu erweitern. Es wäre der einfachste Versuch an einen
Übertragungsrahmen, bestehend aus Synchronisationsbyte und 7 Datenbyte, weitere Datenbyte anzuhängen.
Aber was geschieht; mein Fahrregler und meine Funktionsdecoder ignorieren das zusätzliche Datenbyte und arbeiten
normal weiter, aber die Loks rühren sich nicht. Die Decoder müssten das zusätzliche Datenbyte überlesen
weil sie auf das nächste Synchronisationsbyte warten sollten, aber Funkstille.
Also ging ich hin und baute zwischen zwei Grundrahmen einige Störbits ein. Bestanden die Störbits aus 1-Bits,
gab es keine Probleme, aber sobald ein paar 0-Bits hintereinander folgten war wieder Funkstille.
Vermutlich gibt es bei einer Erweiterung des Protokolls Probleme mit der Abwärtskompatibilität zu SX1-Produkten.
Was erwarten Modellbahner überhaupt von SX2?
| 4-stelliger Adressbereich 0-9999 |
derzeit möglich 103, 4-stellige Adresseingabe unkomfortabel aber gutes Werbeargument |
| 127 Fahrstufen | bereits vorhanden 7 mal 31 Fahrstufen, durch die logarithmische Kennlinie ein, weiches Anfahren und Abbremsen möglich |
| 8 Funktionsausgänge | vorhanden 2 Funktionsausgänge, das ist zu wenig, 8 Funktionen wünschenswert, Schalten von Kupplungen, Licht, Soundmodulen |
Mai 2004
Nachdem ich im April den obigen Artikel eingestellt habe, scheint doch etwas Schwung in diese Sache zu kommen.
Mittlerweile bin ich hingegangen und habe das SX1-Protokoll erweitert.
Ich habe an jeden SX1-Frame mit 96 Bit zwei weitere mit je 60 Bit angehängt. Der zusätzliche Frame (Sx2-Frame)
besteht aus 5 Byte (Synch+4 Byte). Der SX2-Frame ist kürzer als der SX1-Frame und wird von den Lokdecodern
nicht erkannt, sie laufen weiter, wie bisher. Damit ist schon mal die Abwärtskompatibilität gewährleistet.
In meinen Versuchen habe ich meinen SX2-Frame mal wie folgt definiert:
| Byte(12Bit) | PX-Bus | SX-Bus |
| 1. Synch | Synch-Bits + Adresse A8-A11 | Kennung + Adresse A8-A11 Kennung=1, Frame belegt |
| 2. Adresse | Adresse A0-A7 | Adresse A0-A7 |
| 3. Data | 127 Fahrstufen + Richtung | 127 Fahrstufen + Richtung |
| 4. Data | Funktion 1-8 | Funktion 1-8 |
| 5. Data | Funktion 9-16 | Funktion 9-16 |
Für die Decoderadresse stehen mir so 13 Bit zur Verfuegung (8192 Adressen). Ich habe nur mal 12 Bit verwendet.
Es wäre aber auch möglich die Adressen in 2 vollen Bytes zu übertragen (16 Bit = 65535 Adressen). Welche Bits,
welche Bedeutung haben sollen, ist Vereinbarungssache unter den Produktherstellern.
Wichtiger sind die Laufzeiten bei zusaetzlich eingebauten Frames. Führt man ständig 16 zusätzliche Frames (je 5 Byte)
mit, ist eine Verzögerung kaum feststellbar. Dies wird erst ab 32 Frames merkbar. Es macht aber keinen Sinn leere Frames
mitzuführen, sondern nur diese, welche eine Adresse belegen. Die Zentrale muss dies verwalten.
So könnte es aussehen.
Zu Beginn wird ein Leerframe an einen SX1-Frame angehangen. Ein Fahrregler, der eingeschaltet wird und eine SX2-Adresse
benutzt, sucht diese Adresse. Falls sie nicht vorhanden ist, belegt er den Leerframe mit der Adresse. Die Zentrale übernimmt
diese Adresse als ständigen Frame und baut wieder einen Leerframe ein. So wird mit jeder neuen Adressen das Protokoll
erweitert. Theoretisch beliebig lang. Dies wird aber durch den Fahrbetrieb begrenzt sein, da sicherlich kaum mehr als
30-40 Loks gleichzeitig fahren werden. Adressen die eine Zeit (5 Minuten) lang nicht benutzt werden, werden aus dem
Protokoll herausgenommen, so dass nach meiner Erfahrung im Club (MTKB) vielleicht maximal 20 Adressen mitgeführt werden.
Ein Problem bei der Belegung eines Leerframes entsteht, wenn mehrere Fahrregler gleichzeitig eine SX2-Adresse einfügen
wollen. Dies ist dann der Fall, wenn die Anlage eingeschaltet wird und angeschlossene Fahrregler mit ihren zuletzt ein-
gestellten SX2-Adressen zugreifen. Sie werden mit Sicherheit ein und denselben Leerframe überschreiben (Kollision).
Es ensteht eine Mischadresse, die als Ballast mitgeschleppt wird. Im nächsten Buszyklus werden die Fahrregler dies
wiederholen, usw (Deadlock). Abhilfe wäre eine Art von Handshakebetrieb mit der Zentrale, aber wie?
Ist einzig ein Interface (Computer) angeschlossen, tritt dies nicht auf, weil es sequentiell auf den Bus zugreift.
Auch im praktischen Fahrbetrieb ist es nicht wahrscheinlich, dass auf zwei oder mehreren Fahrreglern, zeitgleich
neue Adressen angemeldet werden.
Des weiteren ist bei einem dynamischen Mitführen von SX2-Frames zu bedenken, dass Fahrregler dies möglichst einfach
erkennen sollten (Regler-Software). Ich habe jetzt an jeden SX1-Frame grundsätzlich eine SX2-Synchbyte angehangen.
Das Synchbyte dieser Frames enthält die Information, wieviel SX2-Frames folgen. Ein Fahrregler liest das erste Synchbyte
als achtes Datenbyte und kann die nachfolgenden Bytes interpretieren.
Bei einer Belegung ab 16 SX2-Adressen ist eine Verzögerung beim Schalten von Funktionsdecoder über mein Gleisbildstellpult
erkennbar, d.h. der Taster muss etwas länger gehalten werden bis die Rückmeldeleuchten reagieren. An meinem Funktionsdecoder
am Gleis, der einen Lokdecoder im Fahrbetrieb simuliert, ist dies kaum zu erkennen. Wegen der Abwärtskompatibilität muss
man leider den SX1-Ballast mitschleppen und so die Reaktionszeiten in Kauf nehmen.
Oktober 2004
Das Anmelden einer SX2-Adresse ist erstmal ueber Kanal 104/105 gelöst, d.h. der Fahrregler sucht im laufenden Telegramm
seine eingestellte Adresse, wird sie nicht gefunden, so trägt er in K104/105 diese Adresse ein. Bit 7 in K105 wird dabei
als Anmeldeflag zwischen Zentrale und Fahrregler benutzt.
Die Zentrale uebernimmt die Anmeldung und trägt die Adresse als zusaetzlichen Frame in das Telegramm ein.
Es werden bis zu 64 SX2-Adressen verwaltet. Wird eine Adresse ein bestimmte Zeit lang nicht benutzt,
d.h. steht ueber 10 Minuten bei einer Adresse die Fahrstufe auf 0, Licht aus, keine Funktion eingeschaltet,
so wird diese Adresse aus der Liste der SX2-Frames gelöscht. Damit ist sicher gestellt, dass nur die notwendigen
Adressen im Telegramm uebertragen werden.
Die Verzögerung durch eine Anmeldung, auch einer erneuten Anmeldung, ist kaum wahrnehmbar.
Der Fahrregler entscheidet selbst, ob eine SX1- oder SX2-Adresse verwendet wird. Adressen ueber 111 werden
als SX2-Adressen interpretiert.
Februar 2005
Nun ist es raus. Man nennt es Adressdynamik.
Jetzt fehlen nur noch die Lokdecoder, dann kann es los gehen.
Juni 2005
Für ein SX2-Telegramm wird ein Synchzeichen mehr generiert, damit können die Teilnehmer zwischen
SX1- und SX2-Telegrammen unterscheiden. Ein Fahrregler, der mit höheren Adressen oder den erweiterten
Eigenschaften von SX2 arbeitet, muss zuerst ein zusätzliches SX2-Telegramm von der Zentrale anfordern.
Dazu ist generell ein sogenanntes Leertelegramm im Umlauf. Dies enthält 2 Informationsbit s0 und s1.
Der Fahrregler belegt je nach Anforderung diese Bits, dabei können 3 Anforderungen gestellt werden;
Anforderung eines Kurz- (bis 400 Adressen), eines Lang- (bis 10000 Adressen) oder Programmiertelegramms.
Nimmt man an, der Fahrregler fordert z.B. ein Kurztelegramm an, die Zentrale erzeugt ab dem nächsten
Telegrammumlauf ein zusätzliches leeres Kurztelegramm. Der Fahrregler erkennt an dessen Infobits dieses
Kurztelegramm und belegt dies mit seiner eingestellten Adresse, Geschwindingkeit, u.s.w.
Zum bisherigen SX1-Telegramm sind dann ein Leertelegramm und ein Kurztelegramm im Umlauf.
Will derselbe oder ein anderer Fahrregler/Interface für eine weitere Lok eine Kurztelegramm
anfordern, geschieht dies auf die gleiche Weise wie zuvor.
Aber, dies neue leere Kurztelegramm muss mit der neuen Adresse u.s.w vom Teilnehmer belegt werden.
Das Leertelegramm wird an den Infobits s0=0 und s1=0, das Kurztelegramm an s0=1 und s1=0, erkannt.
Nur ist nicht zu erkennen ob das folgende Kurztelegramm leer oder schon belegt ist. Dies erkennt
man erst, wenn das Telegramm vorbei ist.
Dezember 2006
Der SX2-Decoder ist da. Hier im Bild, montiert auf einer AR V200.
Formate
|
|
 |
Der Decoder reagiert auf das Format (SX1, SX2 oder DCC) in dem er zuletzt programmiert wurde.
Die einzelnen Parameter der Formate sind voneinander unabhängig.
nach oben