Hallo Stummis

Der RS-Bus ist der standard Feedback-Bus für das Lenz System und wird von mehrere Hersteller unterstützt. Im Gegensatz zu andere Rückmeldesystemen, implementiert der RS-Bus eine Stromschleife (anstelle von Spannungspegeln), wodurch Rückmeldenachrichten weniger Störanfällig sind. Auch erhalten RS-Bus-Pakete ein Paritätsbit, wodurch eine Art Fehlererkennung möglich ist. Der LZV Zentrale benachrichtigt die Rückmeldedecoder wenn einen solchen Paritätsfehler erkannt wird.

Trotz dieser Vorteile gibt es nur wenige Open-Source Projekte die den RS-Bus für Feedback benützen. Vor etwa zwei Jahren habe ich daher meine RS-Bus-Implementierung als Arduimo Bibliothek auf GitHub bereit gestellt. Vor kurzem habe ich Teile der Empfangssoftware neu geschrieben, um die Effizienz der Bibliothek für moderne ATmega-Prozessoren wie den 4809 (Nano Every) und die AVR DA- und DB-Serie zu verbessern.

Ich hoffe, dass Version 2 dieser Bibliothek andere dazu inspirieren wird, auch RS-Bus-Feedback-Decoder zu implementieren. Bei Interesse werde ich in nachfolgenden Nachrichten weitere Informationen geben.

https://github.com/aikopras/RSbus

Schönen Gruß
Aiko

Hallo Stumis

Heute möchte ich an ein Beispiel zeigen wie man die RS-Bus library benützen kann. Jede Sekunde wird einen 8-Bit Wert gesendet, der immer weiter erhöht wird. Die benützte RS-Bus Adresse ist 100.

Ich hoffe der Code ist zu verstehen. Um 8 Bits zu senden, wird rsbus.send8bits(value) angerufen. Dieser Anruf speichert den Wert in der Library, wonach rsbus.checkConnection() versucht den Wert tatsächlich zu senden.

Natürlich braucht man, neben irgend ein Arduino board, auch entsprechende RS-Bus hardware. Dazu kann man zur Beispiel die folgende Platine benützen: https://easyeda.com/aikopras/rs-bus-tht.

Aiko

#include <Arduino.h>
#include <RSbus.h>
 
// The following parameters specify the hardware that is being used and the RS-Bus address
const uint8_t ledPin = 13;           // Pin for the LED. Usually Pin 13
const uint8_t RsBus_USART = 0;       // Use USART-0. On most boards TX, TXD, TX0 or TXD0
const uint8_t RsBus_RX = 2;          // INTx: one of the interrupt pins
const uint8_t RS_Address = 100;      // RS-Bus addresses must have a value between 1..128
 

// Instatiate the objects being used
// The RSbushardware object is responsible for the RS-Bus ISR and USART.
// The RSbusConnection object maintains the data channel with the master and formats the messages 
extern RSbusHardware rsbusHardware;  // This object is defined and instantiated in the RS-Bus library
RSbusConnection rsbus;               // Per RS-Bus address we need a dedicated object
unsigned long T_last;                // For testing: we send 1 message per second
uint8_t value;                       // The test value we will send over the RS-Bus 
 

void setup() {
  rsbusHardware.attach(RsBus_USART, RsBus_RX);    
  rsbus.address = RS_Address;        // 1.. 128
  value = 0;                         // Initial value
  pinMode(ledPin, OUTPUT);
}
 

void loop() {
  // For testing purposes we try every second to send 8 bits (2 messages) over the RS-Bus
  if ((millis() - T_last) > 1000) {
    T_last = millis();
    if (rsbusHardware.rsSignalIsOK) {
      value++;
      rsbus.send8bits(value);        // Tell the RS-Bus library to buffer these 8 bits for later sending
      digitalWrite(ledPin, HIGH);    // Turn LED on to indicate we have a valid RS-Bus signal
    }
    else digitalWrite(ledPin, LOW);  // No valid RS-Bus signal
  }
  // If a RS-Bus feedback decoder starts, or after certain errors, the feedback decoder needs to "register" 
  // itself to the master station by sending all 8 feedback bits
  if (rsbus.feedbackRequested) rsbus.send8bits(0);
  // Next functions should be called from the main loop as often as possible
  rsbusHardware.checkPolling();      // Listen to RS-Bus polling messages for our turn
  rsbus.checkConnection();           // If data was stored in the buffer for later sending, try to send it
}
 
 

Liebe Stummis

Heute möchte ich zeigen wie man mittels Code ähnlich wie die RS-Bus Library ein RS-Bus Monitor bauen kann.

Obwohl der RS-Bus im vergleich zu einige andere Rückmeldesysteme relativ Störungsunempfindlich ist, ist es nicht ausgeschlossen dass trotzdem Fehler auftreten. Zur Beispiel zeigt die Modellbahnsteuerung eine Rückmeldung nicht an die hätte kommen müssen. Man fragt sich dann ob der Decoder der Rückmeldung überhaupt gesendet hat, oder ob es Bus-Störungen gegeben hat oder das es ein Problem beim Empfänger gab. In solche Fälle wäre es Wünschenswert wenn man ein RS-Bus-Monitor hätte.

Zum Glück ist es relativ einfach einen Arduino-Sketch zu schreiben, der den RS-Bus-Betrieb überwacht. Im Examples Verzeichnis der RS-Bus Bibliothek ist sogar ein Beispiel von so einen Sketch enthalten. Als Hardware braucht mann, neben ein Arduino der mit ein PC verbunden ist, nur den Receive Teil vom RS-Bus hardware, wie unten gezeigt
Bild entfernt (keine Rechte)

Folgende Aspekte können mit dem Beispiel Sketch überwacht werden:
- ob und von welcher RS-Bus-Adresse eine Nachricht gesendet wird
- ob der Command Station ein (Paritäts-)Fehler meldet
- ob Störungen durch externe elektrische Quellen zusätzliche Impulse einfügen (Pulse Count Error)
- ob ein Decoder statt 2ms, die doppelte Zeit für die Übertragung braucht (Doppelbyte)

Die Frage ist nun wie das funktionieren kann.

Im Normalfall, wenn kein Decoder etwas meldet, sendet ein RS-Bus Master 130 Pulse hintereinander. Nachdem alle 130 Pulse gesendet sind, gibt es ein pause von etwa 7ms. Die RS-Bus Monitor Software schaut daher jede Millisekunde was genau am RS-Bus passiert, und wenn mehr als 5ms keine Pulse mehr empfangen sind, weiss es das es sich wahrscheinlich um ein normale 7ms Pause handelt.
Bild entfernt (keine Rechte)

Wenn keine Störungen auftreten, müssen zwischen zwei Pausen genau 130 Pulse empfangen werden. Wenn mehr (oder weniger) Pulse empfangen sind, muss es Elektrische Störungen gegeben haben und wird ein Pulse Count Error erzeugt.

Die Pulse werden von alle Decoder empfangen und gezählt. Nach jede 7 ms Pause werden die Pulszähler wieder auf Null zurückgesetzt. Wenn ein Decoder senden möchtest, wird so lange gewartet bis der Pulszähler den gleichen Wert hat als die Decoder Adresse. Erst dann sendet der Decoder sein Datenbyte, und der master Station wartet bis der Decoder fertig ist bevor die folgende Pulse gesendet werden. Normalerweise dauert es etwas über 2ms bevor der Decoder fertig ist. Da unser Monitor nicht nur Pulse zählt aber auch jede ms schaut was genau passiert, weiss der Monitor software ob gesendet wird und von welche Adresse.
Bild entfernt (keine Rechte)

Wenn der RS-Bus gestört wird während ein Decoder sendet, können bit Fehler auftreten die vom Master Station als Party Error delektiert werden können. Der Master Station informiert jetzt das ein Party Error aufgetreten ist, damit er statt 7ms eine Pause vom 10,5ms wartet. Jede Decoder, also auch unsere RS-Bus Monitor, weiss jetzt das es ein Parity Fehler gab.
Bild entfernt (keine Rechte)

Es gibt noch einige andere Fehler der angezeigt werden können. Für Details und der Monitor Sketch, sehe:
https://github.com/aikopras/RSbus/blob/m...tras/Monitor.md

Es ist zu beachten dass der Datenbyte Inhalt die ein Rückmeldedecoder an den Master Station sendet, nicht angezeigt werden kann mit der RS-Bus Monitor und normaler RS-Bus-Rückmeldedecoder-Hardware. Der Grund liegt darin das ein RS-Bus Decoder Stromimpulse sendet, statt Spannungsimpulse. Spannung die zwischen zwei Leitungen steht kann mann einfach messen, Strom die durch eine Leitung fliest ist schwieriger zu messen. Die Überwachung der Inhalt der Datenbytes erfordert spezielle Hardware, wie sie zur Beispiel auf https://sites.google.com/site/dcctrains/...-monitor/rs-bus beschrieben ist.
Wenn man unbedingt der Inhalt von RS-Bus Berichte auch anzeigen möchte, ist ein besserer Ansatz nicht am RS-Bus selber zu messen, aber was der Master Station davon am Xpressnet Interface ausgibt. Dazu kann man das Lenz-eigene LAN/USB-Interface benützen (Seriennummer: 23151), und Software schreiben der mitliest was genau vom master Station empfangen wurde. MAC OSX-Software die das macht kann heruntergeladen werden von: https://github.com/aikopras/OSX-DCC-Monitor. Eine Windows-Version davon habe ich selber nicht geschrieben, daher bleibt das eine tolle Aufgabe für andere Open-Source-Enthusiasten.

Schönen Gruß
Aiko


Weblinks:
• Der Moba - RS-Bus
• RS-Bus Library - GitHub
• RS-Bus Monitor Sketch - GitHub
• DCC und RS-Bus Monitor für MacOS
• RS-Bus Platine - Normale Komponenten
• RS-Bus Platine - SMD Komponenten

Liebe Stumm

Heute möchte ich mein Arduino Library zum dekodieren von DCC Signale vorstellen: der AP_DCC_Library.
Ein neuer DCC Library? Brauchen wir das? ich wurde meinen nein, …… oder, vielleicht doch …?

Es gibt schon viele Jahre die NmraDcc Library. Diese Bibliothek funktioniert in die meiste Fälle hervorragend, und der Support im Internet ist ausgezeichnet. Es gibt hunderte von Sketches die mit diese Bibliothek gebaut worden sind, und die laufen auf traditionele Arduino Uno (und ähnliche Boards) aber auch auf neuere Platformen, wie zur Beispiel der ESP32. Warum also etwas neues?

Dazu erst etwas Hintergrund. Da ich meine Platinen gerne selber herstelle (oder besser: in China herstellen lasse), benütze ich auch gerne die neuere ATMega Processoren, wie zur Beispiel der 4809 und der AVR-DA und AVR-DB Prozessoren. Diese neue Prozessoren sind nicht nur “besser” als die alte AtMega 328 oder 2560, aber auch noch billiger. Für neuere Decoder Boards kann ich daher jeder empfehlen diese neuere Prozessoren ein zu setzen.

NmraDcc und neuere Prozessoren
Obwohl der NmraDcc-Bibliothek lauft auf die neue AtMega4809, ist deren Leistung etwas enttäuschend. Das hat mehrere Grunde, worauf ich später eingehen werde. Anpassung der NmraDcc-Bibliothek ist nicht einfach, denn es gibt ein zweites Problem: der Quellcode ist nicht sonderlich gut strukturiert und lesbar. Alles steht in eine grosse Datei, und separate Module die optimiert für bestimmte Processoren sind, sind nicht vorher gesehen. Selber neue Module bei zu steuern die optimiert für die neuere AtMega Processoren sind, ist daher kaum möglich. Wenn ich mich aber irre und jemanden Teile meiner Code in der NmraDcc-Bibliothek einfügen kann, würde ich mich aber freuen.

Die NmraDcc-Bibliothek verfolgt einen "brute-force"-Ansatz um das DCC-Signal zu dekodieren. Brute-force in dem Sinne, dass sie nur auf CPU-Geschwindigkeit setzt. Die NmraDcc-Bibliothek benützt keiner der spezielle Hardware-Peripherie Systeme, die auf neuere ATMega Prozessoren zu finden sind. Zur beispiel benützt die NmraDcc-Bibliothek keiner der extra Timers und auch nicht das Event System, die die neuere AtMega Prozessoren gerade so attraktiv machen.

Die Entwicklung von Mikroprozessoren geht in zwei Richtungen. Einerseits sehen wir schnellere Prozessoren (mehr Mhz) auf den Markt erscheinen. Beispiele sind der Raspberry Pi Pico (mit 125 MHz) und der ESP-32 (mit 160 MHz). Anderseits sehen wir eine Entwicklung bei der Prozessoren Leistungsfähigere Zusatz (Peripherie) Funktionen bieten, wie das Event-System, mehr und bessere Timers und Funktionen zur Störungsunterdrückung. Der NmraDcc-Bibliothek richtet sich in die erste Richtung, der AP-DCC-Bibliothek in die Zweite.
Bild entfernt (keine Rechte)

DCC Signal Decodierung
Da ein DCC Signal etwa jede 100 Mikrosekunden von Polarität wechselt, ist es wichtig innerhalb von wenige Mikrosekunde auf eine Änderung zu reagieren. Dafür benutzt man Interrupts. Traditionelle ATmega Prozessoren, wie dem 328P (für den Uno und Nano) und 2560 (für den Mega), haben eine begrenzte Anzahl von Interrupt Pins, die aber alle über ihre eigene Interrupt Vector verfügen und damit sofort ihre eigenen Interrupt Service Routine (ISR) auslösen können. Dies macht herkömmliche ATmega Prozessoren relativ schnell.

Neue ATmega Prozessoren
Die neue ATmega Prozessoren, wie der 4809 und der AVR-DA und AVR-DB Prozessoren, sind etwas anders und unterstützen Interrupts auf (fast) alle Eingänge. Das gibt zwar viele Vorteile, aber leider auch einige Nachteile. So teilen sich zur Beispiel alle Pins die zu einem bestimmten Port gehören, den gleichen ISR-Vektor und Routine. Das resultiert darin das nach ein Interrupt zusätzliche Code ausgeführt werden muss, um zu bestimmen, zu welchem ​​Pin der Interrupt gehört / welche Routine aufgerufen werden muss, um den benutzerspezifischen Teil der Interrupt-Routine aus zu führen. Das Resultat ist das der Anruf von traditionele Interrupt Code (welche auf `attachInterrupt’ basiert) auf neue ATmega Prozessoren etwa zwei mal zu viel Zeit kostet. Zum Glück kann man, statt traditionele Interrupt Code, auch das neue Event system einsetzen um ein Interrupt aus zu lösen wenn das DCC Signal von Polarität wechselt. Dan wird das ganze plötzlich viel schneller.

Performance von den NmraDcc Bibliothek auf 4809 Prozessoren
Im vergleich zu Traditionele ATMega Prozessoren, ist der NmraDcc Bibliothek wegen die andere Interrupt Struktur der neuere ATMega Prozessoren viel langsamer. Ein zusätzliches Problem ist das auch der Arduino `micros()’ Anruf auf neuere ATMega Prozessoren deutlich langsamer ist.
Beide Probleme sind in der folgenden Abbildung dargestellt, die einige NmraDcc-Bibliothek Messungen zeigen. Mann sieht dass auf ein UNO (328) etwa 9 Mikrosekunden benötigt werden um ein Wechsel des DCC-Eingangssignal zu detektieren (attachInterrupt + micros() + digitalRead()), während auf ein Nano Every (4809) etwa 17 Mikrosekunden benötigt werden.
Bild entfernt (keine Rechte)

Wie es besser geht
Obwohl AttachInterrupt() und Micros() auf neue ATMega Prozessoren erheblich langsamer sind, enthalten diese neuen Prozessoren auch eine Reihe neue Peripherie Funktionen, die eine viel schnellere und weitaus präzisere DCC-Decodierung ermöglichen. Det wichtigste neue Peripherie Funktion ist das Event (Ereignis)system, das es ermöglicht den DCC-Eingangs-Pin direkt mit einem Timer zu verbinden. Immer wenn das DCC-Eingangssignal von Polarität ändert, wird der Timer sofort (neu) gestartet, ohne Beteiligung der CPU (oder ein ISR). Darüber hinaus verfügen die verbesserten Timer über neuartige Funktionen wie den „Capture Frequency Measurement Mode“. In diesem Mode aktiviert ein Event (Ereignis) den Timer, um die Zeit seit dem vorherigen Ereignis sehr präzise zu erfassen und in einem speziellen Register zu speichern. Erst danach wird der Timer ISR angerufen, der dann dieses Register in alle ruhe auslesen kann, und beurteilen ob eine 0 oder eine 1 empfangen würde.

Dank des Ereignissystem und dem „Capture Frequency Measurement Mode“, kann der AP_DCC_Library das DCC-Signal sehr präzise erfassen, so das die Bit-Timing-Werte, die vom RCN-210 vorgegeben sind, genau eingehalten werden. Das ist mit der NmraDcc Bibliothek unmöglich. Das DCC Signal wird daher besser erkannt, und Störungen haben weniger Effekt.

Ein zweiter Vorteil ist das der CPU wenige belast wird, weil das Event System und den Timer die meiste Arbeit verrichten. Die folgende Abbildung zeigt dies bei einem (24-MHz) AVR 128DA48 Prozessor, worauf der Main-loop bei jedem Durchgang der TP4 Ausgang ein- und wieder ausschaltet. Nur wenn ein Interrupt Service Routine den Main-loop unterbricht, kann TP4 temporär nicht ein- und ausgeschaltet werden. Die Figur zeigt das, nachdem das DCC seine Polarität gewechselt hat, der Interrupt Service Routine nur noch 3 bis 4 Mikrosekunden benötigt um das DCC Signal zu erfassen und dekodieren. Das ist, verglichen mit der NmraDcc-Bibliothek, eine klare Verbesserung. Statt 15 Mikrosekunden auf ein UNO (328), oder sogar 22 Mikrosekunden auf der Nano Every (4809), wird jetzt nur noch (zwei mal) 3 à 4 Mikrosekunden benötigt (jedes mal wenn die Polarität wechselt).
Bild entfernt (keine Rechte)

Ich hoffe das es Stummis gibt die mit diese Bibliothek etwas anfangen können. Auch möchte ich das OpenDCC Forum bedanken, für die wertvolle Unterstützung die ich während die Entwicklung diese Bibliothek empfangen dürfte.

Aiko

https://github.com/aikopras/AP_DCC_library

Hallo Kollegen,

ich bin eben auf den thread aufmerksam geworden.
Jetzt bin ich nicht der "Softwerker" dennoch hat mich euer Wissen und Fähigkeiten beeindruckt.

Daher mal die Frage an die "Schwarmintelligenz" hier im Forum.

Ich suche einen S88 -> RS Converter.

Hintergrund ist der Drehscheibendecoder von Sven Brand https://digital-bahn.de/shopping/kit_DSD2022 dieser liefert nur das S88 Protokoll.
Leider kann meine Lenz Zentrale damit nichts anfangen. Lenz hat ja den RS Rückmeldebus.

Fragende Grüße
Hans

Ich denken es einfacher war ein separater S88 Interface zu kaufen.

Klaus

Zitat von moppe im Beitrag #6

---

Ich denken es einfacher war ein separater S88 Interface zu kaufen.

Klaus

---

Zitat von hans-gander im Beitrag #7

---

der Drehscheibendecoder liefert ein Signal nach dem S88 Protokoll. Mein Lenz Digitalsystem verlangt aber ein Signal nach dem RS-Protokoll.

---

Hallo Klaus,
ich betreibe meine Modellbahn mit Railware Software.
Damit die Software weiß, wo die Drehscheibenbühne steht und welche Lok darauf steht wird das vom Drehscheibendecoder per S88 BUS zurückgemeldet.
Ich hoffe, dass ich konnte deine Frage erschöpfend beantworten.
Beste Grüße
Hans

Zitat von hans-gander im Beitrag #9

---

Hallo Klaus,
ich betreibe meine Modellbahn mit Railware Software.
Damit die Software weiß, wo die Drehscheibenbühne steht und welche Lok darauf steht wird das vom Drehscheibendecoder per S88 BUS zurückgemeldet.
Ich hoffe, dass ich konnte deine Frage erschöpfend beantworten

---

Zitat von hans-gander im Beitrag #5

---

Hallo Kollegen,
Ich suche einen S88 -> RS Converter.

Hintergrund ist der Drehscheibendecoder von Sven Brand https://digital-bahn.de/shopping/kit_DSD2022 dieser liefert nur das S88 Protokoll.
Leider kann meine Lenz Zentrale damit nichts anfangen. Lenz hat ja den RS Rückmeldebus.

---

Hallo Aiko,
vielen Dank für deinen ausfürlichen Beitrag.
Ich bin ein analoges Fosil. Kenne mich mit OP's aus und habe nie den Umstieg in die digitale Welt gemacht. Daher kommt für mich nur eine fertige Lösung in Frage.
Ich kann zwar die Drehscheibe "händisch" bedienen, nur sind halt keine Abläufe mit Railware möglich.
Beste Grüße @ all
Hans