FireFly/Glühwürmchen Projekt

Dieses Projekt basiert auf einer Idee von
http://www.instructables.com/id/Jar-of-Fireflies/ Gemeinsamkeiten sind
die Idee und der ATtiny45V. Unterschied ist das bei diesem Projekt 12
LEDs angesteuert werden, die Spannungsversorgung aus einem 1.2V NiMH
Akku und einem Stepup Wandler besteht. Der Akku wird durch ein
Solarpanel aus einer Gartenlampe geladen. Statt einer Shottkydiode für
das Solarpanel wird eine quasi "ideale Diode" mit geringstem
Eigenstombedarf benutzt (D1, Q3, Q1, T1, 10mV Spannungsabfall). Als
Stepupwandler wird ein MAX1724
(http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3024) benutzt.
Die Software auf dem AVR besteht aus meinem AVRootloader, ein 1-Wire
Bootloader der 512Bytes benötigt und im Ordner \FireFly\Bootloader\ zu
finden ist. Das eigentliche Projekt befindet sich im Ordner
\FireFly\FireFly\AVR.

Die 12 LEDs werden an 4 Pins des AVRs angechlossen. Man lötet jeweils 2
grüne LEDs (SMD0603 Lowcurrent in meinem Fall) antiparallel an zwei
möglichst grünen Kupferlitzen an (alternativ mit grünem Edding
anpinseln). Davon benötigen wir 6 solcher Litzen um auf 12 einzelne LEDs
zu kommen. Diese 6 Litzen werden so angeschlossen: PB0-PB1, PB0-PB2,
PB0-PB5, PB1-PB2, PB1-PB5, PB2-PB5.
Das Solarpanel kommt mit + an den + Pol des Akkus. Als Akku wurde ein
1.2V AAA NiMH benutzt besser wäre aber einer der neueren NiMHLi Akkus
von Sanyo da diese einen weitaus geringeren Innenwiderstand haben und
somit eine wesentlich geringere Selbstentladung. Die meiste Zeit
befindet sich der AVR im Power Down Modus und bei meinen Messungen
verbraucht die Schaltung dann < 20µA.

Im Ordner \FireFly\HEX\ liegen das AVRootloader.hex File für den
Bootloader und das FireFly.hex File für die eigentliche Software.

Die FireFly Software benutzt eine optimierte PWM Ansteuerng der 12 LEDs.
Sie läuft mit einer PWM pro LED mit 122Hz bei 256 Schritten Dutycycle.
Dabei verbraucht sie minimal nur 0.85% und maximal nur 1.46% an
Rechenzeit der MCU um alle 12 LEDs anzusteuern. Die PWM benutzt den
Overflow und Compare Match Interrupt des Timer0. Die 12 Glühwürmchen
leuchten in 32 verschiedenen Blinkmustern=Waves, dh. die PWM benutzt
eine Wavetable zur Ansteuerung der Glühwürmchen PWMs. Jede dieser Wave
hat eine "Energiebilanz" und die 12 Firelies haben ebenfalls einen Wert
für die Energiebilanz des Glühwürchens, Member ->Hungry. Ein Firefly
beginnt zu leuchten wenn der Wert in ->Hungry == 0 ist. Dabei wird per
Zufall aus den 32 Waves eines ausgewählt und als neues Blinkmuster dem
FireFly zugeordnet. Die Energiebilanz dieser Wave wird auf die
Energiebilanz des Glühwürmchens gebucht, dh. der Wert Hungry wird um den
Energiewert der Wave inkrementiert. Jeder Energiepunkt stellt dabei eine
Wartezeit des WDTs von 16ms dar. Je länger und intensiver das
Glühwürmchen mit dem aktuellen Wave leuchtet desto länger dauert es also
bis es erneut leuchten wird. Zusätzlich werden alle Nachbarglühwürmchen
jeweils um die Hälfte von der Hälfte von der Hälfte usw. mit dem
Energiewert belastet. Dh. das benachbarte Glühwürmchen ebenfalls in
ihrem Leuchtinterval durch das aktuell leuchtende Würmchen belastet
werden. Je weiter entfernt also ein Glühwürmchen zum aktuellen ist desto
weniger Energiepunkte bekommt es abgezogen. Das Auswählen der Wave ist
der einzige Punkt bei dem Zufall im Spiel ist. Die minimale Zeitbasis
des WDT von 16ms ist also gleichzusetzen mit dem Füttern der
Glühwürmchen um 1 Energiepunkt. Damit bestimmen die Werte in
FireFly->Hungry also direkt die Gesamtzeit des WDTs in der der AVR im
Power Down Modus warten muß bis zum nächsten Leuchten eines/mehrer
Glühwürmchens.

Für das globale Timing wird der Watchdog Timer benutzt um auch längere
Zeit im Power Down Modus der MCU verbleiben zu können. Über diesen wird
auch das Messen der Battery- und Solarpanelspannnung erledigt. Aktuell
ca. alle 6 Minuten wird die Akku/Solarpanel Spannung gemessen. Wenn die
Akkuspannung >= 0.9 Volt ist kann ein Leuchten stattfinden. Fällt diese
Spannung unter 0.9 Volt so passiert nichts da der Akkku erstmal durch
das Solarpanel aufgeladen werden muß. Danach wird die Spannung am
Solarpanel gemessen. Übersteigt diese die Akkuspannung so ist es Nacht
und die Glühwürmchen können beginnnen zu leuchten. In der Nacht liefert
das Solarpanel keine Spannung und verhält sich wie ein Ohmscher
Widerstand. Der Minuspol ist durch die aktive Diode (MOSFET) von GND
getrennt da ja die Solarpanelspannung kleiner der Akkuspanung ist
(minimale Differenz 0mV und Spannungsabfall der idealen Diode ist
10mV!). Demzufolge wird in der Nacht am Minuspol des Solarpanels quasi
die Akkuspanung gemessen da der Pluspol des Akkus und Solarpanels
zusammengeschaltet sind.

Die Ausnutzung der Power Down Zeiten ist maximal. Dh. die Wartezeiten
bis das nächste Glühwürmchen leuchten soll verbringt der AVR im Power
Down Modus. Tagsüber ist der AVR also immer im Power Down Modus und
wacht ca. alle 6 Minuten auf um 3 ADC Messungen in ~280µs durchzuführen.
Durchschnittlich alle 8 Sekunden wacht der AVR für ca. 10 µs auf. Wenn
Nachts keines der Glühwürmchen leuchtet gelten die selben Bedingungen,
ansonsten wenn es leuchtet wird bei meiner Schaltung ca. 1-20mA
verbraucht je nach Anzahl der Glühwürmchen die gleichzeitig leuchten und
wie lang sie mit welcher Wave leuchten. In dieser Zeitspanne befindet
sich der AVR zu 99% seiner Zeit im Idle Sleep Modus. Durchschnittlich
leuchtet dann 1 Glühwürmchen alle 15 Sekunden mit 1.2 Sekunden
Leuchtdauer. Das sind aber nur Schätzwerte da auf Grund der sehr
unterschiedlichen Waves und der eingebauten Periodizität der
Glühwürmchen über den Hungry_Threshold mal längere Zeit (über Minuten)
kein Glühwürmchen leuchtet und dann mal wieder mehrere Glühwümchen quasi
in Gruppen aufleuchten. Also so wie in der Natur.

Alle ISR-Handler wurden aus Effizienzgründen in Assembler geschrieben,
Datei Isrs.S.
Als Zufallsgenerator kommt ein 32Bit LFSR zur Anwendung, Dateien lfsr.h
und lfsr.S. Dessen Startwert wird bei jedem Powerup aus dem EEPROM
gelesen, ein neuer Startwert berechnet und dieser wieder ins EEPROM
geschrieben wird. Dazu werden zwei unterschiedliche 32Bit Polynome
benutzt.

Im Ordner \FireFly\FireFly\Windows\ befindet sich ein Wave-Editor für
MS-Windows Systeme. Mit diesem kann man eigene Blinkmuster/Waves für die
Glühwürmchen erzeugen, austesten, laden, speichern und als Header Datei
exportieren kann. Aktuell benutzt das Projekt 32 verschiedene Waves
zusammengesetzt aus einem Wave mit 827 samples. Damit stehen im AVR noch
rund 1.5Kb an FLASH ungenutzt zur Verfügung. Die Leuchtdauer dieser
Waves geht von 0.22 bis 2.88 Sekunden.

Setup:
1.) Schaltung aufbauen ;)
2.) AVRootloader.hex aufspielen, Fuses auf 8Mhz interne PLL, Brownout
Detection off setzen
3.) AVRootloader.exe starten und Testverbindung herstellen, EEPROM mal
lesen und schreiben
4.) wenn alles funktioniert, noch Fuse für RESET Pin als normalen PIN
aktivieren (PB5 wird ja benötigt) und Lockbits entsprechend setzen. Dann
ISP ab, da dieser auf Grund des deaktivierten RESET Pins eh nicht mehr
funktioniert.
5.) mit AVRootloader.exe nun FireFly.hex programmieren
6.) alles irgendwie zuammenbauen so das im Deckel eines zb.
"Rotkohlglases" die Elektronik sitzt, oben drauf das Solarpanel und in
das Glas hineinhängend die 6 Litzen mit den 12 LEDs. Bei mir strahlen
die LEDs alle nach unten ab. Noch ein bischen Plastikgrünzeugs rein
(sollte jeder anständige Bastler auf grund der Vorlieben der eigenen
Frau zur Hand haben, bei mir wars ein Plasikast aus der Dekoration im
Badezimmer), und fertig.

Im Ordner FireFly\FireFly\Schematic\ der Schaltplan und das Boardlayout
als Bitmaps (600 dpi).
Im Ordner FireFly\FireFly\Images\ par Bilder meines Aufbaues.

Was wird also benötigt:

- AVR ATtiny45/85V, Lowvoltage Version wäre gut
- MAX1724 oä. Stepupup Wandler auf 3Volt mit geringem IQ (hier 1.5µA)
- 12 grüne LEDs, am besten Lowcurrent und SMD so klein wie man es noch
löten kann
- 12 kurze dünne Kupferlitzen möglichst in grün, ansonsten ein grüner
Edding um sie einzufärben
- Solarpanel, Nachts freundlichst ausgebaut aus Nachbars
LED-Gartenleuchte, oder eben ein geschenktes Teil ;)
- 1.2V AAA Akku, am besten die neueren Teile von Sanyo
- Glas mit Schraubdeckel, zb. Rotkohlglas von Hengstenberg (nicht den
Inhalt essen bitte artgerecht entsorgen als Giftmüll)
- naja Hühnerfutter, par LED Vorwiderstände, ein Pullup a 330k für PB2
(Bootloader-Detection im AVR) und 2 Low-ESR-Kondensatoren um die 1µF,
und par Litzen.
- ansonsten Kleber, in meinem Aufbau hab ich das SOlarpanel mit solchen
Klebestrips von Pritt (Mutifix) für Poster/Fotos angeklebt hält super.
Ansonsten den Batteryhalter (aus so'n Mini-Fernsteuer-Panzer) mit UHU
puls Endfest 300 an die Unterseite des Deckels angeklebt.
- und natürlich par ansprechnede Plastikgrünpflanzen
- die "aktive ideale Diode" kann auch komplett weggelassen werden und
durch eine Shottky-Diode ersetzt werden. Dann aber diese Diode mit der
Kathode an - des Solarpanels und mit der Anode an GND der Schaltung. Der
Messpunkt des ADC befindet sich dann an der Kathode dieser Diode.
Allerdings nutzt man so nicht die volle Power des Solarpanels aus da so
erst bei +200mV über der Akkuspannung geladen wird. Mit der aktiven
Diode liegt dieser Spannugsabfall nur bei maximal +10mV. Übigens die
BAV70 Dioden stellen sehr hochohmige Pullups dar.

Bisher konnte ich jeden Besucher ohne Probleme davon überzeugen das im
Glas echte Glühwürmchen für meine Unterhaltungsgier schmachten müssen ;)
Meine Nichte war schon drauf und dran gewaltsam diese Glühwürmchen
freizulassen und es dauerte einige Zeit ihr zu erklären das es keine
echten sind.

Gruß Hagen

Bild 1

Bild 2

Bild 3

Schickes Projekt!

Gut um sich m al genauer mit der Energeispaarproblematik
auseinadnerzusetzen ;)

Ist nen schönes Geschenk, mal gucken wann ich das baue :D

schöner beitrag!
ich dachte hier schon mal einen 'nachbau' des ursprünglichen projektes
gesehen zu haben, aber täusche mich wohl.

>Schickes Projekt!
>Gut um sich m al genauer mit der Energeispaarproblematik
>auseinadnerzusetzen ;)

Danke, und ja das Projekt hat einiges Potential das erstmal nicht so
offensichtich ist, bei dem was man lernt.

1.) Wachtdog, was ist der Unterschied wenn man WDE und WDIE Bits setzt
im WDT Interrupthandling ?! Habe lange danach gesucht. Der WDT wird
aktiviert wenn man WDE oder WDIE oder WDE und WDIE setzt, Punkt 1. Setzt
man WDE und WDIE so wird in der WDT-ISR autom. das WDIE Flag gelöscht.
Beachtet man dies nicht so heist dies das der nächste WDT Timeout also
einen WDT-RESET auslösst und nicht in die WDT-ISR verzweigt. Setzt man
von Anfang an nur WDIE so wird die WDT-ISR ausgelösst und dann das WDIE
Flag nicht autom. gelöscht. Die nächsten WDT-Timeouts lösen also
weiterhin die WDT-ISR aus.
2.) Brownout Detection kann beim ATtiny45 per Software deaktiviert
werden, aber welche Reihenfolge vor einem Sleep ist die richtige um
diese Detection auch wirklih abzuschalten ? Ich habe sie per Fuse ganz
abgeschaltet da die Powerup Zeiten aus einem Deep Power Down Modus stark
verlängert werden und somit ab einem bestimmten Breakevenpoint mehr
Strom verbraucht wird. Dh. zb. die abschaltbare Brownoutdetection macht
nur dann Sinn wenn der AVR längere Zeit im Power Down Modus ist, bei mir
musste der AVR weit länger als 8 Sekunden im Power Down sein, also weit
länger als die macimal Zeit des WDTs. Die verlängerte Startup Zeit der
MCU bei zuschaltbarer Brownout Detection frass dann mehr Strom als ohne
diese.
Davon mal abgesehen muß ein ganz gewisses Timing beim Scheiben der
Register beachtet werden damit das Mistding auch wirklich per Software
abgeschaltet wird. Ach und ganz wichtig !! möchte man mit abschaltbarer
Brownout und WinAVR GCC arbeiten dann vergesst ganz schnell die Sleep.h
zu benutzen. WinAVR GCCs Sleep Makros machen alles falsch in diesem
Fall.
3.) PWM Erzeugung für 12 LEDs, quasi Charlieplexing, die aber nur
durchschnitlich 0.85% CPU Last hat. Die von mir implementierte PWM
Routine dürfte wohl das Minimum an Rechenzeit benötigen das möglich ist.
Jedenfalls sehe ich kein weiteres Optimierungspotential mehr um das noch
kürzer zu bekommen. Leuchten alle LEDs permanent in ihrem Muster so
verbraucht die MCU dafür nur 1.45% an Rechenzeit. Pro weiteren LED
Kanal, also dann 20,30,42,56 LEDs, werden dann nur weitere +0.11% mehr
an MCU zeit benötigt. Also eine 20 LED Ansteuerung würde dann minimal
0.85% statt 0.74% und maximal 1.56% statt 1.45% an MCU Zeit benötigen.
Der Zusammenhand ist linear.
4.) variable Watchdog Zeiten um einen genauen Zielzeitpunkt anzusteuern,
natürlich nur in der Genauigkeit die man vom WDT verlangen kann.
5.) wie ist das mit der WDTON Fuse ? löscht man sie muß dem AVR der Saft
abgedreht werden damit das auch wirkt.
6.) PinChange ISR. Man muß sehr vorsichtig damit umgehen, besonders wenn
man diese ständig ein/ausschalten möchte. Aktiviert man eine PinChange
ISR so sollte das in einem CLI()/SEI() Block erfolgen und man muß immer
die ISR-Flags in GFIR explizit löschen. Gleiches sollte man auch in der
PinChange-ISR immer machen. Sollte man kurz vor der Aktivierung einen
PullUp am zu überwachenden Pin aktiviert haben dann ist es ratsam je
nach MCU Takt par NOPs danach einzufügen und erst dann den PinChange zu
aktivieren.

Gruß Hagen

Ja das mit dem Watchdog hab ich beim tiny13 durch.

Ich habe so eine LED kerze mit RGB LED gebaut, besonderheit ist der
Kapazitive näherungsschalter zum ein und ausschalten.

Dort benutze ich den Watchdog interrupt um die Kapazitive taste zu
"entprellen" (Das Sensorergebnis muss Stabil sein, damit ein  wirklicher
absichtlicher Druck erkannt wird)

Wenn ein Tastendruck erkannt wurde wird die Hauptschleife mit der PWM
durchlaufen. Ist schon nen bisschen her, aber ich glaub die zwischenzeit
verbringt er im Idle.

Wenn die Lampe dann wieder ausgeschaltet wird, verbringt er wieder die
meiste Zeit im Tiefschlaf.

Oh super! Das stand schon immer auf meiner todoliste :)

Lad doch mal ein video bei youtube hoch, würd ich gern mal sehen :) :)

Ist ein Problem da ich keine bessere Cam habe und mit der Kamera meines
HTC Touch bekommt man im Dunkeln keine guten Bilder hin. Und tagsüber
ist der Eindruck den die LEDs erzeugen auch nicht der gleiche wie
nachts. Ergo, nachbauen ist die Devise ;)

Du kannst dir aber im beigelegten WaveEditor
(\FireFly\FireFly\Windows\WaveEditor.exe) die von mir benutzten Waves
anschauen und auch austesten. Starte die EXE, lade die Wave.dat und
doppelklicke mit der Maus in die Liste der einzelnen Waves. In der
schwarzen Box leuchtet dann ein grüner Kreis in der ausgewählten Wave.

Gruß Hagen

Schönes Projekt !
Werde ich mal nachbauen. Ich muss nur noch eine Alternative für den
MAX1724 finden, da dieser nicht ganz so leicht zu bekommen ist.

Höhö, sehr lustiges Projekt, super!
Mich würde der Schaltplan, speziell der Teil mit der idealen Diode,
interessieren. Könntest du da den Schaltplan(ausschnitt) reinstellen ?

Ach sehe gerade ist ja schon gaaanz oben drin. Verzeihung. Lesen
bildet...

Vielleicht gehts auch ganz ohne Stepup Wandler. Ich habe den nur
eingebaut weil ich von Anfang an einen 1.2V Akku benutzen wollte. Und
diesen wollte ich benutzen weil dessen Nennspannung weit unterhalb der
3.5V des Solarpanels bei Sonnenbestrahlung ist. Bei Normallicht und am
Akku angeschlossen fließen, bei einem Akku der auf 1.35V voll aufgeladen
ist, gerade noch 200µA vom Solarpanel, das reicht für den AVR und als
Erhaltungsladung für den Akku aus. Somit ist die Wahl des 1.2V Akkus und
dem dann nötigen Stepup Wandler nur den Eigenschaften des Solarpanels
geschuldet und dient dem Ziel die Energie des Solarpanels so gut wie
möglich ausnutzen zu können. Wenn man also ein anderes Solarpanel
benutzt, oder sogar ganz darauf verzichtet dann kann man auch zb. 2 oder
3 solcher AAA Akkus benutzen. Mit 1000mAh sollten diese über Wochen
ausreichend sein.
Bei 0.9V im Akku macht die Schaltung dicht. Das dient zum Schutz vor
Tiefenentladung aber auch um die Funktonsweise der "idealen Diode" zu
gewährleisten. Diese arbeitet zwar auch bei Spanung < 0.8V korrekt, aber
dann wird der Ladestrom über die interne Bodydiode des MOSFETs fließen,
weil der MOSFET bei <0.8V nicht mehr durchgeschaltet wird. In diesem
Moment haben wir wieder den unerwünschten Spannungsabfall der Bodydiode
des MOSFETs und hätten dann gleiche ne Shottky benutzen können. Da aber
immer 0.9V minimal am Akku sichergestellt sind ist dieses Problem
eliminiert. Der Voltagegdrop dieser "idealen Diode" geht lauft
Simulation mit LTSpice gegen 10µV und verbraucht dann ~8nA Strom.

Den MAX1724 habe ich bei MAXIM gesampelt, und ich bin mit dem Teil
wirklich zufrieden und kann diesen speziell für solche Lowpower
Anwednung nur wärmstens empfehlen (mal ohne preisliche Wertung nur aus
Sicht der Technologie), zb. wird bei sehr geringem Sromverbrauch am
Ausgang der PWM Modus umgeschaltet und er Stepup zieht dann nur noch
sehr wenig Strom um die Ausgangsspanung nur konstant zu halten, ideal
also für die Spannungsversorgung eines AVRs der im Power Down ist.
Ein kleines Manko hat er aber. Der Shutdown Modus trennt nicht den
Ausgang vom Eingang. Eine höhere Spannung am Ausgang fließt also auch im
Shutdown Mode zurück zum Eingang. Es gibt aber auch ähnlich gute MAXIM
teile die dann einen echten Shutdown haben.

Gruß Hagen

B1 = Solarpanel
C1 = Akku

Wenn gewünscht poste ich auch noch die Dateien für die Simulation in
LTSpice.
Idee stammt von hier
http://library.solarbotics.net/circuits/misc_switching.html

Gruß Hagen

>>Das dient zum Schutz vor Tiefenentladung aber auch um die Funktonsweise der
>>"idealen Diode" zu gewährleisten.

und natürlich auch für den MAX1724 der ab 0.8V erst beginnt sauber zu
arbeiten.

Die BAV70 kann bzw. muß durch Widerstände ersetzt werden wenn man
schnellere Schaltvorgänge hat. Da aber der Tag/Nachwechsel bei diesem
Projekt so arsch langsam ist kann man auch die BAV70 nehmen um Strom zu
spraen. Insgesamt ist die Schaltung enorm hochohmig und damit auch
störanfällig. Dumm nur das man deren korrekte Funktionsweise mit
Amateurmiteln nicht ausmessen kann da jedes Multimeter/Oszi dessen
Funktionsweise durch die Messungen verändert. Ich habe sie demzufolge
nur per Simulation überprüft und dann über Monate mit einem Akku +
Solarpanel + Amperemeter praktisch ausgemessen, sie funktioniert.

Gruß Hagen

Als Alternative für den MAXIM1724 könnte man den PR 4402 (0,63€) von
Reichelt nehmen. Eigentlich ein LED-Driver (bis 40mA). Mit einer Z-Diode
am Ausgang sollte es gehen...

PR4402

Quiescent Supply Current Vcc > 950mV ist 8 mA.

Wenn der Akku auf mehr als 0.9 Volt aufgeladen wurde zieht das Teil ohne
irgendeine Last am Ausgang, also nur für sich selber zum Eigenbedarf, 8
mA. Das ist das 400 fache dessen was der AVR im Durchschnitt brauch. Zum
Vergleich der MAX1724 benötigt 0.0015mA für sich selber.
Ich mag diese Teile nicht sonderlich, für billige LED Anwendungen sind
sie super, aber nicht für mehr. Desweiteren ist das ein Stepup der am
Ausgang eine Stromsenke, sprich LED, erwartet und kein Regler der auf
eine definierte Spannung regelt. Das ist schon ein Unterschied. Mit dem
Vorschlag der Z-Diode vernichtet man also exakt die wertvolle Energie
die man mit dem Rest der Schaltung mühsam vesucht hat einzusparen.

Jeder kann das halten wie er will. Ich würde diesen LED-Treiber nicht
als Ersatz für einen Lowcurrent Highefficiency Stepup benutzen.

Gruß Hagen

Wie siehts mit der Laufzeit aus wenn man einen Supercap/Goldcap (50F)
anstelle des Akkus verwendet?

Ich überlege gerade es mal mit 2x 1,2V NiMH Akkus zu versuchen. Es wird
zwar vermutlich etwas knapp (grüne LEDs: typ 2,2V), könnte aber
funktionieren.
Das größte Problem dürfte sein, dass die Helligkeit stark von der
Spannung abhängt. Beim Goldcap dürfte das noch extremer sein, denn NiMH
haben eine vergleichsweise flache Entladekurve.

Eventuell könnte der AVR auch die PWM Werte abhängig von der
Akkuspannung kompensiert ausgeben ?

>Ich überlege gerade es mal mit 2x 1,2V NiMH Akkus zu versuchen.

Na dann kannst du auch 3 solcher Akkus nehmen, das passt lässig in den
Deckel rein. Mein Batteriehalter (das güne Teil) war ursprünglich für 3
AAAs gedacht. Die Platine selber ist ebenfalls so breit und lang wie 1x
AAA.
Bei vollgeladenen Akkus wären das 4 Volt und 2.7 Volt bei fast
entladenen Akkus. Dann geht das Ganze auch komplett ohne
Spannungsregler, was weniger Verluste bedeutet. Das Problem düfte halt
das Solarpanel sein. Meines hat einen Innenwiderstand von 3k, eine
Überladung von NiMH Akkus ist damit ausgeschlossen da immer die Spannung
des Solarpanels rapide einbricht. Mein Solarpanel lieferte bei voller
Sonnenbestrahlung ~6 Volt, ohne Last. Mit Last dann 3.5 Volt bei ~10mA.
Aber eben nur bei vollster Sonnenbestrahlung. Bei normalem Tageslicht in
einem Wohnraum (also hinter Glasscheiben) sieht das schon wieder ganz
anders aus. Dann fließen bei 1.35 Volt vollgeladenem AAA Akku nur noch
200-280µA aus dem Solarpanel. Das nimmt dann zu wenn der Akku zb. nur
noch 1.1 Volt Nennspanung liefert. Grundsätzlich ist die gemessene
Spannung am Akku wenn er geladen wird immmer nur die aktuelle
Akkuspannung. Nur über den Strom kann man den Ladevorgang ausmessen. Der
hohe Innenwiderstand des Solapanels sollte also sicherstellen das der
Akku nicht leiden muß.

>Eventuell könnte der AVR auch die PWM Werte abhängig von der
>Akkuspannung kompensiert ausgeben ?

Würde ich anders machen, bzw. das ist der letzte Feinschliff an diesem
Projekt der noch fehlt. Erstmal folgt jetzt ein Dauertest bei dem ich
alle 7 Tage das Teil ausmesse. Danach kommt die letzte Änderung und die
ist folgende:

Beim Tag/Nachtwechsel wird der Akustand der letzten Messung mit dem
aktuellen verglichen. Ist der aktuelle Akkustand kleiner als der des
Vortages wird ein Zähler inkrementiert ansonsten der Zähler
dekrementiert.  Dieser Zähler ist in der Nacht ein Limit der
Schnelligkeit wie oft die Glühwürmchen blinken dürfen. Im Grunde ist
dieser Zähler schon vorhanden, nämlich Hungry_Threshold. Exakt so würde
dieser 2. Zähler arbeiten nur eben das er das zeitliche Limit darstellt
was die Glühwürmchen abwarten müssen bis sie wieder leuchten dürfen.
Somit stellt sich das Leuchten der Glüwürmchen Nachts auf einen Wert ein
der direkt zur gesammelten Energie am Tag proportional ist. Dabei wird
auch zwischen den Jahreszeiten oder der örtlichen Position (Lichtmenge)
des Glases ünterschieden. Es entsteht eine Energiebilanz die ausgewogen
ist, nur die Energie wird verbraucht die per Solarpanel erbracht wurde.

>Wie siehts mit der Laufzeit aus wenn man einen Supercap/Goldcap (50F)
>anstelle des Akkus verwendet?

Habe ich mal durchgerechnet, geht nicht, bzw. zu teuer. Die Entscheidung
auf AAA Akkus fiel auf Grund ihres Preise, Bechaffbarkeit,
Unempfindlichkeit und nicht zuletzt weil ich auch ein Ladegerät für die
Teile habe ;)
Bei GoldCaps muss man auf den Innenwiderstand achten und die maximale
Ladespannung. Besser wären dann diese sogenannten SuperCaps, allerdings
reichen 50F nicht aus. Man kann sich das leicht selber ausrechnen: alle
15 Sekunden leuchtet ein Glühwürmchen für 1 Sekunde mit durchschnittlich
2.5mA Stromverbrauch. 1/15s*2.5mA*360=60mAh Worstworstcase. Das wird mit
SuperCaps einfach zu teuer besonders weil mit den Sanyo AAA NIMhLi Akkus
eine bessere Alternative vorhanden ist.

Ich hatte aber auch kurzeitig diese Alternative in Betracht gezogen. Die
Energieausbeute in Ratio zur Baugröße/Preis hats entschieden.

Gruß Hagen

>Das größte Problem dürfte sein, dass die Helligkeit stark von der
>Spannung abhängt.

Die LED-Vorwiderstände nicht zu klein machen und die regeln dann den
Strom und nicht die Spannung ! Ergo keinerlei Schwankungen, die aber
auch garnicht stören würden, sondern ein Feature sind bei Glühwürmchen
die ja sowieso mit ihrem chemischen Prozess Schwankungen in der
Leuchtintensität erzeugen.
Bei Lowcurrent LEDs können diese Vorwiderstände sogar ziemlich groß
sein. Denn je stärker die LEDs leuchten desto unrealistischer wird es im
Vergleich zur Natur. Der PWM Dutycycle kann dann nicht mehr einen weiten
Helligkeitsbereich abfahren und das bedeutet das die Waves sehr
undifferenziert aufleuchten. Der Trick ist ja gerade das die LEDs quasi
nur glimmen sollen damit es Nachts echt aussieht. Tagsüber bringt das
leuchten garnichts und wird ja auch deaktiviert. Es ist schon doof wenn
Nachts die halbe Fensterbank grün ausgeleuchtet wird, das schafft in der
Natur kein Glühwürmchen, mal davon abgesehen das wir gerade im grünen
Farbspektrum auch am empfindlichsten sind.

Über die Helligkeit oder deren Schwankungen würde ich mir die geringsten
Sorgen machen ;)

Gruß Hagen

PS: als LEDs keine dieser Ultragrünen/TrueGreen oder sowas benutzen. Die
normalen LEDs mit 2.2V haben exakt das gewünschte Farbspektrum das nach
Neongrün aussieht. Übrigens gibts auch Leuchtkäfer die Karminrot, Orange
und Türkis glühen ;)

Hab nicht alles gelesen, aber das Gestrüpp in deinem Glas wird dir
schnell eingehen. Wäre netter mit ner richtigen Bepflanzung im Glas :)

Glaube ich nicht. 1000 Jahre später wird dieses Plastikimmitat immer
noch exitieren und das Glas schon zu Milchglas korrodiert sein, der Akku
samt Schaltung sich selber weggeätzt haben und das Solarpanel nur noch
10mV bei Sonne liefern, eventuell sogar die LEDs schon von den
Kupferlitzen abgefallen sein da mein Flußmittel sie abgeätzt hat ;)

Gruß Hagen

Ich bine gerade am zusammenlöten der Schaltung. Allerding komme ich
nicht so recht weiter:
- Mir ist nicht ganz klar, wie man die 12 LEDs verdrahten muss. Ich habe
4 Ausgänge, wie schließt man da die 12 LEDs an ?
- Wie funktioniert das mit dem Bootloader, wo bzw. wie schließt man den
an ?
- Kann es sein, dass im Schaltplan die Bezeichnungen von Batterie und
Solarzelle etwas durcheinander sind ? Bzw. was ist BAT1+ und BAT2+, und
wiso gibt es keine BAT- sondern nur SOL1- und SOL1- ?
- Sollte der Akku nicht eigentlich direkt an den Eingang der Stepups
(also hinter die "Diode" ? So wie es momentan gezeichnet ist, ist der
Akku direkt parallel zur Solarzelle und die "Diode" hat keinen Nutzen.

Ich habs gerade mal ausprobiert:
Grüne LEDs leuchten bereits bei 2V ordentlich hell.
Ich denke ich werde es einfach mal mit 2x 1,2V NiMH Akkus probieren. Ich
habe noch eine 6V Solarzelle mit ein paar 10mA rumliegen, die ich vor
Jahrzehnten mal gekauft habe.

Erstmal muß ich mich entschuldigen, der Schaltplan war eigentich nur für
mich gedacht und deshalb ist er so ein "Gewusst-wie-Ding".

1.) Falsch im Schaltplan sind PB3 und PB4, dieses sind in der Realität
vertauscht. Das liegt daran das im Schaltplan ein ATTiny15 herhalten
musste. Das macht aber nichts, wichtig ist die Pinzuordnung und da beide
Pins nur den ADC1/ADC2 betreffen wird das in der Software schon richtig
gemacht.


>- Mir ist nicht ganz klar, wie man die 12 LEDs verdrahten muss. Ich habe
>4 Ausgänge, wie schließt man da die 12 LEDs an ?

Ganz einfach. Nehme 2 LEDs und 2 Kupferlitzen. Am Ende dieser zwei
Litzen nun eine der LEDs angelötet. In der Mitte der Litzen dannn die 2.
LED aber antiparallel zur ersten. Als praktisch hat sich erwiesen mit
einem Multimeter das auch LEDs ausmessen kann (sie glimmen dann leicht)
zu arbeiten. So kannst du die antiparallele Polung der LEDs
sicherstellen. Antiparallel bedeutet Anode der einen LED an Kathode der
anderen LED und umgekerht. Nun verdrillst du nur noch die zwei Litzen
und fertig hast du ein von sechs nötigen Leuchtmittel. Du baust das 6
mal so auf und hast somit 12 LEDs verbaut.

Nun haben wir 4 Pins am AVR, sind mit LED? bezeichnet.
An PB0-PB1 eine dieser 2 fach LED Litzen, also an PB0 ein Ende und an
PB1 das andere Ende. Es sieht am Ende so aus

PB0-PB1
PB0-PB2
PB0-PB5

PB1-PB2
PB1-PB5

PB2-PB5

Umsoriert sähe es so aus

PB0-PB1
PB1-PB2
PB2-PB5

PB0-PB2
PB5-PB5

PB0-PB5

es ist egal wie herum du die 2 Enden einer 2 fach LED Litze an die Pins
anschließt, die 2 LEDs sind ja antiparallel verschaltet.

Zwischen einem jeden Pin-Paar, in allen möglichen Kombinationen aus
PB0,PB1,PB2,PB5 befinden sich also 2 LEDs die antirallel geschaltet
sind. Male dir mal 4 waagerechte Linien auf dem Papier auf, bennen sie
PB0,PB1,PB2,PB5 und zeichne nun senkrecht alle 12 LEDs so ein das man
jede einzeln ansteuern kann.

Die PWM geht nun so vor das sie 4 Rows abbildet. Jeweils Row für PB0,
PB1,PB2,PB5. Die Row wird als Ausgang geschaltet und auf VCC gesetzt.
Die zugehörigen Columns stellen dann alle restlichen 3 Pins dar.

Wennn Row PB0 auf Ausgang/VCC ist dann kann ein Strom fließenen zu den
Pins PB1,PB2,PB5. Also 3 LEDs können gleichzeitig leuchten. In der
Timer0 Overflow ISR wird also PB0 auf High Ausgang gesetzt und nun
anhand der nötigen Dutycycle der 3 LEDs in Richtung PB1,PB2,PB5 die DDRB
Bits berechnet. Soll die LED von PB0 nach PB1 also leuchten dann ist
PB0=1 und PB1 als Ausgang mit GND Pegel. Soll die LED nach PB2 nicht
leuchten dann wird im DDRB Register dieser Pin als Input ohne Pullup,
ergo High-Z gesetzt. Somit besteht die Gesamt-PWM aus 4 Phasen. In jeder
Phase wird die Timer0 Overflow ISR aufgerufen, also 4 mal für einen
kompletten PWM Zyklus =122Hz effektiv. In diesen Phase wird nacheinander
PORTB auf PB0,PB1,PB2 und PB5 High/Ausgang gesetzt, alle anderen Bits
auf 0. Nun werden max. 3 DDRB Werte berechnet. Diese 3 Registerwerte
bestimmen welche LED zu welchem OCR0A Wert zu leuchten hat indem über
DDRB die Pins als Ausgang-Low/Eingang-HighZ gesetzt werden. Zu diesen 3
DDRB Werten können maximal 3 OCR0A Werte enstehen die sortiert werden.
Also angenommen LED0 hat Duty 100, LED1 hat 150, LED2 hat 50. Also alle
3 LED dieser aktuellen Row sollen leuchten. Dann muß folgendes Muster
erechnet werden. Zum Timerzeitpunkt 255-150 muß DDRB so gesetzt sein das
LED1 auf Ausgang geschaltet wird. Bei Timerwert 255-100 die LED0 und
LED1 auf Ausgang gesetzt, und bei 255-50 die LED0,LED1 und LED2 auf
Ausgang gesetzt werden. Bei Timerwert 256 = Overflow greift die Overflow
ISR, diese setzt DDRB erstmal auf 0 und dann den entsprechnenden neuen
PORTB Wert für die nächste Row, hier also PB1.

Die Timer0 TOF ISR lädt also zu 3 FireFly Einträgen aus der Struktur
Fireflies die Samples aus der zugeordneten Wave -> FireFly->wave_ptr.
Das sind die OCR0A Werte = Dutycylce der LEDs. Danach lädt sie zur
aktuellen PWM Phase (0,1,2,3) aus ddr_data[] den PORTB Wert und die 3
möglichen DDRB Werte zu den LEDs an den Pins. Durch Umdefiniton dieser
ddr_data[] Tabelle kann man also zu den FireFlys andere physikalische
LEDs zuordnen. Nachdem die ISR diese Werte geladen hat werden diese
Paare aus OCR0A/DDRB Wert nach deren OCR0A Werte absteigend sortiert.
Danach negiert man die OCR0A Werte man rechnet also 255-x aus. Somit
besteht die Dunkelphase einer LED mit Dutycylce 200 aus 255-200=55. Ab
Timerwert 55 beginnnt die LED zu leuchten bis der Timer auf 256
überläuft. Nach der Sortierung werden noch die mitsortierten DDRB Werte
ver-odert. Dann noch diese 3 Wertpare in das array ocr_data[]
gespeichert da diese in der Timer0 Output Compare Match ISR als Input
dienen zum Setzen des nächsten OCR0A und aktuellem DDRB Wert. Damit
benötigt die OC-ISR nur 18 Taktzyklen. Sie wird minimal 0 mal aufgerufen
nämlich immer dann wenn keine der 3 LEDs leuchten sollen (wave_ptr =
nil). Oder aber maximal wird diese OC-ISR 3 mal aufgerufen wenn nämlich
alle 3 LEDs leuchten sollen und deren Dutycylce sich alle voneinander
unterscheiden. Sollten also zb. 3 LEDs leuchten deren Duty ist aber
identisch dann wird die OC-ISR nur einmal pro Timerdurchlauf aufgerufen.
Die TOF-ISR benötigt die meiste Rechnenzeit, minimal 122 Takte, maximal
185 Takte, jenachdem wieviele LEDs pro Zeile leuchten sollen. In 64*256
Takten pro Timerdurchlauf werden so nur minimal 0.74% und maximal 1.45%
an rechenzeit für diese ISRs verbraten. Dabei macht aber die TOF-ISR
auch noch das Laden und Inkremetieren des FireFly->wave_ptr und
überprüft ob dieser Zeiger FireFly->wave_end erreicht hat. Sobald alle
12 LEDs aufgehört haben in ihrer Wave zu leuchten (wave_ptr=nil bei
allen) wird in Flags das Bit FLAG_TIMER gelöscht. Ab diesem Moment wird
der Timer0 samt ISRs deaktiviert und der AVR geht vom Idle-Sleep-Mode in
den Power-Down-Sleep-Mode über, bis das/die nächste/n FireFly/s leuchten
soll/en.
Die TOF ISR benötigt maximal 185 Takte. Das bedeutet bei Prescaler 64
für Timer0 auch das sie quasi 3 Timerzyklen lang dauert. Und das
bedeutet das der Dutycycle der LED nur von 0 bis 252 gehen kann. Deshalb
werden die OCR0A Werte auch negiert. Die PWM beginnt also für alle LEDs
bei OFF und schaltet dann bei 255-Dutycycle die LEDs erst ON. Somit kann
der Dutycylce von 0=aus bis 252=hellstes Leuchten gehen. Da durch unser
logaritmisches Sehen wir eh keinen Unterschied beim Leuchten einer LED
mit Dutycylc 252 bis 255 sehen ist dieses Vorgehen akzeptabel. Wichtiger
war mir das die kleinen Dutycycles bei 0 bis 128 ausgeprägt sind da das
zarte Leuchten einer LED viel schwieriger zu bewerkstelligen ist. Und
eben der Fakt das das komplette Wavebasierte Leuchten der LEDs samt
Multiplexing etc. pp. voll in den ISRs im Hintergrund ablaufen kann.
Nicht in einer schwer synchronsierbaren Main Funktion oder sonstwo, und
das die Synchronistation beim Setzen neuer Waves in den FireFlies auch
sauber ohne Störungen und Zeitverlust durch Sperrung per CLI()/SEI()
Blöcke vonstatten geht. Achte mal drauf wie die Waves in
update_fireflies() aktualisiert werden.
Man könnte die kompletten ersten drei Blöcke in der TOF-ISR entfernen
und auf ein Array[12] of uint8_t ersetzen. Statt also mit Waves zu
arbeiten würde man dann dort den Dutycycle der 12 LEDs eintragen. Und
fertig wäre die effiziente PWM für 12 gemultiplexte LEDs an 4 Pins die
nur 1.45% MCU Zeit benötigt, wahrscheinlich sogar weniger da nun das
Laden der Wavesampoles usw. entfallen würde.

Ups, dieser Text ist eine längere Umschreibung der Funktionsweise als
die Anzahl an Sourcezeilen die es dann real umsetzt in Hardware.

> Wie funktioniert das mit dem Bootloader, wo bzw. wie schließt man
>den an ?

PB2 ist der Bootloader Pin an diesen Pin direkt lötest du das 1-Wire
RX/TX Kabel, hat 330k nach Vcc dran (denke das der Pullup sogar
weggelasen werden könnte). Der Bootloader arbeitet im 1-Wire-RS232,
siehe hier Beitrag "AVR-Bootloader mit Verschlüsselung"
Du nimmst eine RS232 Buchse und benutzt die Schaltung im 1-Wire.jpg. Am
anderen Ende der PC auf dem AVRootloader.exe läuft.

Im ersten Step musst du per ISP den AVR einmalig mit
\FireFly\HEX\AVRootloader.hex programmieren. Dann erstmal die
PC-Software mit dem soeben programmierten AVR austesten, also eine
Verbingung zum Bootloader herstellen und mal EEPROM/SRAM auslesen,
verändern und zurückschreiben in den AVR und nochmal lesen zur
Verfikation.
Wenn das alles geht nochmal per ISP ran und die Fuses setzen. Diesesmal
RESET Pin als normalen Pin fusen und die Lockbits vorher setzen wenn
gewünscht. Danach kannst du ISP vergessen und ablöten, geht eh nicht
mehr. Du müsstest dann also schon im Highvoltage Modus den AVR
zurücksetzen !!
Übrigens da wo bei mir im Borad die 4 LEDs drankommen, also PB0,PB1,PB2
und PB5 liegen auch die ISP Pins MISO,MOSI,RESET,SCK.
Nun kannst du die \FireFly\HEX\FireFly.hex über den Bootloader flaschen.
Ein RESET des AVRs ist danach nicht nötig da die Software im Power Down
Modus den PB2 Pin auf PinChange überwacht. Sollte also die PC-Software
versuchen mit dem Bootloader im AVR zu verbinden und der arbeitet gerade
die FireFly Software ab und befindet sich im Power Down Modus dann
schlägt die PB2 PinChange ISR zu und ruft direkt den Bootloader auf.
Diesen kannst du auch fürs Debugging benutzen indem du über das SRAM HEX
Window den SRAM des AVRs ausliest. Du kannst dir also globale SRAM
Variablen definieren und dort deine Debugwerte reinschreiben. Im MAP
File schaust du nach welche Adddresse sie belegen und kannst dann direkt
in der PC-Software deren SRAM Inhalt auslesen.

>- Kann es sein, dass im Schaltplan die Bezeichnungen von Batterie und
>Solarzelle etwas durcheinander sind ? Bzw. was ist BAT1+ und BAT2+, und
>wiso gibt es keine BAT- sondern nur SOL1- und SOL1- ?

Jain ;) BAT1+ BAT2+ sind SMD Pads und die haben eine gewisse Größe.
Schlußendlich also aus Layoutgründen so gemacht. Es ist ganz einfach: an
BAT1+/BAT2+ das ist ein großes Pad kommt Akku+ und Solar+ dran. An
SOL1-/SOL2-, ebenfalls ein gemeinsammes großes Pad kommt -Pol vom
Solarpanel dran. Damit liegt dieser Pol an ADC2 und am Drain des
MOSFETs.
-Pol des Akkus geht nach Masse, das ist das Via in der Mitte meines
Boards. Exakt daran kommt auch noch Masse des Bootloader Kabels, benötgt
also GND und PB2. Im Schematik befindet sich Masse da wo auch GND des
MAX1724 ist. Habe ich nicht eingezeichnet sorry.

>- Sollte der Akku nicht eigentlich direkt an den Eingang der Stepups
>(also hinter die "Diode" ? So wie es momentan gezeichnet ist, ist der
>Akku direkt parallel zur Solarzelle und die "Diode" hat keinen Nutzen.

Der Akku liegt mit Pluspol wie auch das Solarpanel mit Pluspol am
Eingang des Stepup, da wo der BAT/SHDN (Shutdown) Pin des MAX sind. Die
Doppeldiode BAV70 liegt mit beiden Kathoden ebenfalls an dieser
Versorgungsleitung, also sehr hochohmige Pullups für die beiden
Transistoren T1/T3.

Wie gesagt das Schematik ist nicht so dolle, aber ich dachte mir das ich
es trotzdem so veröffentliche statt mit dem Projekt hinterm Berg zu
halten.

Gruß Hagen

Du kannst den ganzen Quatsch mit der idealen Diaod auch weglassen und
durch eine Schottkydiode ersetzen. Diese mit der Anode dann nach GND der
der Schaltung. An Kathode kommt -Pol des Solarpanels und der geht auch
an ADC2 des AVRs.

Beim Fusen bitte die interne PLL mit 8Mhz benutzen, also CDIV8 raus. Den
Brownout deaktivieren da dieser zu viel Strom frisst und wir selber
darauf achten das keine Tiefenentladung der Akkus erfolgt. Nicht WDTON
aktivieren, wir wollen den Watchdog ja im Interrupt Modus benutzen, und
ausschließlich nur in diesem Modus. Dann setzt du die Lockbitfuses wenn
gewünscht, LPM/SPM muß noch ausführbar bleiben ! Wenn das alles geht als
letzten und wirklich überprüften Schritt den RESET Pin als normalen Pin
fusen. Ab diesem Moment kann man den AVR nur noch über Highvoltage
zurücksetzen.

Gruß Hagen

schau mal hier rein Beitrag "10 Duo LEDs mit ATTiny15 über 5 Pins steuern"
Das zeigt die Anschlußbelegung für 20 LEDs an 5 Pins.

y=x(x-1), wobei x Anzahl der Pins und y Anzahl der LED ist.

Gruß Hagen

Danke für die Erklärung. Ich habe gemerkt, dass die meisten Antworten
auf meine Fragen irgendwo in deinen Texten versteckt drin stehen. Ich
glaube ich sollte erstmal alles gründlich durchlesen. Aber so ist das
halt, wenn man alles so schnell wie möglich am Laufen haben möchte...

Ich habe alles jetzt aufgebaut und die Software geflashed, nur es tut
sich nichts. Fusebits passen, der Bootloader läuft.
Die Software musste ich etwas anpassen, wegen der geänderten
Betriebsspannung.
Kommentiere ich die Zeile
if (flags & FLAG_ISNIGHT)
aus, dann sehe ich die LEDs "blinken", und zwar immer den ganze Schwarm,
ziemlich genau im 17s Rhytmus.
Aus irgendeinem Grund wird also das ISNIGHT Flag nicht gesetzt.
In measure_isnight() setze ich daher das Flag immer (unabhängig von den
ADC Werten, um das als Fehler auszuschließen). Es geht aber trotzdem
nicht. Anscheinend wird measure_isnight() nie aufgerufen.

Was könnte ich falsch gemacht haben ?

Also erstmal ist das doch schon super, ich meine für einen
Übernachtaufbau ;)
Jetzt kommentierst du alle in "measure_isnight()" aus und lässt nur
drinen

flags |= FLAG_ISNIGHT;

Somit ist der ganze ADC Kram deaktiviert und wir simulieren das es immer
Nacht ist.

Nun conntectest du einmal mit  PC-Booloader, Button "Conect to device"
und wenn Verbindung steht wieder ein "Disconnect". Damit machen wir
quasi ein RESET per PC-Software. Das führt dazu das alle 12 FireFlies
Einträge auf alle 0 stehen. Sie beginnen also alle mit einem Schlag zu
leuchten. Schau dir an ob sie

1.) im alerersten gemeinsammen Leuchten mit unterschiedlichem Muster
leuchten
2.) das sie nach dem ersten Leuchten erst einige Zeit später erneut
leuchten
3.) das dann eine Phase eintritt mit längerer Dunkelheit aller LEDs
4.) danach dann vereinzelt die LEDs beginnen zu leuchten, so alle 15
Sekunden

Wenn das geht nochmal mit PC-Software ein "Connect"/"Disconnect" machen
und das Spiel nochmal von Vorne.

Gruß Hagen

PS: sorry, bin noch übernächtig, wer Tippfehler findet darf sie behalten

Achso, ein Connect zum Bootloader ist immer erst dann möglich wenn das
hauptprogram im Power Down Sleep Modus ist. In Main() der letzte IF
Block. Solange also noch eine LED leuchtet muß der Bootloader
(PC-Software) noch warten.

Gruß Hagen

Ich habe jetzt
measure_isnight();
durch
flags |= FLAG_ISNIGHT;
ersetzt.
Ergebnis: Es passiert garnichts.
Nur wenn ich das Flag von Anfang an setze, blinken die LEDs.

Sorry, du musst jetzt bis zu 12 Minuten warten bis was passiert ;)

Das FLAG_ISNIGHT wird erst gesetzt wenn der Measure Timer =
MEASURE_INTERVAL abgelaufen ist, das sind momentan 6 Minuten.

Ändere in FireFly.h

#define MEASURE_INTERVAL  (uint16_t)(10)

um. Das wären dann 10*16ms an Interval, geht dann alles ein bischen
schneller vom Ablauf her ;)

Dann solltest du aber trotzdem obige 4 Punkte beobachten können. Erst
wenn wir das verifiziert haben machen wir Schritt für Schritt weiter.

Gruß Hagen

PS: die LEDs blinken nicht, sondern leuchten in einer Wave ;) hoffe ich
doch.

Benedikt, hast du Skype ?

Dank, jetzt läufts ! Es lag an den 12 Minuten. 6 Minuten hatte ich immer
gewartet, dass es 12 Minuten sein müssen, darauf wäre ich nie
gekommen...

Ich werde jetzt die ADC Routine noch etwas anpassen, damit das ganze mit
2,4V läuft.

>Dank, jetzt läufts

Dh. du sieht nach einem "RESET" per PC-Software erstmal alle 12 LEDs
leuchten, in einem jeweils anderen zufälligen Muster. Dann verlöschen
diese im Leuchten so langsam bis keine merh leuchtet. Dann entsteht ein
längere Phase, so bis 1 Minute wo alles dunkel bleibt und danach
beginnen die LEDs so eine nach der anderen oder auch par in Gruppen zu
leuchten. Wenn dies so ist ist erstmal alles richtig.

Du solltest jetzt dein Amperemeter mal benutzen, Meßbereich 50mA bis
10µA. Während der Bootloader verbunden ist sollten es um die 20mA sein,
während alle LEDs leuchten so um die 15mA maximal (hängt aber von deinen
LEDs und Vorwiderständen ab). Und wenn dann alles dunkel ist sollte der
Strombedarf (Power Down Mode) rapide sinken, < 20µA.

Nun machst du folgendes:

In measure_isnight() kopieren wir die Deklarationen von

uint16_t bat_volt;
uint16_t sol_volt;

raus und setzen sie als globale Variablen vor diese Funktion. Dann
kompilisert du alles und öffnest die Datei FireFly.MAP. Suche in dieser
die Einträge für bat_volt/sol_volt raus und merke dir deren
SRAM-Speicheraddressen. Sollten so bei 0x00CC liegen.

Über die PC-Bootloader-Software das HEX flashen und dann kannst du auf
der "SRAM Content" Page mit "Read from Device" Button den SRAM Inhalt
des AUVs auslesen. An der Speicheraddressee 0x00CC oä. stehen dann die
bat_volt und sol_volt.

Du kannst auch mal den EEPROM mehrmals auslesen. Du solltest dann sehen
das sich die ersten 4 Bytes ständig verändern. Das ist der gespeicherte
Startwert des LFSR-Zufallsgenerators. Diese dürfen niemals auf
0x00,0x00,0x00,0x00 stehen !

Nun stellt sich die Frage: Welche Spannungen wirst du erwarten am
ADC3/ADC2 ?

Bei 2 AAA NiMH Akkus sind das maximal 1.35*2 = 2.7 Volt. Das wäre zu
hoch für die ARef=2.56V. Du solltest also auf ARef = VCC gehen aber das
ist ein Problem da du ja keinen Spanungsregler drinnen hast. Du kannst
nicht VCC messen mit VCC als ARef.

Ergo must du in deinem Falle für das Messen der Akkuspannung einen
Spannungsteiler benutzen 1/2 und dann denoch mit 2.56V ARef messen, die
sind dann ja ein stabislisierter absoluter Bezugspunkt zu deiner
veränderlichen Vcc=Akku.

Problematisch wird das Ausmessen des Solarpanels werden. Falls du die
Idela Diode aufgebaut hast haben wir ein Problem mit dem Messen per ADC.
Denn ein Spannungsteiler müsste vom
ADC->Widerstand->SolarPanelMinusPol->Widerstand->GND gehen. Der
Widerstand von Solar- nach GND würde aber unsere Diode überbrücken, das
ist schlecht.

Also müssen wir das anders machen bei deinem Aufbau. Das Solarpanel ist
mit Plus an Akku+=ADC3 und mit Minus an ADC2. Das habe ich absichtlich
so gemacht. Denn du kannst die Solarpanel Spannung nun per
differentiellem Messen über ADC3-ADC2 versuchen auszumessen. Wichtig ist
dabei ja nur der Fall das diese Spannnung wenige Millivolt betragen
sollte für die Erkennung der Nacht. Sollte das Solarpanel tagsüber mehr
als 2.56V ARef/2 liefern so wird der gemessene ADC Wert saturieren auf
0x03FF.

Deshalb empfehle ich dir den Trick mit dem Auslesen des SRAM per
Bootloader damit du nachschauen kannst ob die Messwerte des ADC auch
stimmig sind.

Gruß Hagen

>Dank, jetzt läufts ! Es lag an den 12 Minuten. 6 Minuten hatte ich immer
>gewartet, dass es 12 Minuten sein müssen, darauf wäre ich nie
>gekommen...

sein können. Minimal sind es 6 Minuten maximal 12 Minuten - x
Millisekunden*16. Zuzüglich die Schwankungen in der Ungenauigkeit des
WDT-Oszillators und die können schonmal 25% betragen.

Du musst dann noch das #define BATTERY_OK an deinen Aufbau anpassen. Und
eventuell die Abfrage

if ((sol_volt > bat_volt) && (sol_volt >= BATTERY_OK)) flags |=
FLAG_ISNIGHT;

abändern, da du ja nicht mehr über das Solarpanel die Akkuspannung
indirekt messen kannst. Es sollte dann eher so aussehen bei dir


if ((bat_volt >= BATTERY_OK) && (sol_volt < par Millivolt)) flags |=
FLAG_ISNIGHT;

Mache deinen Spannungsteiler hochohmig um Strom zu sparen.

Gruß Hagen

Nochmals danke für die Hilfe !
Ich habe das ganze jetzt mit 2x NiMH Akkus am laufen. Die Vorwiderstände
habe ich weggelassen, da die Ports des AVRs bei niedrigen
Betriebsspannungen relativ hohe Innenwiderstände haben (ein paar 10
Ohm). Bis hinunter zu 2V kann man die LEDs noch deutlich glimmen sehen.
Bei 2,4V zieht eine aktive LED etwa 1mA, was optimal ist.
Der Ruhestromverbrauch liegt bei 3µA +/- ein paar µA Messfehler. Also
nahezu unmessbar und warscheinlich geringer als die Selbstentladung von
den billigen Akkus die ich verbaut habe.
Die Messung der Akkuspannung habe ich über einen kleinen Trick erledigt
und so sogar noch einen Pin eingespart: Ich verwende Vcc als ADC
Referenz und messe die interne Referenzspannung.

Jetzt kommt der für mich schwierige Teil: Grünzeug besorgen und das
ganze optisch schön zusammenbauen...

>Der Ruhestromverbrauch liegt bei 3µA +/- ein paar µA Messfehler. Also
>nahezu unmessbar und warscheinlich geringer als die Selbstentladung von
>den billigen Akkus die ich verbaut habe.

Dachte ich mir schon. Ich habe nämlich zu voreilig bei meinem Board
vergessen das ich auch mal den Strom des AVR nach dem Stepup messen
möchte mit vorzusehen. Da mein Stepup nicht ideal dimensioniert ist,
sprich keine Low ESR Kondensatoren und die Spule wohl eher ne Drosssel
ist komme ich auf 22µA. 22µA / (3.1V Vout/1.35V Vin/0.8 Effizienz) =
~7.5µA - 1.5µA IQ Stepup = 6µA des AVRs. Das kann aber nicht stimmen da
laut meiner Rechnerei er auf unter 3µA kommen sollte. Sprich mein Stepup
benötigt 3µA mehr an Power auf Grund der falschen Dimensionierung. Mein
Multimeter hat als unterste Meßbereiche 200µA und 20µA.

>warscheinlich geringer als die Selbstentladung von den billigen Akkus die
>ich verbaut habe

Ich werde demnächst auf die neuen Sanyo Teile umrüsten.

>Die Messung der Akkuspannung habe ich über einen kleinen Trick erledigt
>und so sogar noch einen Pin eingespart: Ich verwende Vcc als ADC
>Referenz und messe die interne Referenzspannung.

Super Idee muß ich mir merken. Mit dem zusätzlichen freien Pin kannst du
ja 5 LED Ausgänge machen, somit wären mit der gleichen Methode 20 LEDs
an 10 Strippen möglich.

Wie kommen die Waves rüber ? Ich habe bisher noch nicht soviel Zeit
gehabt meine Wave.dat besser zu optimieren. Die kleinen Helligkeiten in
der PWM kommen bei mir zu hell rüber, undifferenziert, eben zu kleine
Vorwiderstände verbaut.

Hast du den 330k Pullup an PB2 verbaut für den Bootloader ? Der könnte
eventuell weggelassen werden.

Ähm, da fällt mir auf: du misst aber am Solarpanel per ADC immer noch im
Single Ended Modus bei 2.56 VRef ? Das bedeutet das bei voll geladenen
Akkus = 2.7V schon bei 2.56V der ADC saturiert. Ergibt 2.7V - 2.56V =
140mV die du schon als Nacht-Spannung am Solarpanel erkennst. Das wäre
bei mir noch regnerischer Tag.

Eventuell wäre es also besser die Schaltung anderst aufzubauen.
Solarpanel- an Masse, Solarpanel+ and Schottk Anode und Kathode an Vcc.
ADC misst nun an Solarpanel+/Anode Schottkydiode. Dann kannst du wieder
ohne Probleme mit Single Ended ADC und VRef 2.56V messen, sogar 1.1V
VRef um die Auflösung bei kleinen Spannnng am Solarpanel = Nachts, zu
erhöhen.

Alles in Allem dürfte dein Aufbau sogar noch eleganter sein, da weniger
komplex. Wenn ich das richtig verstanden habe wäre es ganz vereinfacht
so:

- 2x 1.2V NiMh Akkus in Reihe
- Parallel dazu Solarpanel mit - an Masse und + an Schottky Diode Anode
und deren Kathode an VCC.
- parallel dazu AVR
- Ein ADC vom AVR geht zwischen Solarpanel+ und Anode Schottky Diode
- LEDs direkt ohne Vorwiderstände an AVR, 5 Pins für 20 LEDs wären damit
verfügbar

Gruß Hagen

sagt mal, wo habt ihr eure Solarpanels denn her gehabt? Einfach ne
Gartenleuchte geschlachtet (so was:
http://www.pollin.de/shop/shop.php?cf=detail.php&a...
?) oder gibts die irgendwo direkt?

Gruß
Fabian

Mein Schwiegervater hat mir eines zum Schlachten geschenkt. Ist älteres
Modell und neuere dürften wohl besser sein.

Gruß Hagen

Hi.

Echt ein schönes und lustiges Projekt!

Ich hab letzte Woche mein altes Händi geschlachtet, und der Li-Pol Akku
bietet sich dafür an. Liefert 4 Volt und ist nur 7mm dick.

Hab etwas an dem Code rumgebastelt, um das in den ATtiny25
reinzubekommen. Aber jetzt geht's und ich hab's jezt auf genau 2048
Bytes runter schwitz . Natürlich ohne Bootloader und nur mit avr-gcc
3.4.6.

Momentan ist ja Glühwurm-Zeit, und ich hab die Tierchen neulich auf ner
Nachtwanderung beobachten dürfen, wirklich beeindruckend wenn die in
grösseren Mengen auftreten! Allerdings leuchten die recht entspannt und
ausdauernd und sind kaum hektisch am blinken -- ok, kommt vielleicht
noch wenns mit dem Poppen losgeht...

@Hagen:

Gibt's da noch Optimierungspotential? Ich würd gerne 11 LEDs
anschliessen und die eine, die nicht antiparallel ist, zur
Helligkeitsmessung nehmen. Vom Prinzip her geht das, hab das schon mal
gemacht. Allerdings braucht man da einiges