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.
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.
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]
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.
DCC
Beide Signale werden an die H-Bridge geleitet, die dann das DCC-Signal ausreichend verstärkt:
Aufbau meines Frameworks:
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)