Wiener U-Bahn Stationsdisplay#

Projektbeschreibung#

Gemeinsam mit meinem Kollegen Ben entstand die Idee für das Projekt. Grob gesagt sollte es eine Anzeigetafel werden, ganz ähnlich wie man sie aus den Wiener U-Bahn-Stationen kennt. Unser Ziel war es, dass die Tafel in Funktion und Aussehen stark an die Originale erinnert, jedoch in einem wesentlich kleineren Maßstab gebaut wird. Dabei war die Aufgabenteilung von Anfang an klar: Ich übernahm den Hardwareteil, während mein Freund Ben für die Software zuständig war. Aktuell ist zwar noch nichts Konkretes geplant, sollte er jedoch – was ziemlich wahrscheinlich ist – ebenfalls einen Artikel über das Projekt aus der Softwaresicht schreiben, werde ich natürlich an dieser Stelle hier -> auf ihn verweisen.

Beispielbild Stationstafel

Abb.: Beispielfoto für eine Anzeigetafel in den Wiener U-Bahn-Stationen

Auswahl des Displays#

Zu Beginn des Projektes hatten wir die Idee, die Wiener Linien anzuschreiben, ob sie uns nicht eine originale Anzeigetafel aus der Wiener U-Bahn verkaufen würden. Natürlich dachten wir dabei an kein Gerät, das sich noch im aktiven Betrieb befindet. Unsere Hoffnung war, dass eventuell noch Bestände der Linie U2 existieren (der ehemaligen USTRAB 2er-Linie, bald U5), wo die alten Tafeln bereits durch modernere Modelle ersetzt wurden. Leider erhielten wir von den Wiener Linien – wie eigentlich auch erwartet – eine Absage.

Die zweite Idee war es, eine Dot-Matrix-Anzeige nachzubauen, die in Aussehen und Größe jenen der Wiener „Silberpfeile“ (Typ U11 und U2) für die Stationsanzeige ähnelt.

Beispielbild aus Silberpfeil

Abb.: Beispielfoto einer Anzeige in einem Silberpfeil Type U2 auf der Linie U3

Doch auch diese Idee erwies sich schlussendlich als nicht praktikabel. Ich wollte das Display in der exakt selben Größe nachbauen, doch erstens meinte Ben, dass dies viel zu groß wäre (Mimimi), und zweitens hatte ich zu diesem Zeitpunkt bereits ein anderes Projekt mit großen Displays und Segmenten am Laufen.

Glücklicherweise hatte ich vor einigen Jahren alte Kassendisplays mit VFD (Vacuum Fluorescent Display) bekommen und mir diese zu Hause auf Lager gelegt. Ich besaß noch genau zwei Stück des identischen Modells, sogar originalverpackt. Es handelt sich um 20x2 Character VFDs, die sich hervorragend für dieses Projekt eignen würden. Eines davon bekam Ben, das andere behielt ich.

Beispielbild Kassendisplay

Abb.: Foto des Kassendisplays

Als ich Ben das Foto schickte, war seine Antwort kurz und bündig: „Ich find das sieht ziemlich geil aus“, daher war die Entscheidung für das Display gefallen.

Ansteuerung des Displays herausfinden#

Im Internet war es uns schlicht unmöglich herauszufinden, wie genau das Display angesteuert werden muss. Da ich jedoch vor etwa zwei Jahren schon einmal ein Epson DM-D110 Kassendisplay angesteuert hatte (welches heute in meiner Werkstatt Temperatur, Luftfeuchtigkeit, Datum und Uhrzeit anzeigt), hatte ich einen Anhaltspunkt. Zudem lag bei einem der beiden Displays ein kurzes Heftchen bei. Diesem konnte ich eine Pinbelegung entnehmen und feststellen, dass das Display wohl über RS232 kommuniziert. Das Display verfügt über einen DB25-Female-Stecker, in dem zusätzlich eine Buchse für ein 12V-DC-Netzteil integriert ist.

Display Manual

Abb.: Ausschnitt der Pinbelegung aus dem beiliegenden Heft

Zunächst versuchten wir nach der Arbeit gemeinsam, das Display an einem ESP32 zum Laufen zu bekommen. Dazu wurde an den ESP32 ein UART-zu-RS232-Wandler angeschlossen und mit einem provisorischen Adapter vom typischen DB9-RS232-Port auf den DB25-Port des Displays adaptiert. Leider konnten wir den Fehler vor Ort nicht finden. Ich habe denselben Aufbau daher noch einmal zu Hause in Ruhe getestet. Mit dem Oszilloskop konnte ich am TX-Pin des Microcontrollers messen: Die Daten, die als Text-String gesendet wurden, waren eingangsseitig messbar, doch ausgangsseitig kam kein RS232-Signal an. Nach dem Wechsel auf einen neuen Adapter funktionierte das Display plötzlich. Ich konnte nun sowohl das UART-Signal als auch das RS232-Signal erkennen, welches am RX-Pin des Displays ankam.

Oszillogram

Abb.: Ch1: RS232-TX-Ausgang vom Wandler, Ch2: UART-Eingangssignal vom µC TX

Das Display selbst zeigte den Text korrekt an, allerdings konnte ich den Cursor noch nicht setzen. Das spielte zu diesem Zeitpunkt aber keine Rolle, da dies schlussendlich in den Aufgabenbereich von Ben fiel. Somit konnte ich mit der eigentlichen Entwicklung der Hardware beginnen.

Hardwaredesign#

Anforderungen#

Die Anforderungen an das Projekt waren schnell definiert: Der Microcontroller für die Ansteuerung soll ein ESP32 sein. Das gesamte System inklusive Display soll über ein einzelnes 12V-Netzteil versorgt werden können, weshalb die Steuerung ihre eigene 3,3V-Spannung für den ESP32 generieren muss. Die Platine soll eine DB25-Male-Buchse besitzen, an der das Display direkt angesteckt werden kann, sowie eine Möglichkeit, die Spannungsversorgung des Displays direkt dort abzugreifen. Weiters sollten zwei Taster für die spätere Menüführung vorhanden sein und ein Piezo-Summer für akustische Signale eingebaut werden. Zu guter Letzt sollte eine LED an der TX-Leitung signalisieren, wenn eine Datenübertragung stattfindet.

Entwicklung#

Für die Entwicklung nutzte ich den Altium Designer 26, da ich damit in den letzten Jahren bereits gearbeitet, das Hardwaredesign mit diesem Programm gelernt habe und es heute noch regelmäßig verwende.

Als Powerstecker auf dem Print dient eine klassische 5,5/2,1mm-Hohlbuchse. Um die Schaltung vor Verpolung zu schützen, hätte man eine einfache Diode in Flussrichtung verwenden können. Da ich jedoch im Vorfeld getestet habe, ob das Display auch mit nur 11,3V zuverlässig läuft – was ich leider nicht bestätigen konnte –, musste ich einen „anderen“ Weg wählen. Eine Siliziumdiode in Flussrichtung verursacht, abhängig vom Strom und Typ, einen Spannungsabfall von etwa 0,7V, was hier zu viel war.

Schaltplan Spannungsversorgung

Abb.: Stromlaufplan Spannungsregulierung und Verpolungsschutz

Zugegeben, das ist nicht die eleganteste Lösung: Sollte man ein Netzteil mit „Center Negative“ anstecken, entsteht ein Kurzschluss über die Diode D1. Das sorgt dafür, dass die Sicherung durchbrennt und so die restliche Schaltung schützt. In diesem Fall muss die Sicherung zwingend getauscht werden, aber der Rest bleibt heil. Warum ich das trotzdem so mache? Weil es einfach und effektiv ist und es ohnehin nur zwei dieser Displays geben wird. Es ist also extrem unwahrscheinlich, dass einer von uns ein falsches Netzteil erwischt (wir sind schließlich beide Techniker). Ein anderer Kollege von mir (Paul) würde an dieser Stelle sagen: „Wer davon ausgeht, dass ich etwas entwickle, wo man ein Center-Negative-Netzteil ansteckt, dem gehört’s auch, wenn das Gerät nachher hin ist.“

Als Spannungswandler (U1) kommt ein DIO6970 zum Einsatz. Diesen habe ich gewählt, weil ich davon noch einige Stück vorrätig hatte. Er liefert bis zu 2A Ausgangsstrom bei einer maximalen Eingangsspannung von 24V – für dieses Projekt also bestens geeignet, wenn auch etwas überdimensioniert. Er regelt die Spannung, gesteuert über den Spannungsteiler R1/R2 auf die benötigten 3,3V für den ESP32 herunter.

Beim ESP32 (uC1) greife ich auf den ESP32-WROOM-32 zurück. Damit dieses startet, muss der EN-Pin (Enable) per Pullup-Widerstand auf High gezogen werden. Für die Programmierung wurden die UART-Leitungen (RX/TX) sowie 3,3V, GND, IO0 und EN auf einen 6-Pin-Header geführt. So lässt sich jederzeit eine externe UART-Brücke anschließen, um neue Software zu flashen.

Schaltbild ESP32

Abb.: ESP32, Programmierschnittstelle und UART-to-RS232-Wandler

An den Portpins IO22 und IO23 sitzen die zwei Taster (S1 und S2), die gegen 3,3V schalten. Ein Tastendruck wird somit als logische „1“ erkannt. Die Taster verfügen zudem über integrierte LEDs an IO25 und IO26. Der Piezo wurde an IO13 angeschlossen; Tonhöhe und Lautstärke lassen sich später per Software via PWM steuern. Für die Pegelwandlung auf RS232 wird ein MAX3232 verwendet, der an IO4 (TX) hängt. Die Kondensatoren am MAX3232 dienen der internen Ladepumpe zur Pegelanhebung. Da wir nur in eine Richtung kommunizieren müssen, wird lediglich die TX-Leitung des Microcontrollers zum RX-Pin des Displays geführt.

Für den Anschluss des Displays wurden eine DB25-Buchse sowie eine Klemme für die 12V-Versorgung eingeplant.

Displayansteuerung

Abb.: DB25-Connector und Klemme für 12V-Versorgung

Pin 2 der DB25-Buchse ist der RX-Eingang des Displays, der mit Pin 14 des MAX3232 verbunden ist. Pin 7 liegt auf Masse, während die Pins 4 und 5 sowie 6, 8 und 20 gemäß der Anleitung miteinander gebrückt wurden.

Wie man sieht, ist der Aufbau des Prints nicht sonderlich kompliziert. Die genaue PCB-Entflechtung will ich gar nicht im Detail erläutern, nur so viel: Ich habe darauf geachtet, dass Stecker und Taster sowohl von vorne als auch von hinten gut zugänglich sind. Zudem wurde der Bereich unter der WLAN-Antenne des ESP32 vom Kupfer befreit (ausgeschnitten), um Empfangsstörungen zu vermeiden. Den Abschluss bilden großzügige Masseflächen auf der Ober- und Unterseite.

Top View PCB

Abb.: Fertiges PCB v1.1 Topview

PCB 3D Ansicht

Abb.: PCB in 3D-Ansicht Topview

Testen des Prints#

Dankenswerterweise ist das Paket mit der Platine nach drei Wochen Lieferzeit angekommen, sodass es direkt an das Bestücken gehen konnte. Der MAX3232 wurde von einer anderen Platine „recycelt“, während alle übrigen Bauteile neu waren. Das Bestücken selbst verlief unauffällig. Normalerweise versuche ich zwar, zuerst alle Kondensatoren und Widerstände zu bestücken, bevor ich Halbleiterbauteile uns ICs verbaue. In diesem Fall habe ich mich jedoch dazu entschlossen, den DIO6970, den MAX3232 und den ESP32 gleich zu Beginn zu löten, da es sich so bei diesem Platinenlayout vom Platz her einfach angenehmer arbeiten ließ.

Bestückte Platine

Abb.: Bestückte Platine

Um die Platine nach dem Bestücken zu testen, habe ich den bis dahin fertigen Code von Ben genommen, den seriellen Ausgangspin auf IO4 verändert und das Programm einfach mal hochgeladen.

Displaytest über Steuerprint

Abb.: Displaytest über den Steuerprint

Um Software auf den ESP32 auf dem Print hochzuladen, wird eine UART-Brücke benötigt. Diese kann man entweder direkt fertig erwerben oder – wie in meinem Fall – selbst improvisieren: Ich habe von einem defekten ESP32-Dev-Board einfach den Prozessor abgelötet und anschließend RX, TX, IO0, EN, GND und 3V3 herausgeführt, um den Mikrocontroller nun extern flashen zu können.

Fazit#

Das Projekt hat absolut Spaß gemacht! Vor allem die Zusammenarbeit zwischen meinem Teil mit der Hardware und Bens Part mit der Software war super. So konnte ich mich voll und ganz dem für mich lustigeren Teil widmen, ohne mich am Ende auch noch um die Software kümmern zu müssen. Stattdessen konnte ich mich darauf konzentrieren, Ideen einzubringen, die dann von Ben umgesetzt wurden (danke dafür nochmal! :)), was umgekehrt natürlich ganz genauso lief.

Es gibt dennoch zwei Dinge, die ich im Nachhinein eventuell an meiner Hardware ändern würde: Einerseits würde ich die TX-Leitung des Displays nun doch ebenfalls mit dem Mikrocontroller verbinden. Auch wenn es nicht unbedingt erforderlich ist, wären jedenfalls noch genug freie GPIO-Pins zur Verfügung gestanden.

Das andere ist: Ich würde bei den Displays den D-Sub-25-Stecker gegen einen RJ45-Stecker oder einen anderen D-Sub-25-Stecker (mit anderem Pinout) austauschen. Damit hätte ich mir das separate 12V-Versorgungskabel vom Print in den Stecker für das Display sparen können. Da in dem breiten Stecker ohnehin sehr viele Pins ungenutzt sind, wäre es definitiv eleganter gewesen, die Spannungsversorgung direkt über den Stecker mitzuführen.

Den finalen Test mit allen Funktionen auf dem Display und wie das Ganze am Ende aussieht, kann man dann auf Bens Blog finden, sobald sein Teil des Projektes ebenso komplett fertiggestellt wurde.

Projektunterlagen#

Gerberfiles zum Steuerprint

Schaltplan und Bestückungsliste

Unterlagen des DSP800

Git-Repositories:

WienerlinienKassenDisplay - Software

WienerLinien-Display - Hardware