DCC Generierug mit einem ESP8266

Fragen zu Fahrdecodern
little.yoda
Senior
Beiträge: 190
Registriert: Mo 9. Nov 2015, 21:05
Kontaktdaten:

DCC Generierug mit einem ESP8266

Beitrag von little.yoda » So 9. Jul 2017, 21:04

Hi

Es begann mit einem Beitrag von Julian Zimmerman Anfang des Jahres im Spassbahn-Forum. Er zeigte eine Lösung auf, wie man mit einem ESP8266 ein DCC-Signal so erzeugen kann, dass ein normaler DCC-Decoder gesteuert werden kann.

Die Befehlen können also z.B. per WLAN an den ESP8266 verschickt werden, dieser generiert ein DCC-Signal für eine H-Bridge und betreibt somit einen klassischen DCC-Decoder, der den Motor steuert.

Z21 App oder Wlan-Maus => WLAN => ESP8266 => H-Bridge => DCC-Signal => DCC-Decoder => Motor / Sound

Warum der Aufwand? Zwei Gründe (wovon ich aber nur den ersten wirklich teile)

1.) Nutzung von Sound
Obwohl es auch möglich wäre, Sound über den ESP8266 abzuspielen, ist die Nutzung eines klassischen DCC-Sounddecoder doch sehr viel einfacher

2.) bessere Qualität der Motoransteuerung
In den ESP8266-Decodern (auch im meiner) wird meistens nur ein einfaches lastunabhängiges PWM-Signal generiert. Hier sind die DCC-Decoder deutlich weiter.

Mein erster Prototyp
Da Julian zur Zeit ausgelastet ist und mich das Technische interessierte, habe ich um die Sourcen gebeten, damit ich es in mein Framework integrieren kann. Nach einigen frustrierenden Abenden habe ich vor ein paar Tagen endlich einen Prototypen zum laufen gebracht und der Motorblock reagierte endlich auf die generierten DCC-Befehle.

Bild


Schaltplan


Die letzten Tage habe ich genutzt, um den Sourcecode aufzuräumen und die Schaltung aufzumalen.
Die aktuelle Schaltung besteht aus einem NodeMCU (D1 oder ähnliches würde natürlich auch gehen), einer L298N Motor Platine, einem NPN-Transitor (2N2222A), zwei 1k Ohm Widerstände und einem Akku-Pack.

Bild

Natürlich können auch andere H-Bridge genutzt werden. Hier muss ggf. noch eine unabhängig 5V Versorgung hinzugefügt werden.


Ansteuerung des ESP8266

Die Lösung kann über 2 Wege gesteuert werden:
  • Der Decoder kann sich über WLAN mit einer Z21 verbinden und von dort die Befehle erhalten
  • Der Decoder kann eine Z21 Simulieren und ein WLAN-Netz aufspannen.
    Dann kann man den Decoder direkt und ohne die notwendiger einer Z21, über die Z21-App oder über die WLAN-Maus steuern.
  • [Steuerung über einen Browser fehlt im Moment noch]
  • [Natürlich konnte man noch ein paar Bauteile hinzufügen und dann den DCC-Decoder nutzen, um die DCC-Befehle am Gleis zu dekodieren. Aber das macht dann wirklich keinen Sinn mehr]
Technischer Hintergrund
Das Signal wird im ESP8266 über den SPI-Ausgang erzeugt. Dieser Ausgang hat einen Hardware-Buffer, so dass sichergestellt ist, dass das DCC-Timing eingehalten werden. Es wird also immer ein DCC-Paket erzeugt, in das notwendige SPI-Format gewandelt und anschließend in den Hardware-Buffer geschrieben. Bei den ersten Tests stellt sich heraus, dass die SPI-Library beim Senden so lange blockiert, bis das Paket komplett verschickt wurde. Desweiteren blockierte die Library direkt drei GPIO für MISO, MOSI, SCK. Also habe ich die SPI-Library genommen und sie auf das nötigste reduziert. Jetzt wird nur noch ein Pin (13 bzw. D7) genutzt. Dieser Pin ist fest, da er der einzige nutzbare Port mit Hardware-mäßiger SPI Unterstützung ist.

"Halbes" DCC
An D7 liegt aber nur eine Art "positive Halbwelle" des DCC-Signales an. (siehe das erste Signal in der folgenden Grafik).
Da das DCC-Signal aber eine Wechselspannung ist, benötigt man aber auch noch die "negative Halbwelle". Aus diesem Grund wird das Signal von D7 einmal über einen Transistor invertiert (siehe zweites Signal).
An DCC-Paketen wird einmal ein Paket für die Geschwindigkeit und Richtung erzeugt und danach die ganzen Pakete für den Zustand von F0 bis F28.

Bild

DCC

Beide Signale werden an die H-Bridge geleitet, die dann das DCC-Signal ausreichend verstärkt:

Bild


Aufbau meines Frameworks:
Bild

Weitere Schritte
  • Ich überlege, ob ich eine Platine für den DRV8870 fertigen lasse, die auf diesen Anwendungsfall ausgelegt ist.
  • Im Spassbahn-Forum gab es die Diskussion, ob die H-Bridge überhaupt so stark sein muss oder ob es nicht ausreichen würde, den Decoder über den PowerPack-Eingang zu versorgen und eine "schwache" H-Bridge zu nutzen. (Diesen Test überlasse ich gerne anderen Personen)
Sollten ihr noch Fragen haben, her damit ;-)
Zuletzt geändert von little.yoda am Sa 14. Okt 2017, 18:32, insgesamt 2-mal geändert.
bin jetzt mehr hier zu finden.

Benutzeravatar
OldNat
Senior
Beiträge: 103
Registriert: Do 28. Nov 2013, 09:46
Wohnort: Wien

Re: DCC Generierug mit einem ESP8266

Beitrag von OldNat » Mi 2. Aug 2017, 09:43

Hallo Kollegen!

Natürlich hatte ich einen Haufen Fragen, aber die waren vorerst zu barbiemäßig, um sie hier einzustellen, daher habe ich Sven direkt damit genervt.
Er hat dann auch (sehr geduldig, muss ich sagen) immer geantwortet, bis ich soweit war, dass ich anfangen konnte.

Meine ersten Erfahrungen habe ich zuerst auf Sven's erster Bitte in dem Thread "drüben" zusammengefasst:

http://gartenbahntechnik.de/forum/viewt ... 2555#p2555

aber da es eher hierhin passt, haben wir uns eas doch anders überlegt, daher hole ich es doch hierher und mache hier weiter, siehe gleich unten:.

LG Zoltan
Zuletzt geändert von OldNat am Mo 7. Aug 2017, 10:53, insgesamt 3-mal geändert.

Benutzeravatar
OldNat
Senior
Beiträge: 103
Registriert: Do 28. Nov 2013, 09:46
Wohnort: Wien

Re: DCC Generierug mit einem ESP8266

Beitrag von OldNat » Mo 7. Aug 2017, 10:43

Hallo Kollegen!

Hier also mein Bericht vom 2. August, hierhin transferiert von dem Thread über "Weichensteuerung per WLAN und Z21", da es eher hier hineinpasst.

Ich habe es zuerst dort drüben platziert, weil Sven mich gebeten hat, es dort zu tun, aber dann haben wir überlegt, dass es doch lieber hier sein soll. Also sorry für den Umweg.

Ich fasse also meine Erfahrungen mit dem DCC-Generator für die Loksteuerung doch in diesem Thread zusammen.

Ich hole ein wenig weiter aus, damit man die Randbedingungen sieht, aber in vornherein muss ich sagen: Das kann die Zukunft sein. Ich zitiere von Sven's Wiki:

"Hierbei wird ein DCC-Signal generiert; der ESP8266 verwandelt sich somit in eine kleine Art Minizentrale, die komplett in einem Zug eingebaut werden kann. Mit der Kombination Akku, ESP8266, H-Bridge und DCC-Decoder kann man einen autonomen Zug bauen, der weiterhin alle Vorzüge eines DCC-Decoders (z.B. Soundausgabe) bietet."

Ich bin auf dem ESP gestoßen, als ich eine billige und einfache RC-Lösung für meine Echtdampflokomotiven suchte. Basierend auf dem RoboRemo Projekt habe ich in LUA ein kleines Programm geschrieben, mit dem ich per PWM 3 Servos für Dampfregler, Umsteuerung und Pfeife einfach übers Handy per IP/Wifi steuern konnte.

Später wollte ich, von Julian und Sven inspiriert, auch für die "elektrischen" etwas haben, und mit dem L298N und PWM habe ich auch das mit LUA gelöst, per RoboRemo mit geregelter Geschwindigkeit vorwärts und rückwärts fahren zu können. Ich habe das uA. hier beschrieben:

http://gartenbahn-45-mm.phpbb8.de/allge ... t8433.html

Aber ich wollte mehr: Licht, Sound, alles... Zwar hat die Trainline WLAN Lösung über Susi ziemlich gute Ergebnisse geliefert gehabt (in 2013 habe ich statt DCC damit meine "Digitalisierung" angefangen, weil ich schienenstromunabhängig bleiben wollte), aber erstens war das teuer, zweitens nicht wirklich klein, drittens in der Entwicklung dann irgendwo mittendrin stehen geblieben - ich fahre immer noch die V1.1, weil das immerwährende Einschicken nach Deutschland zum Upgrades Patchen kein gangbarer Weg für mich ist und mit der Remote Flash Möglichkeit ist Karl immer noch "schuldig". Ich will nichts schlechtes darüber sagen, das Ding funktioniert tadellos, aber hat DCC und Umgebung doch noch nicht "eingeholt" - die Entwicklung der Technik war scheinbar schneller als die Entwicklung dieser Lösung. Eigentlich schade, es war ein interessanter Ansatz, auch wenn es mit der Raspberry ein wenig auf "Kanone auf Spatz" erinnerte.

Zurück zum ESP - Julian und Sven (und wohl auch viele andere) haben inzwischen weitergearbeitet. Ich war mit beiden genannten Kollegen in Kontakt und habe sie so lange genervt, weiterzumachen (als ob sie es alleine nicht vorantgetrieben hätten), bis es endlich soweit war, dass ich vom GitHub Projektlink von Sven das Programm herunterladen konnte.

Jetzt kommt es endlich zum eigentlichen Bericht und entschuldigt bitte die obige weite Einführung.

Ich ging also auf Sven's GitHub Seite:

https://github.com/littleyoda/littleyoda-DCC-Decoder

Eigentlich steht dort alles, und dieser Beitrag ist fast überflüssig, aber ich wollte mal zeigen, wie es bei einem halbwegs Laien funktioniert. Ich gehe die Schritte nur deshalb noch einmal barbiemäßig durch, damit man sieht, wie einfach für den Anwender eigentlich das ganze gemacht worden ist; bzw. um die direkte Links zu posten. (Und auch um zu zeigen, dass die ganze Arbeit nicht umsonst ist: Man baut es nach! Man soll es auch! Und man kann!)

Ich habe also dort das Wiki aufgemacht. Unter "Erste Schritte"
https://github.com/littleyoda/littleyod ... e-Schritte
ist alles beschrieben, was man zum Anfangen braucht.

Als Flasher benutze ich den gleichen, mit dem ich auch die LUA Firmwares geflashed habe:

Bild

(Ich stelle hier keine Screenshots ein vom Flashen, denn die hat Sven schon ins Wiki integriert.)

Zum Debuggen habe ich den LuaLoader benutzt, womit ich die anderen Projekte "bestritten" habe. Nach Erfolg sieht die Ausgabe etwa so aus:

Bild

Die erste Kontaktaufnahme habe ich gleich mit dem Handy Browser gemacht.
Die Website erschien und funktionierte wie im Wiki beschrieben.
Die beiden .css Dateien habe ich zuvor schon aufs Handy gespielt, also konnten sie wie beschrieben "geladen" werden:

Bild

Da ich die Variante "Lok simuliert eingebaute Z21-Zentrale" haben wollte, habe ich die entsprechende Config-File von
https://github.com/littleyoda/littleyod ... onfig.json
ebenfalls aufs Handy kopiert, die Parameter "ssid" und "pwd" entsprenchend meiner Wünsche editiert und dann über die WebOberfläche wie oben beschrieben, "aufgeladen". Danach habe ich die NodeMCU powercycled, und sie spannte danach statt dem bisherigen "HELLO WORLD" meine "eigene" WLAN auf, und ich konnte mich mit dem Handy wie beschrieben auf http://192.168.0.111
verbinden. Die debug Ausgabe am PC in LuaLoader sah dann so aus:

Bild

Bild

Also konnte ich mich mit der Z21 App vom Handy auf den ESP verbinden. Die ESP wurde als Z21 Zentrale erkannt:

Bild

Ich zog dann das USB-Kabel ab, und die Handy-Oberfläche meldete das sofort mit Rotwerden des WLAN-Symbols rechts oben:

Bild

Nach Einstecken des Kabels und etwa 30 Sekunden war meine WLAN wieder da, und ich konnte mich verbinden:

Bild

und alles war wieder in Ordnung, das WLAN Symbol der App änderte sich wieder auf grün:

Bild

Die Beschreibung im Wiki für Firmware Updates
https://github.com/littleyoda/littleyod ... re-Updates
funktioniert auch entsprechend, nach Ausführen kann man auf der Seite
http://192.168.0.111/log
sehen, dass es erfolgreich war.

Nun folgt das praktische (aber erst später).

Ich muss die komplette Schaltung wie hier beschrieben:
http://gartenbahntechnik.de/forum/viewt ... 2554#p2525
aufbauen, und das ganze auch in der Praxis testen.

Hierzu werde ich vorerst das ganze auf einem Breadboard zusammenstecken, und eine ESU LokSound 4 XL auf dem Prüfstand anschliessen, und probieren, mit wie vielen 18650 Akkus das ganze stabil läuft. Ich hoffe auf 3, womit meine "poor man's Feldbahn RC" läuft, bin aber eher skeptisch; Sven hat 4 benutzt, das müsste eigentlich reichen (ich will ja nicht rasen, und Spannung braucht man ja eigentlich nur für die Motorgeschwindigkeit...). Für den PikoSmartBox im Geisterwagen lasse ich übrigens 5 mitfahren. Es muss ja später alles im Bauch des Harzkamels (mein Versuchskaninchen für den am Anfang beschriebenen "autonomen Zug") unterkommen, zuzüglich Lautsprecher und Rauchgenerator... das wird dann "der dritte Streich".

Ich werde weiter berichten, wenn ich dazukomme - zZ. gibt es auch sehr viel anderes zu tun.

LG Zoltan

PS an einer Lötanleitung bzw. Platine wäre ich auch evtl interessiert...

Benutzeravatar
ateshci
Senior
Beiträge: 193
Registriert: Mi 16. Jan 2013, 15:12
Wohnort: Friedberg(Hessen)

Re: DCC Generierug mit einem ESP8266

Beitrag von ateshci » Sa 12. Aug 2017, 14:22

@oldNat
Der Decoder alleine muss schon laut DCC-Norm mit einem 2S-LiPo ( 7,4V >7V lt. Spec. ) funktionieren - aber 3S ist immer im grünen Bereich.
Für meine Gartenbahnist das alles allerdings Schnee von gestern - ich fahre wieder analog! Zugegeben mit Batterie von 48V und Lokführer in der Lok auf 240mm Spurweite.
Gruß vom Heizer

Benutzeravatar
OldNat
Senior
Beiträge: 103
Registriert: Do 28. Nov 2013, 09:46
Wohnort: Wien

Re: DCC Generierug mit einem ESP8266

Beitrag von OldNat » Sa 12. Aug 2017, 21:31

Danke für die Info!

Aber du fährst nicht analog, du fährst "organisch" :D

LG Zoltan

Benutzeravatar
OldNat
Senior
Beiträge: 103
Registriert: Do 28. Nov 2013, 09:46
Wohnort: Wien

Re: DCC Generierug mit einem ESP8266

Beitrag von OldNat » Fr 6. Okt 2017, 08:53

Hallo,

wie erwähnt, gestern habe ich den ersten Versuch gewagt und es hat nicht funktioniert.

Voraus:
Wie ebenfalls schon erwähnt, die Lok ist mit dem ESU LokSound 4 XL erfolgreich digitalisiert und fährt mit einer "echten" Zentrale tadellos.
Und, wie ebenfalls schon erwähnt, funktioniert die ESP soweit gut, dass die ESP für die Z21- Handy-App erfolgreich eine Z21 Zentrale "simuliert" und ich mich dazu verbinden kann.
Ich habe die Schaltung von Sven mit der L298N und dem Transistor mitsamt 2 Widerstände, fertig gelötet und auch in die Lok eingebaut.
Als Energiequelle sind 4 18650-s eingebaut, mit einer Nominalspannung von 14,8 V (Leerlafspannung etwa 16,8 V).

Nun habe ich den Eingang (TR) des Decoders mit dem Motorenausgang der Bridge verbunden.
An der Bridge (Input Voltage) liegen die 16,8 V an.
An der 5-V-Klemme ist die 5 V da.
ESP bootet und spannt das WLAN auf.
Z21 App kann connecten.
Erkennt die "Zentrale":
Bild

Ich wähle die Lok mit der Adresse 3 aus (das war voraussetzung):
Bild

Bild

Ich kann das Interface dann auf "Go" schalten:
Bild

Interface reagiert, zB. beim Antippen von F0 "leuchtet" das Icon - aber die Lok nicht.
Die Lok reagiert auf nichts, kein Sound einschaltbar, keine Lichter, nichts.
Beim "Hochschieben" des Fahrreglers gehen die grüne Stricherl aufwärts, aber dann geht das Interface auf Stop - und ab dann kann man es auch nicht wieder auf Go schalten:
Bild

Nur nach einem Neustart kann ich es wieder auf Go schalten (und Tasten drücken, ohne dass es Stop geht), bist auf die Fahrstufen: dann springt es wieder auf "Stop" und siehe vorher.

Am Decoder wird nichts heiß, auch Akkus nicht, der Kühlkörper der Bridge wird ganz leicht lauwarm, also sie scheint etwas zu tun.

Die Spannung glaube ich ist nicht zu klein, denn die Bridge geht mit 3 Akkus schon (mit der selben Bridge, ESP und RoboRemo PWM) und steuert die Lok (siehe Youtube-Film):
https://www.youtube.com/watch?v=SCceQ6VcFWE
(EmbedLink scheint nicht zu funktionieren)

Meine Vermutung: ESP ist OK, Kommunikation ESP-Handy ist OK, aber die Kommunikation ESP-Decoder (besser gesagt ESP-Bridge, also entweder die ESP Ausgänge, die Schaltung dazwischen oder die Bridge selber, scheinen nicht das zu "wollen" was ich will. Die Verbindung von Bridge zu Decoder kann es nicht wirklich sein, das sind einfach 2 Drähte von Bridge Motor Ausgang zu Decoder TRK Aingang, da kann schwer was danebengehen - Polarität hier soll doch Wurscht sein, eine Lok kann so oder so auf die Schinene gestellt werden...

Oder sind 4 Akkus doch zu wenig? Glaube ich nicht, denn bei Sven geht alles mit 4 Akkus. Allerdings habe ich es hier mit 2 Motoren zu tun.

Ich habe aber nur ein einfaches Digital-Multimeter und weiß nicht recht, was und wo ich messen kann.
Wie kann ich nun weiterkommen, was und wo kann/soll ich checken?
Was soll an den einzelnen Pins der NodeMCU anliegen?
Was soll am Bridge Ausgang anliegen?


DLG Zoltan

IPTRAIN
Senior
Beiträge: 202
Registriert: Di 15. Jan 2013, 20:20

Re: DCC Generierug mit einem ESP8266

Beitrag von IPTRAIN » Fr 6. Okt 2017, 11:28

Hallo Zoltan,

für Signalverläufe in erster Näherung würde ich mir dieses kostengünstige Oszilloskop zulegen. Da kannst Du schon eine Menge mehr Root Cause Analysis betreiben.

https://www.banggood.com/DSO138-DIY-Dig ... mds=search

Gruesse

Koller
Neuling
Beiträge: 2
Registriert: Mi 2. Aug 2017, 11:53

Re: DCC Generierug mit einem ESP8266

Beitrag von Koller » Mi 11. Okt 2017, 14:54

Hallo Zoltan
hast Du den Fehler schon gefunden?
Wenn nicht hier meine Lösung.
Die config ist falsch, in der config ist D3 Ausgang auf dem ESP nicht wie im Plan D8.
Ausgang D3 ESP auf Eingang EN Brücke.
Zum einschalten der Brücke einen Richtungsimpuls oder Fahrbefehl geben.

Grüsse

little.yoda
Senior
Beiträge: 190
Registriert: Mo 9. Nov 2015, 21:05
Kontaktdaten:

Re: DCC Generierug mit einem ESP8266

Beitrag von little.yoda » Mi 11. Okt 2017, 18:31

Hi

ich habe schon intensive mit Zoltan direkt ausgetauscht.

Mist. Tatsächlich. Das Config-File ist falsch :-(

Danke für den Hinweis.
Ist der Fehler nur so aufgefallen oder hast du es nachgebaut?
Wurde mich über Rückmeldung freuen, wenn jemand sich mit meinen Decoder beschäftigt.

Gruß,
Sven
bin jetzt mehr hier zu finden.

Koller
Neuling
Beiträge: 2
Registriert: Mi 2. Aug 2017, 11:53

Re: DCC Generierug mit einem ESP8266

Beitrag von Koller » Mi 11. Okt 2017, 18:44

Hallo Sven

Ich habe den Decoder nachgebaut, mit einem Sniffer den Ausgang belauscht.
Dann hab ich gesucht wie ein großer. Auf dem Bild mit deinem Aufbau hab ich gesehen das EN auf plus liegt.
Umgesteckt funktionierte. Weiter suchen, config gelesen da stand "enable D3"??
Wieder umgesteckt ging.

Grüsse
Heinrich

Antworten

Zurück zu „Fahr- und Sounddecoder“