Guten Morgen,

ich möchte euch hier mein aktuelles Projekt für einen Rückmeldebaustein vorstellen.

Ursprünglich bin ich durch die LZV100 auf den RS-Bus angewiesen gewesen. Für diesen gibt es leider eine geringere Vielfalt an Rückmeldebausteinen als für andere Bussysteme und auch preislich sind die Bausteine eher teuer. Letztlich sind aber auch für andere Busse die Bausteine pro Rückmeldeadresse nicht gerade billig.

Ein zweiter Aspekt war, dass ich einfach keine Lust hatte, über meine 9 Segmente noch ein weiteres Buskabel zu verlegen, um dann pro Segment nur einen Baustein zu versorgen. (Das mag komisch wirken, ist aber so.)

Und dann erfuhr ich von der Arduino-Welt. Seither bin ich fasziniert von den Möglichkeiten. Als ich dann noch den ESP8266 kennenlernte, der noch kleiner war, leistungsfähiger, und WLAN an Bord hatte, war das weitere Vorgehen klar: Die Rückmeldung muss drahtlos erfolgen, ein Rückmeldebaustein muss lediglich lokal mit Strom versorgt werden.

In https://youtu.be/pCdXxmmhwbA könnt ihr den Rückmelder in Aktion sehen mit einem eigens gebauten Testgleis und einem Halleffektsensor im Gleis (N). In weiteren Beiträgen werde ich den Aufbau der Platine und die Materialien beschreiben.

Nun fragt sich der eine oder andere, warum ich mit dem Zusatz "smart" agiere. Da ich die Software des Bausteins volkommen in meiner Hand habe, konnte ich ein Optimum an Funktionalität und Komfort umsetzen. Zum Komfort zählt für mich eine einfache Konfiguration. Ich will nicht wie üblich über Tastendrücke Adressen lernen lassen und dabei unter die Anlage kriechen müssen - daher gibt es ein Web-Interface. Ferner steht die Frage, warum ein Rückmeldebaustein einfach nur Rückmeldungen geben soll - mindestens soll er (ebenfalls über das Webinterface) Auskunft über die Belegtmeldungen geben (zu Testzwecken) und nebenbei noch Geschwindigkeiten zwischen benachbarten Meldern messen - einfach bei jeder Überfahrt oder etwas anspruchsvoller durch Ermittlung und grafischer Anzeige einer Messkurve (Fahrstufe zu Geschwindigkeit), wobei das zu messende Fahrzeug vom Baustein gesteuert wird (ebenfalls via WLAN - ich verwende eine DR5000, kompatibel zur Z21). Oder die Konfiguration von Schaltbefehlen, die beim Ansprechen eines Melders ausgelöst werden, die ich z.B. für einen Signalhaltfall nutze.

Viele Möglichkeiten also, von denen ich schon fast alle realisiert habe und berichten werde. Und das beste: die Materialkosten liegen bei etwa 1€ pro Rückmeldeadresse. Nicht eingerechnet die Arbeit, aber die zählt im Hobbybereich bekanntlich anders und allein die technische Herausforderung reizte mich.

Es gibt viele Modellbahnkollegen, die tiefe Elektronikkentnisse haben. Das ist bei mir anders, ich könnte niemals eine Schaltung entwerfen, die über Widerstände und Dioden hinausgeht. Bei meinem Projekt brauchte ich jedoch wenig Kenntnisse auf diesem Gebiet, dafür kann ich programmieren und habe meine C++ - Kenntnisse wieder ausgegraben (wobei ich gestehen muss, C++ nicht wirklich zu mögen).

Ich würde mich über Interesse freuen und hoffe auch auf die eine oder andere Anregung!

Moin Frank,
so ein ESP8266 WLAN-Rückmelder ist vor einigen Jahren mal im Rocrailforum vorgestellt worden, hat dort aber wenig Resonanz gefunden.
Mit Anbindung an MQTT laufen dort m.E. zwei weitere Projekte dieser Art.
Das nur als Vorbemerkung.

Da ich selber auch Lenz mit RS-Bus fahre und als Gartenbahner nicht immer überall Strippen zur Verfügung habe, interessiert mich Dein Projekt,
wenn es ohne MQTT auskommt (ich will hier keinen MQTT einbinden).
Mit Youtube habe ich leider meine Probleme, mir daraus verständliche Regieanweisungen und Hinweise zum Bau herauszuziehen, ich bevorzuge eine "richtige" Dokumentation, gerne auch auf elektronischem Medium.

Mein Einsatzspektrum / Lastenheft sähe so aus (sicherlich gegenüber Deinem Vorhaben stark reduziert)
- Einsatz ESP8266 als Rückmeldemodul
- Sensor ist Reedkontakt (für Spurweite 45mm). Hallsensor habe ich noch nicht ausprobiert.
- Stromversorung Batterie / Akku 3 x AA oder vergleichbar (je nach Spannungsbedarf)
- Anbindung ESP8266 via WLAN auf den PC mit meiner Steuerungssoftware (PC ist "Raspberry Pi", Software ist "Rocrail")

Ich benötige derzeit nur die "Positionsmeldung" (aktivierter Rückmelder) des ESP8266 auf dem RasPi, den Rest macht meine Steuerungssoftware.
Wenn Du deine Dokumentation unter diesem Gesichtpunkt gestallten könntest, würde ich mich freuen.
Leider habe ich nicht die Zeit, mich selber in diese Materie einzuarbeiten, so dass ich auf vorgefertigte Lösungen / Lösungsbausteine angewiesen bin.

Schöne Grüße
johannes

Zitat

---

ich möchte euch hier mein aktuelles Projekt für einen Rückmeldebaustein vorstellen.

.....

Ich würde mich über Interesse freuen und hoffe auch auf die eine oder andere Anregung!

---

Habe das von Johannes genannte Projekt aus dem Rocrailforum mal versucht aufzubauen, bin aber mit der dort erforderlichen SMD-Löterei des Prozessors nicht klar gekommen und habe mich dann auch für den ESP8266 bzw. ESP32 erwärmt, weil die in der Regel auf Platinen verkauft werden, bei denen ich mir das Löten noch gerade zutraue.

Aktuell gibt es tatsächlich zwei Projekte für reine Stromfühlerbelegtmeldung, in Anlehnung an die üblichen IoT-Projekte, die zu Wehnachten laufen sollen.
Auch ohne MQTT, was aber scheint eigentlich schon der
zukunftsicherste Ansatz zu sein scheint...

MfG

vik

Hallo Johannes und Vik,

schön, dass Ihr Interesse habt! Auch per PN hat mich eine Rückmeldung (huch, in diesem Zusammenhang doppeldeutig ) erreicht.

Es freut mich besonders deshalb, als dass in meinem "Heimatforum" (1:160.net) das Interesse verebbt ist, gerade wo ich mich nun der Fertigstellung nähere, etwas schade. Da es mich trotzdem juckt, alles auszuspeichern, habe ich mich für dieses Forum entschieden, wo zum einen die Basis breiter ist (im wahrsten Sinne der Spurweite) und, so will mir scheinen, auch diese Themen einen breiteren Raum einnehmen.

Primär geht es mir um den Spaß an der Freude, so etwas selbst zu realisieren. Klar, es wird auch eingesetzt, funktionieren muss es auch tadellos. Aber wie schon geschrieben ist der Weg auch das Ziel. Insofern freue ich mich über das Interesse auch von denen, die vielleicht sagen, dass das nichts für sie ist oder sie es für unnötig oder sonstwas halten. Es würde mir reichen, wenn diejenigen rein aus technischem Vergnügen mitdiskutieren.
Deshalb gleich zu Beginn einige Warnungen:

Anbindung an die Zentrale bzw. die PC-Steuerung
Der aufmerksame Leser fragt sich, wohin die Rückmeldungen gehen sollen: wer sie aufnimmt und sie weiterverarbeitet. Dafür gibt es nach meinem Wissen ja nur die bekannten Busse: S88, RS, R-Bus, SX (habe ich einen vergessen?). Diese laufen in die Zentrale und diese verteilt sie an das PC-Steuerungsprogramm. Es gibt wohl auch die direkte Kommunikation mit der PC-Steuerung. Aber ein Netzwerkinterface via WLAN? Was mache ich also? Zum einen mache ich die Bausteine so intelligent (smart ) wie möglich, so dass sie einige Aufgaben einer PC-Steuerung übernehmen können. Sie werden selbst Zubehörbefehle auslösen können (z.B. Signalhaltfall) oder einen Zug vor dem Halt zeigenden Signal abbremsen, und zwar unabhängig von Decodereigenschaften wie ABC (meine Decoder können das nämlich nicht alle). Weitere Steuerung würden von mir selbst geschriebene Programme auf PC, Android oder Arduino sein. Letzteren finde ich sympatisch, weil er nach Einschalten "sofort" da ist. der PC rödelt da erst etwas ...
Natürlich könnte man ein arduinobasiertes Gateway machen, das mit Zusatzhardware (ich denke an das RS485-Max-Modul) auf einen Bus wie S88, RS usw. umsetzt. Ist aber derzeit nicht mein Fokus.

WLAN
Im anderen Forum wurde das kontrovers gesehen - die Zuverlässigkeit sei gegenüber einer Kabelverbindung ein Problem. Ja, mag sein. Fakt ist, ich habe bisher noch keine Probleme gehabt. Der WLAN-Router steht unter der Anlage. Die eingebaute Antenne des ESP8266 ist klein und nicht sehr empfindlich, aber es reicht problemlos. Weiterhin nehme ich UDP. Das macht fire and forget. Bislang auch problemlos. Bei Bedarf gern Diskussion darüber, ich habe auch dafür eine Lösung vorsichtshalber eingebaut.
Worüber ist eine WLAN-Maus mit einer Z21 oder DR5000 verbunden? WLAN Welches Protokoll benutzt sie? UDP. Wenn Roco dem ganzen traut, warum sollte ich das nicht auch...

Nachnutzbarkeit
Ich stelle gern all meine Erkenntniss frei nutzbar (nicht kommerziell) zur Verfügung. Bitte erwartet (noch) nicht eine einfach nachnutzbare Lösung (Platinenlayout, Software zum Download). Im weiteren Fortschritt kann ich darüber nachdenken. Aber es ist ein Unterschied, wenn ich weiß, dass ich im Haus drei konkrete WLAN-SSIDs habe und sich der ESP8266 einfach in das stärkste Netz mittels WiFiMulti einwählt. Das heißt aber auch, ich habe im Code die drei SSIDs und die Passworte hart codiert. Mir reicht das. Für eine Nutzung durch andere müsste ich es umschreiben: der Baustein ist zunächst selbst ein Access Point, man verbindet sich mit ihm und schaltet ihn in den Client-Mode um und konfiguriert per Webzugriff die eigenen SSIDs und Passworte. Nächstes Problem: dann muss ein Reset her (z.B. FLASH-Taster lang drücken), um ihn wieder in den Auslieferungszustand zu bringen, wenn es damit Probleme gibt. Weiterhin: Ich müsste vielleicht über GITHub nachdenken, um dem Code eine Heimat zu geben und jeder kann ihn benutzen. Damit habe ich noch keine Erfahrung und die zu investierende Zeit ist zwar durch den Kenntniszuwachs lohnend, soll aber zunächst in andere Dinge gesteckt werden. Jetzt bin ich ins Schwatzen gekommen, sorry. Wollte nur sagen, warum ich derzeit so denke. Betonung auf derzeit

Ich hoffe, ihr habt trotz dieser Einschränkungen nicht die Lust verloren.

Noch zu euren Anmerkungen:

@Johannes
MQTT sagt mir etwas, aber ich habe damit noch keine Erfahrungen. Es klingt spannend, aber mir reicht die lokale Lösung - und dir ja auch
Reedkontakt: OK. Habe ich im Einsatz, aber die Halleffektsensoren sind schon in der Mehrzahl. Letztlich jeder Input, der gegen Masse schaltet. Also auch ein Schalter oder Taster, um Bedienereingaben zu registrieren und zu reagieren. Beispiel: Der Baustein kann einen Taster lesen und bei Gedrücktsein eine Folge von Schaltbefehlen absetzen, z.B. so einen Fahrweg (ich möchte nicht von Fahrstraße sprechen) schalten. Häh? Was hat das mit Rückmelder zu tun? Es könnte natürlich auch ein Reedkontakt oder Halleffektsensor auslösen, also dessen Rückmeldung.
Die Stromversorgung der Bausteine ist entweder 3.3V oder 5V. Hallefektsensoren, die ich habe, müssen aber auch versorgt werden und da sind 3.3V zu wenig. Aber deine Reeds würden gehen. Zu bedenken ist, dass gerade WLAN energiehungrig ist. Mein Baustein ist für den stationären Einsatz mit 5V-Versorung per Strippe gedacht. Würde ich eine Akkuversorgung planen, gibt es auch eine Lösung: man kann den Baustein in den deep sleep schicken, dann spart er Strom. Aufgeweckt würde er per Interrupt. Allerdings ist nicht jeder GPIO interruptfähig (einer, ich glaube D0, ist es nicht). Akkuversorgung mit deep sleep würde dann auch zwingend Reeds vorschreiben, denn wenn trotz deep sleep die Halleffektsensoren an der Stromversorgung knabbern, wäre der Effekt dahin. Dein Einsatzgebiet könnte aber auch so aussehen: von der digitalen Gleisspannung per Stepdown 5V abzweigen. Lokale Verdrahtung und gut iss.
"Anbindung an PC mit meiner Steuerungssoftware" -> wenn "mein" nicht "selbstgeschrieben" heißt, fehlt noch das Gateway, siehe oben.
Ich glaube, jetzt habe ich dich etwas enttäuscht in Bezug auf einfache Nachnutzbarkeit.

@Vik
Ich verstehe deinen Satz mit den zwei Projekten so, dass es deine Projekte sind, die du bis Weihnachten zum laufen bringen willst - ich bin gespannt über deine Herangehensweise.

Moin Frank,
meine PC Steuerungssoftware ist Rocrail.
Verbindung via WLAN mit dem PC, auf dem Rocrail läuft:
- SSID und Passwort des WLANs würde ich ebenfalls hard kodiert in das Programm schreiben, läßt sich ja bei bedarf neu flaschen. bei mir wäre es nur 1 WLAN, das vom im PC (RasPi) integrierten Router gemanaged wird.
- Natürlich ist LAN (kabel) immer besser als WLAN (Funk), aber für meine Einsatzzwecke ist WLAN ausreichend zuverlässig, ich steuere ja auch mit WLAN-angebundenen Handreglern.

Bus:
bei mir würde das ESP8266 direkt quasi im Klartext an Rocrail melden "Sensor Feedbach15 ist aktiviert", also ist es bei mir (von der WLAN-verbindung mal abgesehen) relativ "dumm". Die Steuerungsintelligenz steckt, wie ich schon geschrieben hatte in der Software Rocrail.

Für einen RasPi anstelle eines ESP8266 habe ich eine funktionierende Software (hat Helge Karkoska mal entwickelt), aber RasPi heißt bis zu 8 Rückmeldeeingänge und eigentlich nicht mehr Gleisstromunabhängig betreibbar.
https://wiki.rocrail.net/doku.php?id=use...i-wlan-feedback
Ein Anwendungsfall wäre bei mir z.B. ein temporärer mobiler Aufbau einer Strecke auf einem Stammtisch, wo mich möglichst Strippenziehen vermeiden möchte. Da würde dann jeder Rückmeldesensor sein eigenes ESP8266-Modul bekommen.

Schöne Grüße
Johannes

(Wo ich noch am neuen Beitrag schrieb, hast du, Johannes, schon geantwortet - ich reiche meine Antwort später nach, hier erst einmal das, woran ich schrieb: )
(Anmerkung 2: Bin noch unerfahren in diesem Forum, es meckert gerade über die Bildgröße, bis dahin bitte dieLinks anklicken ...)

So. Nun etwas mehr Info.



Hier seht ihr das Ausgangsmaterial. Bei meiner kleinen Stückzahl habe ich mich zum Selbstlöten entschieden, klar, eine professionelle Platine wäre besser. Wenn ihr mal eine Rückseite einer Platine sehen solltet, würdet ihr bemerken, dass ich kein Lötgott bin.

Ich hatte noch kein Wort über den ESP8266 verloren, denn es gibt ihn als Entwicklerboard in verschiedenen Ausführungen. Ich habe mich für NodeMCU entschieden (spreche etwas ungenau im folgenden trotzdem vom ESP8266). Aus China bestellt kostet er mich etwa 2,50€ einschl. Versand. Eine sehr gute Seite zum ESP8266 ist übrigens https://tttapa.github.io/ESP8266/Chap01%20-%20ESP8266.html. Der ESP32 ist erst später in mein Bewusstsein gerückt, dazu bei Gelegenheit mehr.

Nun ist es einfach: ich greife 16VAC von meiner Ringleitung in jedem Segment ab, schicke sie durch einen Gleichrichter und danach in den Stepdown, den ich auf 5V einstelle. Die gehen an den ESP8266 und schon ist er bereit. Den ESP8266 löte ich nicht fest ein, sondern stecke ihn in abgelängte Buchsenleisten. Seitlich an den GPIOs D1 bis D7 kommen 3polige Pfostenstecker. Diese sind mit dem GPIO, mit Masse und mit 5V verbunden. Ein Reed oder Schalter schalten den GPIO gegen Masse. Ein Halleffektsensor ebenso, nur dass er zusätzlich die 5V bekommt. Alle Inputs kommen mit Dupontsteckern gecrimpt - ganz wie bei Servos - also zweipolig (Reed) oder dreipolig (Halleffektsensor) an und werden aufgesteckt.

Zusammengebaut sieht das dann so aus:


Alle Teile bis auf die ESP8266 habe ich jeweils in Zehnerpacks - ihr ahnt es - aus China bestellt. Dadurch komme ich auf die umgerechnet 1€ pro Rückmeldeadresse, oder anders, etwa 7€ pro Baustein. Brauche ich zwei Bausteine unter einem Segment, schleife ich die 5V des Stepdowns auf eine kleinere Zweitplatine, die nur den ESP8266 trägt, brauche also keine zweite Gleichrichtung/zweiten Stepdown.

Soweit für heute!

Hallo Johannes,

nun möchte ich meine Antwort auf deinen Beitrag nachholen. Ich werde demnächst mal stöbern gehen auf deinen verlinkten Seiten - sehen spannend aus!

Verstehe ich es richtig, dass Rockrail jenseits der üblichen Rückmeldebusse auch über Netzwerk gemeldete Rückmeldungen auswerten kann? Dann würde es passen. In meinem Baustein konfiguriere ich die Adresse und Port des empfangenden Rechners und bei Punktmeldern sende ich per UDP "P15" für beispielsweise den Punktmelder 15. Wäre Melder 15 ein Belegtmelder, würde "B15+" bei Belegung und "B15-" bei Freiswerden gemeldet.

Ansonsten anbei das eigentlich nicht spannende Platinenlayout mit Vorder- und Rückseite:

Moin Frank,
den gleichen Baustein habe ich auch und verwende ihn lieber als ein "nacktes" ESP8266.
Ja, Rocrail kann die über Netzwerk gemeldeten Rückmelder auswerten. Um die technischen Details dazu habe ich mich bislang nicht sehr gekümmert, das Programm für den RasPi lief einfach von Anfang an.

Adressierung des Zielrechners ("rr_server") ist nur die IP-Adresse, der einzelne Rückmelder ("feedback") wird mit seiner Kennung angesprochen (hier mal ein Auszug, der das Stöbern vereinfachen soll):
#user specific data: ip address rocrail server and rocrail sensor ids
rr_server_ip = '192.168.85.1'

# feedback 1
sensor_1_rr_id = 'FB11'
etc.

# add the XML-Header and send it to the server
def sendMsg(s,xmlMsg):
msg = "<xmlh><xml size="%d"/></xmlh>%s" % (len(xmlMsg), xmlMsg)
print msg
try :
s.sendall(msg)
except socket.error, msg:
print 'Send failed. Restart program'
restart_program()

# Main program

Das Programm ist in Phyton2 geschrieben, ich habe es teilweise mal auf Phyton 3 für das aktuelle RasPi Betriebssystem umgesetzt.

Ein zweites Programm, rein für ESP8266 geschrieben, hatte ich wegen Anschlussbelegungs- und Handlingsproblemen mit dem nackten ESP6266 nicht zum Laufen bekommen und daher zur Seite gelegt, stammt von BBernhard aus dem Rocrailforum und müßte ich dort noch mal wieder aufstöbern.

Schöne Grüße
Johannes

Hallo Frank,

Danke für Deine Erläuterungen.
Ja, für unsere bisherigen Prototypen verwenden wir benfalls NodeMCU-Platinen.

Zitat

---

Der aufmerksame Leser fragt sich, wohin die Rückmeldungen gehen sollen: wer sie aufnimmt und sie weiterverarbeitet. Dafür gibt es nach meinem Wissen ja nur die bekannten Busse: S88, RS, R-Bus, SX (habe ich einen vergessen?). Diese laufen in die Zentrale und diese verteilt sie an das PC-Steuerungsprogramm. Es gibt wohl auch die direkte Kommunikation mit der PC-Steuerung.

@Vik
Ich verstehe deinen Satz mit den zwei Projekten so, dass es deine Projekte sind, die du bis Weihnachten zum laufen bringen willst - ich bin gespannt über deine Herangehensweise.

---

Ja, es geht darum - wie auch bei dem Projekt von Matthias - die Rückmeldung auch für die Teppich- oder Weihnachtsbaumfahrer unter uns praktikabel zu machen. Konkret soll es als Ergänzung für eine vorbestehende S88-Infrastruktur einsetzbar sein und unabhängig im zweiten Projekt davon zur Rückmeldung an eine Z21.
Ich persönlich nutze RR sehr gern, aber die meisten Modellbahner in meinem Umfeld setzen das nicht ein.

MfG

vik

(Mir ist aufgefallen, dass das Thema falsch benannt ist, und ich habe "Belegtmelder" durch "Rückmelder" ersetzt, da jegliche Form der Rückmeldung möglich ist (Punktmelder wie Hall, Reed, Taster, Schalter, Stromfühler.)

Hallo,

heute etwas zum Webinterface. Wir befinden uns im Tab "Netzwerk"



Wenn ich einen Baustein in Betrieb nehme, sucht er sich das stärkste WLAN. Dann finde ich ihn in der Fritzbox und weise ihm eine "merkbare" Adresse zu (192.168.178 ist mein Subnet und die Bausteine kriegen .201, .202 usw.) Entsprechend meldet sich jeder Baustein als "FrankyFunky 206" (Beispiel). Franky von meinem Vornamen und Funky weil Drahtlos. Und weil es etwas irre ist, passt das englische "funky" auch ganz gut.

Zuerst zeig FrankyFunky also seine eigene Adresse.
Unter "Rückmeldungen" kann man eine Liste von vierten Bytes der im gleichen Subnetz liegenden Empfänger von Rückmeldungen konfigurieren. "20,21" würde die Server 192.168.178.20 und 192.168.178.21 bedeuten.
Weiterhin kann man die Adresse einer Z21 (oder DR5000 in meinem Fall) angeben, an die Schaltbefehle gesendet werden, wenn für eine Rückmeldeadresse im Tab "Adressen" eine Reihe von Schaltvorgängen konfiguriert ist.

Ich bin ganz zufrieden mit dieser Konfigurationsmöglichkeit bequem vom PC oder Handy aus und muss mir nicht mehr den Kopf stoßen und unter die Anlage kriechen, speziell zur Adresskonfiguration, Screenshot und Beschreibung dazu demnächst.

PS. Ich habe mich über die Danksagungen (bin ich von anderen Foren nicht gewöhnt) von Majestix und Hardi gefreut - meinerseits Dank dafür, ihr lest hier hoffentlich weiter mit. Edit: ich hatte fbstr vergessen.

Hi Franky,

ich bin erst relativ frisch hier wieder unterwegs, da ich nun endlich dazukommen die MoBa wieder aufzubauen. Da ich auch viel mit uC Programmierung ist der ESP mir nicht fremd und ich verwirkliche gerade einen DCC Servo Dekoder für max 16 Servos pro ESP und konfigurierbar auch per Web.


Verfolge daher Deine Lösung hier auch

Sobald meine Lösung stabil läuft und 100%ig funktioniert, werde ich diese entsprechend vorstellen.

Gruß,
Torsten

Hallo Torsten,

ich begrüße dich als neuen Mitleser!

Wenn du deinen Decoder veröffentlichst, poste doch bitte einen Link auf deinen Beitrag. Ich bin gespannt auf deine Realisierung. Die Konfiguration über Browser ist schon eine gute Möglichkeit, die leider allen bekannten Decodern, die ich kenne, abgeht. Schade eigentlich, dieser Komfort sollte heute selbstverständlich sein. Gut, die Decoder sind oft schon älter und werden nicht mehr verändert.
In meiner Probierphase hatte ich auch mal mit einer Servosteuerung herumgespielt. Als ich merkte, dass mein Standardservo bei meinem gekauften Servodecoder 90° macht, bei eigener "Programmierung" (bei der Einfachheit des Ansprechens mag man kaum von Programmierung sprechen) jedoch fast 180° hergab - entscheidende Grad, die manchmal eine bessere Justierbarkeit bewirken - wollte ich schon gedanklich meine Servodecoder ausmustern und ersetzen...

Viele Grüße
Frank

Hallo,

hier nun der Tab "Adressen", damit kann man sich glaube ich auch besser vorstellen, wie die Funktion gedacht ist:


Jeder Baustein bekommt einen Namen, damit man sich besser erinnern kann, wo er ist ("Reserve 6" ist hier allerdings wenig sprechend).

In der ersten Spalte kann man individuelle Rückmeldeadressen konfigurieren. Sie müssen nicht, wie bei den meisten (allen?) herkömmlichen Bausteinen sequenziell vergeben werden, daher habe ich exemplarisch Lücken gelassen.

Die zweite Spalte mit dem Zelt bestimmt, ob es ein Punkt- oder Belegtmelder ist. Für einen Punktmelder wird immer nur dessen Auslösung (z.B. "P11") gemeldet, für einen Belegtmelder die Belegung ("B11+") und das Freiwerden ("B11-"). Gemeldet wird an die im Tab "Netzwerk" - siehe oben - konfigurierten Server, die das dann für die Steuerung auswerten.

In der Spalte mit der Ortsmarke können Bezeichnungen des Einbauortes angegeben werden, damit man den Melder besser findet.

Zum leichteren Prüfen der Funktion wird hinter dem Loksymbol jede Meldung protokolliert. Die Anzahl, wie oft ein Melder angeschlagen hat wird nach "|" von der letzten Zeit, wann das der Fall war, ergänzt. Melder P33 hat zweimal gemeldet, zuletzt 22:30:57, die Melder 11 und 77 haben je einmal gemeldet.

Und weil ich ja "smarter" Rückmelder geschrieben habe, kann man nach ">>" eintragen, welches Zubehör beim Auslösen geschaltet wird. Für P11 wird die Adresse 8 in Grundstellung geschaltet - das ist in diesem Fall das Signal, welches auf Halt geworfen wird. Melder P66 schaltet die Weichen 22 und 30 in Grund- und die Weiche 23 in Minusstellung. Das könnte z.B. das Schalten des Ausfahrtweges aus dem Schattenbahnhof sein. Klar, all das kann eine Modellbahnsteuerung auch, ich möchte hier aber dem Rückmeldebaustein auch solche Intelligenz spendieren. Die Schaltbefehle werden einfach an die im Tab "Netzwerk" - siehe oben - konfigurierte Z21/DR5000 gesendet.

Diese Webseite des Rückmelders dient also einerseits der Konfiguration der Adressen (nach "Speichern" drücken) und kann gleichzeitig die Rückmeldungen für Testzwecke protokollieren.

Ich könnte mir somit ein Gleisbildstellpult bauen ohne großes Kabelgedöns und damit dann meine möglichen Fahrstrassen schalten?
Z.B. auf Ausstellung Schalten mit Stellpult, aber trotzdem digital, an Rocrail auf Raspi; zu Hause schalten am Rechner?

Hallo Uwe,

in der Tat. Statt eines Reeds oder Halleffektsensors als Input könnte ein Taster dienen. Dessen Betätigung würde eine Reihe von Zubehörartikeln (Weichen und schließlich das Signal) schalten, also einen ganzen Fahrweg. Ich sage bewusst nicht Fahrstraße, weil die Sicherungsebene (z.B. Fahrstraßenausschluss) komplett fehlt.

Was der Baustein nicht kann, ist eine Start-/Zielbedienung, denn das wären zwei Inputs, die zu koordinieren sind. Hm, muss ich mal nachdenken, ob ich das mal später, wenn ich selbst ein Gleisbildstellpult baue, einbauen würde.

Da der ESP8266 nur 7 verwertbare Inputs hat, wären entsprechend viele Bausteine nötig. Oder ein ESP32, der hat mehr Inputs (diesen verwende ich noch nicht, kommt später).

Im Zusammenhang mit deinem Gleisbildstellpult wird dich vielleicht das Feature "Loksteuerung" interessieren, komme ich später darauf zurück, der Tab dazu ist schon im Screenshot sichtbar.

Hi

Durch einen Mitleser bin ich auf diesen Thread hingewiesen worden.

Ich entwickele schön seit längeren ein Framework für Modelleisenbahnen auf Basis des ESP8266
https://littleyoda.github.io/littleyoda-DCC-Decoder-DOC/
https://forum.open4me.de

Das Framwork wurde bereits u.a. erfolgreich als Weichendecoder, als Lokdekoder per PWM Steuerung und als Lokdekoder, der einen Standard DCC SoundDekoder anspricht ("DCC over Wifi"), eingesetzt. Servo steuerung z.B. per F-Tasten als auch über "Weichenbefehle" werden unterstützt.
Hierbei kann das Framework entweder die Befehle über DCC über das Gleis erhalten, aber auch kabellos von einer z21 oder Rocrail. Als Bonus kann das Framework "zentralenlos" genutzt werden. Hierbei wird eine z21 simulieren, so dass eine einzelne Lok via Wlan-Maus oder z21-App gesteuert werden kann.
Ein minimalisierter Prototyp für ein kabelloses Gleisbildstellwerk existiert auch schon.

Konfiguration erfolgt per Config-File.

Vielleicht ergibt sich ja eine produktive Zusammenarbeit.

Hallo,
ich finde das prinzipiell auch interessant und hatte (sowas ähnliches) auch schon versucht per WLAN zu realisieren. Leider hat das aufgrund der stark schwankenden Latenzen im WLAN nicht meinen Ansprüchen genügt. Ich wollte damals Punktmelder bauen, die eine exakte Positionserkennung der Züge erlauben. Durch die schwankenden Latenzen hat es dann doch schon Unterschiede in der Position ergeben, die (in H0) ca. 5-10cm ausgemacht haben. Das war mir Zuviel. Kennt ihr das Problem (und konntet ihr das lösen), oder stört das Euch nicht. Wenn man einen Taster drückt, macht's nichts aus, auch wenn man nur eine Belegtmeldung will, finde ich ist's ok. Aber wenn man punktgenau halten will (was ich wollte), war's per WLAN halt nicht geeignet.

Einschub dazu:
Deshalb habe ich das Projekt anders weiterentwickelt, dadurch geht natürlich der Komfort der Web-Frontend zuzugreifen verloren und man braucht ein Gateway. Über das Gateway sind die Konfigurationseinstellungen trotzdem möglich am PC. Dann halt über die serielle Schnittstelle. Ich hatte vor einiger Zeit mal eine Anleitung zum Nachbau verfasst, die ich Euch gerne zur Verfügung stellen möchte. (Leider musste ich die Datei stark verkleinern, damit ich sie hier hochladen konnte . Ich hatte die Melder auch schon verkleinert, so dass sie in den Schienenkörper von H0 integrierbar sind. Die Erfassung erfolgt derzeit per IR-Reflexlichtschranke. Dadurch kann das ganze Rollmaterial ohne Veränderungen erfasst werden. Das Detektionsprinzip ist identisch zu (viewtopic.php?f=5&t=157920). Allerdings leidet durch die Miniaturisierung der Komfort im Aufbau doch sehr... Man müsste die Platine eigentlich automatisch bestücken lassen, sonst gibt es wahrscheinlich bei 2/3 der Anwender Frust beim Aufbau. Damit sich das lohnt muss man aber mind. 100 Stück abnehmen. Ich habe daraufhin das Projekt erstmal zurückgestellt, obwohl es wirklich gut funktioniert.

Gerne würde ich mich aber auch wieder an etwas Neuem beteiligen, Schaltungsentwürfe und Platinen kann ich machen, wenn ihr das braucht.

Grüße
Matthias

Hallo Matthias,

vielen Dank für deinen Beitrag und die Verlinkung auf dein Projekt - ich finde das sehr beeindruckend! Dass du auch einzelne Achsen damit zählen kannst, finde ich ziemlich cool. Ich bin mit dem Magnet-Prinzip eigentlich sehr zufrieden, hatte aber gestern einen kleinen Rückschlag, weil sich doch unter manchen (N-)Loks nicht so recht der Platz für den Magneten finden lässt (Neodym - ich habe bisher absichtlich nicht hinunter zu den kleinsten ausgewählt, sondern die 2mm dicken genommen). Dieses Problem hast du mit IR nicht.

Zur Latenzzeit:

meine Randbedingung ist, dass im ca. 4,50 x 4,30 großen Kellerraum auch der WLAN-Router steht. In letzter Zeit mache ich ihn aus Bequemlichkeit gar nicht an, so dass der im Nachbarkeller (Kalksandsteinwand dazwischen) stehende Router herhalten muss (der Baustein verbindet sich mit bis zu drei verschiedenen WLANs). Ich habe keine Probleme feststellen können, habe aber auch noch keinen Regelbetrieb.

Als ich noch auf XpressNet-Basis probierte, lieferte der Baustein via WLAN Daten an ein Gateway (Arduino Mega) und von dort an das XpressNet. Das Gateway machte die Auswertung und steuerte die Versuchszüge. Dabei habe ich an jedem verlegten Punktmelderpaar gleiche Geschwindigkeiten gemessen, das fand ich schon erstaunlich, weil ich hier auch mit etwas ungleichmäßigem Signallauf gerechnet hatte.
In meinem jetzigen Versuchsaufbau funkt der Baustein direkt an die Z21 ("direkt" ist nicht korrekt - immer noch über den Router, aber ohne Gateway dazwischen). Die hohe Messgenauigkeit kommt hier zusätzlich dadurch, dass ich direkt im Baustein die Meldungen auswerte (meine Lösung ist jetzt sehr dezentral) und berechne, im vorherigen Versuchsaufbau war das im Gateway.

Bezüglich der allgemeinen Nachnutzbarkeit hatte ich ganz oben ja schon einige Einschränkungen geschrieben, sollte sich Bedarf entwickeln trotz der Spezialität des Ansatzes, kann man ja über das Lösen der Einschränkungen nachdenken. Danke jedenfalls für deine Bereitschaft zur Mithilfe!

[gelöscht, war doppelt gepostet]

Hallo,

heute will ich kurz die Möglichkeit der Loksteuerung über den Baustein zeigen.

Der Grund ist folgender: an meiner An-der-Wand-Anlage längs wird natürlich rangiert. Es ist immer die gleiche Rangierlok, also die gleiche Adresse. Wenn ich einfache Endlosregler fest einbaue, kann ich immer schnell hingreifen und die Rangierlokgeschwindigkeit regeln, brauche keinen Handregler "dabei" haben. Betroffen sind vier Segmente, ich würde also 4 Endlosregler installieren. Konfiguriert wird dann so:

, wobei noch die D

Die Konfigurierbarkeit der Adresse fehlt noch.

Als Endlosregler wird der KY-040 dienen.

Drehen nach links würde abbremsen, drehen nach rechts beschleunigen. Drücken wäre Fahrtrichtungswechsel. Durch den Endlosregler kann ich fliegend übernehmen ohne Geschwindigkeitssprünge. Über Z21-Befehle wird dann die Lok über UDP gesteuert. Die erste Erprobung verlief erfolgreich.

Hallo,

nun geht es zur Geschwindigkeitsmessung. Hier gibt es zwei Arten (über die "+" und "-" - Schaltflächen rechts ein-/ausblendbar):



Ich beginne mit der Ad-hoc - Messung:



Gedacht ist sie dafür, immer mal spontan messen zu können, wie schnell ein vorüberfahrender Zug ist. Im Beispiel wurde eine Messstrecken aktiviert und befahren und die Geschwindigkeit angezeigt.

Bisher erfolgt die Anzeige ebenso spontan (ad hoc), d.h. erst, wenn man sich über die Weboberfläche aufschaltet. Wenn ich meine Steuerung zentralisiere, werde ich über das Weitermelden nachdenken, so dass alle Messstellen der Anlage zentral angezeigt werden können (bei Bedarf). Zwar könnte die Steuerung, die die Meldedaten empfängt, das auch selbst ausrechnen, aber das lokale Ausrechnen vor dem Weitermelden hat den Vorteil, genauer zu sein, da keine Netzwerklatenzen beeinflussen können. Im Sinne von Wiederholungen ("fährt die Lok auch im zweiten, dritten, ... Versuch noch genauso schnell?") wäre das günstiger.

Hallo,

klappen wir nun die Ad hoc - Messung zu und die Messreihe auf:



Es läuft gerade eine Messserie mit der Lok mit Adresse 52. Oben stelle ich ein, wie die Lok in Bezug auf die Melder A und B steht, damit nach Drücken des Buttons automatisch die Serie mit den Fahrstufen 120,100,80,60,40 und 20 durchgeführt wird. Das Bildchen neben dem Button wird während der Messung aktualisiert - gerade hat die Lok den Melder A (Adresse 1) passiert, mit Passieren von Melder B wird dann die neue Geschwindigkeit (die 35km/h stammen noch von der Rückwärtsfahrt in Fahrstufe 40) angezeigt.

Gerade läuft die 6. Messung mit Fahrstufe 20 vorwärts. Ins Diagramm wird die aktuelle Kurve für Vorwärts- und Rückwärtsfahrt eingetragen. Man sieht, dass die Lok sehr schön linear fährt. Genau so möchte ich alle Loks haben, weil die Steuerung dann sehr einfach die Geschwindigkeit zu einer Fahrstufe ausrechnen kann.

Ich denke, hier sieht man ganz gut, dass FrankyFunky smart ist, neben den banalen Rückmeldungen auch solche Funktionen anzubieten - d.h. z.B., ich kann an jeder beliebigen Anlagenposition, wo Rückmeldebausteine sind, solche Messungen machen.

Soweit ein Zwischenfazit: der Baustein kann (banalerweise) rückmelden oder Taster/Schalter einlesen, mit ortsfesten Drehreglern Loks steuern, ad hoc Geschwindigkeiten zwischen Meldern errechnen und die Fahrstufe-zu-Geschwindigkeitskurve messen und visualieren.

Wozu das ganzei Bohei? 1) Weils Spaß macht und 2) um die finale Funktion vorzubereiten: dezentrales Signalbremsen. Wenn ich sicherstellen kann, dass eine Lok (nach Einstellung der entspr. CVs) linear fährt, wird der Baustein eine Reihe von Signalbremsabschnitten überwachen können. Vorschau auf die in Arbeit befindliche Seite:



Aktiviert ist der erste Signalbremsabschnitt. Mit Passieren von Melder @2 und @7 wird die Geschwindigkeit ausgerechnet. Nun kann mit Annahme einer linearen Kennlinie (siehe oben) ermittelt werden, wie die Lok so zum Halten gebracht werden kann, dass sie den festen, angegebenen Bremsweg einhält. Vorher wird der Signalzustand abgefragt, ob überhaupt gebremst werden muss.

Dazu ist noch etwas Arbeit erforderlich: welche Lok ist es denn? Hier werde ich um einen zentralen Mechanismus, der Lokadressen weitermeldet (wie eine ZN-Anlage) nicht herumkommen. Daher wird dieser Teil noch etwas Arbeit und Zeit kosten und melde mich vorerst - außer bei Fragen - nicht mehr.

Noch der Hinweis auf die allerletzte Funktion: OTA-Update (over the air). Hier kann ich bequem jedem FrankyFunky neue Software aufspielen und muss dazu nicht unter die Anlage kriechen - sehr bequem bei den 4 vorhandenen und weiteren geplanten Bausteinen.

Danke für diesen spannenden Thread. Habe gerade die neueste DiMo gelesen und habe mich ebenfalls inspirieren lassen.
Ich hast bis vor 5 Jahren eine Modellbahn mit C-Gleis, S88N Rückmeldern, einer CS1-reloaded als Booster und iTrain auf einem Mac als automatische Modellbahn Steuerung. Nach dem Umzug bin ich auf Teppichbahn reduziert. Der Drahtverhau mit den Rückmeldern ist ein no-go. Wireless ist angesagt.

Ich habe recht viel Erfahrung mit dem Programmieren der ESP8266 Chips. Die Grundidee ist im Moment, dass die Sensoren den Event frei-besetzt und besetzt->frei melden, und zwar via das MQTT Protokoll an einen MQTT Broker auf einem RaspberryPi. Dort konvertiert eine Software auf ein Protokoll, das meine MoBa Steuerung iTrain versteht und via Ethernet empfängt. Xander von iTrain empfahl mir, das Protokoll des LoDi-S88-Commander zu verwenden, oder dasjenige des µCon-S88-Master.
Idealerweise passt der Sensor unter das C-Gleis, wie im DiMo Artikel.

Hallo Urs,

Zitat

---

Danke für diesen spannenden Thread. Habe gerade die neueste DiMo gelesen und habe mich ebenfalls inspirieren lassen.

Nach dem Umzug bin ich auf Teppichbahn reduziert. Der Drahtverhau mit den Rückmeldern ist ein no-go. Wireless ist angesagt.

Ich habe recht viel Erfahrung mit dem Programmieren der ESP8266 Chips. Die Grundidee ist im Moment, dass die Sensoren den Event frei-besetzt und besetzt->frei melden, und zwar via das MQTT Protokoll an einen MQTT Broker auf einem RaspberryPi.

---

Ich bin gespannt. Hast Du auch Erfahrung mit dem ESP32?

Zitat

---

Idealerweise passt der Sensor unter das C-Gleis, wie im DiMo Artikel.

Kommentare, Tipps und Gedanken dazu generell sind willkommen.

---

Ideal für Modellbahner wäre ein generisches offenes modulares Konzept, bei dem auf dem Raspberry ein beliebiges Protokoll zu der vom Modellbahner bereits bisher genutzten Zentrale "eingehängt" werden könnten...

MfG

vik