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

>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.

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.

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

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&p...
?) 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 an Code (Input-Capture).

Was ich bisher optimiert hab ist:

-- TIM0_OVF_vect: Laden von _a, _b und _c in eine Funktion ausgelagert
-- Zeug für Bootloader-Support entfernt
-- Kleinigkeiten, um GCC bei der CSE-Optimierung zu helfen.
-- Sortierung von _b gegen _c in eigener Funktion

Dann, soweit ich sehen kann, können alle Daten im RAM ebensogut
uninitialisiert sein nach RESET? Hab mal die .init4 rausgekickt
(clear-bss + copy-data). Das funzt genauso mit anderem Startmuster und
würd nochmal satte 40 Bytes bringen!

An den Waves, den leuchtmustern, muß noch verbessert werden. Dazu ist ja
der beigelegte Waveeditor von mir auch da. Bisher bin ich noch im
Langzeittest, zwecks Energieverbrauch und diesen ausgewogener
hinzubekommen.

>>-- TIM0_OVF_vect: Laden von _a, _b und _c in eine Funktion ausgelagert

Hat das was gebracht ? Du musst auch immer darauf achten das die maximal
nötige Anzahl an Takten dabei nicht größer 192 wird. Ansonsten benötigt
die TOV ISR nämlich nicht mehr 3 sondern zb. 4 Timerzyklen und dann darf
der höchste PWM Wert in den Waves 251 nicht überschreiten.

>>-- Sortierung von _b gegen _c in eigener Funktion

Wieviel hat es eingespart ? FLASH zu Taktzyklen ?
Es sind 3 Elemente zu sortieren.

[asm]
// now sort each pair of DDRB/OCR0A values descending to OCR0A value ==
PWM dutycycle for each LED
        cp      _b_ocr, _c_ocr
        brsh    50f
        movw    _y, _b
        movw    _b, _c
        movw    _c, _y
50:     cp      _a_ocr, _b_ocr
        brsh    51f
        movw    _y, _a
        movw    _a, _b
        movw    _b, _y
        cp      _b_ocr, _c_ocr
        brsh    51f
        movw    _y, _b
        movw    _b, _c
        movw    _c, _y
51:
[/asm]

Es sind maximal 3 Vergleiche auszuführen und in 50% der Fälle werden
tatsächlich nur 2 der obigen Vergleiche real durchgeführt. Pro Vergleich
fallen 3 Takte, bzw. 6 Takte an und benötigt 10 Bytes FLASH. Lagert man
dies in Funktionen aus so gewinnt man wirklich nur marginal an FLASH
Speicher erhöht aber überproportional die Anzahl der nötogen Takte,
wegens rcall/ret Opcodes und verbraucht mehr Stack.

Zeig doch mal deinen Source damit man das besser beurteilen kann, aber
aus meiner Sicht wäre das die letzte Stelle an der ich irgendwas
optimieren würde, da der Gewinn einfach nicht den Aufwand rechtfertig.

Da ist die Optimierung das Laden der PWM Dutycylce für a,b,c am Anfang
dieser ISR wirklich lohnenswerter.

>>Gibt's da noch Optimierungspotential?

Wenig. Man kann immer noch was optimieren, allerdings bin ich nicht der
Typ von Programnmierer der Stunden damit verbringt um schlußendlich das
letzte 0.1% an besseren Code noch rauszuquetschen. Der Source dürfte für
ein AVR GCC C Projekt schon ziemlich kompakt sein. Ich stand eben auch
vor der Entscheidung den Source noch nachvollziehbar zu halten. Man
könnte so einige C Funktionen noch nach Assembler portieren, meistens
gewinnt man so nach meiner Erfahrung bis zu 50% an FLASH und es wird
auch noch effizienter.
2k FLASH sind halt ziemlich schnell verbraucht wenn man in C
programmiert.

>>Ich würd gerne 11 LEDs
>>anschliessen und die eine, die nicht antiparallel ist, zur
>>Helligkeitsmessung nehmen.

Ich kenne deinen konkreten Aufbau nicht. Du kannst erstmal nichwas an
der HW verbesseren (habe ich schon getestet).

Man kann einen ADC Pin einsparen und hätte somit noch einen freien Pin
zur Verfügung. Das geht so:
Wir benötigen nur einen ADC Eingang der die Spannung am Solarpanel
misst. Damit hast du deine Tag/Nacht==Helligkeitserkennung drinnen. Das
Messen der AKKU Spannung wird geändert und erfolgt gegen die interne
AREF von 2.56V/1.1V. Statt also mit einem eigenen ADC Pin zum AKKU
dessen SPannung zu messen, mesen wir VCC gegen AREF, denn du arbeitest
ja ohne Stepup Wandler direkt den AKKU am VCC Pin, richtig ?

Man könnte aber auch die Messung des Solarpanels noch wegoptimieren.
Dann so wie du es vorschlägst über die LEDs selber. Dabei ist es egal ob
die LEDs single oder double-antiparellel angeschlossen sind, denn man
misst dabei ja die Kapazitive Ladungsmenge der LEDs um die Helligkeit zu
ermitteln. Dürfte also auch mit antiparelle verschalteten LEDs gehen.

Allerdings würde ich halt die Mehtode des Solarpanels benutzen, dürfte
weit exakter sein.

>Dann, soweit ich sehen kann, können alle Daten im RAM ebensogut
>uninitialisiert sein nach RESET?

Ja das geht schon und ich habe bei den Datenstrukturen/Register
Belegungen/Initialisierung exakt darauf geachte das es uninitialisiert
sein könnte. Allerdings habe ich das Linkerskript nicht dahingehend
angepasst, einfach weil es dann für unerfahrene Leute nicht mehr
verständlich wäre.

Es macht also aus Sicht des programablaufes nur den Unterschied aus das
dann die Fireflys quasi schon zufällig initialisiert wären, und das
beeinflusst nur das Delay der erste Dunkelphasen der Glühwürmchen, mehr
nicht.

>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...

Nee leider nicht. Wie üblich finde ich es bei solchen Projekten eben
auch spannend mich mit der Materie drumherum intensiv zu befassen (plane
sogar meinen Vietnamurlaub eventl. neu um die nur dort existierenden
roten Glühkäfer zu sehen :) Ich habe also auch im WEB intensiv
recherchiert um das Leuchtverhalten der Simulation an die Realität
anpassen zu können. Das zu planen/herauszufinden hat übrigens die meiste
Zeit gekostet ;)
Nungut, ich selber bin mit der Simulation auch unzufrieden. Die Waves
müssen länger und ruhiger leuchten, was aber über den Waveeditor ja
leicht anpassbar ist.

In der Fortpflanzungszeit verändert sich das Leuchtverhalten nur
unmerklich. In der Natur ist es so das eine Gruppe von Männchen um
ein/zwei Weibchens buhlen muß. Dabei sind die Weibchen defakto die
Auslöser der Leuchtmuster, dh. die Männchen antworten im Grunde als
Gruppe (am Anfang unsynchronisiert bishin zu vollständigen
Synchronisation) auf die Weibchen. Das ist ein wesentlicher Unterschied
zu meiner Simulation.
Ein weiterer Unterscheid ist die Anzahl, mit 12 LEDs ist man im Grunde
schon unrealistisch beschränkt.

Da ich nun schon drei Aufträge aus meiner Familie habe für einen Nachbau
arbeite ich nebenbei an einer neuen Version. Diese wird einfacher
aufgebaut sein und mit 20 LEDs funktionieren. Der Aufbau ist sehr
simpel, ein Solarpanel das mehr Spannung liefert (5V-6V) wird mit
Pluspol direkt an einen ADC Pin des AVRs angeschlossen. An VCC kommt ein
3.7V LiPo Akku ohne jedweige Schutz/Ladeelektronik. Über den AVR Pin und
die Software im AVR wird der Akku dann vom Solarpanel Pluspol -> AVR ADC
Pin -> nach VCC -> Akku aufgeladen. Wenn man bestimmte Kriterien
beachtet so geht das hervoragend und erste Langzeittest laufen schon.
Dh. der AVR stellt sowas wie ein Solar-LiPo-Laderegler dar. An die
restlichen Pins dann die 20 LEDs im Charlieplexing. Somit kein Stepup,
keine ideale Diode, keine Shottkydiode mehr.

Übrigens denke ich das du deinen zeitlichen Aufwand enorm reduzieren
könntest wenn du 20 Cent mehr investieren würdest, nämlich in einen
ATTiny45V statt einem 25'er. Das beseitigt all deine Problem mit dem
geringsten Aufwand ;) (ich weiß das man als Hobbybastler immer das
verbauen möchte was man da hat, aber in einem solchen Fall denke ich
pragmatisch).

Gruß Hagen

Achso, du könntest auch die Wave[] kürzer machen. Statt mit 32 Waves zu
arbeiten zb. nur mit 16 Waves. Das spart dann schonmal in Wave_Data[]
exakt 96 Bytes FLASH. Dann noch Wave[] selber verkürzen. Starte einfach
mal im Ordner \Windows\ die WaveEditor.exe und lade dort die Wave.dat.
Du kannst dann mit der Maus oben im Waveeditor die Samples verschieben
und somit kürzere Waves bzw. deren Anzahl verändern.

Es sollten dabei 8,16,32,64 Einzelwaves entstehen (links in der Listbox
die Anzahl der Einträge). Sollte die Anzahl nicht eine Potenz von 2 sein
so musst du im AVR Source in uprdate_fireflies() den Aufruf von lfsr(5)
verändern. Bei 16 Waves dann lfsr(4) (4 Bits = 16). Bei zb. 24 Waves
dann so: lfsr(4) + lfsr(3) == 2^4 + 2^3 = 16 + 8 = 24.

Gruß Hagen

Und dann könnte man die Art der Erzeugung der Waves noch verändern.
Statt nun  die Wave als Samples mit fester Samplingfrequenz (122Hz)
abzuspeichern, speichert man quasi nur Stützstellen mit zb. 12Hz. Wenn
man sich die Wave genau anschaut so erkennt man lange Phasen in denen
die Samples identisch sind. Das lässt sich wegoptimieren indem man quasi
einen Bresenham-Linien/Spline-Algorithmus anwendet. Bei langsammeren
Wavemustern (was ja erwünscht ist) könnte man so mindestens 90% der Wave
einsparen und hätte den gleichen Effekt wie jetzt. Mein Waveeditor
arbeitet ja auch mit einem Splinealgorithmus. Allerdings wollte ich mir
das zeitlich nicht antun ;)


Gruß hagen

Hagen Re wrote:
> An den Waves, den leuchtmustern, muß noch verbessert werden. Dazu ist ja
> der beigelegte Waveeditor von mir auch da. Bisher bin ich noch im
> Langzeittest, zwecks Energieverbrauch und diesen ausgewogener
> hinzubekommen.
>
>>>-- TIM0_OVF_vect: Laden von _a, _b und _c in eine Funktion ausgelagert
>
> Hat das was gebracht ? Du musst auch immer darauf achten das die maximal
> nötige Anzahl an Takten dabei nicht größer 192 wird. Ansonsten benötigt
> die TOV ISR nämlich nicht mehr 3 sondern zb. 4 Timerzyklen und dann darf
> der höchste PWM Wert in den Waves 251 nicht überschreiten.
>

In wave[] ist der größte Wert 0xFA=250, also ist da noch einiges an
Luft, was die Ticks bis >251 (also >=252) angeht. Und Werte auf 251
kappen wäre auch nicht schlimm, weil man in dem PWM-Bereich eh kaum
einen Unterschied wahrnehmen dürfte. Kritischer wäre, wenn kleine
PWM-Werte nach unten beschränkt wären.

Das Laden in eine Func auszulagern dürfte nur unmerklich mehr an Strom
kosten, bringt aber 52 Bytes -- n Haufen Holz, wenn man um jedes Byte
kämpfen muss!

>>>-- Sortierung von _b gegen _c in eigener Funktion

Schon wieder raus, waren nur 4 Bytes. Wie gesagt, wenn's Program nicht
passt, passt's eben nicht. Hab aber inzwischen den Code anderwärtig
verändert.

> Da ist die Optimierung das Laden der PWM Dutycylce für a,b,c am Anfang
> dieser ISR wirklich lohnenswerter.

Sieht so aus jetzt:

load_fly:
        clr     _c_ocr
        ldd     _zl, y + WAVE_PTR                      // if fly->wave_ptr == 0 goto 1:  Fly don't ligthing
        ldd     _zh, y + WAVE_PTR+1
        sbiw    _zl, 0
        breq    1f
        ori     _flag, (1 << FLAG_WAVE)                // any fly is ligthning
        lpm     _c_ocr, z+                             // load next wave sample = fly->wave_ptr
        ldd     _c_ddr, y + WAVE_END                   // check if fly.wave_ptr >= fly.wave_end, finished lightning ?
        cp      _zl, _c_ddr
        ldd     _c_ddr, y + WAVE_END+1
        cpc     _zh, _c_ddr
        brne    0f
        clr     _zl                                    // if finish setup fly.wave_ptr = nil
        clr     _zh
0:      std     y + WAVE_PTR  , _zl
        std     y + WAVE_PTR+1, _zh
1:      adiw    _y, SIZEOF_FLY                         // increment _fly_ptr by 1 fly
        ret

...
        rcall   load_fly
        movw    _a, _c
        rcall   load_fly
        movw    _b, _c
        rcall   load_fly
...

>>>Gibt's da noch Optimierungspotential?
>
> Wenig. Man kann immer noch was optimieren, allerdings bin ich nicht der
> Typ von Programnmierer der Stunden damit verbringt um schlußendlich das
> letzte 0.1% an besseren Code noch rauszuquetschen. Der Source dürfte für
> ein AVR GCC C Projekt schon ziemlich kompakt sein. Ich stand eben auch
> vor der Entscheidung den Source noch nachvollziehbar zu halten. Man
> könnte so einige C Funktionen noch nach Assembler portieren, meistens
> gewinnt man so nach meiner Erfahrung bis zu 50% an FLASH und es wird
> auch noch effizienter.
> 2k FLASH sind halt ziemlich schnell verbraucht wenn man in C
> programmiert.

>
>>>Ich würd gerne 11 LEDs
>>>anschliessen und die eine, die nicht antiparallel ist, zur
>>>Helligkeitsmessung nehmen.
>
> Ich kenne deinen konkreten Aufbau nicht. Du kannst erstmal nichwas an
> der HW verbesseren (habe ich schon getestet).

Bei der nächsten Bestellung werd ich mit nen ATtiny44 oder so für das
Projekt nehmen, da hat man ein paar Ports mehr zum Messen. Die Größe ist
ja kein Thema, eher die Bauhöhe und die ist gleich, und Preis ist für 1
Prokejt auch egal.

Prinzipiell geht's so:

LED-A = I/O-HIGH
LED-K = I/O-HighZ -> AnaComp -> InputCapture

Die entstehenden Ladungsträger bauen in der LED ein Potential auf, je
heller desto schneller. Hatte mal den Versuch gestartet, die
lichtabhängige Kapazität einer LED zu messen, aber das hat überhaupt
nicht gefunzt (mit Kondensatoren ging das bis runter zu 10pF oder so).

Prinzip da:

http://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=160444

>
> Man kann einen ADC Pin einsparen und hätte somit noch einen freien Pin
> zur Verfügung. Das geht so:
> Wir benötigen nur einen ADC Eingang der die Spannung am Solarpanel
> misst. Damit hast du deine Tag/Nacht==Helligkeitserkennung drinnen. Das
> Messen der AKKU Spannung wird geändert und erfolgt gegen die interne
> AREF von 2.56V/1.1V. Statt also mit einem eigenen ADC Pin zum AKKU
> dessen SPannung zu messen, mesen wir VCC gegen AREF, denn du arbeitest
> ja ohne Stepup Wandler direkt den AKKU am VCC Pin, richtig ?

Ja, hab ich ohne StepUp geplant, d.h. ich bin an 4V. Allerdings sehe ich
nicht, wie ich das mit AREF = 2.56 ausmessen kann. Bei einer VCC < 2.56
Volt ist der LiPOL wohl tiefentladen? Und bei "interner" Messung kann
ich kein Spannungsteiler anklemmen.

>
> Man könnte aber auch die Messung des Solarpanels noch wegoptimieren.
> Dann so wie du es vorschlägst über die LEDs selber. Dabei ist es egal ob
> die LEDs single oder double-antiparellel angeschlossen sind, denn man
> misst dabei ja die Kapazitive Ladungsmenge der LEDs um die Helligkeit zu
> ermitteln. Dürfte also auch mit antiparelle verschalteten LEDs gehen.

Wie gesagt, meine Versuche in die Richtung sind fehlgeschlagen. Bei 2
antiparallelen LEDs wird nur ein kleiner Sprom im Kreis fliessen und
sich kein Potential aufbauen können

>>Dann, soweit ich sehen kann, können alle Daten im RAM ebensogut
>>uninitialisiert sein nach RESET?
>
> Ja das geht schon und ich habe bei den Datenstrukturen/Register
> Belegungen/Initialisierung exakt darauf geachte das es uninitialisiert
> sein könnte. Allerdings habe ich das Linkerskript nicht dahingehend
> angepasst, einfach weil es dann für unerfahrene Leute nicht mehr
> verständlich wäre.

Hab ich so gemacht, geht bestimmt besser. Mit Linker-Skripten kenn ich
mich nähmlich net aus...

noinit.ld:

SECTIONS
{
    .nirvana : { *(.init4) }
}

Beim Link-Aufruf (avr-gcc als Linker) gibt man zusätzlich als Optionen
an

avr-gcc ... noinit.ld -Wl,--section-start,.nirvana=0xa00000

> Nungut, ich selber bin mit der Simulation auch unzufrieden. Die Waves
> müssen länger und ruhiger leuchten, was aber über den Waveeditor ja
> leicht anpassbar ist.

Am einfachsten wäre es doch, den gleichen Datensatz nicht nur 1x sondern
zB 4x hintereinander zu nehmen. Aber seh noch nicht wo ich da was
aufbohren müsste.

> Ein weiterer Unterscheid ist die Anzahl, mit 12 LEDs ist man im Grunde
> schon unrealistisch beschränkt.

Für ein Glas in das doch ok, da wäre der Effekt mir 1 LEDs bestimmt
schon auch faszinierend für Deine Nichte.

> Übrigens denke ich das du deinen zeitlichen Aufwand enorm reduzieren
> könntest wenn du 20 Cent mehr investieren würdest, nämlich in einen
> ATTiny45V statt einem 25'er. Das beseitigt all deine Problem mit dem
> geringsten Aufwand ;) (ich weiß das man als Hobbybastler immer das
> verbauen möchte was man da hat, aber in einem solchen Fall denke ich
> pragmatisch).

Jo, bei der nächsten Bestellung. Hab den ATtiny25 eben hier und der ist
bin-kompatibel zum 45. Aber 2K sind schon gut, weil dann würde das in
nen ATtiny2313 passen, und der hat leider keinen großen Bruder.

> Achso, du könntest auch die Wave[] kürzer machen. Statt mit 32 Waves zu
> arbeiten zb. nur mit 16 Waves. Das spart dann schonmal in Wave_Data[]
> exakt 96 Bytes FLASH. Dann noch Wave[] selber verkürzen. Starte einfach
> mal im Ordner \Windows\ die WaveEditor.exe und lade dort die Wave.dat.
> Du kannst dann mit der Maus oben im Waveeditor die Samples verschieben
> und somit kürzere Waves bzw. deren Anzahl verändern.

Die Anzahl der Waves wollte ich eigentlich so lassen, auch wenn die
mächtig Flash saugen.

Weiß ja auch net, wie Du an wave_data[] rangekommen bist. Wenn die
Indizes durch 4 teilbar wären, könnte man statt der Adressen den durch 4
geteilten Index in wave[] speichern und zur Laufzeit die Adresse
ausrechnen. Geht bestimmt in deutlich weniger als 64 Bytes.

>Ohne die Datenblätter im Detail verglichen zu haben: Was müsste man
>ändern um den Code auf einen Tiny44 anzupassen?

Das müsste eigentlich sehr einfach möglich sein, da keine speziellen
HW-Feasture benutzt wurden, ein besserer Timer reicht. Das ganze Projekt
dürfte auf fast allen AVRs mit mäßigen Aufwand portierbar sein, solange
sie einen ADC, WatchDog-ISR und Timer mit Timer Overflow ISR und Output
Compare ISR haben.
Allerdings muß man den Pulsstrom der LEDs durch das vergrößerte
Multiplexing bei mehr LEDs immer höher treiben und das geht auf Grund
der max. Ströme des AVRs nicht. Somit wird man immer an eine Grenze
stoßen ab der die LEDs in ihrer maximalen Gesamthelligkeit immer weiter
abnehmen. Ich denke für das Glühwürmchenprojekt kann man noch einen Pin
mehr benutzen um dann 20 LEDs statt 12 LEDs zu treiben. Bei noch einem
Pin mehr wären das dann schon 30 LEDs und dann dürfte das
Multiplexingtiming so schecht werden das die LEDs nicht mehr voll
getrieben werden können.

Gruß Hagen

>mit mehr LEDs spürbar interessanter aussieht?

Nein nicht probiert. Je nach Betrachtungsabstand kann man ab 2 Meter eh
nicht mehr exakt unterscheideen welche der 12 LEDs gerade geblinktert
hat. Mehr LEDs würden also nur dann Sinn machen wenn man sie auch
räumlich weiter voneinander entfernen möchte, sprich größerers Glas
benutzen möchte. Dann leidet aber die Glaubwürdigkeit der Konstruktion,
denn keiner fängt Glühwürmchen in einer Vitrine ;)

>Beim Tiny44 könnte man ja zwei getrennte Ketten machen.

Das wiederum ist möglich und man könnte die Software dahingehend
anpassen.

Gruß Hagen

Hallo,

da ich gerade eine bestellung bei Reichelt fertig mache wollte ich mir
auch mal eben die paar sachen für dieses nett Projektchen hier mit in
den Korb werfen. 10µF Keramik-Kondensatoren habe ich noch rum liegen.
Der Maxim sollte auch irgendwann kommen.
Nun muss ich noch die passende Drossel für L2 finden.
Welches model von Reichelt wäre denn da empfehlenswert und würde ins
layout passen?
Ich hätte zwar noch eine sehr kleine Würth Speicherdrossel da, aber die
hat nur 2,2µH. Das Datenblat bleibt da leider etwas schwammig, was die
Induktivität angeht.
Ach ja, in Hagens Schaltplan stehen 150µH dran, das ist ja nun ganz
ordendlich mehr. Was denn nun richtig?

viele Grüße

Aike

5-10uH, besser sind 10uH mit 500mA Sättigungsstrom der Spule. Dann
arbeitet der DC-Konverter schon bei 0.8V am Eingang.

Gruß Hagen

So, Drossel und leds sind da, 0603 sind doch recht klein ;-)
Mal sehen wie lange Maxim bruacht bis der 1724 da ist.

wenn ich erfolg habe oder auch nicht sag ich mal bescheid

vielen Dank

Aike

Super, es scheint aber noch einen kleinen Bug in der Software zu geben.
Die Art und Weise wie per ADC die Akku-Spannung und Solarzellen-Spannung
gemessen wird muß ich nochmal umändern. Es scheint so das wenn der Akku
schön voll ist, dann Nachts über die Schranke zum Einschalten des
Blinkens der LEDs, also die Messung der Solarzellenspannung,
fehlschlägt. Das führt dazu das mehrere Tage lang die LEDs nachts nicht
leuchten wenn sie es eigentlich sollten. Nach par Tagen fängt sich dann
die Software und das Projekt läuft anstandslos, bis zum nächsten
"Aussetzer". Nungut, ich verkaufe es gerne als Feature, aber es ist ein
Softwarefehler denn ich demnächst nochmal korregieren muß.

> 0603 sind doch recht klein ;-)

Jupp und dann noch 0.2er Kupferlitze dranlöten kann eine Herausforderung
sein. Ich habe es meditativ gesehen und fast 5 Stunden für die 12 LEDs
an 6 Strippen benötigt, und war dann kurz vorm Nirvana fertig ;)

> Mal sehen wie lange Maxim bruacht bis der 1724 da ist.

eine Woche. Ich habe noch in der selben Woche der Bestellung die
Lieferung erhalten.

> So, Drossel...

Du redest immer von Drossel, meinst aber hoffentlich eine
Speicherdrossel bzw. Induktor. Wichtig ist für den MAX1724
- Induktivität ca. 10µH mit 500mA Strombelastbarkeit, also
Sättigungsstrom
- am Eingang und Ausgang nicht zu große Kondensatoren, Low-ESR
selbstverständlich, ich habe X7R verbaut geht auch, sie sollten aber
nicht mehr als 4.7µF haben, ich habe 1µF drinnen sekundär und 470nF
primär weil dort ja auch der leistungsfähige Akku sitzt

Über die Vorgehensweise der ersten Test habe ich oben schon was
geschrieben. Zuerst deaktiviert man in Software die ADC Messungen, also
Spannungsüberwachung Akku und Solarpanel. Das Projekt wird also so
laufen als wenn es permanent Nacht ist. Damit saubt man einen extern
voll geladenen Akku beim ersten Langzeittest vollständig leer. Man misst
dabei die Zeitspanne die dafür benötigt wird. Dann aktiviert man in
Software die ADC Messungen, aber nur die Akku Überwachung. Nun wird das
Projekt immer dann leuchten, egal ob Tag oder Nacht, wie der Akku im
vorgesehen Spannungsbereich liegt. Nun misst man wieder die Zeitspanne
bis der Akku aufgeladen ist. Als letztes dann auch die ADC Messung des
Solarpanels aktivieren.

Gruß Hagen

Hallo,

so ein Bug ist natürlich nicht so schön, wie oft kommt der denn vor? Wie
das mit dem messen der Solarspannung genau funktioniert muss ich mir
nochmal genauer ansehen wenn ich das aufgebaut habe. Habe den Code auch
noch nicht so genau gelesen, mache ich dann wenn ich auch mal nachmessen
kann. Vielleicht kann ich dann ja auch selber was dran tun.

2 Stunden habe ich für die Leds nicht gebraucht, aber mir sind leider 5
Stück Kaput gegangen jetzt habe ich noch genau 12 über für ein
eventuelles 2. Glas für meine Freundin ;-) man muss die doch sehr
vorsichtig behandeln.
Ich habe mir vorher die stellen an die ich die leds löten wollte mit nem
großen Lötkolben mit 460° abisoliert und dann habe ich die dräte an
diesen stellen verlötet und die Dräte dann verdrillt. Danach dann das
Lötzin wieder weg machen, dann ist es nicht mehr so schwer die leds
richtig zu positionieren.


> Du redest immer von Drossel, meinst aber hoffentlich eine
Speicherdrossel bzw. Induktor.

Ja, ich meine eine Speicherdrossel. Habe die L-PIS2408 von Reichelt
genommen, die sollte gehen denke ich.

> am Eingang und Ausgang nicht zu große Kondensatoren, Low-ESR
> selbstverständlich, ich habe X7R verbaut geht auch, sie sollten aber
> nicht mehr als 4.7µF haben, ich habe 1µF drinnen sekundär und 470nF
> primär weil dort ja auch der leistungsfähige Akku sitzt

Nanu? Ich habe eigentlich vor 10µF X5R zu nehmen, die habe ich halt noch
da. Ich hätte jetzt nicht unbedingt gedacht das da größere Kondensatoren
schaden können. Was ist denn da der Grund für?

Deine Erläuterungen zur Inbetriebnahme hier im Thread habe ich schon
aufmerksam gelesen, bin mal gespannt ob das alles auf anhieb klappt. Ich
habe mir bei Pollin jetzt auch 3 Solarlampen und zwei von diesen neuen
NiMhLi Akkus geordert, hast du da schon drauf umgerüstet?

viele Grüße

Aike

Wer Lust hat, kann sich ja mal diese Links ansehen. Auch die
Google-BILDERsuche nach pummer brngt einiges zu diesem Thema.

In anderen Ländern existiert eine regelrechte und nicht kleine Szene,
die sich ausgiebig mit diesen Dingen beschäftigt. Hier isn D ist mir das
nicht bekannt, oder hat da jemand andere Infos?

Die Links bringen jede Menge Schaltungen und Anregungen, besonders auch
Ladeschaltungen für Accus und Goldcaps:

http://www.solarbotics.net/
http://www.solarbotics.net/bestiary/1120_pummer_gal.html


Jochen Müller

>so ein Bug ist natürlich nicht so schön, wie oft kommt der denn vor?

so 1-2 mal im Monat, dann für 2-3 Tage.

> Nanu? Ich habe eigentlich vor 10µF X5R zu nehmen, die habe ich halt noch
> da. Ich hätte jetzt nicht unbedingt gedacht das da größere Kondensatoren
> schaden können. Was ist denn da der Grund für?

Passt schon so. Viele denken mehr ist besser, stimmt aber nicht. Ein
Stepup erzeugt Stromspitzen die ausgeglichen werden müssen. Dabei
entscheidet primär die Kombination aus Input Kondensator + Spule +
Output Kondensator über die Effizienz, Frequenz und max. Leistung des
Stepups. Um mit dem MAX1724 bei möglichst kleinen Spannungen schon
arbeiten zu können empfiehlt der Hersteller die Inuktivität ein bischen
größer zu dimensionieren. Der AVR läuft schon ab 2.7V stabil und der
Stepup sollte der 3V oder 3.3V Typ sein, selbst bei 300mV Ripple am
Ausgang des Stepups also kein Problem. Die Größe der Kapazitäten hat nun
einen entscheidenden Einfluß auf die Verluste die durch den Stepup
entstehen. Auf Sekundärseite haben wir den Akku, meistens ein NiMH mit
1200mAh und damit ein guter Energielieferant für einen Stepup. Wir
können also die Eingangskapazität des Stepups kleiner halten und kommen
so einfacher an Caps. mit kleinem ESR ran. Dieser ESR ist für die
Verluste im Cap verantwortlich. Gleiches gilt auch für die Sekundärseite
des Stepups.

>NiMhLi Akkus geordert, hast du da schon drauf umgerüstet?

Nein bisher nicht und es zeigt sich auch das bei meinem Aufbau der Akku
ständig gut geladen ist. Das Problem ist halt das man über die
Solarpanelspannng die Entscheidung trifft ob es Tag oder Nacht ist.
Viele der besseren Gartenleuchten benutzen dafür einen Photowiderstand,
die billigeren Leuchten werten ebenfalls das Solarpanel aus. Dies kann
aber problematisch sein da auch Infrarotstrahlung eine Spannung im
Solarpanel erzeugt. Dh. wenn es Nachts sehr dunkel ist aber auch sehr
warm bzw. aufgeheizte Wände noch Wärme abgeben, dann liefert das
Solarpanel zuviel Spannung und die Software kann die Nachtphase nicht
als solches erkennen. Ich denke das dies auch der "Bug" in der Software
ist. ZZ. verändere ich die Meßmethode für das Solarpanel und Akku und
passe die Thresholds besser an. Man könnte die Schaltung auch umbauen
und mit einem Photowiderstand + Spannungsteilerwiderstand erweitern,
aber das wollte ich vermeiden um Strom zu sparen.

Gruß Hagen

Hallo mal wieder,

ich habe jetzt obwohl mir noch die Solarzelle, der richtige akku und der
Max1724 fehlen mal einen kleinen Test gemacht.
Ich habe einen noch hier zu testzwecken rumliegenden TPS61200 genommen,
den auf 3,0V eingestellt und an VCC und Masse gehängt.
Dann die Software angepasst so das immer Nacht ist.
Soweit so gut, nach 12 Minuten fangen die Leds an zu leuchten, sieht
schon ganz nett aus.
Leider ist das leuchten noch viel zu dunkel, was wohl an den
Vorwiederständen liegt, die ich verwendet habe. Hatte nurnoch 1k
Widerstände da, das macht dann 1mA, die Leds würden aber 2 mA benötigen,
sind ja sowiso nicht so sehr hell die Lowcurrent-Leds.
Daher muss es wirklich stockduster sein, damit man was sieht.
Naja, Habe gerade noch ein paar 472Ohm miniMelfs gefunden, mal sehen ob
ich die irgendwie auf die Pads bekomme ;-)

Eine sache ist allerdings noch seltsam. Wenn ich den Programmier-Adapter
anstöpsel dann ist sofort Ende mit leuchten. Auch die Stromaufnahme von
4µA im Standby auf ca. 25µA.
Nach dem Programmieren steigt dann die Stromaufnahme auf irgendwas
größer 1mA was das Multimeter dann nicht anzeigt.
Programmieradapter ab, reset und dann gehts los.
Dafür habe ich noch keine rechte Erklärung.

Auf jeden Fall schonmal ein sehr cooles Projekt!

viele Grüße

Aike

Kleiner Nachtrag,

hatte bei meinen Vorwiderständen natürlich total übersehen, das das ja
ne Matrix ist. Habe jetzt auf 100Ohm reduziert, jetzt sind die Leds auch
was heller.

>Eine sache ist allerdings noch seltsam. Wenn ich den Programmier-Adapter
>anstöpsel dann ist sofort Ende mit leuchten. Auch die Stromaufnahme von
>4µA im Standby auf ca. 25µA.
>Nach dem Programmieren steigt dann die Stromaufnahme auf irgendwas
>größer 1mA was das Multimeter dann nicht anzeigt.
>Programmieradapter ab, reset und dann gehts los.
>Dafür habe ich noch keine rechte Erklärung.

1. Sobald der Adapter angeschlossen ist wird ein Strom für die RS232
verbraucht.

2. die effektive Stromaufnahme kann also nur exakt ermittelt weren wenn
der
Adapter nicht angeschlossen ist

> Habe jetzt auf 100Ohm reduziert...

könntest sie ohne Probleme noch weiter reduzieren.

Gruß Hagen

Hallo mal wieder,

leider bin ich immer noch nicht fertig, der Max1724 ist leider noch
nicht da :-(
Dafür sind heute von Pollin die solar-Lampen gekommen.
So ne schöne Solarzelle wie bei dir ist da aber leider nicht drin, da
sind einfach vier von diesen Streifen in den Deckel eingegossen. Habe
gerade mal gemessen, in der prallen Sonne bringt die 2,5V und 50mA
Kurzschlussstrom.
So muss ich dann mal schauen, wie ich die möglichst elegeant da raus
sägen kann und hoffen, das das reicht.

viele Grüße

Aike

So, da bin ich mal wieder. Habe inzwischen Post von Maxim bekommen.
Direkt von den Phillipinen. Habe den Max1724 direkt eingelötet.
Leider funktionert der nicht. Ich messe am Ausgang nur 0,8V.
Ich vermute mal, das das jetzt kein simples Standard-Problem ist was
sich aus der Ferne diagnostizieren läst, oder?

Richtig rum eingelötet ?

Das sollte man doch eigentlich nicht falsch rum einlöten können, auf
einer seite fehlt doch der pin in der Mitte.

Stimmt. Ich habe zuerst nur den Stepup aufgebaut, also ohne AVR. Diesen
dann getestet und ging auf anhieb. Danach AVR drauf und programmiert.

Wenn es also bei dir nich geht dann vermute ich das deine "Drossel" +
Kondensatoren nicht ganz passen, oder du hast nicht richtig verlötet.

>Ich messe am Ausgang nur 0,8V.

Wieviel Spannung hast du am Eingang des Stepups ? Es sollten erstmal
mehr als 0,8V sein da ansonsten der Stepup nicht anschwingt. Wenn er
erstmal läuft dann saugt er den Akku auch unter 0.8V leer, bei mir bis
0.65V runter.

Gruß Hagen

Hagen Re wrote:
> Wenn es also bei dir nich geht dann vermute ich das deine "Drossel" +
> Kondensatoren nicht ganz passen, oder du hast nicht richtig verlötet.
Werde ich morgen nochmal gründlich prüfen. Vielleicht sitzt doch noch
irgendwo ein Tropfen Lötzin. Induktivität und Kondensatoren sollten
eigentlich passen. Aber wer weiß.

> Wieviel Spannung hast du am Eingang des Stepups ?

1,29V frisch von Akku.

viele Grüße

Aike

>1,29V frisch von Akku

also damit läuft mein Stepup wunderbar.

Gruß Hagen

Meine Güte, wie früh bist du denn wach?

Nun gut, mein Stepup läuft jetzt auch, die Spule war an einer Seite wohl
nicht richtig verlötet.
Leider funktioniert jetzt der µC nicht mehr, aber den Grund dafür finde
ich hoffenlich noch. Der hat ja vorher mit externer Versorgung
funktioniert.

>Meine Güte, wie früh bist du denn wach?

Meine Güte, wie früh bist du denn noch wach? wäre die richtige Frage.
Wenn es nach mir ginge würde ich am liebsten 24h pro Tag wach sein ;)

Ansonsten: du wirst das Ding schon zum Laufen bringen, toitoi.

Gruß Hagen

Oder auch so ;-)

Nun denn, ich will jetzt nicht mit allen Details rumnerven, aktueller
Status ist das es jetzt läuft, der Tiny hat wohl was ab gekrigt und
wurde nun ersetzt.
Ich muss jetzt mal ausgibig testen.

Vielen vielen Dank auf jeden Fall für dieses tolle Projekt und die viele
Hilfe von dir!

Aike

Hallo doch nochmal,

ich habe mich jetzt zu den etwas interessanteren Problemen vor
gearbeitet.
Also erstmal ein paar grundsätzliche Fragen damit ich weiß, das ich das
alles richtig verstehe.
1. Wenn ich die Spannung der Solarzelle zwischen SOL- und BAT+ messe,
dann werde ich max. eine Spannung knapp über der Batteriespannung messen
können, also ca. 1,3V? Weil die Spannung der Solarzelle mit last
einbricht.
2. Wenn ich mit im RAM die werte für sol_volt und bat_volt ansehe, dann
sinkt der wert bei steigender Spannung der Solarzelle. Bis
sol_volt=bat_volt ist?

Gut, so kann ich es jedenfalls nachvollziehen.

Dann also zum Problem. Das Programm wechselt offensichtlich nicht in den
Nachtmodus. Wenn ich das Solarpannel umdrehe, dann habe ich im Speicher
sowas stehen wie: e5 01 und für bat_volt f5 01. Also 485 zu 501.
Da scheint es mir auch logisch das sol_volt>bat_volt nicht erfüllt
werden kann.

Wo ist also mein Fehler?

viele Grüße

Aike

Mach mal

if (sol_volt >= bat_volt) &&

draus. Wir messen BAT+ minus Solarpanel Spannung. Wenn es Nacht ist
liegt ja SOL- über die Diode an Akku-. Exakt an SOL- messen wir mit dem
ADC. Bei Nacht degradiert das Solarpanel zu einem Widerstand, dh. an
SOL- messen wir quasi die Akkuspannung abzüglich der minimalen
Solarpanelspannung.

Du könntest, um den Source an dein Solarpanel anzupassen, es auch so
abändern:

uint16_t sol_volt = ADC + x; // x für Spannung des Solarpanels bei
Dunkelheit

Aber Recht hast du, denn an diesem Punkt vermute ich auch bei meinem
Projekt noch eine Schwachstelle. Solarpanels sind halt nicht besonders
gut als "Tag/Nacht" Sensor geeignet.

Gruß Hagen

Edit: aber Vorsicht mit dem Messen durch ein Multimeter. Die "ideale
Diode" die SOL- von AKKU- trennt falls Solarspannung < Akkuspannung ist
enorm hochohmig, ergo sehr empfindlich. Das Multimeter/Tastkopf Oszi
beeinflusst diese Schaltung. Defakto kann man die korrekte Funktioon
dieser Diode nur per Strommessung korrekt messen.

Hallo,

seltsames Problem. Ich habe jetzt mal Probehalber zum sol_volt wert 200
hinzu addiert, damit komme ich einen bereich bei dem einfaches umdrehen
des Panels dazu führt das ich einmal einen sol_volt Wert habe der
deutlich über bat_volt liegt und einmal einen der deutlich darunter
liegt. Ich habe mir jetzt mal alle wichtigen Werte ins SRAM geschrieben
- auch ein flag das mit das ergebnis der If Abfrage ausgibt.
Aus den Werten im SRAM geht eindeutig hervor, das isnight gesetzt ist,
aber nix passiert.
Schreibe ich allerdings als letzte Zeile in die funktion measure_isnight

flags |= FLAG_ISNIGHT

dann glimmen die Leds direkt los, so wie es am Anfang sein soll. Leider
durchblicke ich den rest des Programms noch nicht so weit, das ich da
einen Grund für erkennen könnte.

Weißt du noch Rat?

viele Grüße

Aike

Jo, warte par Minuten ;) Der Test auf Nacht wird ja nur so ca. alle 6
Minuten durchgeführt. Es kann dann noch weitere 6 Minuten dauern bis das
System loslegt und blinkt. Ich habe dies absichtlioch so konstruiert da
man so quasi einen "Lowpass Filter" erhält und das System nicht sofort
jedesmal anfängt zu leuchten nur weil kurzzeitig eine Verdunklung der
Solarzelle erfolgte. Und zusätzlich sparrt es Strom da der AVR nach dem
ADC auslesen erstmal für 6 Minuten in den Powerdown geht.

Ansonsten wäre es angebracht wenn wir per Mail weiter machen. Denn dann
kannst du mir auch entsprechende Source senden und ich schaue drüber.

Gruß Hagen

Hallo,

da Hagen im Moment nicht Antwortet, versuche ich mal zu helfen.

Kennst du den Fuses Calculator?

http://palmavr.sourceforge.net/cgi-bin/fc.cgi?P_PR...

So sind die Fuses auf deinem Screenshot gesetzt, das sieht glaube ich OK
aus.
Allerdings kann ich nicht nachvollziehen, was du dann machst. Der
nächste Schritt wäre jetzt den Bootloader auf den Tiny zu laden. Dann
musst du dir noch diesen 1Wire adapter bauen damit du mit dem Bootloader
kontakt aufnehmen kannst.
Das würde ich als erstes angehen.

viele Grüße

Biertrinker

Hi!

Muss die Spannung an pin3 nicht kleiner als an pin2 sein ?
Also spannung solar < spannung akku -> glühwürmchen an

Gruss

Hallo,

MEASURE_INTERVAL verändert nicht die Ausführungsgeschwindigkeit selbst,
sonder nur die Abstände zwischen den Messungen. Die Glühwürmchen
"blinken" schon recht schnell, das würde ich als normal ansehen. Ich
denke es ist ok so und du solltest Akku und Solarzelle anschließen und
dann weiter schauen.

Ja, das meinte ich ja schon, die Glühwürmchen blinken normal schneller
als man erwarten würde.

viele Grüße

Biertrinker

Wenn du das original übersetzt, stimmt dann dein hex mit dem original
überein ?
Oder evtl mal die asm listings nachm gcc vergleichen.

Meine Platine ist leider noch nicht fertig, teste das aber auch die Tage
(kann noch dauern...)

Gruss

if (--idx > 7) idx = (idx & 0x07) | (1 << WDP3);

ist natürlich richtig. Idx enthält die "Bitcodierung" des WDT Timeouts
umgerechnet aus dem der Funktion übergebenen Timout Wert in WDT Ticks.
Dazu dienen ja die WDP? Bits. Davon liegen 3 Bits im untersten Nibble
aber das WDP3 Bit liegt eben pysikalisch woanders. Ergo Idx muß mit 0x07
maskiert werden und dafür das WDP3 Bit rein-ge-odert werden.

Beim Setzen der verschiedenen WDT Betriebsmodis muß man aber aufpassen.
Wir benötigen nur den periodischen WDT Interrupt. Dazu darf WDE nicht
gesetzt werden und statt dessen nur WDIE. Setzt man WDIE und WDE dann
wird nur einmalig ein WDT IRQ ausgelösst. Wird in dieser ISR nicht
explizit erneut das WDIE Bit gesetzt, es wird bei der Kombination WDIE +
WDE autom. per Hardware vor dem Einsprung in die WDT-ISR gelöscht, dann
würde der nächste WDT Timeout einen echten WDT-Reset auslösen. Benutzt
man nur WDIE, also ohne WDE, so wird das WDIE Bit nicht mehr per
Hardware vor dem Einsprung in die WDT ISR gelöscht. Somit bleibt der
WDIE permanent aktiviert ohne das man sich darum weiter kümmern müsste.
Und exakt diesen Modus wollen wir benutzen, da der WDT nur als, zwar
rel. ungenauer, Timer benutzt wird der aber eben auch im Power Down
Sleep Modus noch arbeitet.

Wird also in wdt_setup() das WDE Bit ebenfalls gesetzt so verhält sich
das Projekt garaniert nicht so wie es sein sollte. Nach dem ersten
Auslösen der WDT-ISR, in Datei isrs.S -> WDT_vect, würde der AVR beim
nächsten WDT Timout einen HW-Reset machen.

Danke für das Aufspüren dieses Bugs (es gibt keine Software ohne Fehler
;)

Das Projekt basiert also darauf das es die minimale Zeitdauer bis zum
nächsten Aufleuchten eines/mehrer Glühwürmchen, so effizient wie möglich
in variable WDT Timouts umrechnet und somit im Power Down Sleep Modus
verbringt. Diese Zeitspannen sind variabel und somit auch die WDT Phasen
im Sleep Modus.
Bei WDT Timouts die gestaffelt als Potenz zur Basis 2 vorliegen ist
zwangsläufig die binäre Codierung der effizienteste Pfad um mit wenigen
WDT Timouts einen Gesamttimout zu zerstückeln. Pure Mathematik.

Gruß Hagen

Allerdings muß man beim ersten Setzen des WTCRs die Kombination WDE +
WDCE benutzen und beim zweiten Setzen des Registers darf dann das WDE
Bit nicht mehr gesetzt sein. Das wäre aber bei der Maskierung mit 0x0F
uU. aber der Fall.

Warum ich diesen Fehler bei meinem Projekt nicht sofort bemerkt habe ist
mir aber selber ein Rätsel ;)

Gruß Hagen

@Randy:

Du hast also die komplette Auswertung vom Solarpanel und Akkuspannung
deaktiviert und gibts immer das Flag FLAG_ISNIGHT.

Dann sollte das Teil eigentlich unendlich lange so weiterlaufen und
nicht seinen Dienst irgendwann einstellen, es sei denn die
Versorgungsspannung bricht ein, sprich deine Akkus wären leer.

Falls all dies nicht zutrifft dann muß noch ein Bug in der Software
sein. Ich könnte mir nur einen Überlauffehler bei den Berechnungen
vorstellen. Das könte dann dazu führen das eine Wartezeit berechnet wird
die sehr groß ist. Bei zb. dem Wert 0xFFFF als Wartezeit wären das dann
ca. 17 Stunden.

In Main() die Variable Timout enthält diesen Gesamttimeout in WDT Zyklen
a 16ms. Gesetzt/berechnet wird sie aus dem Hungry Wert der Firefly
Datenstruktur. Also in der Funktion update_fireflies() der Rückgabewert
Food.
Du kannst dir das also so vorstellen das eine Zeitspanne von 16ms des
WDT quasi 1 Energiepunkt als Futter für ein Glühwürmchen darstellt. Je
höher der Wert Hungry eines Fireflys ist desto länger die Zeitspanne in
16ms Schritten bis es genügend Energie gesammelt hat und erneut leuchten
kann. Wenn es dann leuchtet oder seine Nachbarn wird der
Energieverbrauch des Leuchtmusters (Dauer * Intensität) auf seine
Energiebilanz addiert, also das Member .Hungry inkrementiert.
Das einzige Zufallselement ist also nur die Auswahl in welchem
Leuchtmuster ein Glühwürmchen leuchten soll, alles Andere leitet sich
davon deterministisch ab. Da aber jedes gerade leuchtende Glühwürmchen
auch die Energiebilanz seiner Nachbarglühwürmchen beeinflusst -> Hälft
von der Hälfte von der Hälfte usw. wird es trotz Zufall zu Phasen kommen
müssen bei denen durchschnittlich 50% der LEDs quasi fast zu gleichen
Zeitpunkt gleichzeitig leuchten. Also so als ob sie gegenseitig mit
Leuchtmustern aufeinander antworten. Forciert wird dieses Verhalten nun
auch noch durch das Hungry_Threshold. Diese Variable wird im Laufe der
Zeit innerhalb eines Fensters hin und her schwanken und bestimmt wie
häufig bzw. schnell sich diese Synchronisation der Leuchtmuster
einstellen.
Es sollte also schon so sein das es längere Phasen gibt bei denen nichts
leuchtet. Dann sollte sich das Einzelleuchten langsam aufschauckeln bis
zu dem Punkt wo überdurchschnittlich viele und gleichzeitig leuchten.
Dieser Prozess geht über Stunden.

Bei mir, mittlerweile 3 Nachbauten, geht das auch immer exakt so.

Allerdings habe ich ebenfalls bei einem der Nachbauten das Problem das
sich  nach einiger Zeit garnichts mehr tut, so als ob es hängt. Nach
Austausch der Akkus ist das aber beseitigt und so vermute ich eher das
es an den Akkus/Stepup oder ADC Auswertung der Akkuspannung liegen wird.

Gruß Hagen

Danke für deine Mühen. Weiter oben sagte ich ja schon das dein
beobachtetes Verhalten eigentlich nur auf einen Überlauf in den
Berechnungen hindeutet. Ich selber hatte diese Probleme in der Form
nicht, werde aber meine Aufbauten mit deinen Änderungen updaten.
Technisch möglich wäre es nämlich das der PRNG bei dir so ungünstige
Waves/Leuchtmuster auswählt das der Timeout überläuft. Auf Grund meines
"Sparsamkeitskomplexes" habe ich aber die meisten Variablen als 16 Bit
deklariert statt auf Nummer sicher zu gehen und sie int32 zu
deklarieren.

Andererseits müsste bei einem Überlauf im uint16_t es zur Konsequenz
haben das die Dunkelphasen künstlich verkürzt werden. Dh. wenn im
Timeout ein Wert wie 0xFFFF errechnet wurde dann ist dies im Grunde auch
korrekt so, da bis dahin ja noch kein Überlauf erfolgte. Entsteht nun
ein Überlauf von zb. +2 so würde Timout den Wert +1 annehmen und somit
der WDT noch 16ms warten und dann die Glühwürmchen durch den Aufruf
update_fireflies() beginnen zu leuchten.

Das was du mit deiner Änderung also machst ist nichts anderes als einen
Maximal-Timout von 0x7FFF einzubauen. Man könnte auch gleich so arbeiten

if (timout >= XYZ) timout = XYZ;

wobei XYZ eine nach belieben einstellbare Konstante wäre.

>Ob sie wieder anfangen weiss ich noch nicht, sie stehen erst zu kurz im
>dunklen Schrank 8)

Bei meinen vorgegebenen Intervalen sollten sie nach spätestens 12
Minuten wieder beginnen zu leuchten.

Gruß Hagen

>Ne, ich meinte das genau anders rum:

>timeout -= wdt_setup(timeout);

Deine Vermutung eines Problemes dürfte aber nicht auftreten ;)

wdt_setup() bekommt den aktuellen Timeout als Paramater übergeben. Diese
Funktion errechnet nun einen realen WDT Timout, und setzt den WDT auch,
der immer kleiner oder gleich dem übergebenen Timout ist. Also wenn
Timout den Wert +2 hätte dann gibt wdt_setup() einen Wert zwischen 1 bis
gleich 2 zurück.

Also angenommen Timout ist 512+256+128 dann würde wdt_setup(Timout) im
1. Aufruf 512 zurückgeben müssen. Im 2. Aufruf dann 256 und im 3. Aufruf
dann 128. So zerstückelt wdt_setup() den Timeout Wert in Zeitabschnitte
die man im WDT auch benutzen kann, es sind immer Potenzen zur Basis 2.
Nimmt man also den aktuellen Wert in Timout und multipliziert diesen mit
16 ms so hat man die Gesamtwartezeit die der WDT warten muß. Diese
Wartezeit wird so zerstückelt das man den WDT auch entsprechend
programmieren kann.

Wenn dann solltest du mal folgendes als Debug Code einbauen:

uint16_t t = wdt_setup(timeout);

if (t > timeout) printf("Error");

timout -= t;

Falls die Meldung "Error" erscheien sollte dann ist definitiv irgendwas
in wdt_setup() noch falsch.

Gruß Hagen

Jo Video wäre gut, ist mir nämlich nicht so gelungen wie man es mit
eigenen Augen in real sieht.

sieht doch gut aus. Besonders im ersten Video erkennt man wie die
Glühwürmchen aufeinander antworten ;) Auch die unterschiedlichen Waves
erkennt man gut. Bei mir ist es auf alle Fälle exakt genauso.

Damit nicht noch andere Nachbauer verzweifelt nach Fehlern suchen:

Mit der aktuellen Version des Winavr (Stand Mai 2009) läßt sich der
Source meiner Erfahrung nach NICHT wunderfrei compilieren. Es kommt zu
allerlei bunten Effekten.
Die von Hagen benutzte, ältere Version mit AVR-GCC 3.4.6 führt zu
verlässlichen Ergebnissen. Z.B. von hier:
http://sourceforge.net/project/showfiles.php?group...

Aber vielleicht weiss das ja auch schon jeder - außer mir. ;)

Nochmals Dank an Hagen für seine wertvollen Tipps!

In diesem Sinne
  Lothar

Lothar Merl schrieb:
> Damit nicht noch andere Nachbauer verzweifelt nach Fehlern suchen:
>
> Mit der aktuellen Version des Winavr (Stand Mai 2009) läßt sich der
> Source meiner Erfahrung nach NICHT wunderfrei compilieren. Es kommt zu
> allerlei bunten Effekten.

Einen Bug bekommt man mit -fno-split-wide-types weg. Probleme machen
aber u.U auch globale Register. GCC 4 optimiert die teilweise gnadenlos
weg, auch wenn man sie per -ffixed- "reserviert". Ob das nun ein Bug
oder ein Feature ist...?

> Die von Hagen benutzte, ältere Version mit AVR-GCC 3.4.6 führt zu
> verlässlichen Ergebnissen. Z.B. von hier:

Jo, nud der Code ist oft sogar dichter. Und Bugs hab ich bei dem noch
keine gefunden. :-)

Johann

das ist der Grund warum ich diese Version am häufigsten einsetze. Man
muß halt dann die nötigen Libs/Includes manuell auf den neusten Stand
halten.

Gruß Hagen

Hallo,
ich bin noch blutiger Anfänger, und wollte Fragen ob mein Gedanke
richtig ist?
Wenn ich die Glühwürmchen auf einen ATMEGA32 draufmache und den Code
abändere, kann es sein das dann statt der 4 Ausgängen für LED's dann 32
zur verfügung stehen würden?
LG
Michael

Ich hab keine Ahnung, aber wären die Änderungen etwa richtig so?
weil so wären es 29 * 2 LED's also insgesammt 58 LED's.
LG
Michael

Das wird so einfach nicht funktioniern.
Mit dem aktuellen Code für die PWM können nur 12 LEDs gesteuert werden.
Diese 12 LEDs werden pro PWM Durchlauf in 4 Gruppen unterteilt a 3 LEDs
die leuchten. Somit leuchtet eine LED pro PWM Zyklus nur 25% der Zeit.
Nun rechne es aus: 8MHz Takt  64 Prescaler  256 Schritte / 4 Gruppen =
122Hz LED Refresh Rate. Die PWM Software befindet sich in Datei isrs.s
und ist vollständig Assembler. Diese kann nur 4 Pins mit 12 LEDs
ansteuern. Dh. du musst diese schon erweitern/ändern damit dein Plan
funktioniert. Aber du musst auch das ganze Timing verändern damit deine
LEDs nicht zu langsam refesht werden. Es dürfte zu einem Problem werden
diese ISR Routinen noch weiter zu beschleunigen mit einem schnelleren
CPU Takt.

Beispiele für's Charlieplexing:

12 LEDs = 4 Pins = 25% jeweils 3 LEDs pro Zyklus, 4 Zyklen
20 LEDs = 5 Pins = 20% jeweils 4 LEDs pro Zyklus, 5 Zyklen
30 LEDs = 6 Pins = 17% jeweils 5 LEDs pro Zyklus, 6 Zyklen
42 LEDs = 7 Pins = 14% jeweils 6 LEDs pro Zyklus, 7 Zyklen
56 LEDs = 8 Pins = 12% jeweils 7 LEDs pro Zyklus, 8 Zyklen

Dh. bei 56 LEDs ergibt sich folgedenes PWM Timing:

8 mal hintereinander leuchten jeweils 7 LEDs mit in dieser Zeitspanne
einstellbarem Dutycycle in 256 Schritten. Deine LEDs müssen also mit
8mal höherem Strom betrieben werden im Vergleich zu einer direkten PWM.

Möchtest du 100Hz Refreshrate so ergobt das einen Timer Takt von
100Hz*256 Schritte pro LED * 8 Zyklen = 205kHz. Mit einem 16Mhz AVR /
205kHz = 78 Takte hast du maximal zur Verfügung für deine ISRs. Bei 8MHz
Takt nur noch 34 Takte.

Die PWM Software benutzt den Timer Overflow Interrupt und den Output
Compare Match Interrupt. Die Timer Overflow benötig die meiste
Rechenzeit. Jetzt im aktuellen Projekt sind es 192 Takte maximal. Damit
ist dauert dieser ISR Handler schon länger als er dürfte. Denn er dauert
länger als 1 PWM Takt der LEDs. Wir tricksen und nutzen nur eine maximal
einstellbaren Dutycycle pro LED von 0 bis 252. Die Output Compare Match
ISR ist dageben zeitlich unkritischer aus sich der notwenigen CPU Takte
für die ISR Handler. In dieser werden ja nur die in der TOV ISR
berechneten Werte aus dem SRAM gelesen und der PORTB/DDRB gesetzt. Diese
ISR darf niemals länger dauern als der Prescaler Wert des Timers. Die
jetzige ISR benötigt 18 Takte +4 Takte falls aus dem Idle Sleep
aufgerufen. Der Prescaler ist jetzt 64 und damit geht das gut. Für deine
56 LEDs am gleichen PORT ist diese ISR softwaremäßig 1zu1 identisch. Der
einzige Unterschied wäre das sie bis zu 7 mal pro Zyklus aufgerufen
werden kann statt nur bis zu 3 mal bei 12 LEDs.

Du hast also zwei Probleme:

1.) Der LED Strom muß 8 mal höher gewählt werden und die AVR Pins können
aber nur 20mA treiben. Da aber bis zu 7 LEDs pro Zyklus gleichzeitig an
ein 1 Pin Spaltenauswahl betrieben werden ist der maximal zulässige
Strom also 20mA/7 = 2.9mA pro LED. Bei 2.9mA / 8 = 363µA Dauerstrom pro
LED müssen deine LEDs noch ausreichend Helligkeit abgeben.

Im Gegensatz dazu 12 LEDs -> 3 LEDs in ein Pin -> 20mA/3 = 7mA/4 =
1.75mA Dauerstrom und ausreichend Helligkeit ist mit Low Current LEDs
ohne Problem möglich.

2.) den ISR-Handler für die TOV ISR musst du umschreiben damit diese 8
Zyklen für 7 LEDs + 1 Spalte macht. Das heist statt wie jetzt 4 Zyklen
somit 8 Zyklen und pro Zyklus nicht die Daten für 3 LEDs berechnen
sondern für 7 LEDs. Grob gerechnet brauchen wir ca. 64 Takte pro LED * 7
= 448 Takte für deine veänderte ISR. Da nun aber der PWM Takt auch noch
wesentlich höher sein muß bei deiner Anordnung hast du weniger
Rechenzeit zur Verfügung. Ich würde schätzen das du den Dutycycle der
LED nur von 0 bis 240 einstellen kannst.

Ich denke nur bis zu 20 LEDs können so sinnvollerweise angesteuert
werden. Das wäre aber keine Beschränkung aus Sicht der Rechenpower und
PWM Zeiten da man ja mit einer einstellbaren Heeligkeit von 0 bis 240
durchaus leben kann (also die hellen Helligkeiten wären weniger und da
wir logarithmisch die Helligkeit wahrnehmen könnten wir eh keinen
Unterschied feststellen). Zudem benötigt die jetzige Sofwtare auch nur
maximal 1.64% der CPU Zeit was sich bei deinem 56 LEDs nicht wesentlich
verschlechtern sollte. Problematisch ist nur die Reaktionszeit dieser
ISRs.
Das Hauptproblem dürfte der maximale Strom den du über die Pins für die
LED treiben kannst sein. Bei 56 LEDs ist nur ein Pin als Spaltentreiber
geschaltet und er muß den Strom der anderen 7 Pins = LEDs sinken/sourcen
können und das dann pro 7 LEDs nur 1/8'tel der gesammten PWM Zeit.

Wenn also eine LED mit 20mA Dauerstrom die hellste Helligkeit liefert,
dann sind das ein notweniger Pulsstrom in einer PWM betriebenen LED von
20*8 = 160mA. Diese 160mA pro LED muß 7'fach in den einen Spaltenpin,
ergo müsste der AVR pro Pin 1120mA sourcen/sinken können.

Umgedreht gerechnet: 20mA max. Strom pro Spaltenpin,  7  8 = 360µA LED
Konstantstrom. Die maximalste Helligkeit der PWM ist also vergleichbar
mit einer LED die mit 360µA Dauerstrom betrieben wird.

Ich weiß Thema "gepulste LEDs und nicht proportionaler, vermuteter
Zusammenhang zwischen Pulsstrom und Helligkeit", bitte keine Diskussion
dazu hier anfangen.

Gruß Hagen

Die TOV ISR ist so aufgebaut:

        push    _a_ocr
        push    _a_ddr

        push    _b_ocr
        push    _b_ddr

        push    _c_ocr
        push    _c_ddr

Hier temporäre Register für 3 LEDs sichern. Due bräuchtest 7 solcher
Registerpaare.

// fly a
        ldd     _zl, y +FLY0 +WAVE_PTR_L                    // if FLY0->wave_ptr == 0 goto 11:  Fly don't ligthing
        ldd     _zh, y +FLY0 +WAVE_PTR_H
        sbiw    _zl, 0
        breq    11f
        ori     _flag, (1 << FLAG_WAVE)                     // any fly is ligthning
        lpm     _a_ocr, z+                                  // load next wave sample = FLY0->wavr_ptr*
        ldd     _a_ddr, y +FLY0 +WAVE_END_L                 // check iff FLY0.wave_ptr >= FLY0.wave_end, finished lightning ?
        cp      _zl, _a_ddr
        ldd     _a_ddr, y +FLY0 +WAVE_END_H
        cpc     _zh, _a_ddr
        brne    10f
        clr     _zl                                         // if finish setup FLY0.wave_ptr = nil
        clr     _zh
10:     std     y +FLY0 +WAVE_PTR_L, _zl
        std     y +FLY0 +WAVE_PTR_H, _zh
11:

Holt aus der WAVE Table den aktuellen PWM Wert für eine LED. Im
aktuellen Source ist dies also 3 mal vorhanden du musst es 7 mal machen.

// load DDRB/PORTB values from ddr_data for current 3 flies
        ldi     _zl, lo8(ddr_data)
        ldi     _zh, hi8(ddr_data)
        add     _zl, _ddr_idx
        adc     _zh, _zero
        lpm     _a_ddr, z+
        out     _SFR_IO_ADDR(PORTB), _a_ddr
        lpm     _a_ddr, z+
        lpm     _b_ddr, z+
        lpm     _c_ddr, z+
        subi    _ddr_idx, -4
        andi    _ddr_idx, 0x0F
        brne    40f
        sbrs    _flag, FLAG_WAVE                            // any fly was lightning ?
        andi    _flag, ~(1 << FLAG_TIMER)                   // no, then reset FLAG_TIMER to signal nothing is playing
        andi    _flag, ~(1 << FLAG_WAVE)
        ldi     _yl, lo8(fireflies)                         // _fly_ptr = &fireflies[]
        ldi     _yh, hi8(fireflies)
40:     movw    _fly_ptr, _y

Holt aus dem FLASH das Mapping der LEDs. Statt für 3 LEDs musst du für 7
LEDs diese Daten holen (lpm a_ddr, z+, Aufrufe also 7 mal).

// now sort each pair of DDRB/OCR0A values descending to OCR0A value == PWM dutycycle for each LED
        cp      _b_ocr, _c_ocr
        brsh    50f
        movw    _y, _b
        movw    _b, _c
        movw    _c, _y
50:     cp      _a_ocr, _b_ocr
        brsh    51f
        movw    _y, _a
        movw    _a, _b
        movw    _b, _y
        cp      _b_ocr, _c_ocr
        brsh    51f
        movw    _y, _b
        movw    _b, _c
        movw    _c, _y
51:

Sortiert nun die 3 OCR/DDR Paare, du musst 7 solcher Paare nach dem OCR
Wert sortieren.

// OCR0A values must be negated
        neg     _a_ocr
        neg     _b_ocr
        neg     _c_ocr
// setup PINs
        or      _b_ddr, _a_ddr
        or      _c_ddr, _b_ddr

Negiert OCR Werte und verodert die DDR Pins für 3 LEDs, du 7 LEDs.

// store calculated OCR0A/DDRB pairs to ocr_data[] for Output Compare ISR
        ldi     _yl, lo8(ocr_data)
        ldi     _yh, hi8(ocr_data)
        movw    _ocr_ptr, _y
        cp      _a_ocr, _b_ocr
        breq    60f
        st      y+, _b_ocr
        st      y+, _a_ddr
60:     cp      _b_ocr, _c_ocr
        breq    61f
        st      y+, _c_ocr
        st      y+, _b_ddr
61:     st      y+, _zero
        st      y+, _c_ddr

Speichert die 3 -1 OCR/DDR Paare in den SRAM für die Output Compare ISR.
Du für 7 -1 solcher Paare.

In deinem Falle musst du diese unrolled Loops wieder in Schleifen
verbauen da dir die Register des AVRs ausgehen werden.

Gruß Hagen

Danke für die sehr ausfürliche Antwort. Leider kann ich damit nichts
anfangen, denn das Ganze überschreitet meinen derzeitigen Kenntnisstand
bei Weitem.
Ich habe jetzt erst mal die "Originalschaltung" aufgebaut um erst mal zu
sehen, wie es so aussieht. Leider bin ich schon an der Programmierung
des uControllers gescheitert. Dieses mitgelieferte Progamm, mit dem man
die firefly.hex brennen soll, kann keine Verbindung zum Chip aufbauen.
Ich schätze mal, dass man dafür einen ISP oder JTag-Programmer braucht?
(Ich verwendete bisher immer das Pollin Evaluationsboard mit Ponyprog)

Du kannst das FoireFly.hex auch ohne den Bootloader flashen. Dann über
ISP usw. Willst du den Bootloader benutzen dann musst du diesen
natürlich als erstes drauf programmieren. Danach, also nach den Tests
seiner Funktionen, kannst du das ISP vom AVR trennen.

Du musst aber die Bootloader Software neu kompilieren da du ja einen
anderen AVR Prozessor benutzen möchtest. Ich würde dir dann empfehlen
mit der aktuellesten Bootloader Version zu arbeiten, findest du hier:
Beitrag "Re: AVR-Bootloader mit Verschlüsselung"

Gruß Hagen

>Im Thread "umschalten zw. Solarezelle und Goldcap" gehst du genauer auf
>die Funktion der Dioden-Schaltung ein. Beim Wechsel von Dunkel auf Hell
>braucht der FET etwas Zeit um Umzuschalten, da seine Gatekapazität erst
>über den BAV70-Pullup geladen werden muss während im umgekehrten Fall T1
>das Entladen der Kapazität erledigt. Korrekt?

Ja.

>Wenn es nun sehr schnell hell wird zB aufgrund eines Blatts, das die
>Solar-Zelle verdeckt hat und vom Wind entfernt wird, würde die Spannung
>auf PB3 des AVR für die Zeit, die Q1 zum Öffnen braucht unter GND Niveau
>fallen. Ist das deswegen nicht weiter tragisch weil die Spannung an der
>Zelle in dieser Zeit einfach nicht so schnell fallen kann, dass es zu
>Schaden am AVR kommt? Mir ist natürlich klar, dass der AVR Schutzdioden
>(und Q1 seine Body-Diode) hat, aber ich hätte da halt ein ungutes
>Gefühl.

Dann würde bei < -0.7 Volt aber die Bodydiode des MOSFETs zuschlagen.

>Dass Du statt Widerständen eine BAV70 genommen hast, liegt nicht
>irgendeiner Weise daran, dass sie eine Diode ist, sondern einfach nur am
>hohen Widerstand in Rückwärtsrichtung, oder? Andersgesagt - außer dass
>ich mit zusätzlichem Standbystrom im einstelligen µA Bereich rechnen
>muss, sollts beim Ersatz der Diode durch 2x 1M oder ähnliches kein
>anderes Verhalten geben.

Korrekt, ist eine Stromsparmaßnahme. Sinn der Schaltung ist es ja das
diese "Diode" schon bei > 10µV aufmacht und so minimalsten Volrtagedrop
hat und somit schon leichte Mehrspannungen des Solarpanels ausgenutzt
werden zum Laden.

>Die Frage ist wahrscheinlich beim Ersatz von D1 durch 2x R eh hinfällig,
>aber sind für T1 und T3 jeweils die Versionen mit dem höchsten HEF
>nötig?

Besser wäre es da dadurch der minimale Volrtagedrop dieser "Diode"
beeinflusst wird.

>Meine Solarzelle schafft bei voller Sonneneinstrahlung einen Strom von
>~20mA durch einen ziemlich vollen Akku zu treiben was für eine
>Erhaltungsladung doch relativ heftig ist.

20mA halte ich für viel für kleine Solarpanels. Messe die Impedanz des
Solarpanels, sie sollte bei 1k liegen, bzw. in jedem Falle höher als der
Innenwiderstand des Akkus. Wenn dem so ist kann das Solarpanel den Akku
nie überladen.

In deinem Falle kannst du dann aber auch die "ideale Diode" ersetzen
durch eine Shottky Diode.

>Außerdem ist mir nicht so recht klar, welchen Schwellwert ich für
>"Akku-voll" annehmen soll. Was ich gelesen haben sehen die
>Ladealgorithmen für NiMH so aus, dass geladen wird bis es nach dem
>Spannungsscheitelwert zu einem leichten Rückgang kommt. Oder aber man
>führt (genau) Buch darüber wieviel Strom in den Akku hineingepumpt
>wurde. Beides kommt mir etwas sehr aufwendig vor; die simple Variante
>wird wohl sein U(voll) auf 1.25 oder 1.30 festzusetzen und es damit gut
>sein zu lassen. Natürlich mit etwas Hysterese. Wie seht Ihr das?

Voll geladene NiMH Akkus haben bei mir 1.4V, professionelles Ladegerät.

Wie gesagt, mit entsprechendem Solarpanel kannst du NiMH Akkus nicht
überladen.

Bei mir ist eher das Problem das die Gesamtpower des Solarpanels auf
Dauer eben nicht ausreichend ist. Ich muß so alle halbe Jahre extern den
Akku laden.

In deinem Falle kannst du im AVR die Software erweitern und einen
Counter hoch/runterzählen der das Ratio zwischen Akku-Voll-Zeiten zu
Glühwürmchen-Leucht-Zeiten mitführt. Wenn dieser Counter dann zb. einen
Threshold übersteigt so dürfen die Glühwürmchen Nachts häufiger und
heller leuchten. Sie verbrauchen also die überschüssige Energie in Ratio
zur gesammelten Energie.

Gruß Hagen

Korrekt, und ab einer gewissen Unterschreitung muß die interne Bodydiode
leiten. Aber es geht ja garnicht um den Fall wenn die Akkuspannung zu
klein zum Öffnen des MOSFETs ist, sondern um den Fall darüber.
Normalerweise sollte der Akku Nachts über also nicht unter die Gate
Threshold Spannung des MOSFETs entladen werden. Tags über soll möglichst
alle Eneregie in den Akku fließen ohne den Voltagedop von min. 200mV
wenn man eine Shottkydiode benutzen würde. Sogesehen sollte der Akku
nicht unter 0.7 Volt entladen werden. Ein Grund der Vorltagedrop der
interen Bodydiode des MOSFETs falls dieser bei 0.7V am Gate nicht mehr
ordentlich leitet. Der andere Punkt ist der Stepup Wandler der nur bis
>0.7V runter anschwingt und nur wenn er schon läuft auch unter 0.7V
arbeitet.

Gruß Hagen

1206'er SMD, sind übrigens nur 4.7µ verbaut worden.

BSS123 hat mit 1V höhere VGS(th), der BSS138 hat laut Datenblatt 0.5V.
Ansonsten sind bei diesen kleinen MOSFETs nur 2 Dinge wichtig: Gate
Threshold Spannung und das es N-Kanal MOSFETs sind.

Du kannst auch ganz auf diese Schaltung verzichten und mit einer
besseren Schottky Diode arbeiten. Bei dieser Schaltung geht es nur um
die 200mV Spannungsabfall an der Schottky Diode der entstehen würde und
der mit dieser Schaltung auf ~10µV reduziert wird.

Gruß Hagen

Der RDS(on) ist relativ unwichtig solange er nicht im kOhm Bereich liegt
und das Solarpanel nicht ganze Ampere an Strom liefert. Beides bei
diesem Projekt nicht der Fall. Die VGS(th) ist der wichtigste Parameter
und sollte so niedrig wie möglich sein, mindestens < 0.7V. Die per ADC
ermittelte Abschaltspannung sollte demnach > VGS(th) und > 0.7V Startup
Voltage des Stepups sein. Der normale Arbeitsbereich der "iealen Diode"
liegt also bei > 0.7V bis maximale Akkuspannung. In diesem Bereich
wünschen wir uns das der Voltagedrop über diese Diode möglichst 0V ist
da somit die volle Energie des Solarpanels benutzt wird. Wie gesagt, wer
mit 200mV Verlust in diesem Bereich leben kann nimmt eine Schottky
Diode.

Gruß Hagen

Hallo und Sorry,
also irgendwie tue ich mich mit dem Schaltbind Schwehr, also wenn ich
mit Zwei Akkus direkt reinfahre ohne den Max??? und der schaltung dazu,
dann sollte doch die Schaltung wenn ich es richtig gelesen habe etwa so
aussehen, zumindest die LED Anschlüsse?

Im Anhang habe ich das Schaltbild mitgeschickt.

Und hier noch die Erklärung zu den Anschlüssen:

LED Paar:
-->|--
--|<--

1A und 1B = LED Paar 1    PB0-PB1
2A und 2B = LED Paar 2    PB0-PB2
3A und 3B = LED Paar 3    PB0-PB5
4A und 4B = LED Paar 4    PB1-PB2
5A und 5B = LED Paar 5    PB1-PB5
6A und 6B = LED Paar 6    PB2-PB5

und an + und GND 2x 1,2 V = 2,4 V

Habe ich das richtig verstanden weil wenn ja dann kommt man auch mit nur
Drei Wiederständen aus?
In der Schaltung steht Tiny13 einen 45er hatte das Programm nicht in
seiner Bibliothek.

Im vorraus schon einmal vielen Dank.
LG
Michael

Hatte mich vertahn war wohl zu früh hier das verbesserte Schaltbild,
sind doch Vier Wiederstände.

1A und 1B = LED Paar 1    PB0-PB1
2A und 2B = LED Paar 2    PB0-PB2
3A und 3B = LED Paar 3    PB0-PB5
4A und 4B = LED Paar 4    PB1-PB2
5A und 5B = LED Paar 5    PB1-PB5
6A und 6B = LED Paar 6    PB2-PB5

LG
Michael

Hallo Randy,
Meinst Du etwa So?
LG
Michael

Hallo zusammen,

ich habe mir mal die Idee der "Glühwürmchen im Rotkohlglas"
aufgegriffen,
etwas vereinfacht und als Programmpunkt des diesjährigen Ferienprogramms
für Kinder angeboten ;-)

Bilder dazu im Anhang...

Viele Grüße aus Kraichtal, Roland

Bild_1

Bild_2

Bild_3

Bild_4

und Bild_5

Guten Abend,

hatte das Projekt vor ner Zeit nachgebaut aber dann in die Ecke gelegt,
da nach etwa 2-3 Stunden die LED's in der Nacht aufgehört haben zu
leuchten, trotz vollem Akku.

Nun hab ich das ganze malhervorgeholt und das Programm etwas
durchgesehen. dabei bin ich auf 2-3 Kleinigkeiten gestoßen die mir nicht
so ganz einleuchten.

Ich verwende eine Mignon-Zelle und nen Tiny85.

Die Watchdog Routine hab ich nach dem Post von Randy am 18.12.2008 18:35
entsprechend auf

    if (--idx > 7) idx = ((idx & 0x07) | (1 << WDP3));  
    idx |= (1 << WDIE);                  // enable WDT-ISR
    wdt_reset();
    WDTCR |= (1 << WDE) | (1 << WDCE);
    WDTCR  = idx;

 angepasst.

Wieso wird wenige Zeilen weiter unten erst WDE und WDCE gesetzt, wenn
anschließend das ganze Register mit "idx" überschrieben?

Des weiteren hab ich ne Frage zum Auslesen der Batterie-/Solarspannung.
Gehe ich richtig in der Annahme, dass die beiden Byte Werte im RAM
vertauscht, gehören? Müsste ja so sein, durch LittleEndian,...

So habe die Software zum testen so umgebaut das ständig Nacht ist.
Weiter hab ich

MEASURE_INTERVAL    (uint16_t)(625)

 gesetzt. Die LED'S beginnen nach 1 Minute zu blinken. Jedoch ist es nun
nach etwa 70 Minuten dunkel und auch nach 3 Stunden hat nichts mehr
angefangen. Die Spannung liegt bei etwa 1.2, also vollkommen im grünen
Bereich.

Wer hätte nen Tip?

Gruß Stefan

Desweiteren ist mir im Datenblatt auf Seite 49 aufgefallen, das WDP
maximal auf 1001 stehen darf, alle höheren Bit-Kobinationen sind
reserviert. Allso müsste die Zeile doch folgendermaßen lauten ?

    if (--idx > 7) idx = ((idx & 0x01) | (1 << WDP3));  // neue Idee ??
//    if (--idx > 7) idx = ((idx & 0x07) | (1 << WDP3));  // max timeout setzen

Gruß Stefan

So, nachdem das Projekt eine Zeit gelegen hatte hab ich mich die Tage
mal wieder dran gemacht den Fehler zu finden, wieso die Schaltung nur
die erste Nacht funktionierte und dies auch nur, wenn sie bei Dunkelheit
eingeschaltet wurde. Da es beim Vorgaukeln ständiger Nacht funktionierte
erwartete ich den Fehler in der Software bei der AD-Messung. Naja
inzwischen bin ich mal wieder belehrt worden, immer alle Teile der
Schaltung in betracht zu ziehen,...

Der Übeltäter ist die linke der beiden Doppeldioden. Nach dem ersten
Nacht-Tag wechsel fingen die kleinen nicht mehr an. Nach einer Berührung
der Platine bei den Transistoren lief sie plötzlich wieder an.
Der finale Grund ist, dass der Leckstrom der Diode einen zu geringen
Spannungsabfall erzeugt, das die Transistoren wieder schließen.

Ein Wiederstand von 10M Ohm, der noch in meiner Bastellkiste war, über
die linke Diode nach Bat+ reichen vollkommen aus.

Sollte es bei euch nicht laufen, könnte es an dieser Kleinigkeit liegen.

Gruß Stefan

PS:
Ist da nicht noch ein gedanklicher Fehler in der wave.h ?
Es wird die wavetable definiert mit

prog_uint8_t wave[827] = {...

somit hat sie ja 827 Stellen, adressiert wird aber von 0... 827

wave_data_t wave_data[32] = {
  {&wave[   0], &wave[  26],  832},
  {&wave[   0], &wave[  99],  865},
...
  {&wave[ 534], &wave[ 827],  987},
  {&wave[ 693], &wave[ 827],  927}

Das ganze sollte evtl. in den Umsetzungen bedacht werden.

Stefan

@Stefan:

Tja, Unterschied zwischen Simulation und Realität. In der Simulation mit
LTSpice zeigte sich das mit den Dioden der geringste Stromverbrauch (µA
Bereich) zu erreichen ist. In der Realität ist das Ganze viel zu
hochohmig und deshalb erwähnte ich irgendwo hier das man besser
Widerstände dafür nehmen sollte. Bei mir geht es aus irgendeinem Grund
bei mehreren Aufbauten, ich schätze das mein selbstgeätztes Layout daran
"Schuld" ist.

Danke für den Tipp.

Ansonsten kann man ja auch diese "ideale Diode" auch einfach komplett
durch eine Shottky ersetzen.

Gruß Hagen

>somit hat sie ja 827 Stellen, adressiert wird aber von 0... 827

>wave_data_t wave_data[32] = {
>  {&wave[   0], &wave[  26],  832},
>  {&wave[   0], &wave[  99],  865},
>...
>  {&wave[ 534], &wave[ 827],  987},
>  {&wave[ 693], &wave[ 827],  927}

>Das ganze sollte evtl. in den Umsetzungen bedacht werden.

Nein ist richtig so, musste aber auch erstmal drüber nachdenken da du
mich im ersten Moment überrumpelt hast ;)

Das sind Zeiger in die Wave-Tabelle. Der Zeiger &Wave[827] zeigt damit
hinter das letzte Byte der Wave Tabelle und somit an das Ende.
wave_data[] enthält also einen Zeiger mit dem Start der Wave und einen
Zeiger auf das Ende der Wave +1 Sample. Der Start wird geladen und
solange inkrementiert bis er auf Ende steht.

Nur der erste Zeiger (Start) wird zum Zugriff auf die Waves[] benutzt.
Der zweite zeiger dient als Vergleichwert mit dem internen Zeiger der
mit Start initialisiert wird und immer +1 inkrementiert wird bis er eben
auf Ende steht.

Man hätte nun statt einen Ende-Zeiger einen Samples-Zähler benutzen
können. Das führt aber dazu das man entweder

1.) eine Endevariable auf Start + Sample_Count initialisieren muß oder
2.) in der Zählschleife sowohl den aktuellen Samplezeiger +1 wie auch
Sample_Counter -1 rechnen muß

Somit ist das eine Optimierung durch Vorausberechnung und man lädt
einfach Start in den Samplezeiger und vergleicht diesen mit dem Ende
Zeiger und inkremeniert nur eine Variable den Samplezeiger.

Das dient der Codeoptimierung letzendlich. Denn ich lade die Wave Sample
mit LPM r,Z+ also mit implizitem Postinkrement. Nach dem Laden steht der
Zeiger Z also, wenn er das Ende erreicht hat, auf +1 Samples hinter der
Wave. Danach wird er mit Ende verglichen.

Ein Marker in den Samples geht nicht. Dh. man definiert einen speziellen
Samplewert der als Endemarke in den Waves[] drinnen steht. Das geht
nicht weil die verschiedenen Leuchtmuster alle in Waves[] gespeichert
sind und sich überschneiden, also Teile des einen Leuchtmusters werden
durch ein anderes Leuchtmuster mit benutzt.

Gruß Hagen

Hi Leute, ich habe ein kleines Problem mit der Schaltung von Randy. Ich
habe die Version nachgebaut. Nur läuft sie nicht richtig. Nach dem
Einschalten (LDR abgeklemmt) fangen verschiedene LEDs nach ca.20
Sekunden an zu flackern und gehen teilweise in Dauerleuchten über. Also
keine 6 Minuten bis es losgeht. Dann irgendwann gehen sie aus und das
Spiel beginnt von vorne.

Ich habe den Code auch schon selbst kompiliert, ohne Erfolg. Die Fuses
habe ich kontrolliert und glaube sie stimmen (L=E2, H=DF, E=FF).

Geflasht hab ich versuchsweise mit BASCOM und avrdude, beidesmal ohne
Fehler. Verify gegeneinander war auch ok.

Irgendjemand ne Ahnung wo ich suchen könnte.

Hallo,

es hat den Anschein das etwas mit det Taktfrequenz oder dem Measure
intervll nicht passt.

#define MEASURE_INTERVAL    (uint16_t)(5 *  3750)       // each 6 minutes measure interval

Der Controller sollte mit 8MHz laufen. CLKDIV müsste rausgenommen
werden.

Viel Erfolg beim weiteren Testen.

Stefan

Also ich bin weiter. Das Hex-File scheint mit 15 Sekunden
MEASURE_INTERVAL kompiliert zu sein. So steht es auch im Quelltext.

Ich habe jetzt mal die Sourcen neu kompiliert bei der ich die
measure_isnight Routine fest auf flags |= FLAG_ISNIGHT; gesetzt habe.
Damit klappt es schonmal so weit, dass die Würmchen aufleuchten und
nicht mehr flackern. Ein Problem hatte ich noch beim Kompilieren mit
einer ignoring Warnung in der wave.h.
(gcc version 4.3.3, WinAVR 20100110)

Das stand:

typedef struct {
....
} wave_data_t PROGMEM;

muss aber jetzt

typedef struct PROGMEM {
....
} wave_data_t ;

sein.

Jetzt werd ich das mit der ADC-Geschichte in der insnight-Routine mal
durchsehen und auch mal schauen ob ich ein wenig mehr "Action" bekomme.
Bei mir ist nur selten mehr als ein Glühwürmchen aktiv. Und das Ganze
mit langen Pausen ohne Aktivität dazwischen.

Hallo,

ich habe die Glühwürmchen etwas verändert / vereinfacht nachgebaut:
- 2 * AAA Eneloop Akkus,

- Solarzelle mit Shottky Diode abgekoppelt

- Messung der Batteriespannung über interne Bandgap, dadurch bleibt der
Reset Pin frei

- Doppelt lange Wave, damit sie nicht so nervös blinken....

- verschiedene Varianten der Helligkeitsmessung,
  a) über Solarzelle, geht bei manchen Solarzellen anscheinend schlecht
(infrarot?), deshalb
  b) Messung über LDR mit (Reset-Pin) geschaltetem Pull-up
  c) Messung über LDR mit Kondensator

Deshalb gibt es drei Schaltbilder, im Code wird über #ifdef
umgeschaltet.

Gruß,
Bernhard

Tom schrieb:
> Hallo Bernhard
>
> bin hier absoluter Neuling.
> Kannst Du mir mal das Layout der Platine und die genaue Anleitung ins
> Board stellen?
> Wäre Dir sehr dankbar.
>
> LG
> Tom

Hi Tom,

ich habe kein Layout, weil ich die auf Lochraster aufgebaut habe.

Was brauchst du noch als Anleitung?

Gruß,
Bernhard

Hi,

am laufen habe ich a) und c), b) hatte ich kurzzeitig.

Ursprünglich habe ich eines mit a) gebaut, das geht ganz gut.
Ein weiteres mit einer anderen Solarzelle hat "Nacht" unzuverlässig
erkannt, deshalb der Umstieg zu c).

c) deshalb, damit man den Reset noch für ISP behalten  kann.

Gruß,
Bernhard

Hallo René,

iah hatte mir die Version mit Solarzelle als Sensor nachgebaut.
Hatte das Problem das es immer gut anlief und nach einer unbestimmten
Zeit nocht mehr reagiert hat, so zumindest der anschein. Mit dem Loader
kam ich aber immer ohne Probleme drauf.

Wenn du ne recht aktuelle Version von WinAVR verwendest solltest du
einmal beim kompletten neukompilieren kontrolieren ob von der "wave.h"
ein warning kommt bezüglich Definition/Reihenfolge von "Progmem".

Sieh dir dazu mal den Beitrag von Joachim am 19.07.2011 13:25 an.
Beitrag "Re: Glühwürmchen in Rotkohlglas gefangen"

Bei mir war nur dies der Fehler das es als "ausgestiegen" ist.

Viel Erfolg
Stefan

Hi,

angehängt noch mal alle sourcen.
Ich programmiere unter Linux. Da es dafür kein bootloader Programm für
Hagens bootloader gibt verwende ich Peters bootloader, das hat aber
keinen Einfluss.
Kompiliert habe ich mit gcc 3.4.6, ziemlich alt aber relativ
"fehlerfrei" (andere Projekte kompilere ich z.Zt. mit 4.4.2, der könnte
hier auch gehen).
Ansonsten laufen beide Varianten (Solarzelle als Lichtsensor und LDR mit
Kondensator) seit Juli / August dauerhaft und leuchten immer noch...

Gruß,
Bernhard

Hi,

entschuldige die späte Antwort, ich habe es erst jetzt gelesen....

Es kann durchaus sein, daß die Glühwürmchen mal lange Pause machen, das
kommt ab und zu mal vor.

Ich kann heute Abend die HEX files posten, bestimmte oder alle drei?

Gruß,
Bernhard

Hi,

so, hier mal das Hex für Solarzelle und LDR (ohne Verwendung des Reset
Pins). Beide laufen bei mir monatelang ohne Probleme.

Gruß,
Bernhard

Guten Morgen,

also den LDR Wert habe ich dann auch ausprobiert, im abgedunkeltem
Raum.Die Zykluszeit stark heruntergesetzt, dann immer Wert verändert,
programmiert, schauen, ob die LEDs blinken. So habe ich mich
herangetastet...
Im Endeffekt ist es jetzt so, daß die LEDs im noch relativ hellen Raum
schon anfangen, meinen Sohn stört das aber nicht.

Gruß,
Bernhard