Solaruhr - Prototyp

Eine Uhr mit LED Display, nur per Solarzelle betrieben und somit ohne Strom vom Netz auskommen, geht das? Bevor nun ein Nachfolger für die DCF77 Uhr entstehen sollte, musste ein Prototyp her. Die finale Version soll eine 35x15 LED Pixel Matrix nutzen. Der Prototyp nutzt eine kostengünstigere 28x5 LED Pixel Matrix. Und damit die Platine später nicht nutzlos im Schrank landet, sollte diese auch nach der Testphase sinnvoll nutzbar sein.

Bilder

Daten

  • ATxmega64A1 Mikrocontroller mit 32kHz Uhrenquarz (RTC)
  • 28x5 Pixel LED Anzeige, dimmbar per Software PWM
  • DCF77 Funkempfänger
  • Temperatursensor
  • Helligkeitssensor
  • Betrieb per Solarzelle mit 4V Nennspannung
  • Zwei NiMH Akkus (AAA oder AA) ermöglichen für einen durchgängigen Betrieb
  • Vier Buttons, entweder per kapazitivem Touch oder berührungslosem Infrarot Sensor realisiert
  • Lautsprecher für Wecker
  • Messen der Akkuspannung und Strom der Solarzelle
  • Komplettes Menüsystem mit sehr vielen Einstellungsmöglichkeiten
  • Optional RFM12 Funkmodul
  • Optional TSOP31238 Infrarot Empfänger
  • Optional I2C EEPROM fürs Aufzeichnen von Messdaten
  • Optional kann ein Quarz statt des internen Oszillators verwendet werden
  • Printf debugging per seriellen Leitungen oder RFM12 Funkmodul
  • Die komplette GUI ist auch ohne Hardware auf einem PC lauffähig

Fragestellungen und deren Ergebnisse

  • Welche Farbe (rot, orange, grün) soll als LED Matrix gewählt werden?
    Orange. Die in den anderen Farben (rot, grün) gekauften Module verbleiben in den Prototypen.
  • Sind die LEDs bei einer 1:16 Multiplexing hell genug?
    Ja
  • Welcher Strom pro Pixel ist erforderlich um bei Zimmerhelligkeit gut lesbar zu sein?
    400µA -> Bei einem 1:16 Multiplexing ist ein Strom von 6mA erforderlich.
  • Funktioniert die ultra low-drop - Regelung für die LED Spannung?
    Ja, aber es sind mehr Kondensatoren erforderlich.
  • Funktioniert die Helligkeitsmessung per Fototransistor?
    Ja, wenn zwischen mehreren Messbereichen gewählt werden kann.
  • Ist ein externer Quarz oder der interne Oszillator energiesparender?
    Der interne Ostzillator mit 2MHz ist sparsamer als ein 4MHz Quarz. Im normalen Betrieb wären rund 500kHz als CPU Frequzenz ausreichen.
  • Funktioniert ein kapazitiver Touch?
    Ja, aber nicht berührungslos durch eine Plastikabdeckung.
  • Lässt sich ein PIR Sensor einfach verwenden?
    Nein.
  • Welche Probleme treten bei einem ATxmega auf?
    Der A/D Wandler hat Einschränkungen die beim Schaltungsdesign beachtet werden müssen. Für die Synchronisation zwischen RTC Timer und CPU vergehen mehr Zyklen als laut Datenblatt zu erwarten sind.
  • Wie viel Energie benötigt die Uhr im Schnitt?
    10mA bei 2,4V reichen bei normaler Zimmerhelligkeit für das Anzeigen der Zeit ohne Sekundenanzeige. Im Dunkeln sind 1mA für Anzeige und Controller genug. Im Sommer werden rund 100mAh/Tag benötigt, dies ergibt einen Durchschnittsverbrauch von 4,1mA.
  • Reicht eine 500mA Solarzelle zusammen mit zwei NiMH AAA Akkus als Puffer?
    Von April bis September funktioniert die Versorgung mit einer 500mA Solarzelle auf einer nach Nord-Osten ausgerichteten Fensterbank hervorragend. Im Winter ist entweder eine bessere Ausrichtung der Solarzelle, eine leistungsfähigere Solarzelle oder ein Abschalten der Uhr während des größten Teils des Tages erforderlich. Ohne nachladen ermöglichen die Akkus einen Betrieb für rund sechs Tage.
  • Halten die NiMH Akkus Jahrelang tägliches teilweises laden und entladen aus?
    Seit 15Monaten funktioniert es. Die Akkus waren zuvor schon einige Jahre alt. Alles weitere wird die Zeit zeigen.
  • Wie schwierig ist es TQFP Bauteile mit 0,5mm Pinabstand zu löten?
    Schwierig aber machbar. Ohne Mikroskop ist ein auffinden von Lötbrücken nicht möglich. Ist der Chip beim Festlöten verrutscht, ist eine Korrektur nur mit entsprechend professioneller Ausrüstung möglich.
  • Wie genau läuft der Uhrenquarz ohne DCF77 Synchronisation?
    Ein Prototyp geht täglich 6Sekunden vor. Bei dem zweiten sind es 12Sekunden. Aus der Quarztoleranz ergibt sich eine erlaubte Abweichung von +-20Sekunden pro Tag.

Software und Schaltplan

Wie immer, Verwendung auf eigenes Risiko und ohne Gewähr.
Für die Versionsverwaltung wurde Github verwendet: https://github.com/Solartraveler/solarclock

Messwerte

Der Plot der Daten zeigt den Verbrauch im Laufe eines Jahres. Diese korreliert mit der Helligkeit und des erreichbaren Ladestroms. Insbesondere in dunklen Herbsttagen liefert die verwendete Solarzelle nicht ausreichend Energie. Im Sommer ist sie hingegen überdimensioniert und der Akku bereits Mittags wieder vollständig geladen. Der Ladezustand kann generell nur geschätzt werden. Hierfür wird der Ladestrom gemessen und der eigene Verbrauch in Abhängigkeit der CPU Last, aktivierter Peripherie, Anzahl der aktiven LEDs und deren Helligkeit errechnet. Über die Zeit entsteht so ein unvermeidlicher Integrationsfehler. Erst wenn die Akkuspanung eindeutig einem leeren Akku zuzuordnen ist, kann der errechnete Akkustand dem tatsächlichen Wert angepasst werden. Die Daten zeigen, dass im Sommer bei großen Lichtmengen der Ladestand unterschätzt wird, sonst würde der Ladevorgang stets zu früh beendet werden und der Akku wäre irgendwann leer. Im Winter wird der Ladestand hingegen überschätzt, dies ist an dem plötzlichen leeren Akku während der Mikrocontroller noch einen halb vollen Akku errechnet hat, erkennbar.

Verbesserungen

Bei dem Prototyp wurden viele neue Dinge ausprobiert und dass vieles nicht wie geplant funktionieren würde, war von Anfang an zu erwarten. Eine Liste aller Hardwarefehler gibt es hier.
All diese Erkentnnisse werden irgendwann für eine weitere Solaruhr genutzt werden.