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.
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
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
https://youtube.com/shorts/J2u_XakEdE4?feature=share 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.
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.
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 manuelle Bewegen einrasten
das Klappverhalten ist Wetterabhängig
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...
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 2x4 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:
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:
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.
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 280x280 µm.
