Keysight DSO-X 2012A Oszilloskop stirbt im Standby – Netzteiltausch

In einem alten Beitrag aus dem Jahr 2019 habe ich über Oszilloskope des Herstellers Keysight und deren Problem mit einem plötzlichen Ausfall berichtet. (siehe Link). Es ging damals darum, dass die Oszilloskope plötzlich ihren Dienst verweigerten – manchmal auch mit einem Knall und anschließendem Geruch nach „Strom“. Oder es passierte einfach gar nichts nach dem Einschalten. Der Grund dafür war und ist immer wieder der Ausfall des verbauten 12VDC Netzteils CCH0123F1-Z03A. Das Oszilloskop ist so konstruiert, dass das Netzteil bei ausgeschaltetem „Hauptschalter“ des Oszilloskops trotzdem am Netz hängt und im Standby-Modus betrieben wird. Der an der Frontseite des Gerätes befindliche Druckschalter schaltet das Netzteil dann in den PowerON Modus und die 12V Leistung ein. Wenn die Geräte in den Labors permanent an bestromten Steckdosen hängen, verwundert es auch nicht, dass die Geräte schneller altern, als die guten alten Kisten mit den Kathodenstrahlröhren. Die Teile, die der permanenten Stromversorgung durch thermische Dauerlast zu Opfer fallen, habe ich, sowie auch den Reparaturaufwand im damaligen Beitrag dargestellt. Von Seiten der Vertriebsfirmen ist auch ein Nachbestellen oder eine Ersatzlieferung von neuen Netzteilen nicht vorgesehen oder gewünscht. Wenn die Geräte innerhalb der Garantie- Gewährleistungszeit ausfallen sollten, ist der Austausch durch den Hersteller kein Problem. Fallen die Geräte aber erst aus, wenn sie schon ein paar Jahre im Labor oder der Werkstatt verweilen (dabei spielt es aber keine Rolle ob sie jeden Tag in Betrieb sind, oder eben nur angeschlossen und ausgeschaltet herumstehen), so läuft ein üblicher Reparatur- Serviceprozess beim Hersteller. Da sind dann auch die ordentlichen Tarife für den Service von Messtechnik zu bezahlen.

Im Bild oben: „neues Meanwell Powersupply“ unten: „origales Lineage Power“

Die Netzteile sind, wie im alten Bericht beschrieben, recht gut zu reparieren. Allerdings ist die Reparatur auch ziemlich zeitaufwendig. Schneller geht es natürlich, wenn ein neues Netzteil eingebaut wird. Die Vertriebsfirmen der Keysight Oszilloskope bieten leider keinen Ersatzteilsupport an und einen direkten Lieferanten des original verbauten Lineage Power Netzteils habe nicht finden können. Es gibt aber auch eine andere Alternative: Im Forum des EEV-Blogs haben einige User alternative Netzteile gefunden, die in die DSO-X Oszilloskope passen. Ein passendes Modell ist das RPSG-160-12 von Meanwell. Es handelt sich dabei um ein 12V 160W Powersupply. Die Bezeichnung „G“ in RPSG deutet darauf hin, dass auch ein 5V Standby-Supply vorhanden ist. Und genau diese Funktion benötigt auch das DSO-X. Denn wie schon zuvor beschrieben, ist der Frontschalter am Oszi nicht dazu gedacht, die Primärseite der Netzversorgung zu trennen, sondern lediglich eine Leitung am DC-Niedervoltstecker gegen Masse zu schalten. Diese Leitung steuert im Netzteil den „PowerON-Pin“.

Mechanisch passt das Meanwell beinahe auf die Montagehalterungen des DSO-X. „Beinahe“ bedeutet, dass der Abstand der Befestigungslöcher der Längsseite am Powersupply um etwa einen Millimeter weiter auseinander liegt, als die Befestigungsbolzen am Chassis des Oszilloskops. Das lässt sich aber mit einer kleinen Rundfeile oder einem 4mm Bohrer schnell anpassen. Jetzt kann das Meanwell Powersupply mit den originalen Torx Schrauben am Oszi Chassis befestigt werden. Die Steckverbindung für die AC-Versorgung von der OSZI-Platine zum Netzteil kann direkt vom alten Netzteil übernommen werden.

Pinout der Meanwell Steckerleisten

Die 12V Spannungsversogung am CN2 des Netzteils liegt an den Pins 1,2,3,4 (+12V) und 5,6,7,8 (GND) an. Die Verbindungsleitung zum Oszi ins entsprechend anzupassen.

DC12V Ausgänge an CN2

Im Bild unten sind die Pins der Steckerleiste am Oszi beschriftet dargestellt.

DC12V Eingang ins Oszilloskop

Ich habe die Drähte passend umgepinnt und den Stecker wie unten dargestellt mit dem Powersupply verbunden.

Die Hauptenergieversorgung zum Oszilloskop ist jetzt hergestellt. Es fehlt nur noch die „Einschaltleitung“ (PowerOn). Hierzu habe ich den 7. Pin (GND) und den 9.Pin(Switch) aus dem alten Stecker gelöst und direkt auf dem Standby Board des Netzteils angelötet. Der Draht am untersten Pin des Standby Boards ist das Signal „PowerOn“ und der darüber ist GND. Somit kann das Netzteil mit dem frontseitigen Einschalter am Oszilloskop hochgefahren werden.

„Steuerleitungen“ für das PowerOn des Netzteils

 

Gesamtansicht der Verkabelung

Nach einem kurzen Funktionstest und Überprüfen der Spannung (kann ggf. auch an dem Trimmpoti am Netzteil korrigiert werden) ist der Umbau abgeschlossen und der Zusammenbau kann wieder erfolgen.

EVU Smartmeter mit ESP32 auslesen und Daten per MQTT senden

So nach und nach bringe ich viele meiner Smarthome Komponenten auf einen gemeinsamen Standard. Dabei habe ich mich entschieden, sämtliche Geräte über einen NodeRed Server zusammen zu führen. Auch das HomeMatic System kommuniziert mit NodeRed. Hier übergebe ich unter anderen auch die Messwerte des EVU-Zählers (bei mir ist ein Siemens IM350 Smartmeter verbaut) an die HomeMatic CCU. Dies geschieht wie schon einem früheren Beitrag erwähnt, über die LED-Impulsschnittstelle (1000 Impulse/kWh). Hierzu wird einfach ein Fototransistor über der LED am Zähler angebracht, der die Blinkimpulse der LED erkennt und in der Zählersensor-Sendeeinheit HM-ES-TX-WM in die Momentanleistung umrechnet und über die Zeit integriert und die Daten dann an die CCU weitersendet. Das funktioniert an sich ganz gut. Nur die Aktualisierungsrate (im Minutenbereich) ist mir zu lange. Auch scheint der Fototransistor immer wieder auf das Streulicht der benachbarten LED (diese zeigt die Blindleistung in 1000 Impulse/kvarh an) zu reagieren. So entstehen Abweichungen zwischen der Zählung über den HomeMatic Sensor und den direkt am Zähler abgelesenen Werten.

Das geht auf jeden Fall genauer. Wenn man sich den IM350 Smartmeter Zähler im Detail ansieht, bzw. das Manual durchliest, so stellt man schnell fest, dass er eine sog. „Kundenschnittstelle“ besitzt. Diese Kundenschnittstelle stellt einige Messdaten über eine galvanisch getrennte Datenleitung im Sekundentakt zur Verfügung. Dazu gehören unter anderen die momentane Wirkleistung in beiden Richtungen, sowie die Zählerstände von Wirk- und Blindleistung in Bezugs- und Einspeiserichtung. Also perfekte Ausgangbedingungen, um den HomeMatic Zählersensor durch eine eigene Konstruktion zu ersetzen. Nach ein wenig Internetrecherche habe ich schnell erkannt, dass ich nicht der Einzige bin, der sich mit genau dieser Thematik beschäftigt. Die Daten der Kundenschnittstelle purzeln nach Anforderung über eine Daten-Request Leitung mit einer Geschwindigkeit von 115kbaud heraus. Sie sind allerdings verschlüsselt, und nicht direkt lesbar. Um den 16 Byte langen Entschlüsselung Key zu erhalten, muss der Energieversorger konsultiert werden. Der Schlüssel ist an die Seriennummer des Smartmeters gebunden und für jedes Smartmeter individuell. Nach einigem Telefonieren mit meinen Kärntner Energieversorger wurde mir der Key-Code per Mail zugesandt. Im nächsten Schritt testete ich mit einem USB-UART Adapter an einem PC, ob bei korrekter Beschaltung der Schnittstelle auch wirklich Daten aus dem Zähler herauskommen. Dazu habe ich einen RJ11 Stecker auf ein geeignetes 6pol. Kabel gekrimpt und das offene Ende des Kabels entsprechend des Datenblattes des Zählers beschaltet. Dazu ist nicht besonders viel notwendig. Eine 5V Versorgung muss die Schnittstelle aktivieren, ebenso muss auch die Data Request Leitung an 5V geschaltet werden und schon stehen an der Data Out Leitung die Datenpakete an. Es funktioniert übrigens auch mit einer 3V3 Versorgung. Mit einem Terminalprogramm am PC (ich verwende meist putty oder hterm) kann man die verschlüsselten Daten visualisieren.

Jetzt ging es daran, sich zu überlegen, wie die Daten entschlüsselt und aufbereitet werden. Hierzu findet man mit Netz zwei Ansätze:

* über einen RaspberryPi, mit einer Python-Umgebung und einem Python Skript. Die Skripten übernehmen hier den Empfang und die Entschlüsselung der Daten und stellen sie dann auf unterschiedliche Weise zur weiteren Verarbeitung zur Verfügung

* über einen ESP32. Der ESP ist ebenfalls in der Lage eine 128Bit AES Verschlüsselung zu dekodieren und hat noch reichlich Ressourcen um die Daten aufzubereiten und über WiFi zu versenden. Außerdem ist ein ESP für wenig Geld in ausreichender Stückzahl verfügbar. Also habe ich mich für diese Lösung entschieden. Dazu gibt es auf GitHub ein open source Projekt vom User https://github.com/Andre-Schuiki/esphome_im350  in dem er einen ESP32 IM350 Decoder als Basis für eigene Projekte zur Verfügung stellt. Mit seinen Sourcen erhält man einen Decoder der die Zählerdaten im Sekundentakt ausliest und über die USB UART Programmierschnittstelle und auch via Telnet über WiFi ausgibt. Dieses Sourcen habe ich als Basis verwendet. 

Mein Ziel ist es, die aus dem Smartmeter gewonnenen Daten in MQTT Messages zu verpacken und an meinen MQTT Broker zu senden. Ab da ist es dann ein Einfaches, sie in NodeRed und die HomeMatic CCU zu bekommen und dort zu speichern. Also habe ich den Code angepasst.  Dazu wurde die Wifi Verbindung zum Router auf eine statische IP gesetzt. (sind in settings.h zu definieren). Die ausgelesenen Messwerte, sowie die RSSI der WiFi Verbindung, werden jetzt über MQTT Topics zur Verfügung gestellt. (die IP-Adresse zum Broker ist auch in settings.h zu definieren). Wenn man den Code jetzt kompiliert und auf den ESP jagt, dann sollte er sich in das jeweilige Netzwerk einbuchen. Solange der ESP noch auf einem PC-hängt, kann man über die Programmierschnittstelle und ein Terminal auch gleich überprüfen was er tut. Verbindet man jetzt den RJ11 Stecker mit der Kundenschnittstelle des Zählers, dann solle im Display des Zählers im Sekundentakt das Dreieck über der Beschriftung „KU“ blinken. Passiert das, dann sollten auch schon im Terminal die Messwerte stehen (vorausgesetzt man hat den KEY vom EVU nicht vergessen in secrets.h einzugeben). Klappt auch das, dann stellt ein Blick auf den MQTT-Broker (mit z. Bsp.: MQTT-Explorer) sicher, dass die Messages auch ankommen. Jetzt kann der ESP vom PC entfernt werden.

Anschlussbelegung
ESP32 im „freifliegenden“ Testaufbau

Ich habe eine sehr einfache Lösung gewählt und des ESP auf einer Lochrasterplatine befestigt. Das 6polige Kabel zum Smartmeter dort angelötet. Auf der Lochrasterplatte finden dann noch die Pull-Up Widerstände und ein NPN Transistor (BC547 etc.) zum Invertieren der Datenpulse Platz. Die Platine habe ich in einem kleinen Kunststoffkästchen untergebracht, dass jetzt lediglich mit einem Kabel an der Kundenschnittstelle und mit einem USB Kabel an einem USB Steckernetzteil angeschlossen ist.

Der fertige Aufbau sieht dann (bzw. zurzeit) so aus. Die Daten landen im MQTT Broker und NodeRed visualisiert sie und schickt sie auch zur HomeMatic CCU.

so kommen die Daten im MQTT Broker an
und können zum Beispiel so in NodeRed verarbeitet werden

wenn jemand an den angepassten Skripten interessiert ist, kann ich die gerne zusenden. Betreffend einer Veröffentlichung auf  GitHub muss ich mich erst informieren welche Lizenzbedingungen betreffend des ursprünglichen Repositorys zu erfüllen sind. Es wird dann hier (public) verfügbar sein:

https://github.com/ingmarsretro/esphome_im350/tree/main/standalone_version_mqtt

Die Wärmepumpe (NEURA) in das Smarthome einbinden

Ein Smarthome ist heute keine Seltenheit mehr und sehr weit verbreitet. Es gibt unzählige Systeme am Markt, die das eigene Zuhause „Smart“ machen. Die digitalen Sprachassistenten von Google, Amazon und co. in Verbindung mit Smarten Glühlampen zählen zu den einfach und schnell zu installierenden Systemen. Aber es gibt auch komplexe Smart Home Systeme, bei denen in den Hausverteilern Aktoren für jede Lampe und Steckdosen verbaut sind. Die Fenster und Türen sind mit Meldekontakten ausgestattet und sichern das Eigenheim oder melden, wenn einmal auf das Schließen der Fenster nach dem Stoßlüften vergessen wird. Das diese Systeme bei vernünftiger Programmierung auch zur Energieoptimierung beitragen ist selbstverständlich. Auch ich betreibe Smarthome Komponenten unterschiedlichster Hersteller.

Dazu gehört seit Jahren das HomeMatic System, das sowohl kabelgebunden als auch über das Bidcos-Protokoll mit seinen Aktoren und Sensoren kommuniziert. Das HUE – System von Phillips spricht dabei über ZigBee mit seinen smarten Lampen und Steckdosen. Die Gateways dieser Systeme sind an ein LAN Netzwerk angeschlossen und jedes System bringt seinen eigenen Webserver mit, über den es dann zu steuern und einzustellen ist. Ein Wechselrichter von Photovoltaikanlagen kann seine Daten über unterschiedlichste Schnittstellen (RS485, CAN, RS232) zur Verfügung stellen. Um alle auf eine zentrale Darstellungsebene zu bringen, habe ich mich für das NodeRed System entschieden. Der Dazu notwendige NodeRed Server läuft auf einem Raspberry PI. (Auf der CCU3 mit dem Raspbian Image ist noch genug Platz um den NodeRed Server laufen zu lassen – der ist sogar als eigenes Plugin für die CCU verfügbar und wird „RedMatic“ genannt).  Mit dieser Konfiguration lässt sich fast alles im Bereich Homeautomation „erschlagen“. Mit ESP32 und Raspberry lassen sich über MQTT (Message Queueing Telemetry Transport) bequem Statusinformationen übertragen. Dies wende ich beispielsweise bei den kleinen Einspeise Wechselrichtern einer Balkon PV-Anlage an, als auch bei den PV-Wechselrichtern einer Offgrid-Anlage. Hier werden die Daten über unterschiedliche Bussysteme im Raspberry oder ESP32 empfangen und in das MQTT-Protokoll umgesetzt. Der MQTT Broker sammelt die Daten der einzelnen Geräte und über NodeRed lassen sie sich dann in eine Datenbank schreiben, im Browser oder am Smartphone visualisieren und auch einfach, je nach Bedarf, im HomeMatic System verarbeiten.

Beispiel eines Smarthomenetzwerks

Somit ist es möglich, nahezu alle Systeme miteinander Smart zu vernetzen und, für mich wichtig auf EINER Plattform zu visualisieren. Ein einziges System fehlte bisher noch. Das ist meine alte Neura Heizungswärmpepumpe. Die Firma Neura ist schon seit einigen Jahren nicht mehr existent und der von „b.i.t.“ entwickelte auf Webserver „webidalog“ wurde nie mehr aktualisiert. Die Wärmepumpe hat also einen Webserver auf einem kleinen mit Linux-Rechner onboard und baut die Webapplikation mit einer uralten Java Version. Für die Bedienung muss am PC eine Java Runtime installiert sein, die nur mit einigen Tricks auf einem aktuellen Windows Rechner läuft (Stichwort: Virtualisierung). Für die Bedienung über ein Smartphone ist eine html – Version mit eingeschränkter Funktionalität verfügbar. Mein Plan war es nun, eine Schnittstelle zu finden, mit der ich die Daten der Wärmepumpe zumindest einmal auslesen kann, um Vorlauf- Rücklauftemperaturen der Fußbodenheizung, Kesseltemperatur, etc. auch in meinem NodeRed System zur Verfügung habe. Da zu dem System aber so gut wie keine Dokumentation zu finden ist und ein Reverse-Engineering ein wenig kritisch ist, wenn das System weiter laufen soll, kam mir folgende Idee:

Mit einem „headles browser“ sollte es ja möglich sein, die html-Version der Neura WebDialog Website zu parsen und die relevanten Daten zu finden und über Variablen in MQTT-Topics zu verwandeln. Und hier muss ich einen besonderen Dank an meinen Kollegen Mario Wehr aussprechen, der mir die Softwarestrukur zum parsen der Website gebaut hat. Die Software ist in PHP geschrieben und läuft schlussendlich auf einem Raspberry PI. Hier sind lediglich eine php8-cli runtime und ein paar Module notwendig. Die Software funktioniert so, dass bei jedem Aufruf ein Login auf der Wärmepumpenwebsite ausgeführt wird, danach werden die Daten geparsed und zu MQTT-Broker gesendet. Das kontinuierliche Aufrufen des php-Skriptes habe ich dann einfach mit einem cronjob gelöst, der jede Minute ausgeführt wird.

 

>sudo crontab -e

und der job sieht dann so aus:

* * * * * sudo php /home/neura2mqtt/neura2mqtt.php -c

(wenn man sich die files  ins  /home/ verzeichnis legt…). Das Projekt habe ich auf github unter:  https://github.com/ingmarsretro/neura2mqtt veröffentlicht.

Neura Daten am NodeRed Dashboard

 

 

 

 

Ein Nachbauprojekt für die Vectrex

Es ist wieder einige Zeit vergangen, dass ich es schaffe, in den späteren Abendstunden Zeit und Energie zu finden, hier im Blog über eines meiner kleinen Projektchen zu schreiben. Ich habe mir in den letzten Jahren angewöhnt, bei Autofahrten und nächtens, Podcasts zu hören. Dazu gehören in erster Linie Podcasts zu technischen Themen. Darunter ist auch ein Podcast, der sich „Retrokompott“ nennt und sich mit Homecomputern und Technik aus unserer Jugendzeit beschäftigt. Deren Slogan lautet:

Retrokompott, eine Zeitreise in die Vergangenheit alter Homecomputer, Spielekonsolen und Games

[http://blog.retrokompott.de/]

In einem der Beiträge von Retrokompott diskutierte man einige Folgen lang (172-177) über die Vectrex, den Heim – Vectorspieleautomaten von MBE. Hier wurden unter anderen auch Homebrewprojekte, also Software-Eigenentwicklungen der Anwender vorgestellt.  „Vectorblade“ ist dabei ein Spieletitel, der von Malban [http://vide.malban.de/] entwickelt wurde. Das Projekt wurde dabei mit dem ebenfalls von Malban entwickelten Vectrexcompiler (vide) erstellt. Die Sourcen sind öffentlich auf der Website verfügbar. In dem „Kompott“-Beitrag hat man so begeistert über Vectorblade berichtet, dass mein Interesse dafür geweckt war. Das Spielemodul war auch eine Zeit lang über Malban zu erwerben. Ich habe aber keine Quelle gefunden, über die ich das Modul auf einfache Weise erwerben kann. So dachte ich mir, baue ich mir das halt einfach nach. Das Besondere an diesem Gamerom ist die Größe des Games. Es hat stolze 192 kB. Um diesen Speicher adressieren zu können, hat sich Malban der Bank-Switching Technologie bedient. Er verwendet in seinem Design einen Flash-Speicher von SST, den SST39SF020. Das Bankswitching wird über einen Vierfach-2-Eingang NAND Schmitt Trigger (74AC132) gesteuert. Malban hat auf git das Layout veröffentlicht. Dort verwendet er den Speicher im DIL-Package und ebenso auch den AC132. Eine detaillierte Anleitung findet man hier.

Da ich von meinem alten Selbstbau-Rom Modul Projekt noch einige Platinen über habe, konnte ich schnell einen Versuchsaufbau zusammenstoppeln.  Flashspeicher hatte ich zwar keinen zur Verfügung – sehr wohl aber eine ausreichend großes EPROM. Der Vide-Compiler und die Source-Files sind auf Malbans GIT ebenfalls veröffentlicht. Nach kurzem Studium seines Vide-Compilers ist es mir gelungen das Projekt zu kompilieren und eine ROM – Datei zu erstellen. Mit meinem „Fernostprogrammer“ konnte ich dann das EPROM „brennen“.  Mit ein paar Drahtbrücken und einem AC132 wurde aus meinem alten ROM-Platinen Projekt dann der Vectorblade Versuchsaufbau.

Versuchsaufbau Vectorblade

Mit der Ausnahme, dass keine Settings gespeichert werden können, funktioniert der Testaufbau und das Game lässt sich spielen :). Der nächste Schritt des Nachbaus war dann die Platine zu zeichnen. Hier wollte ich den Schmitt-Trigger Baustein in SMD Ausführung einbauen und den SST weiterhin in DIL. Ich habe diese Ausführung auch realisiert und erfolgreich getestet. Es gibt aber einen kleinen Haken – keiner meiner Lieferanten hat den SST39SF020 Flashspeicher in DIL Ausführung auf Lager. Ich habe jetzt zwar einige Platinen mit DIL – Layout aber eben keine Chips… Also noch einmal zum PC und das Design auf PLCC Sockel umzeichnen. Gedacht – getan und einen Satz Platinen beim Fernostproduzenten bestellt.

Ein passendes Gehäuse lässt sich mit dem 3D-Drucker selbst erstellen. Genauer gesagt wurde ich auf Thingiverse fündig und konnte  aus einer Vielzahl an geeigneten Designs wählen.

Es fehlt zwar das Overlay –  aber auch ohne das macht das Spiel Spass. Hier ist Malban ein tolles Game gelungen.

MIDI DB50XG – ein Interface für das Daughter Board

Beim Stöbern in einer Kiste mit meinen alten Bastelarbeiten ist das folgende Kästchen zum Vorschein gekommen.  Es stammt aus der Zeit als ich noch mit Amgia, aber auch schon mit PCs zu tun hatte – ich schätze so ca.  um 1996. Das Kästchen beschriftete ich mit „DB50XG MIDI – Wavetableprozessor“.

Das Fundstück aus der Kiste

Darin befindet sich eine Platine von Yamaha, die sich eben DB50XG nennt. Diese Platine war als Tochterplatine für PC-Soundkarten mit „Waveblaster“ Erweiterungsport konzipiert. Sie erweiterte die Soundkarten um einem polyphonen MIDI – Wavetable – Sampler. So konnte der General Midi Standard und der Yamaha XG Standard wiedergegen werden.  Heute macht sich darüber niemand mehr Gedanken. Wenn man damals mit einem PC aus Midi – Daten Sounds erzeugen wollte, dann war entweder eine externe Hardware notwendig, oder eben eine Soundkarte mit einem OnBoard Midi Synthesizer oder Wavetable Chipsatz. Der PC übernahm dann die Steuerung, das Senden und Empfangen der Midi Daten über eine Sequenzer Software. Heute werden die Midi Sounds direkt am PC generiert und die Samples und Tonmodelle in die Software eingebunden. Damals reichte die Leistung der PC-Hardware dazu nicht aus. Wenn sich jetzt jemand gerade fragt, worüber ich hier palavere – was ist Midi und wofür benötigt man das? – dann sei hier kurz gesagt: Midi ist die Abkürzung für „Musical Instrument Digital Interface“ – also eine digitale Schnittstelle – ein Datenprotokoll für Musikinstrumente. Es dient – grob erklärt – dazu, elektronische Musikinstrumente untereinander zu vernetzen und zu steuern. So kann zum Beispiel über ein einziges Keyboard eine Vielzahl von klangerzeugenden Geräten gesteuert werden. Wie der Midi Standard funktioniert, wie die Datenpakete aussehen und das elektrisch aussieht, werde ich hier nicht erläutern. Dazu findet man, wie immer, reichlich Informationen im Netz.

Im Inneren des Kästchens

Zurück zum selber gebastelten Kästchen. In die Plastikbox habe ich damals das DB50XG gepackt und vom „Waveblaster“-Port, einer 26poligen Buchsenleiste, die notwendigen Leitungen zur Inbetriebnahme der Midi Platine nach Außen geführt. Und das war ziemlich simpel. Die Platine benötigt eine Spannungsversorgung von +/-12V und +5V. Es gibt einen Midi-IN und einen Midi-OUT (Through) Pin, einen Reset-Pin und zwei Analog Audio Out Pins – je einen pro Kanal. Die untenstehende Tabelle zeigt die Pinzuordnung des Steckers:

Pin Nummer Zuordnung
1 Digital Masse
2 nicht verbunden
3 Digital Masse
4 nicht verbunden
5 Digital Masse
6 Versorgung +5V
7 Digital Masse
8 nicht verbunden
9 Digital Masse
10 Versorgung +5V
11 Digital Masse
12 nicht verbunden
13 nicht verbunden
14 Versorgung +5V
15 Analog Masse
16 nicht verbunden
17 Analog Masse
18 Versorgung + 12V
19 Analog Masse
20 Audio out rechts
21 Analog Masse
22 Versorgung -12V
23 Analog Masse
24 Audio out links
25 Analog Masse
26 Reset

Der ganze Aufbau war damals eher sehr spartanisch gestaltet. Die Stromversorgung musste über ein, oder mehrere externe Netzteile hergestellt werden. Es gab keine galvanische Signaltrennung mittels Optokoppler. Da musste ich mich auf den ordentlichen Aufbau des Midi-IO-Controller verlassen, den ich an den Amiga angeschlossen hatte. So durfte das natürlich nicht bleiben. Und das schöne DB50XG Board nicht mehr zu verwenden, oder dem Elektronikschrott zuzuführen, bringe ich nicht über´s Herz. Der Plan der daraus entstand, war, ein neues Interfaceboard zu entwickeln – oder basteln, das möglichst universell einsetzbar werden sollte. 

DB50XG

Diese Idee ist nun schon wieder einige Jahre her und immer wieder einmal habe ich ein wenig daran gearbeitet. Folgende Punkte, so habe ich mir ausgedacht, sollte das Interfaceboard erfüllen:

  • eine einfache Spannungsversorgung soll das Yamaha Board mit Energie versorgen. Idealer Weise soll ein USB-Port und optional ein Anschluss für ein Universalnetzteil vorhanden sein. Alle benötigten Spannungen sollen auf dem Interfaceboard aus den 5VDC generiert werden.
  • Das DB50XG soll, wie seinerzeit, auch als „Huckepack“ Platine aufgesteckt werden können
  • Das Midi-in Signal soll über die 5polige DIN Buchse und auch über einen Pinheader eingespeist werden können – natürlich schön entkoppelt (Damit kann auch ein Microcontroller wie Arduino und co. ganz ohne Aufwand angeschlossen werden)
  • Der Ton, also das Audiosignal soll pro Kanal über je eine Chinch-Buchse und auch als 3.5mm Klinkenbuchse und über einen Pinheader zur Abnahme bereitstehen.
  • Wortwiederholungen SOLLTEN vermieden werden, ist mir aber egal 🙂

Daraus entstand schlussendlich der folgende Schaltplan. Die 5VDC Versorgung der USB Quelle wird direkt zur 5V Versorgung des Midi Boards geführt. Die ebenfalls benötigten +12V/-12V erzeugt ein DC/DC Converter (TMR0522). Dieser wird eingangsseitig vom 5V Netz versorgt. Der optionale „Externe“ Spannungseingang gelangt an einen LM2596ADJ. Das ist ein Step-Down Voltage-Regulator der mit Eingangsspannungen bis zu 40V arbeiten kann. Die geregelte Ausgangsseite ist in vielen Bereichen verfügbar. Ich habe hier den ADJ (Adjustable) Typ in die Schaltung integriert, da ich davon einige Stück im Sortiment Kasten habe. Durch einen Jumper am Board ist, die Spannungsquelle wählbar.

Auf Basis dieses Schaltplanes habe ich ein Layout erstellt und es vorerst einmal im eigenen Ätzbad hergestellt. Heraus kam die folgende Platine, die als Testaufbau diente. Technisch funktionierte das Board einwandfrei, jedoch die Anordnung der Komponenten hat mir nicht gefallen. Den Step-Down Converter samt Spule hatte ich auf der Rückseite platziert. Auch war mir der Abstand zwischen den Anschlussbuchsen zu eng beieinander. Und wie man das als PCB Layouter so macht – man macht immer ein zweites Design. So auch dieses Mal.

Der Testaufbau mit bestücktem Midiboard ist im nachfolgenden Bild zu sehen. Das Midi-Signal als Testquelle kommt vom PC und wird durch einen USB-Midi Adapter aus Fernost generiert.

Also noch einmal vor den Rechner gesetzt und das Layout umgezeichnet. Heraus gekommen ist dann die folgende Version. Diese Ausführung habe ich dann bei einem Leiterplattenhersteller bestellt.

Die schlussendlich gefertigte Platine in bestücktem Zustand sieht dann so aus. Darunter ist sie  mit dem aufgesteckten DB50XG Board zu sehen.

 

Wenn der Spiegel nicht mehr klappt

Immer öfter höre und lese ich von nicht mehr richtig funktionierenden elektrisch einklappbaren Außenspiegeln bei Fahrzeugen des deutschen Herstellers mit den vier Ringen. Das Problem tritt bei vielen Modellen auf, die schon ein paar Jährchen in Betrieb sind und in unserem hiesigen Klima betrieben werden. In Internetforen findet man einige User, die dieses Problem kennen. Auch in meinen Bekanntenkreis gibt es ein paar Ringe-Fahrer die einen klemmenden elektrischen Außenspiegel haben. Als Lösung wird vom Hersteller natürlich immer der Austausch der kompletten Einheit empfohlen. Wer sein Erspartes aber nicht sinnlos für neu produzierten Restmüll ausgeben möchte, kann sich selbst dieses Problems annehmen. Es ist sogar eine ziemlich kleine Ursache, die dieses Problem verursacht. Und das Beste – es lässt sich ohne Materialaufwand reparieren. Auch ist die Langlebigkeit der Reparatur mittlerweile bewiesen…

Der Fehler zeigt sich durch folgendes Verhalten:

  • der Spiegel macht quietschende, knarrende Geräusche beim Aus – Einklappen
  • der Spiegel bleibt an falscher Position stehen und lässt sich nur durch manuelles Bewegen einrasten
  • das Klappverhalten ist abhängig vom Wetter

 

Man liest darüber viele Beiträge mit möglichen Ursachen – von defekten Motoren und defekten Türsteuergeräten. Am besten sollte man gleich die Spiegeleinheit erneuern und dazu ein neues Türsteuergerät – ja klar …

Die Lösung des Problems ist einfacher: ein kleiner Stahlbolzen, der von einer kleinen Feder rausgerückt werden soll, bleibt in seiner Führung stecken. Der mechanische Bereich des Spiegels ist natürlich auch den Umweltbedingungen ausgesetzt und so kommt der Bereich mit Regen, Spritzwasser – im Winter Salzwasser in Kontakt. Im Laufe der Zeit verlieren die Schmierstoffe ihre Eigenschaften oder werden sogar ausgewaschen und das ganze „Werkl“ wird schwergängig. Also was hilft? Komplett zerlegen, reinigen neu schmieren und wieder zusammenbauen.

Ich habe für diesen knapp eineinhalbstündigen Eingriff damit begonnen, den Spiegel aus der Tür auszubauen und in der gemütlichen Werkstatt zu untersuchen. Dazu ist die am einfachsten die Innenverkleidung der Türe abzunehmen (je nach Fahrzeug ein paar Schrauben und viele Klipse…) Der Spiegel ist dann mit einem Kabel am Türsteuergerät angesteckt und mit Torx-Schrauben befestigt.

Das Spiegelglas lässt sich am einfachsten mit einem Plattenheber (Saugnapf) ausklicken. Dann sind vorsichtig – falls vorhanden- die beiden Flachstecker von der Spiegelheizung abzuziehen (unbedingt die Kontakte auf der Heizfolie gegenhalten). Als nächstes können beiden Kunststoffhälften des Spiegel Gehäuses entfernt werden. Hier hilft ein wenig Beobachtungsgabe, welche Schrauben zu entfernen sind und wie die Hälften zusammengehalten werden.

Jetzt liegt das Kernstück des Spiegels da. Die beiden Druckgussteile sind über eine hohle Achse miteinander verbunden. Durch die Achse führt das Anschlusskabel zum Spiegelverstell-Antrieb und zur Heizung. Über der Achse sitzt eine große Stahlfeder die mit einer Distanzscheibe und einem Spannring (keine Ahnung, ob das die korrekte Bezeichnung ist) befestigt. Die Feder übt einen ordentlichen Druck zwischen den beiden Teilen aus- und das ist jetzt der einzige etwas schwierigere Teile – die Feder muss raus. Dazu ist der Spannring auszuhebeln, während die Feder auf Spannung gehalten wird. Heraus geht sie einfach – aber das wieder einbauen wird zur Herausforderung, wenn man kein geeignetes Werkzeug hat.

Auf dem Bild ist die schon entspannte Feder zu sehen. Jetzt können die beiden Teile auseinandergenommen werden.

Hier sind die Teile in zerlegter Form zuerkennen. Um nun das Corpus Delicti zu erreichen, muß das kleine Getriebe mit dem Motor abgeschraubt werden. Darunter ist der Bolzen zu erkennen, der in diesem Fall fest in seiner Bohrung steckte, sodaß es der Feder nicht mehr gelungen ist, ihn heraus zu drücken.

Deckel des kleinen Getriebe
Bolzen ist links neben dem Befestigungsloch zu erkennen

Bolzen mit Feder
auch die Führung des Bolzen ist zu reinigen

Die Prozedur ist ziemlich einfach – alles reinigen, die Korrosionen entfernen und mit Schmierstoffen neu abschmieren. Danach wieder alles zusammenbauen sich freuen. 🙂 Die meiste Zeit der ganzen Arbeit bnimmt das Reinigen in Anspruch.

Übrigens: der hier beschriebene Spiegel stammt von einem A5…

UV-Sensor Logger selbstgebastelt

Kommt der Sommer, kommen neue Ideen. In den Sommermonaten ist ja bekanntlich die Sonnenscheindauer länger und auch die Intensität der Sonnenstrahlen höher. Viele nutzen diese Eigenschaft der Sonne, um ihre Vitamin-D Produktion des Körpers anzutreiben, andere wiederum legen sich unter die Strahlenquelle um durch den hohen UV Anteil ihrer Hautfarbe abzudunkeln. Dies wiederum steigert vermeintlich deren Attraktivität und regt die Hormonproduktion und die Paarungsbereitschaft an… Leider hat der nicht sichtbare UV Bereich im Spektrum des Sonnenlichts bekanntlich auch negative Auswirkungen auf den menschlichen Körper. Auch technisch kann das Sonnenlicht genutzt werden. Durchschnittlich wird die Leistung der Sonne pro Flächeneinheit mit 1000W pro m² angenommen. Großflächige P-N Übergänge in Halbleitermaterialien schaffen mittlerweile mit einem Wirkungsgrad von bis zu 22% daraus elektrische Energie zu erzeugen.

Man kann die Energie aber auch noch anders nutzen, bzw. den UV-Anteil. Vielen Retrosammlern ist sicherlich das Problem mit den vergilbten alten Kunststoffgehäusen bekannt. Um das in den Griff, bzw. wieder in den Ursprungszustand von vor 30, 40 Jahren zu bekommen, verwendet man H2O2 also Wasserstoffperoxid und UV Licht um so einen Bleichprozess in Gang zu bekommen. Und so kam ich zur Idee für folgendes Projekt.

Bei einem online-Elektronik-Laden fand ich im Abverkaufs Angebot ein UV-Sensor Board des Herstellers Waveshare. Darauf befindet sich ein LITEON OPTOELECTRONICS LTR390 Chip samt Levelshifter-Schaltung. Als Interface steht ein I²C Bus zur Verfügung. Ein Blick ins Datenblatt verriet mir, dass der Sensor zwei Wellenlängenbereiche erfasst und separat ausgibt.  Der ALS (Ambient Light Sensor von 500-600nm) und der UV (Ultra Violett Bereich von 300-350nm).  Damit kann man doch schnell ein einfaches Logging Board basteln – dachte ich mir.  So habe ich mir gedacht, das Board sollte folgendes können:

  • Spannungsversorgung von einer 18650er Zelle oder USB
  • USB soll den Akku auch laden können
  • einen Micro-SD Slot zum Aufzeichnen der Sensordaten
  • einen RS-232 Port, zum direkten Loggen am PC
  • ein cooles OLED Display
  • zwei Taster zum Bedienen des Loggers (Intervall, Start/Stop etc.)

Die Steuerung soll natürlich wieder einmal ein Chip von Atmega – der 328er übernehmen. Davon befinden sich einfach noch genügend Stück in meinen Sortiment Kästchen. Damit man sich schneller einen Überblick über den Aufbau verschaffen kann, habe ich das folgende Blockdiagramm gezeichnet:

Im nächsten Schritt habe ich aus dem Blockschaltbild einen Schaltplan erstellt, um aus dem dann wiederum ein Layout erstellen zu können.  Parallel zur Schaltplanerstellung habe ich einzelne Bereiche per „Luftverkabelung“ auch gleich probeweise zusammengeschaltet und getestet, ob das alles auch so funktioniert, wie ich mir das vorstelle. Und vor allem sollte auch alles im Flashspeicher des Microcontrollers Platz haben.

Im Bild oben ist der „luftige“ Aufbau bestehend aus fertigen Komponenten zu erkennen. Für die ersten Tests mit dem Sensor und dem OLED Display reichte ein Arduino vollkommen aus. Damit war es mir möglich, die gewünschten Funktionen zu testen. Somit stand der Erstellung des Schaltplanes nichts mehr im Weg. Eine 18650er Lithiumzelle soll als primäre Energiequelle dienen. Alternativ wird auch ein USB-Port vorhanden sein, der die Zelle laden kann bzw. den Sensor betreiben kann. Dafür, weil ich faul bin und auch ziemliche Bauteil Lieferengpässe ein großes Problem sind, verwende ich zum Laden des Akkus eine fertiges Wemos-D1-Mini Board. Das wird genauso wie das OLED Displayboard und das Sensorboard als fertige Komponente auf dem Design der Platine Platz finden.  Als Controller kommt wieder, wie schon erwähnt, ein Atmega328 im TQFP Gehäuse zum Einsatz. Dieser wird über die I²C Schnittstelle mit dem OLED Display (SBC-OLED01 mit SSD1306 Controller) und dem LTR390 UV-Sensorboard kommunizieren. OLED und Sensor sind 5V kompatibel. Die SD-Karte wird aber mit 3.3V betrieben. Dafür benötigt die Schaltung noch einen Spannungswandler von 5V auf 3.3V für die Versorgung und einen Levelshifter für den SPI-Datenbus, über den die SD-Karte mit dem Atmega die Daten austauscht. Da der Atmega dann auch mit seiner Firmware programmiert werden möchte, habe ich einen 2×4 Pinheader für den Anschluss eines Programmers vorgesehen. Sechs Pins davon (GND,5V, MOSI, MISO, SCK und RESET) benötigt der Programmer und die zwei verbleibenden Pins sind für die serielle Schnittstelle vorgesehen. Die beiden Interrupt-Eingänge des Atmega werden mit je einem Taster beschalten, der dann die Software bedienbar macht. Die Batteriespannung wird über einen Teiler an einem der ADC-Eingänge gemessen bzw. auch mitgeloggt. Das Ergebnis dieser Gedanken ist der folgende Schaltplan:

Ein Layout ist danach der nächste Schritt.  Bei einer Größe von 12 x 4,5 cm ist die Platine einigermaßen „handlich“. Die Leiterbahnführung findet auf beiden Seiten statt und die Module (Ladeschaltung, Display und UV-Sensor) sind über Pinheader steckbar ausgeführt.

Die beiden Bilder oben zeigen die Vorschau der „Top-“ bzw. „Bottom-“ Seite des Layouts. Aus den so erstellten Produktionsdaten konnte eine Platine erstellt werden.

Nach einiger Lötarbeit war die Hardware dann soweit fertig. Um diesem „Lötwerk“  letztendlich auch Leben einzuhauchen, bedurfte es einer Software, die auf dem Microcontroller ihre Arbeit verrichtet.

Beim Basteln der Software bediente ich mich der kostenlosen „Arduino IDE“ Entwicklungsumgebung.  Die Dokumentation des LTR390 beschreibt genau über welche Register welche Funktionen des Sensors zu bedienen sind. Es gibt aber auch schon für ganz Bequeme eine fertige Library – so wie für fast alle Sensoren und Aktoren, die an Microcontroller angeschlossen werden sollen. In der Arduino IDE findet man über den Boardmanager die „Adafruit LTR390 Library“ über die man einfach mit dem Sensor kommunizieren kann.  Die Ansteuerung des OLED Displays übernimmt in meinem Fall die SSD1306Ascii Library. Die Buskommunikation übernehmen die „Wire“ und “ SPI“ Library und die „SD“ spricht mit der SD – Karte.  Die Includes sehen dann so aus:

#include <LTR390.h>
#include <SD.h>
#include <SPI.h>
#include <Wire.h>
#include „SSD1306Ascii.h“
#include „SSD1306AsciiWire.h“

Den gesamten Code kann ich bei Bedarf gerne hier veröffentlichen. Er ist allerdings kein Hexenwerk, sondern simples und sicher nicht optimiertes Codezeilen Geschreibe 🙂 In der derzeitigen Code- (Firmware) Version 1.3d gibt es ein kleines Auswahlmenü, das es ermöglicht, das Logintervall der SD-Karten-Aufzeichnung einzustellen und natürlich auch die Aufzeichnung zu starten bzw. zu stoppen. Geloggt wird in ein Textfile. Die aufgezeichneten Daten sind UV-Index, Umgebungshelligkeit und die Akkuspannung.

Einen Auszug aus dem Datalog habe ich unten eingefügt:

 Ambient[lx], UV-indx, Batt[V], Loggingintervall[s]  
 691.60,0.01,3.77,20  
 691.60,0.03,3.76,20  
 1184.00,0.03,3.77,20  
 1184.00,0.03,3.75,20  
 1191.00,0.03,3.77,20  
 1191.00,0.03,3.75,20  
 1198.60,0.03,3.76,20  
 1198.60,0.03,3.73,20  
 1211.60,0.03,3.76,20  
 1211.60,0.04,3.75,20  
 1223.00,0.04,3.75,20  
 1223.00,0.04,3.76,20  
 1234.20,0.04,3.76,20  
 1234.20,0.04,3.74,20  
 1243.60,0.04,3.76,20  
 1243.60,0.04,3.76,20  
 1252.00,0.04,3.75,20  
 1252.00,0.04,3.73,20  
 1261.20,0.04,3.74,20  
 1261.20,0.04,3.72,20  
 1269.60,0.04,3.76,20  
 1269.60,0.04,3.76,20  
 1278.40,0.04,3.76,20  
 1278.40,0.04,3.75,20  
 1288.40,0.04,3.76,20  
 1288.40,0.04,3.75,20  
 1298.20,0.04,3.76,20  
 1298.20,0.04,3.74,20  
 1305.80,0.04,3.73,20  
 1305.80,0.04,3.73,20  
 1313.20,0.04,3.73,20  
 1313.20,0.04,3.75,20  
 1321.60,0.04,3.74,20  
 1321.60,0.04,3.75,20  
 1331.80,0.04,3.75,20  
 1331.80,0.04,3.75,20  
 1341.60,0.04,3.74,20  
 1341.60,0.04,3.76,20  
 1349.40,0.04,3.76,20  
 1349.40,0.04,3.76,20  
 1358.20,0.04,3.72,20  
 1358.20,0.04,3.76,20  
 1365.60,0.04,3.74,20  
 1365.60,0.04,3.73,20  
 1374.20,0.04,3.72,20  
 1374.20,0.04,3.75,20  
 1380.60,0.04,3.75,20  
 1380.60,0.04,3.76,20  
 1386.60,0.04,3.75,20  
 1386.60,0.04,3.76,20  
 1394.80,0.04,3.75,20  
 1394.80,0.04,3.75,20  
 1401.40,0.04,3.73,20  
 1401.40,0.04,3.74,20  
 1408.60,0.04,3.75,20  
 1408.60,0.04,3.74,20  
 1414.20,0.04,3.73,20  

 

Diese Daten lassen sich jetzt sehr einfach weiterverarbeiten und grafisch darstellen. Als Office-Nutzer kann man zum Beispiel auf Excel zurückgreifen und die Daten dort importieren und als Graphen darstellen. Es geht aber noch einfacher und auch sehr schnell mit Tools wie Matlab. Mit einem Script wie dem nachfolgenden kann man die Logdatei dann visualisieren.

 

 %% Setup the Import Options and import the data  
 opts = delimitedTextImportOptions("NumVariables", 4);  
 opts.DataLines = [3, inf];  
 opts.Delimiter = ",";  
 opts.VariableNames = ["Ambientlx", "UVindx", "BattV", "Loggingintervalls"];  
 opts.VariableTypes = ["double", "double", "double", "double"];  
 opts.ExtraColumnsRule = "ignore";  
 opts.EmptyLineRule = "read";  
 opts = setvaropts(opts, ["Ambientlx", "UVindx", "BattV"], "TrimNonNumeric", true);  
 opts = setvaropts(opts, ["Ambientlx", "UVindx", "BattV", "Loggingintervalls"], "DecimalSeparator", ",");  
 opts = setvaropts(opts, ["Ambientlx", "UVindx", "BattV"], "ThousandsSeparator", ".");  
 datalog = readtable("F:\ingmarsretro\datalog.txt", opts);  
 clear opts  
 x=size(datalog); % groesse der tabelle  
 measurement=x(1); % anzahl messungen   
 uvi=datalog{1:measurement,2};  
 ambient=datalog{1:measurement,1};  
 messzeit = linspace(0,(measurement*datalog{1,4}),measurement); %zeitvektor von 0 bis zeitintervall aus datalog spalte4 * messungen  
 figure(1);  
 title('UV - Index');  
 subplot(2,1,1);  
 plot(messzeit,uvi);  
 title('UV - Index');  
 xlabel('Zeit [s]');ylabel('UV - Index');  
 subplot(2,1,2);  
 plot(messzeit,ambient);  
 title('Beleuchtungsstärke');  
 xlabel('Zeit [s]');ylabel('Beleuchtungsstärke [lux]');  

Wird das Script ausgeführt, dann erhält man einen Plot, der die Messdaten visualisiert.

Die technischen Informationen zum Sensor sind dem Datenblatt des Herstellers zu entnehmen. Hier ein paar kurze Eckdaten:

Der LTR390 besteht aus zwei Fotodioden, einer für das sichtbare Spektrum des Lichtes und einer, die im UV-Bereich empfindlich ist. Der Strom der Photodioden wird in internen ADCs digitalisiert. Eine Interne Logic steuert die ADCs und über eine I²C Schnittstelle wird die Verbindung zur Außenwelt hergestellt. Die Auflösung von ALS und auch UVS ist in 13,16,17,18,19 und 20 Bit konfigurierbar. Der Sensor Chip ist in einem 2x2mm 6pin Gehäuse untergebracht. Die Detektoröffnung hat eine Kantenlänge von 280×280 µm.

Quelle: Datenblatt LTR-390UV https://optoelectronics.liteon.com/en-global/Led/LED-Component/Detail/926
Quelle: Datenblatt LTR-390UV https://optoelectronics.liteon.com/en-global/Led/LED-Component/Detail/926

 

 

Eigenbau Nixiuhr

Das in den letzten Jahren das Thema Retro immer mehr zum Trend wurde, ist auch mir nicht entgangen. Auch der „Industrial“- und „Steam“-Style hat in vielen Haushalten Einzug gehalten.  Man(n) stellt sich wieder viele Dinge ins Regal, die die robuste Technik und das Aussehen der vergangen Jahrzehnte repräsentieren. So flackern LED-Leuchtmittel in den Räumen, die optisch den Glühbirnen der Gründerzeit nachempfunden wurden. Die Messing Lampenfassungen werden von einem mit Stoffgeflecht ummanteltem Kabel gehalten. Anstelle der Kohle- oder Wolframglühfäden in den Birnen arbeitet modernes LED-Filament. Thematisch diesem Stil entsprechend, sind beispielsweise auch mechanische Uhren und elektrische Uhren mit Leuchtanzeigen aller Art wieder gefragt. Passend zu diesem Trend, habe ich in älteren Blogbeiträgen schon über die VFD-Uhren berichtet. (VFD = VaccumFLuoreszenzDisplay) Diese Anzeigetechnologie verwendete man zum Beispiel bis Ende der 90iger Jahre noch häufig in Videorecordern, HiFi Geräten und diversen Radioweckern. Danach war die LED und LCD Technologie Standard. Heute halten überall die kleinen OLEDs Einzug. Im Rahmen des Retro Revivals werden VFD´s in Form von Einzelziffer-Anzeigeröhren zu Uhren zusammengebaut. Diese Uhren gibt es als Fertiggeräte oder auch als Bausätze (grother.de).  Da diese Anzeigeröhren mittlerweile nicht mehr hergestellt werden und nur Altbestände (new old stock) verfügbar sind, steigen auch die Preise. Aber es geht preislich noch schlimmer – eine technische Entwicklung aus den 1920er Jahren ist eine Anzeigetechnologie nach dem Prinzip der Glimmlampe.  Hierbei wird in einem, mit Edelgas gefüllten, Glaskolben eine aus Draht gebogene Ziffer als Kathode, vor einem dünnen Metallgitter als Anode angebracht. Legt man eine Spannung an, so beginnt das Edelgas entlang des als Ziffer geformten Drahtes zu glimmen. So entsteht, von außen betrachtet, der Eindruck einer leuchtenden Ziffer. In einer solchen Röhre sind meistens die Ziffern von 0-9 untergebracht und für jede Ziffer ist natürlich auch ein separater Anschluss vorhanden. Viele von den Lesern werden diese Art von Röhre sicherlich kennen. Sie nennt sich NIXIE – Anzeigeröhre (stammt von der der Bezeichnung „Numeric Indicator eXperimental No. 1“

Eine Uhr mit solchen Anzeigeröhren fehlt noch in meiner Sammlung. Also möchte ich eine solche haben. Aber kaufen ist einfach – und außerdem auch sehr teuer. So habe ich mir vorgenommen, eine Nixieuhr selber zu bauen. Begonnen hat alles mit einer langwierigen Suche nach den Röhren, denn auch für diese muss man mittlerweile schon einiges hinlegen. Und ich benötige mindestens sechs Stück, da meine Uhr auch eine Sekundenanzeige haben soll. So habe ich also im Internet auf verschiedensten Plattformen gesucht – und in der Bucht wurde ich fündig. Dort wurde ein Board bestückt mit Nixieröhren angeboten, das aus irgendeinem alten Gerät herausgebrochen wurde. Die Funktion des Boards wurde als „unbekannt“ angegeben – dafür war es sehr günstig. Der Verkäufer hatte zwei davon. Also riskierte ich es und kaufte die beiden Platinen bestückt mit je fünf Nixies.

Die Röhren waren dann auch mit einiger Vorsicht erfolgreich ausgelötet. Die Type der Röhre ist die Z574M, zu der man im Netz auch die Datenblätter findet und somit auch die Sockelbeschaltung hat.

Mit Hilfe der Beschaltung lässt sie sich dann auch einfach kontaktieren und so Ziffer für Ziffer jeder Röhre überprüfen. Die Kenndaten der 574 sind:

  • Anodenzündspannug: 150V
  • Anodenbrennspannung: 140V
  • Anodenlöschspannung: 120V
  • Max Anodenspannung: 170V
  • Kathodenstrom min: 1.5mA
  • Kathodenstrom max: 2.5mA

Mit einem geeigneten Netzgerät konnte ich die notwendigen Versorgungsspannungen für den Funktionstest schnell einstellen.

Man sieht hier, dass die Röhre bei einer Brennspannung von knapp 140V einen Strom von 2.8mA zieht. Das entspricht einer Leistung von 392mW. Wenn ich also hochrechne und alle sechs Ziffern der Uhr dauerbestromt werden, dann muss die Spannungsversorgung für die Röhren ca. 2.3W bringen.

Die Röhren funktionieren also schon mal. Jetzt kann ich mir Gedanken machen wie die Uhr aussehen soll und noch mehr, wie ich sie konstruieren will.

Die Idee ist, dass ein Mikrocontroller alle sechs Röhren ansteuern soll.  Das will ich mit 8-Bit 4094er Schieberegistern realisieren, wovon je vier Bit für eine Röhre verwendet werden. Diese vier Bit aus dem Shift-Register sollen dann über Binary Coded Decimals (also BCD) die Röhren ansteuern. Da die Röhren aber für jede Ziffer einen Anschluss haben, müssen aus den vier BCD-Leitungen zehn separate Zifferansteuerungen generiert werden. Das wird ein CD4028 erledigen. Der IC CD4028 ist ein „BCD to Dezimal Decoder“. Um die relativ hohen Spannungen der Nixies zu schalten, wird der BCD-Dezimal Decoder einen geeigneten Transistor ansteuern. Hier wird der MPSA42 seinen Dienst verrichten. Das ist ein NPN Bipolar Transistor mit einer Kollektor-Emitter Spannungsfestigkeit von 300VDC bei einem maximalen Kollektorstrom von 500mA.  Um die Röhren möglichst flexibel einsetzen zu können, habe ich mir ausgedacht, für jede Röhre eine eigene Platine zu gestalten. Diese einzelnen Anzeigeplatinen sollen dann auf eine Hauptpatine gesteckt werden. So kann man, sollte ein Digit einmal defekt sein, das betreffende Board einfach herausziehen und es reparieren. Dann muss nicht am Mainboard herum gelötet werden.

Am Mainboard soll der Microcontroller Platz finden. Auch die Nieder- und Hochspannungsversorgung und die Schieberegister sollen am Mainboard untergebracht werden. Die Display-Platinen tragen lediglich die Nixieröhre samt deren Treibertransistoren und den BCD-Dezimal Decoder. Mittels Pfostensteckverbindern sollen sie einfach in das Mainboard einsteckbar sein. Um diese Formulierungen ein wenig einfacher darzustellen habe ich diese Skizze angefertigt:

Auf Basis dieser Idee begann ich nun, die Schaltpläne zu zeichnen. Mit dem Displayboard, auf dem sich die Röhre befindet fing es also an. Der Schaltungsaufbau ist sehr einfach. Über zwei gegenüber liegende Pfostensteckverbinder sollte das Board auf dem Mainboard einen stabilen Halt bekommen. Einer der Steckverbinder versorgt den BCD-Dezimaldekoder (CD4028N) mit den vier Dateneingängen und der 5V Versorgungsspannung für die Logik. Auf der anderen Seite des Boards wird die „Hochspannung“ für die Röhre bereitgestellt.

Daraus konnte ich dann einfach ein Layout erstellen und dieses dann als Prototyp als Platine herstellen.

Nach dem Ätzen und Bestücken der ersten Platine und fünf Weiteren war der erste Schritt der Nixieuhr getan:

Um den ersten Teil des Machwerks zu testen, hatte ich an meiner Arbeitsstelle ein DEB100 Digital-Experimentierboard zur Verfügung. Das folgende Kurzvideo zeigt das Testergebnis:

Nachdem dann alle sechs Boards bestückt und getestet waren, hatte ich mich mit der Planung des Mainboards beschäftigt. Zu Beginn stand natürlich wieder die Erstellung eines Schaltplanes. Aus einer externen einer 12VDC Quelle, die idealer Weise ein simples Steckernetzteil sein sollte, mussten die Versorgungsspannungen generiert werden. Zum einen benötigte ich eine 5VDC Versorgung für den Microcontroller, die Schieberegister und die BCD Decoder und zum anderen eine „Hochspannung“ von 140VDC für die Nixieröhren. Die 5V waren schnell erledigt – hier sollte ein 7805 Längsregler seinen Dienst verrichten. Da die Stromaufnahme der digitalen Komponenten relativ gering ist, bedurfte es hier keiner aufwendigen Maßnahmen. Die 7V Differenz am 7805 bei den paar Milliampere packte er ohne großartige Verlustleistungswärmeabgabe. Für die Erzeugung der 140V bastelte ich einen Step-Up – Konverter mit einem MC34062 (Inverting Regulator – Buck, Boost, Switching) Controller, der über einen FET eine 220uH Induktivität schaltet. Über einen Spannungsteiler mit Trimm Poti am Ausgang lässt sich eine Spannungsrückmeldung an den Komparator Ausgang des Controllers senden und somit die Ausgangsspannung einstellen. Als Microcontroller nehme ich für die meisten meiner Projekte (aufgrund des Lagerstandes 🙂 ) immer Atmega328 und Ähnliche. So auch hier. Das Ergebnis ist folgender Schaltplan:

Daraus habe ich wieder ein Layout gebastelt und wieder ein Board geätzt und bestückt. Allerdings wurde dieses Prototypen Testboard nur eine Version mit vier Digits. Der Grund war auch, dass ich keine größere Roh-Platine zur Verfügung hatte 🙂

Daraus habe ich wieder ein Layout gebastelt und wieder ein Board geätzt und bestückt. Allerdings wurde dieses Prototypen Testboard nur eine Version mit vier Digits. Der Grund war auch, dass ich keine größere Roh-Platine zur Verfügung hatte 🙂

Nach diversen erfolgreichen Tests mit dem Prototypen Board, bestellte ich mir beim Platinen Herstellers meines Vertrauens professionell gefertigte Boards. Nach dem Bestücken derselben erstellte ich mir dann ein Testprogramm das alle Digits ansteuern konnte. Ein kurzes Testvideo ist unten verlinkt:

Wie die Uhr dann mit den „schön“ gefertigten Boards aussieht, zeigen die folgenden Fotos. Um das ganze Werk noch etwas nostalgischer zu gestalten, hatte ich die Idee die Boards auf einer gefrästen Holzplatte zu montieren. (Danke an Gebhard für die Holzarbeiten). Um die Uhrenelektronik auch dauerhaft staubfrei zu halten, ließ ich mir eine transparente Plexiglashaube anfertigen.

Skizze für die Arcylglashaube

Die Software habe ich wie so oft mit der Arduino IDE gebastelt. Zum Flashen des Microcontrollers verwende ich den AVRISP mkII Programmer.  Wenn jemand am Code interessiert sein sollte kann ich ihn hier im Blog auch posten.

 

Ich suche EINE Taste vom Commodore Plus4

Der Titel sagt ja schon alles. Ich bin auf der Suche nach der RUN/STOP Taste für einen Commodore Plus 4 Computer. Das Modell, das ich herrichte ist bis auf eben diese fehlende Taste schon fertig. Ich habe in der Bucht und auf Flohmärkten gesucht, aber niemand kann mir da helfen, bzw. man bekommt ganze Tastaturen, aber leider zu einem unfairen Preis. Falls also irgendjemand einen Plus4 zum Schlachten herumstehen hat und mir mit der Taste zu einem fairen Preis helfen kann – das würde mich sehr freuen.

Sprachausgabe in den 80igern – Speak and Spell

Viele der Leser dieses Beitrages kennen vielleicht den Hollywood Film E.T. (The Extra-Terrestrial), in unseren Regionen in der übersetzten Version: „E.T. – Der Außerirdische“.

Zumindest die älteren unter den Lesern werden ihn kennen. Der Film lief 1982 in unseren Kinos und ich hatte damals auch die Möglichkeit, ihn mir anzusehen. Als Kind tauchte man (zumindest ich) immer in die Geschichten ein und lebte darin mit. Kurz erzählt handelt die Geschichte von einem kleinen Außerirdischen, der versehentlich auf der Erde zurückgelassen wurde, während seine Artgenossen auf der Flucht vor Regierungsagenten mit ihrem Raumschiff davonflogen. So versteckte sich der kleine E.T. in einem Schuppen, in dem er von Kindern des Ortes gefunden wurde. Die freundeten sich mit ihm an und halfen ihm dabei mit dem Raumschiff Kontakt aufzunehmen. Dazu konstruierte er aus Dingen des alltäglichen Lebens eine Art Funkanlage. Die Antenne bestand beispielsweise aus einem Regenschirm, einem Plattenspieler mit einem Sägeblatt einer Kreissäge, einem Kleiderbügel mit Speisegabel und einem Kinderspielzeug, das synthetische Stimmen erzeugen konnte. Dieses Spielzeug nennt sich „Speak & Spell“ als „Spreche und Buchstabiere“ und wurde von der Firma Texas Instruments entwickelt.

Der Speak & Spell ist ein Handheld Kindercomputer von TI (Texas Instruments), der aus einer Tastatur, einem Display und einem kleinen Lautsprecher besteht. Das Herzstück des Gerätes ist ein Sprachsynthesizer IC, der es ermöglicht, eine künstliche Stimme zu erzeugen. Per LPC (linear predictive coding – also linearer Vorhersagecodierung) wird eine, der menschlichen Sprechstimme ähnlichen Audioausgabe erreicht. Mit einem internen Rom und optional auch externen Rom-Modulen, können verschiedene Aufgaben (Buchstabieren, Wortratespiele etc.) realisiert werden. Die Auswahl und Eingabe erfolgen über eine Tastatur.

Der Speak & Spell Kindercomputer stammte ursprünglich aus einer dreiteiligen Spielzeugserie mit „sprechenden“ Computern. Es gab noch ein Speak & Math und ein Speak & Read. Man findet gelegentlich auf Videoplattformen im Netz noch Sammler, die ihre Geräte präsentieren. Verkauft wurden die Geräte anfangs in den USA, Großbritannien und Japan. Je nach Auslieferungsland gab es auch noch unterschiedliche ROM-Module mit Minispielen, wie Mystery Word, Letter oder Secret Code. Gedacht waren diese Computer für Kinder ab dem 7. Lebensjahr. Später wurden weitere Sprachbibliotheken in sieben Sprachvariationen veröffentlicht. So soll es unter andren auch ein Modul für die deutsche Sprache gegeben haben.

Der erste Speak & Spell wurde auf der Consumer Electronics Show 1978 als einer der ersten tragbaren Geräte mit visuellem Display und steckbaren ROM Spielekassetten vorgestellt. Dieses Modell wurde auch durch den Einsatz im Film E.T. bekannt. Es unterscheidet sich von späteren Gerätegenerationen optisch lediglich durch die Tastatur, die in der Urversion noch aus „richtigen“ Tasten bestand. In seinem inneren arbeitet der TMC0280 Synthesizer Chip. Dieser wurde einem kleinen Team von Technikern unter Paul Breedlove † (1941-2021), Ingenieur bei Texas Instruments in den späten 1970er Jahren entwickelt. Diese Entwicklung begann 1976 als Ergebnis der TI-Forschung zur Sprachsynthese.

Zu Anfang der 1980iger Jahre kam eine überarbeitete Version des Gerätes auf den Markt. Hier hat man die Tasten durch eine Folientastatur ersetzt. Auch eine Speak & Spell Compact Version hat man veröffentlicht. Bei dieser hat man auf das optische VFD Display verzichtet und die Größe halbiert. Ende der Achtziger Jahre gab es erneut eine Auflage. Diesmal wurde das VFD durch ein LC-Display ersetzt und die Tastatur bekam ein QWERTY Layout. Im Rahmen der Retrowelle (so meine Vermutung) hat die Firma „Basic Fun“ 2019 den Klassik Speak&Spell wieder auf den Markt gebracht. Er ähnelt vom Aussehen der 80iger Version, ist jedoch technisch auf dem aktuellen Stand (so wird alles in einem kleinen Chip generiert der direkt auf die „Miniplatine“ gebondet wurde. Auch die Anschlüsse zur Außenwelt gibt es bei der Version nicht mehr.

Auf dem Mainboard der vor 1980 verkauften Version sind folgende Chips verbaut:

  • TMC0271 (Microcontroller und VF-Display Controller für 9 Digits zu je 14 Segmenten)
  • TMC0530 (oder TMC0351, TMC0352) 128kBit ROM
  • TMC0281 (Sprachsynthesizer IC der TMC0280 Serie

Das Modell, das sich in meiner Sammlung befindet, ist eine der nach 1980 verkauften Versionen. Hier sind folgende IC´s verbaut:

  • TMC0271 ( Microcontroller und VF-Display Controller für 9 Digits zu je 14 Segmenten)
  • TMC0281 (Sprachsynthesizer IC der TMC0280 Serie)
  • CD2304 und CD2303 (ROM)

Das VF-Display hat acht Digits zu je 14 Segmenten. Die Versorgungsspannung von 6V wird aus vier in Reihe geschalteten C-Zellen gewonnen. Die 9V und 21V für die Versorgung von VFD und Microcontroller macht ein diskret aufgebauter DC/DC Converter, der sich auf einer eigenen Platine befindet. Die Folientastatur ist in einer 13poligen Flexiprint-Buchse angesteckt. Für die Wiedergabe des Tons gibt es einen kleinen Lautsprecher oder auch die Möglichkeit, über einen 3.5mm Klinkenstecker einen Kopfhörer anzuschließen. Der Ton wird direkt aus dem Synthesizer Chip gewonnen. Um die Ausgangsimpedanz an den Lautsprecher anzupassen hat man einen kleinen Audio-Übertrager direkt neben der Klinkenbuchse verbaut. Eine weitere Buchse dient als externe Spannungszuführung. Ein Trimmpotentiometer ändert die Wiedergabegeschwindigkeit/Tonhöhe der Audioausgabe.

Der TMC0280, später TMS5100 genannt ist der Single Chip Sprachsynthesizer, der ein LPC Modell 10. Ordnung unter Verwendung von pipelined elektronischer DSP-Logik verwendete.  Die Phonem Daten für die gesprochenen Wörter werden im PMOS-ROMs gespeichert. Die enorme Kapazität von 128 Kbit war damals das größte noch bezahlbare ROM. Über eine Aussparung im Batteriefach kann man zusätzliche Speichermodulkassetten einstecken. Der Inhalt der Speichermodule ist über eine Taste am auf der Tastatur anwählbar. Die Datenrate der Audioausgabe beträgt etwas weniger als 1kBit pro Sekunde.

DC/DC Converter Platine