hey joachim,
vielen dank. ok, was die grosse ewige liebe betrifft, hatte schon vor jahren meine frau gewarnt, sie habe ernsthafte konkurrenz... das eisenbahnhobby . und die modelleisenbahn und deren steuerung ist nun auch eine schon fast 20 jahre alte side-chick beziehung...

habe mir das CTC projekt angeschaut. zusammenfassend kann ich sagen: sie benutzen die selbe technologie, verfolgen aber andere ziele. bei ihnen die integrale modelleisenbahnsteuerung, bei mir eher das feeling tonnenschwere züge vom führerstand aus zu bewegen.

zum "schlechten" ADC: was ich meinte, ist das der ADC beim ESP32 generell von schlechter qualität ist. das signal hat viel rauschen und einen starken offset (also nahe bei 0 volt sättigt er, und somit muss man das signal künstlich per widerstandsschaltung etwas erhöhen, um diesen bereich zu vermeiden). solche probleme hatte ich mit anderen mikrokontroller vorher nie.

habe anfangs 2023 an einem zugleitsystem weiter gearbeitet. es ist noch etwas kompliziert zu bedienen. das ziel ist es, fahrstrassen, streckenblock, führerstandsignalisierung einzuführen, züge vollautomatisch fahren zu lassen, wobei ein zug vom führerstand aus während der fahrt "gepickt" werden kann, um ihn manuell zu bedienen, und ihn auch wieder abzugeben, so dass er wieder automatisch gesteuert wird. wobei die sicherheit immer respektiert werden soll. eine vorschau im video hier:

Hallo oli4,

Das sieht wirklich schön modelliert aus, wo Du modelliert hast! Der Tunnel ist tatsächlich gemauert, oder 😁😎

Rauschen im ADC ist natürlich sehr, sehr kritisch. Eigentlich ein NoGo. Du hast das gut gelöst, mit den Offsets im Messkreis.
Ich habe Deinen Regelkreis-Istwert noch nicht verstanden. Du schaltest die H-Brücke ab, verlierst also eigentlich den Bezugspunkt für die Messungen, oder habe ich einen Mittelpunkt übersehen?
Was ich verstanden habe ist, dass Du die H-Brücke alle paar 10 Millisekunden für 2 Millisekunden hochohmig schaltest, dann mehrere Messungen durchführst, mittelst und die Differenz der 2 Messpunkte nutzt. Die hat dann ein Vorzeichen, so dass Du theoretisch 4-Quadranten-Regelungen machen kannst. Den Strom - nehme ich an, misst Du über einen Shunt (habe ich glaube ich gesehen)..

Das Video zeigt etliche Steuerschaltungen, ich nehme an, dass das Besetztmelder, Aktoren-Schaltungen sind, für Weichen, Signale, Kehrschleifen.

CTC legt seinen Gleisplan in Fragmenten, Clustern in den Weichen-Steuermodulen ab. Die zentrale App liest alle Teilpläne ein und fügt sie zusammen. Also eine dezentrale Logik ("Stellwerk"-artig)
Jeder Cluster entscheidet, sagt der Lok, was sie tun soll. CTC nutzt Infrarot-Balisen, oder RFID-Balisen.
Bei Dir ist das eher zentral, oder?

Ich wünsche Dir mal wieder einen Motivationsschub!

Vielen Dank für Deine Erläuterungen!
Das Video werde ich sicher ein paarmal anschauen, bis ich das Steuerungskonzept besser verstanden habe 😎

Viele Grüße,
Joachim

Hallo Oli4,

vielleicht kann ich dich mit dieser kleinen Geschichte motivieren.
Als ich vor einiger Zeit mich erstmalig mit digitaler Modellbahn beschäftigte, kam mein Sohn (ü30 / Informatiker) zu Besuch und ich zeigte ihm stolz meine Selbstbau Zentrale und andere Selbstbaukomponenten (klick) an meinem kleinen Testkreis. Er meinte: "Interessant, aber leider keine Zeit neben Job und Doktorarbeit mich auch noch intensiv damit zu beschäftigen. Was ich aber spontan nicht verstehe - wieso hat noch keiner eine Funksteuerung über WLAN gebaut, statt Befehle über Gleise und Kabel zu senden?"
Du siehst, die Welt wartet auf dein Projekt, selbst jemand ohne Moba sieht sofort dieses Manko.

Gruß Knacki

Hallo,

Zitat von Eifel-Knacki im Beitrag #128

---

Was ich aber spontan nicht verstehe - wieso hat noch keiner eine Funksteuerung über WLAN gebaut, statt Befehle über Gleise und Kabel zu senden?

---

Hallo Vik, Knacki, Oli4,

Grundsatzdiskussionen bringen einen nicht weiter, bzw. Limitierungen zu behaupten, auch nicht.
Funktechnik ist im fraglichen Frequenzbereich einfach gar kein Problem. Punkt.
Interessant ist, dass sowohl Oli4 wie CTC mit dem Durchgriff auf die Loks zwar beide die alten unidirektionalen (!) Gleisprotokolle überwinden können, aber zunächst die übergeordnete Steuerung entweder auf einen Lok-Fahrstand abbilden, oder die Eingangsprotokolle der z21 nutzen, um fertige Steuerungssysteme einzubinden.
Oli4 hat den Rückkanal genutzt, CTC auch, aber übergeordnete Systeme steuern noch immer nur unidirektional und nutzen die Möglichkeiten nicht, die es gäbe.
Insofern verstehe ich die Suche nach Steuersystemen mit Mehrwert. Oli4 hat ihn gefunden, CTC für sich ebenfalls. Beides ist aber noch lange nicht ausgereift.
Bidirektionaler Austausch zur und von der Lok bietet aber prinzipiell großartige neue Möglichkeiten.

Ich persönlich finde, dass Weichensteuerungen per DCC zwar meist ausreichen, aber Rückmeldungen der Position noch besser wären.
Alle Lokalisierungstechniken (wie Railcom) sind unvollkommen.
Die große Bahn hat sie, wenn auch u.a. per Funk.

Viele Grüße,
Joachim

Zitat von vikr im Beitrag #129

---

z21-Lan-Spezifikation

---

hallo zäme,
hier ein paar antworten:

@joachim:
der tunnel ist "gegibst" und geritzt...

der bezugspunkt der h-brücke kann zwar innerhalb der speisespannung wandern, ausserhalb aber nicht, dank den dioden in den FETs. da ich die differenzspannung evaluiere, spielt dies keine rolle. noch was: den genauen "null"-punkt wird per software kalibriert, wenn der motor länger still steht.

wenn ich mich richtig erinnere, benutze ich die strommessung (shunt-spannungsabfall) gar nicht, da zu ungenau. die motorlast wird mittels reglerausgang im vergleich zu einer kalibrierungstabelle (LUT), welche den reglerausgang im unbelasteten zustand bei allen geschwindigkeiten aufgezeichnet habe, vergleicht. diese messung wird für die geschwindigkeitsregelung gar nicht gebraucht, aber hingegen beim speziellen "reibungskompensations"-mode, welcher bei mehrfachtraktionen ins spiel kommt.

zum zugleitsystem: momentan habe ich nur gleisbesetztmeldungen und weichensteuerung. das zugleitsystem ist vollständig auf gleisbesetztmeldungen aufgebaut. die steuerung läuft auch bei mir dezentral. jeder bahnhof und jede strecke hat ein raspberry-pi, welcher seine züge steuert, und diese weiterreicht, wenn diese ihren bereich verlassen. das ganze ist in einem MQTT-system vernetzt. es gibt dann doch ein paar zentrale komponenten, wie den zugserver, welcher die eventuellen doppeltraktionen abstrahieren, der tachygraph fürs aufzeichnen aller fahrten, oder der routing-server, welcher globale automatische szenarien dirigiert, wie zum beispiel pendelfahrten...

@knacki: danke für deine motivation! aus diesem "gebastel" ein produkt zu machen wird wahrscheinlich ein lebenswerk...

@vik und joachim: auch ich denke das potential der bidirektionalen kommunikation ist riesig. man denke an genauere positionierung durch reelle geschwindigkeits- oder distanzerfassung, last-abhängige fahrsimulation (z.B. mehr power um bergauf zu kommen, mehr beschleunigung bergab, also mehr bremsen, von alleine wegrollen falls in der steigung ungebremst...). habe mit diesen ideen schon ein wenig herumgespielt, ist aber nicht ganz einfach, diese robust genug zu implementieren. manchmal fängt mein zug an, in der ebene wegzurollen... darum gilt: im stillstand zugbremse immer aktivieren

gruss
oli4

Hallo Oli4,

ich verfolge Dein Projekt ebenfalls mit grossem Interesse und kann die eine oder andere Motivationsdelle nachvollziehen. Mit Lebenswerken habe ich auch so meine Erfahrung.

Ich bin voll dabei wenn es um bidirektionale Kommunikation mit den Loks geht. Allerdings hatte ich mich damals entschieden DCC/Railcom "aufzubohren". Es ist ein anderer Ansatz und ich will keine Grundsatzdiskussion. Es geht mir um das Bi-Direktionale (Hin-/Rueckkanal). Meine Loks mit meinen Decodern (alle Spur-N) senden u.a. Motorstrom, Gleisspannung, reale Geschwindigkeit, Streckenintegral und b.B. auch X/Y/Z (Nick, Roll, Yaw) mittels inertial Sensoren. Das ganze Zeugs wird dann auf dem PC in Echtzeit verarbeitet. Damit das funktioniert habe ich ein eigenen schnellen Layout-Bus entworfen (ich nenne diesen RTB = Real-time Bus). Bei Dir gehts drahtlos via WLAN, bei mir 'klassisch' via DCC/Railcom. Am Ende haben wir die Daten zur Verarbeitung oben auf dem PC. Das ist m.E. der Knackpunkt.

Also, hau rein ... weiter so!

@Motor langsam drehen:
Habe meinen NEM651 Decoder ein wenig hochgebogen, damit man den Anker sehen kann - https://youtu.be/xgu4DMY3AJU
Hier eine V100 mit 3-Anker Motor und ohne Schwungmasse: https://youtu.be/G0pOsj4374I

@Echtzeit Daten vom Decoder
Hier die gemessene Gleisspannung, Motorstrom und Wegstrecke in Echtzeit auf ein LCD Display gelenkt - https://www.youtube.com/watch?v=ktvZBJyPXjg

Hallo Frank,

Das sieht doch super aus, mit dem nochmal kleineren Motor! Die Motorregelung funktioniert bestens. Greifst auch Du über den Motor seine Eigeninduktion ab, während Du die H Brücke freischaltest?

Diese Rückgabeparameter finde ich super. Wertest Du auch die Bewegungssensoren aus und was schließt Du aus deren Werten?

Viele Grüße,
Joachim

Zitat von joachimkr im Beitrag #134

---

Wertest Du auch die Bewegungssensoren aus und was schließt Du aus deren Werten?

---

• Yaw(blau) ... ist der Kompass 0..359 Grad
• Roll(gelb) ... entspricht dem seitlichen Kippen der Lok im Gleis (z.B. Kurven Ueberhoehung)
• Nick(orange) ... entsprint der Steigung der Lok bzw. des Gleises

• zuerst faehrt die Lok in eine 180 Kurve (Yaw: 359 -> 180)
• dann kommt die Gegengerade (Yaw bleibt bei ca. 180 Grad)
• dann kommt die zweite Kurve zum Vollkreis (Yaw: 180 -> 0)
• zum Schluss die Zielgerade

Hallo Frank,

Die Orientierung mittels 'Kompass' ist interessant. Die Ermittlung von Steigungen und Neigungen sind wohl für Sound verwertbar. Meine Frage war, was machst Du aus diesen Messwerten?
Wertest Du sie in der Steuerung aus?
Ich wollte ja gern wissen, welche Parameter Du zur Motorsteuerung nutzt, ob sie auch vom Motor aus freigeschalteter Brücke stammen?

Dass diese Menge an Parametern in der Austastlücke übertragen werden kann, ist erstaunlich. Wie gehst Du mit Anwesenheit mehrerer Loks in größerem Layout um?

Viele Grüße,
Joachim

Oh, dann hatte ich deine Frage missverstanden.

- Die Motorsteuerung wertet nur die Gegen EMK für die Drehzahlregelung aus.

- Der Motorstrom dient dem Decoder zur Kurzschluss/Überlast Erkennung.

- Die Decoder Temperatur wird zur Notabschaltung herangezogen.

- Die EMK wird zusätzlich noch integriert und in eine Wegstrecke umrechnet. Diese ist ziemlich genau … wenige mm pro gefahrenen Meter.

Das wird alles per Railcom hochgemeldet. Mehrere Decoder sind kein Problem,

ca. 50 Decoder wenn maximal 10 gleichzeitig fahren
ca. 70 Decoder wenn maximal 5 gleichzeitig fahren

(fahren bedeutet Geschwindigkeit > 0)

Mein DCC Generator arbeitet auch auf dem PC. Der Algorithmus ist daher vermutlich besser optimierbar. Der PC ist bei mir der Master Mind.

Hallo Frank,

Das klingt besser, als die normalen Railcom Spezifikationen hergeben. Wie schaffst Du es, die Sende-Kollisionen der 10 aktiven Decoder aufzulösen?

Viele Grüße,
Joachim

Hallo Joachim,

ich denke wir kommen vom Thema in diesem Thread ab. Vorschlag: Ich mache beizeiten eine Diskussion auf. Bzgl. Kollisionen, Railcom Kanal-2 ist per Definition kollisionsfrei. Der Zentrale, wo die DCC Befehle generiert werden, kommt eine tragende Rolle zu, wenn es um die Optimierungen des Railcom Rueckkanals geht. Ich denke, da sind viele DCC Generatoren 'sub-optimiert'.