Solarwecker mit DCF77 sowie Temperatursensor
Von Matthias Nahr
Motivation
Der Wecker gehört zu den bedeutendsten Geräten im Alltag. Seine Qualität steht und fällt mit seiner zentralen Funktion: Schafft er es, mich am nächsten Morgen zu wecken? Manch ein käuflich erworbenes Gerät ist:
- zu leise,
- zu schnell oder versehentlich abschaltbar (keine ordentliche „snooze“-Funktionalität),
- vom Stromnetz abhängig,
- von Batterien betrieben, die im falschen Moment versagen können
- zu ungenau, zumindest nach ein paar Monaten.
Die zentrale Motivation für diesen Wecker ist allerdings: Als ehemals begeisterter Bastler hatte ich nach jahrelanger Abstinenz mal wieder richtig Lust auf ein Elektronik-Projekt :-) Inzwischen ist der Wecker ohne Ausfall seit 6 Monaten in Betrieb und eine Dokumentation ist überfällig. Ich gehe nicht auf alle Details ein, sie soll nur einen Überblick bieten. Im Detail ist ein Blick in den Sourcecode oder Schaltplan die bessere Auskunft. Na dann mal ran'...
Features
Okay, was kann der Wecker?
- wecken :-) mittels Piezo-Summer und einfacher, schöner 4-Ton Melodie per PWM
- Anzeige von sekundengenauer Uhrzeit, synchronisiert mittels des DCF77 Signals ("Funkwecker")
- Datumsanzeige
- Anzeige der Tage seit letzter erfolgreicher DCF77-Synchronisation
- Anzeige der Raumtemperatur mit hoher Genauigkeit
- Eingabe komfortabel mittels Drehgeber und LED-Taster
- drei programmierbare Weckzeiten - schnell einstellbar am Abend ohne minutenlang Morse-Codes zu drücken
- kein 230V Stromnetz notwendig
- kein Batteriewechsel notwendig
- die 2 fetten Solarmodule (5V, 150mA) laden die Buffer NiMH-Akkus auch bei geringem Lichteinfall im Schlafzimmer, auch in der Wintersaison ausreichend
- verschiedene Stromsparmechanismen
- bei Dunkelheit und Tastenaktivität -> rote LCD Hintergrundbeleuchtung
- Spannungsmessung des Akku-Packs
- Spannungsmessung der Solarzellen
- ... ein paar Kleinigkeiten, die nicht der Rede wert sind
Bilder
Schaltung
Display
Technische Details
Der Aufbau ist mit einer kleinen Lochraster-Platine realisiert, da die Beschaltung noch recht übersichtlich ist. Die Verbindungen/Stecker etc. kommen aus der Restekiste. Das Gehäuse ist aus preiswertem Pappelholz mit der Laubsäge bearbeitet, verleimt und mit Leinöl versiegelt.
Stromversorgung
Gespeist wird die Schaltung von 3xAAA NiMH Zellen mit je ca. 750mAh, welche eine sehr geringe Selbstentladung besitzen.
- Die Nennspannung liegt bei 3x1.2V = 3.6V.
- Entladen 3x1.0V = 3.0V.
- Vollgeladen 3x1.5V = 4.5V.
Die Hauptschaltung des Weckers würde theoretisch bis etwa 1.8V gut funktionieren, allerdings ist spätestens ab 2.8V das LCD nicht mehr funktionsfähig, weshalb 3 Zellen in Serie geschaltet werden müssen, um die Versorgung mit ca. 3V sicher zu stellen. Für eine stabile Spannungsversorgung der gesamten Schaltung dient der Lowdrop-Längsregler MCP1702-3002, welcher zudem durch sehr geringe Verluste auffällt. Die gewählten 3.0V helfen gegenüber den üblichen 3.3V die Energiebilanz etwas zu verbessern.
Eine zentrale Rolle spielt die Unabhängigkeit des Weckers von externer Energieeinspeisung - vom Sonnenlicht mal abgesehen. Die beiden in Serie geschalteten Solarzellen mit spezifizierten 2x5V = 10V und 150mA liefern diese natürlich nur unter direktem Sonnenlicht. Im Wohnbereich sind Werte um 1-2 Promille dieser Angaben realistisch - dies bestätigen auch meine Messungen: An einem durchschnittlichem Wintertag bricht selbst die Leerlauf-Zellspannung stark ein und es können nur geringe Ströme vom ca. 160-300uA bei insgesamt 4,5V fließen. Diese elektrische Leistung wird direkt abgegriffen, um die 3 NiMH-Zellen zu laden. Bei diesen geringen Strömen ist keine besondere Ladeschaltung notwendig. Selbst bei unrealistisch hoher Sonneneinstrahlung werden die Akkus auf diese Weise nicht beschädigt, da bis ca. 100mA als "Erhaltungsladung" akzeptabel sind.
(!) Das Tolle bei der Dimensionierung der Solarzellen in Verbindung mit den Akkus bezogen auf den Lichteinfall in unserem Schlafzimmer: Die Ladung regelt sich quasi automatisch bei ca. 3.8V ein, was der Lebensdauer der Akkuzellen sehr zugute kommt. Ist die Spannung des Akkupacks höher, fällt der Ladestrom der Solarzellen ab. Bei niedriger Spannung des Akkupacks genügt hingegen sehr wenig Licht um einen Ladestrom zu liefern.
Stromsparmechanismen
Der Mikrocontroller von Atmel bietet verschiedene Möglichkeiten, um seinen Stromverbrauch zu minimieren. So ist er beispielweise programmiert, die meiste Zeit im Sleep-Mode zu verbringen. Nur selten wird er per Interrupt geweckt, um Benutzereingaben zu bearbeiten oder Tasks des Scheduler auszuführen. Eine RTC dient dazu, den Controller viermal in der Sekunde zu wecken und etwaige Tasks abzuarbeiten.
Es sind 3 Fälle zu betrachten:
- Nacht-Modus (ca. 8uA Stromverbrauch)
Alle 8 Sekunden überprüft der Controller, ob das Umgebungslicht hell genug ist, um das LCD-Display ablesen zu können. Als Lichtdetektor dienen hier die Solarzellen bzw. die per AD gemessene Spannung am Widerstand R2/R4. Ist eine gewisse Schwelle unterschritten, so wird einer der größten Verbraucher (LCD) abgeschaltet. Eine regelmäßige Temperaturmessung findet ebenfalls nicht statt. Der Nachtbetrieb kann durch beliebigen Tastendruck jederzeit für einige Sekunden unterbrochen werden. In diesem Fall leuchtet das Display durch die gedimmte (PWM) Backlight LED.
- Tag-Modus (ca. 155uA Stromverbrauch)
Das LCD ist eingeschaltet und verursacht den größten Strombedarf. Der Temperatursensor wird lediglich alle 8 Sekunden eingeschaltet und nach der ersten Messung wieder deaktiviert - der Strombedarf ist für diesen in Summe zu vernachlässigen.
- Aktivität DCF/Alarm/LED-Backlight (bis ca. max. 5mA Stromverbrauch)
Egal ob der Alarm ertönt, auf das DCF77-Signal synchronisiert wird oder das LED-Backlight nachts bei Aktivität dazugeschaltet wird - es werden bis zu 5mA fließen. In Summe ist der Einfluss auf den Gesamtenergiebedarf allerdings recht gering und muss nicht weiter betrachtet werden.
Controller
Als Basis dient der 8Bit-Mikrocontroller Atmel ATMEGA328P-PU, welcher mit insgesamt 28 Pins bzw. drei I/O-Ports gerade so genügend Anschlüsse bietet. Die komplette Software passt bequem dort hinein:
- Program Memory Usage : 7802 bytes 23,8 % Full
- Data Memory Usage : 723 bytes 35,3 % Full
RTC
Mit einem externen Standard-Uhrenquarz (32kHz) sowie dem Timer2 der ATmega-Serie lässt sich sehr einfach eine RealTimeClock aufbauen, die als Taktgeber für die Uhrzeit verwendet werden kann. Der Vorteil zum Ringoszillator des Controllers liegt in der deutlich stabileren Frequenz sowie des niedrigen Taktes, der dabei hilft, richtig Strom zu sparen. Als Alternative könnte ein noch genaueres externes RTC-Modul verwendet werden, doch angesichts der DCF77-Synchronisation ist dies definitiv unnötig. Die Ganglaufzeit der Uhr variiert natürlich mit der Frequenzgenauigkeit des Quarzes und muss durch Software kalibriert werden. Auch wenn dies dank des DCF77-Zeitsignals überflüssig erscheint, so wird die Uhrzeit einmal täglich automatisch angepasst: Bei meinem verbauten Quarz muss ich sie täglich um fast eine Sekunde zurückstellen ((126/128) sec.)
Temperatur Sensor TSic306
Der Sensor ist mehr eine Spielerei und technische Herausforderung. Eine Herausforderung insofern, als dass er mittels eines Ein-Draht Protokolls (ZACwire) ausgelesen werden muss. Kritisch ist hierbei die Synchronisation der Datenbits. Ein permanentes Polling der Information wäre problemlos möglich, erfordert jedoch eine ständige Aktivität des Controllers, was gegen das Stromsparprinzip verstößt. Als Alternative bietet sich ein flankengesteuerter Datenempfang per Interrupt an, der nur aktiviert wird, sobald der Sensor seine Daten sendet. In diesem Fall ist allerdings die Auswertung des Datums am Port innerhalb der ISR dermaßen Zeitkritisch, dass die standardmäßige CPU-Frequenz von 1 Mhz nicht genügt, um das ZACwire-Protokoll zu verarbeiteten. Ein Zurücksetzen des Atmel CKDIV8 FUSE-Registers auf den Teiler Faktor 1x schafft hier problemlos Abhilfe als sodann die 8 MHz des Ringoszillator direkt abgegriffen werden.
LCD Display DOG-M 1x8
Ein tolles DOT-Matrix-LCD, welches auch bei 3V VDD hervorragend funktioniert, verhältnismäßig wenig Strom benötigt und mittels SPI ansprechbar ist. Gerade letztere Eigenschaft hilft dabei, wertvolle I/O-Ports zu sparen.
LCD LED Backlight red
Falls das Umgebungslicht eine gewisse Schwelle unterschreitet sowie eine Benutzereingabe erfolgt, wird das LCD auch bei Dunkelheit lesbar :-)
DCF77-Empfangsmodul
Erst war ich enttäuscht über die Empfangsqualität des Empfängers DCF-2 von ELV, da eine Synchronisation nur mit exakter Ausrichtung nach Frankfurt möglich war. Später war jedoch klar, dass mein Versuchsaufbau zu viele Störquellen aufwies. Im reinen Batteriebetrieb ist der Winkel der Ferritantenne zum Sender fast nicht mehr entscheidend. Das Modul bietet keine echte Auswertung des DCF-Signals, ob also eine "1" oder "0" übertragen worden ist, muss der Controller selbst entscheiden bzw. messen. Die Implementierung ist letztlich recht einfach: Die Flanken des DCF77-Moduls werden durch einen externen Interrupt im Controller ausgewertet bzw. die Abstände zwischen den Flanken mit dem 32kHz Timer2 gemessen. Nach einer Minute liegt das komplette Datenpaket vor und muss auf Fehler geprüft werden. Es ist wichtig zu wissen, dass der vorgesehene CRC-Test NICHT hinreichend ist, um Übertragungsfehler zu detektieren - zumindest nicht, wenn man an nächsten Morgen pünktlich geweckt werden möchte! Daher verwendet der Wecker das DCF77 Datenpaket erst, wenn es nur eine minimale Zeit-Abweichung zur aktuellen Uhrzeit/Datum besitzt oder insgesamt dreimal hintereinander korrekt ausgewertet wurde. Das DCF-Signal unterliegt vielen Störungen, von daher ist eine saubere Fehlerdetektion von zentraler Bedeutung. Im Zweifel sollte die Synchronisation beendet werden. Falls nach 10 Minuten keine Synchronisation erfolgt, bricht der Wecker diese ab, reportet dies und läuft ansonsten ungestört per RTC weiter. Die Synchronisation wird Nachts durchgeführt, um sicherzustellen, dass möglichst wenig Störquellen aktiv sind.
Drehgeber
Ein Standard-Drehgeber von ALPS. Er wird per externem I/O Interrupt ausgewertet, was zwar nicht die ideale, aber zumindest die sparsamste Variante ist. So kommt es schon einmal vor, dass eine Drehraster-Abtastung „verschluckt“ wird. Ein ständiges Polling durch die CPU führt dagegen zu einer sauberen Auswertung, aber leider auch zu höherem Stromverbrauch und wird daher nicht eingesetzt.
Wecksignal
Der Piezo-Summer Ekulit RMP-14P/HT leistet beim derzeitigem Setup im Bereich der Resonanzfrequenz etwa 70dbA in 10cm Abstand, was genügt um mich zu wecken und die Nachbarn in Ruhe lässt.
Software
Die Firmware ist in C geschrieben. Sie ist weitesgehend modular aufgebaut, um in Teilen auch für andere Projekte wiederverwertet werden zu können. Aufgrund der vielen verschiedenen Interrupt-Quellen muss der Controller im Zweifel viele ISRs bedienen können, daher sind diese sehr kurz gehalten. Für die Ausführung von längeren Aufgaben dient ein Task-Handler zur seriellen Abarbeitung gesammelter Aufgaben wie z.B. Display-Updates. Weiterhin ist ein Task-Scheduler implementiert, der sich um die Ausführung von seltenen Ereignissen kümmert, wie Beispielsweise die Weckfunktion, die Temperaturmessung oder die tägliche DCF77-Synchronisation.
Entwicklungsumgebung
Zum Debuggen und Proggen: Der AVR Dragon sowie Atmel Studio 6
Ausblick
Bisher bin ich sehr zufrieden. Die Software bzw. das Menü ist flott zu bedienen, der Wecker weckt zuverlässig und die Spannung des Akkupacks liegt seit Monaten sehr stabil bei ca. 3.8V. Klar, ein schönes PCB-Layout und ein optimales Gehäuse wären schon lecker, aber es würde der Bastel-Look fehlen.
Ach ja, sollten wir mal umziehen, so darf das Schlafzimmer nicht ohne Fenster sein ;-)
Downloads
Todo
Ein paar Links oder eine BOM müssten hier nochmal irgendwann rein.