www.mikrocontroller.net

Forum: Projekte & Code Glühwürmchen in Rotkohlglas gefangen


Autor: Hagen Re (hagen)
Datum:
Angehängte Dateien:

Bewertung
3 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bild 1

Autor: Hagen Re (hagen)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bild 2

Autor: Hagen Re (hagen)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bild 3

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schickes Projekt!

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

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

Autor: jo (Gast)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh super! Das stand schon immer auf meiner todoliste :)

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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ja mann (Gast)
Datum:

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

Autor: Ja mann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach sehe gerade ist ja schon gaaanz oben drin. Verzeihung. Lesen 
bildet...

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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

Autor: Mario Grafe (mario)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerd (Gast)
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ;)

Autor: Marius S. (lupin) Benutzerseite
Datum:

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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt, hast du Skype ?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Fabian B. (fabs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

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

Gruß Hagen

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Den MAX1724 habe ich bei MAXIM gesampelt, und ich bin mit dem Teil
> wirklich zufrieden und kann diesen speziell für solche Lowpower

gibts so einen ähnlichen Step-Up mit geringem Eigenverbrauch den man bei 
den "üblichen Hobbyversendern" kaufen kann? Sampeln geht ja nur bei 
einem Einzelstück.

Ohne die Datenblätter im Detail verglichen zu haben: Was müsste man 
ändern um den Code auf einen Tiny44 anzupassen? Dann wären ein paar mehr 
LEDs möglich ohne die wie-spare-ich-noch-einen-Pin Diskussionen. Und das 
bisschen Platz ist eigentlich auch egal.

Randy

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Stimmt, daran hatte ich gar nicht gedacht. Hast du probiert ob das Glas 
mit mehr LEDs spürbar interessanter aussieht? Beim Tiny44 könnte man ja 
zwei getrennte Ketten machen.

Randy

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

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

Gruß Hagen

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fabs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Darum hatte ich auch mal gefragt wo's schöne Zellen gibt. Die meisten 
Solarlampen haben hab nur noch etwas lächerlich aussehende "Splitter" 
verbaut. Die schönste solche Zelle hab ich mal in so ner Leuchtkugel 
gefunden...nur leider funktionierte die Kugel noch und die Besitzer 
wollten sie nicht hergeben ;-). Da war die Zelle ca 5x5cm gross und vom 
aussehen her a-Si oder CIS Zelle (schwarz).

Gruß
Fabian

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig rum eingelötet ?

Autor: Aike T. (biertrinker)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>1,29V frisch von Akku

also damit läuft mein Stepup wunderbar.

Gruß Hagen

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hab die sache jetzt mal nachgebaut, und - ta,ta - funktioniert 
nicht.
OK, woran könnte das liegen?
Per ISP hab ich versucht die Fuses richtig zu setzten... leider ist das 
evtl. nicht so übersichtlich dargestellt:

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

Was ich ggü. default geändert habe:
- CkDIV8 deaktiviert
- SelfPrgGen aktiviert
- den Reset hab ich nicht deaktiviert, weil ich danach nicht mehr an die 
Fuses rankomme.
Ich hab einen Ponyprog-Screenshot angehänt.

Wenns nicht die Fuses sind:
Ich betreibe das Teil gerade im "Trockendock", d.h. ohne Soalrzelle und 
Akku, einfach mit 3,3V Betriebsspg. Um die "Akku-voll" und "Dunkel" 
Messung zu simulieren habe ich die Pins 2 und 3 auf 3,3V gehängt. Das 
sollte doch so korrekt sein?

Hat einer eine Idee woran es scheitern könnte?
Ich hab nach dem Einschalten durchaus 20 min gewartet, aber nix 
passiert. Die LEDs sind richtig verdrahtet, beim ISP-Programmieren sieht 
man sie blinken.
Die Software scheint auch zumindest irgendwas zu tun, zumindest haben 
die ersten 4 Bytes im EEPROM ihre Werte verändert (d.h. AVRrootloader 
geht, damit kann ich das EEPROM lesen), das kann eigentlich nur die 
uC-Software gemacht haben... (-> Startwert für das Rückgekoppelte 
Schieberegister neu geschrieben)

Was kann ich noch probieren?

Randy

Autor: Randy (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Natürleich den Screenshot vergessen

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> So sind die Fuses auf deinem Screenshot gesetzt, das sieht glaube ich OK
> aus.

Vielen Dank für deine Antwort. Die einzige Fuse bei der ich mir 
tatsächlich unsicher war ist die WDTON.
Die hab ich auf Factory-Default gelassen. (=1, d.h. unprogrammiert)

> Allerdings kann ich nicht nachvollziehen, was du dann machst. Der
> nächste Schritt wäre jetzt den Bootloader auf den Tiny zu laden.

Bootloader geht. Damit hab ich das eigentliche Prg auf den uC geladen 
und testweise das EEPROM gelesen. Funktioniert also.
Was ich dann gemacht habe: Pin 2 und 3 auf Betriebsspg. (3,3V) gezogen, 
das sollte nach meinem Verständnis dazu führen dass die Software 
"Akku-voll" und "dunkel" registriert und die Glühwürmchen von der Leine 
lässt, aber nichts passiert. Auch nicht nach >12min. Deshalb die Frage 
im Forum...

Randy

Autor: Ssss Ssssss (sssssss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

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

Gruss

Autor: Ssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry hab nicht richtig hingeguckt, da hängt ja sol- dran...

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich nochmal:
wenn ich die "measure_isnight" Routine deaktviere, d.h. das Flag immer 
setzte, und dann noch das MEASURE_INTERVAL auf 100 oder was kleineres 
setzte:

> Ä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 ;)

sehe ich die LEDs leuchten, wenn auch die Waves mit einer irren 
Geschwindigkeit abgespielt werden.
Setzte ich (sonst alles gleich) das MEASURE_INTERVAL auf 1000, tut sich 
gar nichts, auch nicht nach einer 10x so langen Wartezeit.
An was könnte das liegen?

Randy

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Oh, das sind dann aber sehr "nervöse" Glühwürmchen. Ich kenne nur die 
die ich hier in Deutschland sehe, die leuchten eher kontnuierlich, und 
brauchen ein paar Sekunden um von "nicht leuchten" auf "leuchten" 
umzuschalten.

> denke es ist ok so und du solltest Akku und Solarzelle anschließen und
> dann weiter schauen.

Ich will das Ding en an 2 oder 3 Zellen betreiben, ohne Step-Up, dazu 
muß ich die Mess-Routinen sowieso verändern. Aber wenn es z.Z. nicht mal 
so (d.h. am Netzteil) geht, brauche ich die restliche Hardware noch gar 
nicht aufbauen...
Ich will es eh endgültig auf einen Tiny44 umprogrammieren damit ich den 
ISP nicht deaktivieren muß (und die Lichtmesung mit einem LDR machen 
kann). Das Ding mit dem Tiny45 ist nur da um die Software erst mal so 
zum laufen zu kriegen wie sie ist, bevor ich zum umprogrammieren 
anfange.

Randy

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

> Oh, das sind dann aber sehr "nervöse" Glühwürmchen.

Das was ich als schnelles Blinken interpretiert habe ist wohl eher die 
Multiplex-Frequenz. Das flimmern sieht nach irgendwas in der Gegend von 
10Hz aus. Ist das normal für das Programm? Ich hoffe dass der uC-Takt 
passt, ich hab den Reset jetzt deaktiviert, komme also nicht mehr an die 
Fuses ran...

Randy

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das was ich als schnelles Blinken interpretiert habe ist wohl eher die
> Multiplex-Frequenz.

ok, das nehme ich wieder zurück, die Multiplex-Frequenz ist ca. 100Hz. 
Das recht nervöse Blinken dem langsamere (aber immer noch im 
1-Sekubnden-Bereich) Helligkeitsänderungen überlagert sind ist 
anscheinend beabsichtigt.

Randy

Autor: Aike T. (biertrinker)
Datum:

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

viele Grüße

Biertrinker

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

jetzt funktioniert alles soweit, nur das mit dem MEASURE_INTERVAL macht 
noch Probleme:

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

> so sehe ich die LEDs leuchten
> Setzte ich (sonst alles gleich) das MEASURE_INTERVAL auf 1000, tut sich
> gar nichts, auch nicht nach einer 10x so langen Wartezeit.
> An was könnte das liegen?

Ich hab jetzt herausgefunden: mit 127 gehts noch, die Wartezeit nach 
einem Reset bis die Glühwürmchen loslegen beträgt ca. 6 Sekunden, also 
in etwa so lang wie man erwarten würde. Aber bei Zahlen ab 128 geht gar 
nichts mehr...
Ich übersetze den Sourcecode mit der aktuellen Version von WinAVR (d.h. 
mit dem gcc), was benutzen die anderen Nachbauer? Evtl. alle das 
AStudio?
Oder woran könnte das noch liegen?

Vielen Dank, auch für die Tipps bisher.
Randy

Autor: Ssss Ssssss (sssssss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

So, hab auch getestet. Erstmal die korrekten FUSES:
lfuse: 0xE2
hfuse: 0xDF (mit reset noch reset, dann aber keine leds an resetpin!) 
bzw 0x5F mit reset disabled
efuse: 0xFF

-> Damit ist auch das blinken ok. Bei falschem CLKDIV8 ist die pwm freq 
~12 Hz !

Dann scheint es echt einen Bug im GCC bzw ein Problem im Zusammenhang 
mit der ASM/register definition (brrrr kann sowas echt gutgehen ?)
Wenn der Wert MEASURE_INTERVAL größer als 127 gesetzt wird dann geht es 
nicht mehr.
KA. wieso. Vermutlich irgendein Problem mit lo() hi() und dem setzen 
einer 1 in irgendein Register das schon per register def als Variable 
dient.
Keine Ahnung...

Achja, ich hab avrgcc 4.2.2

Leider funktioniert das HEX bei mir nicht da ich 2 Zellen nehme
(Erkennung für isnight muss geändert werden)
Für heute hab ich keinen Nerv mehr...

Gruss

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> So, hab auch getestet. Erstmal die korrekten FUSES:
> lfuse: 0xE2
> hfuse: 0xDF (mit reset noch reset, dann aber keine leds an resetpin!)
> bzw 0x5F mit reset disabled
> efuse: 0xFF

Die Efuse musst du noch auf 0xFE setzten wenn du den Bootload benutzen 
willst (bzw. den musst du benutzen wenn du den Reset-Pin deaktivieren 
und danach noch ein Update einspielen willst)
Ich werde in absehbarer Zeit eine auf en Tiny44 angepasste Version hier 
reinstellen, bei dem hat man genügend Pins um den Reset-Pin nicht mit 
einer LED belegen zu müssen. d.h. man kann auf den Bootloader verzichten 
weil man den ISP nicht deaktivieren muß.



> Dann scheint es echt einen Bug im GCC bzw ein Problem im Zusammenhang
> mit der ASM/register definition (brrrr kann sowas echt gutgehen ?)
> Wenn der Wert MEASURE_INTERVAL größer als 127 gesetzt wird dann geht es
> nicht mehr.

Ich glaube inzwischen dass der Bug nicht am avr-gcc liegt. Ich hoffe der 
Orginal-Autor schaut nochmal rein um die Zeilen der wdt_setup-Funktion 
zu kommentieren (die Kommentare sind von mir, der Code vom 
Original-Programm):
  uint16_t res = 1;
    uint8_t  idx = 1;
    while ((res <= time) && (idx < 10)) {
      res += res;
      idx++;
    }
// wenn diese Schleife verlassen wird hat idx einen Wert
// von 1..9 (inklusive)
// Gerade bei einem Wert von time>=128 bekommt idx den Wert 9
    res /= 2;
    if (--idx > 7) idx = (idx & 0x0F) | (1 << WDP3);
// idx hat nach dem -- einen Wert zw. 0 und 8, d.h. der Wert 8 ist der
// einzige bei dem das if in den "then" Zweig läuft
// im then-Zweig wird idx durch das &0x0F nicht verändert(!),
// wenn man sich die Bits im Register WDTCR ansieht, würde ein
// idx & 0x07 logischer erscheinen
// Bit 3 ist naemlich "Watchdog Enable" (s.47/48 im Datenblatt)...
    idx |= (1 << WDIE);                                                 // enable WDT-ISR
// ...und das macht in Kombination mit "WDIE" keinen Sinn ("If WDE is set,
// WDIE is automatically cleared")

    wdt_reset();
    WDTCR |= (1 << WDE) | (1 << WDCE);
    WDTCR  = idx;
  

Ob die Änderung von 0x0f in 0x07 das Problem behebt probiere ich am 
WoEnde aus.

Randy

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> // Bit 3 ist naemlich "Watchdog Enable" (s.47/48 im Datenblatt)...
>    idx |= (1 << WDIE);                                                 // > 
enable WDT-ISR
> // ...und das macht in Kombination mit "WDIE" keinen Sinn ("If WDE is set,
> // WDIE is automatically cleared")

Ich sehe gerade: Laut Tabelle 8-2 im Datenblatt S.48 sollte es nicht 
schaden wenn man zum WDIE auch zusätzlich das WDE setzt. Das sollte 
genau keine Veränderung bewirken, sondern beide male der Watchdog einen 
Interrupt auslösen...

Randy

Autor: Ssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok mit der efuse hast du recht, ich nutze den Bootloader nicht (da kein 
linux loader verfügbar).
Ich teste es einfach mit ohne Reset pin disable und dann wird am ende 
die fuse
so gesetzt dass er nicht mehr per isp programmierbar ist.

Ich werde morgen meine Platine umändern und doch eine zelle + stepup + 
originalcode (hex) verwenden. Langsam wird die Zeit knapp 
(Weihnachtsgeschenk g)

Autor: Sssssssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Super, ich glaub du hast den Bug gefunden!

Wenn ich folgende Änderung mache:
//if (--idx > 7) idx = (idx & 0x0F) | (1 << WDP3);
if (--idx > 7) idx = (idx & 0x07) | (1 << WDP3);

dann gehts :) Zumindest leuchten die Glühwürmchen ab und an.
(MEASURE_INTERVAL=1300 getestet)

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sssssssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Hmm echt komisch. Evtl hat der gcc bei dir irgendwas anders optimiert 
und deshalb kam es bei dir nicht zum Bug ?
Ich hab jetzt mal die Platine auf stepup umgelötet.
Gar nicht so einfach wenn man sie per Tonermethode ätzt, nicht aufpasst 
und am Ende die Platine gespiegelt hat g (alle Bauteile haben jetzt 
umgebogene pins g)

Mal schaun ob das original HEX läuft. in 12minuten weiss ich mehr :)

Kann es evtl sein dass du den bug gefixt hattest aber im source der oben 
gepostet wurde nicht ?
Dann dürfte das original HEX ja auch nicht richtig laufen. Das sehe ich 
gleich :)

Gruss

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Danke für die Bestätigung. Wenn man in den Sourcen von anderen Leuten 
werkt besteht immer die Gefahr dass man Codestücke falsch interpretiert 
bzw. Zusatzeffekte übersieht.

Was mir noch aufgefallen ist: Ich habe meine Platine z.Z. noch fest auf 
"Nacht" geklemmt. Nach ein paar Stunden Aktivität stellen die LEDs das 
Leuchten ein, und zwar - so wie es aussieht - dauerhaft. Ist das so 
beabsichtigt? (evtl. als Schutz gegen in-den-Schrank-stellen)
Als ich in der (originalen) wdt_setup Funktion eine Zeile drin hatte die 
das Argument "time" auf Werte <=127 begrenzt hat war das nicht der Fall.

Randy

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Du hast also die komplette Auswertung vom Solarpanel und Akkuspannung
> deaktiviert und gibts immer das Flag FLAG_ISNIGHT.

Gerade haben sie wieder angefangen, aber seit heute Morgen ist das die 
erste Aktivität, das waren jetzt mind. 7 Stunden Pause. aber sehr 
zögerlich und nur mit einer LED. Und jetzt ist schon wieder seit >15min 
nix los.
Das Flag habe ich nicht per Software deaktiviert, sondern die 
ADC-Eingänge fest über einen Spannungsteiler an 1,2 und 1,3V gelegt so 
dass das Flag immer aktiviert sein sollte. Und nach einem Reset legt die 
Schaltung ja auch erst mal kräftig los.
Aber jetzt bau ich den Code erstmal auf den Tiny44 um, dann hab ich ein 
paar Pins übrig, das ist immer praktisch zum Debuggen. Z.B. kann ich mir 
die Wartezeit bis zur nächsten Aktivität per SPI raustakten und 
anzeigen...

Randy

Autor: Ssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

So richtig will es immer noch nicht. Ich hab ne frage zum source:
  // first dummy reading, VRef=2.56V
    PRR    = (1 << PRTIM1) | (1 << PRTIM0) | (1 << PRUSI);
    ADMUX  = (1 << REFS2) | (1 << REFS1) | (1 << MUX1) | (1 << MUX0);
    ADCSRA = (1 << ADEN) | (1 << ADIE) | (1 << ADPS2) | (1 << ADPS0);
    sleep_cpu();
  // read battery voltage
    sleep_cpu();
    uint16_t bat_volt = ADC;
 // read solar panel voltage
    ADMUX  = (1 << REFS2) | (1 << REFS1) | (1 << MUX1) | (0<<MUX0);
    sleep_cpu();
    uint16_t sol_volt = ADC;
    if ((sol_volt > bat_volt) && (sol_volt >= BATTERY_OK)) flags |= FLAG_ISNIGHT;

bat_volt wird zuerst gelesen, von ADC3 (=PB3 = pin2 = BAT+ beim tiny45)
sol_volt danach, von ADC2 (=PB4 = pin3 = SOL- beim tiny45)

Ok soweit.

Nun wird sol_volt > bat_volt getestet:
Das kapier ich irgendwie nicht. Sagen wir es ist Nacht, dann sei die 
Solarzelle wie ein Widerstand mit zb 5 Ohm.
Dann liegt an SOL- eben genau die Spannung BAT+ - eventuelle 
Spannungsabfall an.
Sprich sol_volt kann NIE größer als bat_volt werden ??!?

Hab ich da irgendeinen Denkfehler drin ?

Ich hab jetzt mal
uint16_t sol_volt = ADC + 100;
gemacht, dann erfolgt die Erkennung ob es Nacht ist und die Würmchen 
leuchten.
Ob sie auch irgendwann stoppen weiss ich noch nicht.

Gruss

Autor: Ssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

So, habe jetzt mal mit dem bootloader experimentiert.
Super, der Loader funzt sogar unter wine !!!

Wichtig sind die Fuses (efuse, selfprgen!)
hfuse: 0x5F (RESET disabled!!)
lfuse: 0xE2
efuse: 0xFE


Beim eigentlichen Glühwürmchen code habe ich immer noch Probleme.
- der Timeout 6*3750 scheint irgendwo probleme zu machen, bis 5*3750 
gehts...
- beim ADC messen hab ich beim sol_volt = ADC + 50

Irgendwann hören die Glühwürmchen auf zu leuchten...
Habe jetzt mal den resetpin disabled und auch würmchen dran. Mal sehn.
Ausserdem teste ich ISNIGHT fest auf 1...

Autor: Ssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmm mit deaktivierter nachtmessung leuchten die würmchen brav vor sich 
hin:

deaktiviert durch:
static void measure_isnight(void) {
...originalcode...
flags |= FLAG_ISNIGHT;
}

wenn ich das nicht mache hören sie nach einiger Zeit (einigen 30min bis 
stunden) auf zu leuchten
(volle AAA batterie mit 1.5V, dh spannung zu niedrig kanns nicht sein)

Ich forsche mal weiter...

Autor: Sssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok an der Messung lag es nur zum Teil...

Ich glaube die uint timeout wurde irgendwann mal "negativ".
Dh sie springt von z.B. 2 nach 0xFFFF -> sehr groß!
Folgender Code läuft bei mir jetzt wie er soll (bzw ich hab noch ein 
paar debugroutinen drin gehabt, ich hoffe es lag nicht an den 
debugroutinen. in dem diff hier hab ich die rausgenommen):
130c135
<     uint16_t sol_volt = ADC;
---
>     uint16_t sol_volt = ADC+50;
147c159,162
<     if (--idx > 7) idx = (idx & 0x0F) | (1 << WDP3);
---
>     if (--idx > 7) idx = (idx & 0x07) | (1 << WDP3);
160,161c176,177
<     uint16_t timeout = 0;   // remaining time in WDT cycles a 16ms upto next event
<     uint16_t measure = 0;   // remaining time upto next measurement^M
---
>     int16_t timeout = 0;   // remaining time in WDT cycles a 16ms upto next event
>     int16_t measure = 0;   // remaining time upto next measurement
167c183,186
<         if (timeout == 0) {
---
>       if (timeout < 0){
>         timeout = 0;
>       }
>         if (timeout==0){

Sie haben die ganze Nacht durchgeleuchtet und gerade im Licht brav 
aufgehört.
Ob sie wieder anfangen weiss ich noch nicht, sie stehen erst zu kurz im 
dunklen Schrank 8)

Gruss

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sssssss (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Sie haben auch wieder angefangen zu leuchten :)
Ok dann wars evtl doch nicht die Änderung...
Ich häng mal mein C File und das Hex an was bei mir momentan gut läuft.
Evtl liegt es auch irgendwie an meinen Debug werten/Code liegt oder so.
Evtl irgendein fieses Optimierungproblem oder so.

Hast du ne Ahnung warum deine Originalversion ohne das +50 beim ADC 
funktioniert ?
Das kann doch eigentlich gar nicht sein, oder ?
Oder evtl misst ein adc port bei dir immer minimal falsch oder so.


Das die Würmer aufhörten zu leuchten war sehr zufällig.
Mal war nach ein paar minuten Ende, mal dauerte es 3h.
Aber sobald sie aufhörten war auch ne h später nichts mehr zu sehen.
Jetzt scheint es zu gehen, die ganze nacht haben sie geleuchtet, heute 
morgen aufgehört und nach dem verdunklen auch wieder angefangen und 
leuchten immer noch.

Komisch :-\

Gruss

Autor: Sssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
achja bzgl timeout:
Ne, ich meinte das genau anders rum:

timeout -= wdt_setup(timeout);

Da wird timeout verkleinert. Wenn jetzt timeout zb 2 ist und man zieht 3 
ab
käme ein sehr grosser wert raus 0xFFFE oder so.
D.h. nun wäre der Timeout riesig (oder ist 0xFFFE noch vertretbar lang ? 
k.a. hab nicht geguckt was da genau drinsteht).

Ausserdem prüfst ja nur timeout==0. Was wenn timeout (warum auch immer, 
buig in wdt_setup oder so) nie gleich null wird ?
Drauf gekommen bin ich als ich in wdt_setup immer nur einen festen
timeout gewartet habe, da lief das programm lange durch.
Keine Ahnung obs daran liegt. Meine Würmer leuchten rechtzeitig zum Fest 
8)

Gruss

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Sssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
printf ? ui sowas hätt ich gern g
Ich hab nur Variablen im globalen speicher gesetzt und per bootloader 
beobachtet :)
Ich hab leider keine Zeit genau zu debuggen was schiefging.
Jedenfalls funktioniert das hex aus dem archiv was ich vorhin gepostet 
habe. Warum ist mir erstmal egal solange die Würmchen leuchten wie sie 
sollen 8)

Danke übrigends für das chöne Projekt! Ich poste mal Fotos und ggf. ein 
Video :)

Gruss

Autor: Hagen Re (hagen)
Datum:

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

Autor: Sssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Randy (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
jetzt muß ich doch noche meine Ankündigung wahr machen und eine Variante 
der Software für den tiny44 ins Forum stellen.

Meine Veränderungen:

- Der Reset-Pin bekommt keine weitere Aufgabe, d.h. man kann beim ISP 
Programmierer bleiben und braucht den Bootloader nicht.
- Die LEDs hängen an PA 2,4,5,6. Das bedeuted dass drei der Leitungen eh 
am ISP Stecker hängen. Ich hab dann PA2 auf einen 7.Pin des Steckers 
geführt, so dass ich für die LEDs und den ISP nur einen Stecker brauche. 
(Ich benutze immer die 6-polige ISP-Steckerbelegung von 
http://www.mikrocontroller.net/articles/AVR-Tutori...)
- Ich benutze keinen Step-up, sondern 2 oder 3 NiMH Zellen. Der 
Tiefentladeschutz ist darauf abgestimmt. Es wird immer Vcc als Ref-Spg 
für den ADC benutzt und die intere 1,1V-Ref-Spg gemessen (wie es weiter 
oben in dieser Diskussion beschrieben worden ist)
- Zur Nacht-Erkennung benutze ich einen LDR. Der Spannungsteiler (siehe 
Schaltplan) wird nur zur Messung mit Strom versorgt. Die Schwelle liegt 
bei der viertel Betriebsspannung.
Alternativ kann man auch ADC0 an den Minuspol der Solarzelle 
anschliessen (Diode am Minuspol, wie bei der urspr. Schaltung von 
Hagen). Bei Helligkeit ist die gemessene Spannung niedrig, bei 
dunkelheit liegt an der Solarzelle keine Spannung, der ADC misst also 
eine hohe Spannung. Evtl. hilft ein hochohmiger Widerstand über der 
Solarzelle, weil diese auch bei wenig Beleuchtung schon (fast) die volle 
Spannung erzeugt, aber hald nur wenig Strom. (nicht getestet! Ich habs 
nur mit dem LDR ausprobiert.)


Bei den LEDs die ich benutze ("LG L29K" bzw "LG P47K" von Reichelt) ist 
die Schwellspanung niedrig genug dass 2 Zellen durchaus reichen. Bei 
2,2V sind sie zwar schon recht dunkel, aber die Zellen haben ja bei >80% 
der Entladekurve 2,4V oder mehr, so dass das schon klappt.
Zwei statt drei Zellen auch deshalb weil bei den Solarzellen dieser 
Serie (z.B. Best-Nr. 110330) die für drei Zellen geeignete zu grpß ist 
für mein Einmachglas. Deshalb die Versuche die gezeigt haben dass es mit 
zwei Zellen auch geht, wenn auch knapp.

Hat jemand einen Tipp mit welchem Kleber man am besten die Solarzelle 
und die Platinen auf den Glasdeckel eines Einmachglases kleben kann? Am 
besten mit genauer Produktbezeichnung? Ich hab mit sowas überhaupt keine 
Erfahrung.

Randy

Autor: Randy (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
und der Quellcode hinterher

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, die Fuses: Ckdiv8 deaktivieren, alle anderen auf der 
Fabrikeinstellung lassen.

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Zwei statt drei Zellen auch deshalb weil bei den Solarzellen dieser
> Serie (z.B. Best-Nr. 110330)

Gemeint ist die Conrad-Bestellnummer.

Randy

Autor: Lothar M. (lme)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Haussmann (kochloeffel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Ich hab jetzt die I/O Pind des Mega32 nicht gezählt, aber kommt schon 
hin. Nur ist gerade die PWM-Ansteuerung der LEDs (IMHO) recht 
unübersichtlich geraten, ist also gar nicht so einfach da was zu ändern; 
man muß sich zumindest recht tief in die Details der Ansteuerung 
einarbeiten. Aber warum sollte es nicht gehen?
Ich habs mit der originalen Zahl von 12 LEDs nachgebaut und denke die 
Anzahl reicht. Man braucht gar nicht mehr um einen guten Effekt zu 
erreichen.

HTH
Randy

Autor: Michael Haussmann (kochloeffel)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Haussmann (kochloeffel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: wtzm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo mitsammen,
danke für die Schaltung bzw. Idee Hagen. Ich hätte ein paar Fragen dazu:

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

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.

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? BCW61 kann ich bei Farnell nicht finden, ein BCX71 wirds aber 
wohl auch tun. Ein Ersatz für T1 mit niedrigerem Leckstrom lässt sich 
zwar finden (wie im anderen Thread erwähnt), allerdings hab ich den 
Eindruck, dass die Alternativen dann auch wieder eine niedere HFE haben.

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. Meine Anwendung wird im Sommer 
sicher nicht so viel Energie benötigen wie während des Tages gesammelt 
wird, daher war meine Überlegung entweder (a) an einem der AVR Pins 
einen Widerstand (oder Led etc.) den ich bei Bedarf einschalten kann zu 
setzen oder (b) einen baugleichen FET mit Drain und Source vertauscht in 
Serie zu schalten, damit ich per Software weiteres Laden unterbinden 
kann. Allerdings hätte ich bei Variante (b) dann wieder das Problem, 
dass negative Spannung an PB3 liegt.
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?


Danke fürs Lesen &
Beste Grüße

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Ich hab kein Hersteller-Datenblatt, jedoch gibt es mehrere Quellen die 
besagen dass Dauerladen mit C/20 relativ problemlos sein sollte. Und 
ständig in der prallen Sonne steht das Ding ja nicht.
http://www.jens-seiler.de/bastelecke/akkus/
http://www.motelek.net/allgemein/akkus/nixx_akku.html
Da hab ich mir keinen Kopf drum gemacht, Akkus sind eh 
Verschleißteile...

Randy

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Beim langsamen Laden ist es in der Tat unmöglich zu sagen wann der Akku 
voll ist. Das geht nur mit besagtem Delta-U was vorraussetzt dass mit 
mind. C/4 geladen wird.

Randy

Autor: wtzm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Links, Randy.
Bei dem Akku der in der Leuchte drinnen waren (lt. Beschriftung 600mAh) 
kommt der Strom ziemlich genau auf die C/20 hin. Wahrscheinlich wird die 
original Elektronik der Leuchte den Stromfluss auch weiterlaufen lassen.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Wie soll die "Impedanz des Solarpanels" definiert sein? Mit dem 
Ohm-Messbereich des Multimeters wird man nichts aussagekräftiges messen 
können. Der Innenwiderstand eines typischen AAA-Akkus liegt bei <1 Ohm.

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

Ich denke das kommt stark auf den Standort an. Bekommt das Glas bei dir 
auch ab und zu mal direkte Sonne?

Randy

Autor: wtzm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 20mA halte ich für viel für kleine Solarpanels. Messe die Impedanz des
> Solarpanels, sie sollte bei 1k liegen

Eine U/I Testreihe habe ich nur bis zu einem kleinsten Widerstand von 
1.5 Ohm gemacht, in dieser Region (bzw. bei etwas höheren Widerständen) 
würde ich auf einen differentiellen Widerstand des Panels von ca. 1100 
Ohm kommen.

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Eine U/I Testreihe habe ich nur bis zu einem kleinsten Widerstand von
> 1.5 Ohm gemacht, in dieser Region (bzw. bei etwas höheren Widerständen)
> würde ich auf einen differentiellen Widerstand des Panels von ca. 1100
> Ohm kommen.

Klar, in der Region sehr kleiner Lastwiderstände, d.h. bei Spannungen an 
der Solarzelle sehr viel kleiner als die Leerlaufspannung, liefert die 
Zelle im wesentlichen einen konstanten Strom, ihren Kurzschlussstrom.
http://www.physik.uni-augsburg.de/~ferdi/umweltpra...
Damit berechnet man natürlich einen hohen differenziellen Widerstand. 
Ich sehe aber nicht inwieweit dieser Widerstnad eine Bedeutung für das 
Akku-Überlade Thema hat. Solang die Akkuspannung nicht nahe an die 
Leerlaufspannung der Solarzelle steigt(*) , pumpt die Solarzelle immer 
den Strom in den Akku der der aktuellen Beleuchtung entspricht.

Randy

(*) und das kommt sie nicht: Normale Ladespannung mind. 1,4V, das muß 
die Solarzelle auch liefern können. Spannung bei Überladung mit 
moderatem Strom, z.B. C/10, auch nicht mehr als höchstens 1,5-1,55V.

Autor: wtzm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... liefert die Zelle im wesentlichen einen konstanten Strom, ihren
> Kurzschlussstrom
Womit wir also eine Konstantstromquelle mit C/20 haben, also alles in 
Ordnung. Ich glaube eh nicht mehr, dass die Gefahr einer Überladung 
besteht.

Eine Frage hätte ich noch an Hagen: Der FET wird in der Schaltung mit 
sehr niedriger Vgs betrieben - im besten Fall 1.3V wenn der Akku 
komplett voll ist. Falls jetzt der Akku leer ist (0.9V) würde ich 
meinen, dass durch die noch niedrigere Vgs der Ladestrom auf derart 
niedrige Wert begrenzt wird, dass eine Wiederaufladung des Akkus sehr 
lange dauern würde.
Im Infineon Datenblatt zum BSS138 ist eine typische Gate Threshold 
Voltage von 1.0V angegeben. Bei einem Drainstrom von 26µA allerding. 
Fairchild gibt typische 1.3V für 1mA an.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann statt dem BSS138 auch ein BSS123 verwendet werden??

In welchem Gehäuse sind die beiden Kondensatoren C1 und C2??

Danke im Voraus
lg Robert

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: wtzm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke auf jeden Fall mal an alle, meine Fragen sind fürs erste 
beantwortet. Was mir noch beim durchschauen der Datenblätter aufgefallen 
ist, dass es anscheinend beim BSS138 je nach Hersteller doch heftig 
verschiedene Drain-Source Widerstände im durchgeschalteten Zustand gibt. 
Wobei wahrscheinlich auch die Frage ist welcher Prozentsatz der 
Exemplare bei der Berechnung der "Typical Characteristics" einbezogen 
wird.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Haussmann (kochloeffel)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Haussmann (kochloeffel)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum hast du die LED-Vorwiderstände so seltsam angeordnet? Die 
Widerstände müssen dirkt an den entspr. Portpin. Die drei Strippen zu 
den LEDs kommen auf den anderen Anschluss des Widerstandes. So dass der 
Strom immer über zwei Widerstände fließen muß, egal welche Kombination 
von Pins eingeschaltet ist. Nur so sind alle LEDs gleich hell.

HTH
Randy

Autor: Michael Haussmann (kochloeffel)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Randy,
Meinst Du etwa So?
LG
Michael

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> firefly1a.pdf

Ja, genau so.

Autor: Roland Sz (rolandsz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Roland Sz (rolandsz)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bild_1

Autor: Roland Sz (rolandsz)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bild_2

Autor: Roland Sz (rolandsz)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bild_3

Autor: Roland Sz (rolandsz)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bild_4

Autor: Roland Sz (rolandsz)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
und Bild_5

Autor: Randy (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Zur diesjährigen Bastelsaison habe ich ein Layout für meine Version der 
Glühwürmchen-Schaltung erstellt. Diese unterscheidet sich vom Original 
in den Punkten:

- es werden 2 Mikro-Zellen verwendet; ohne Step-Up
- Der Code ist auf einen Tiny44 umgeschrieben, damit braucht man
  keinen Bootloader weil der Reset-Pin keine weitere Aufgabe bekommt.
- Die Lichtmessung erfolgt über einen LDR, nicht über die Solarzelle
- Es gibt einen Watchdog

Zum letztem Punkt: Bei mir hat immer nach spätestens ein paar Tagen der 
Controller seinen Dienst eingestellt. Das liegt möglicherweise an der 
gcc V3 vs. V4 Problematik die im Juni angesprochen wurde. Das hab ich 
allerdings nicht verifiziert, denn die Lösung mit dem Watchdog war schon 
seit Januar fertig und hat funktioniert. Der Watchdog ist ein Programm 
im Tiny45 das den Glühwürmchen-uC resettet wenn der 30 Minuten keine 
Aktivität zeigt. Das kann er dadurch detektieren dass der Tiny44 zum 
messen der Helligkeit den Pin 6 (PA7) kurz auf High legt um den 
Spannungsteiler R6/LDR mit Strom zu versorgen. Misst der Tiny44 mehr als 
30 Minuten die Helligkeit nicht (=keine Aktivität), bekommt er einen 
Reset.
Der ISP-Stecker (aus 
http://www.mikrocontroller.net/articles/AVR-Tutori...) 
hat einen 7.Pin bekommen, so dass er nach dem Programmieren als Stecker 
für die LED-Ketten dienen kann.
Das Layout habe ich nur in der Version 1.0 gebaut, die 1.1 ist das 
Ergebnis der Inbetriebnahme ;-) Hoffe dass ich alle Fehler korrekt 
berichtigt habe. Falls es jemand nachbaut freue ich mich über ein 
Feedback.

Randy

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
Im Layout sind zwei Luftlinien verblieben, das ist der Preis für das 
einseitige Layout. Die Verbindungen muß man mit zwei Drähten manuell 
einfügen.

Autor: Thomaso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Randy

Hab deine Schaltung mit den beiden Tinys (44V und 45V) geätzt und 
gelötet, die Luftleitungen sind drin.
Hab jetzt einfach mal deine beiden Hex-Files aufgespielt und es tut 
sich...mmmmh...naja, ein bißchen was.
Hab im Moment 3 Test-LEDs dran (zwischen 2-5, 2-7, 4-5 gemäß deiner 
Steckerleiste), doch irgendwie scheint immer nur das gleiche Muster im 
gleichen zeitlichen abstand bei genau einer LED (4-5) abzulaufen?!?!

Kann ich überhaupt einfach deine Hex-Files aufspielen, ohne das es 
irgendwelche Probleme gibt? Muss ich irgendwas aufs EEProm spielen?

Zweites Problem: Ich kann die Files für den Tiny44 nicht kompilieren 
(tiny45=watchdog funktioniert): folgende Fehlermeldung tritt auf:
> "make.exe" all

-------- begin --------
avr-gcc (GCC) 4.2.2 (WinAVR 20071221)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiling C: firefly.c
avr-gcc -c -mmcu=attiny44 -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./firefly.lst  -std=gnu99 -Wundef -MMD -MP -MF .dep/firefly.o.d firefly.c -o firefly.o 

Linking: firefly.elf
avr-gcc -mmcu=attiny44 -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=firefly.o  -std=gnu99 -Wundef -MMD -MP -MF .dep/firefly.elf.d firefly.o --output firefly.elf -Wl,-Map=firefly.map,--cref     -lm
firefly.o: In function `eeprom_read_block':
c:/winavr/bin/../avr/include/avr/eeprom.h:268: undefined reference to `seed'
c:/winavr/bin/../avr/include/avr/eeprom.h:268: undefined reference to `seed'
firefly.o: In function `init':
C:\Dokumente und Einstellungen\tw\Desktop\glühtest/firefly.c:64: undefined reference to `lfsr_poly'
firefly.o: In function `update_fireflies':
C:\Dokumente und Einstellungen\tw\Desktop\glühtest/firefly.c:75: undefined reference to `lfsr'
make.exe: *** [firefly.elf] Error 1

> Process Exit Code: 2
> Time Taken: 00:02

Weiß jemand Rat? Was muss ich ändern, damit ich die Files kompilieren 
kann?

Man, das Microcontrollerzeugs kann echt deprimierend sein =(

Grüße,

Thomaso

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomaso,

> Hab im Moment 3 Test-LEDs dran (zwischen 2-5, 2-7, 4-5 gemäß deiner
> Steckerleiste), doch irgendwie scheint immer nur das gleiche Muster im
> gleichen zeitlichen abstand bei genau einer LED (4-5) abzulaufen?!?!

Wie lang hast du es laufen lassen? Manchmal kommen über mehrere Minuten 
nur recht eintönige Muster mit nur wenigen LEDs.

> Kann ich überhaupt einfach deine Hex-Files aufspielen, ohne das es
> irgendwelche Probleme gibt? Muss ich irgendwas aufs EEProm spielen?

Das sollte so passen, ich hab auch nie was ins EEPROM geschrieben.

> C:\Dokumente und Einstellungen\tw\Desktop\glühtest/firefly.c:64:
> undefined reference to `lfsr_poly'

Ich hab die orig. Software nicht geschrieben, nur für den Tiny44 
angepasst, deshalb durchblicke ich auch nicht alle Funktionen. Und auch 
mit dem WinAVR kämpfe ich manchmal, wenn sich ein Programm auf einem 
Rechner kompilieren lässt, und ein anderer Rechner mit einer anderen 
Version von WinAVR seinen Dienst verweigert.
Deshalb kann ich keine fundierten Tipps geben. Als einziges ist mir 
aufgefallen dass dein Pfad Leerzeichen und Umlaute enthält, würde mal 
Prüfen ob nicht das die Quelle des Ungemachs ist. Und auch mal im 
makefile schauen, da stehen manchmal absolute Pfade drin, die können bei 
deinem Rechner anders sein.

Randy

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein Hinweis:

Beim ISP/LED-Stecker liegt auf Pin 1 die Betriebsspannung. Die ist für 
den Programmer notwendig, führt aber dazu dass eine LED durchbrennt wenn 
man man den Stecker mit den LED-Ketten um einen Pin versetzt aufsteckt. 
Deshalb hab ich nach dem Programmieren Pin 1 abgezwickt, damit ein 
Fehler beim Zusammenbauen nicht die Hardware zerstört. Falls man doch 
noch mal programmieren muß kann man die Spannung für den Programmer ja 
manuell zuführen.

Randy

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Kann ich überhaupt einfach deine Hex-Files aufspielen, ohne das es

Nur eins noch: Die Fuse für 8MHz RC-Clock setzen, d.h. die Clock_Div_8 
setzen/löschen, ich weiß jetzt nicht. Auf jeden Fall ggü. dem 
Default-Wert negieren.

Randy

Autor: Thomaso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die schnelle Antwort, Randy!

Die Fuses sind auf 8Mhz interner Takt und der interen Div8-Teiler is 
ausgeschaltet... Müsste also mit 8Mhz laufen.

Mit dem Stecker selbst dürfte es keine Probleme geben, da ich die 
Drähtchen direkt anlöte (also ohne Stecker =)

Das kompilieren klappt immernoch nicht, aber solangs auch mit deinen 
Hex-Files geht, sollte es ja irgendwie klappen =)

Werd jetzt die kommenden Tage mal die restlichen LEDs dranbaun und 
schaun, was passiert. Meld mich dann wieder!

Vielen Dank schönmal

Thomaso

Autor: tripledot (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
N'Abend...


könnte jemand, der sich mit dem Thema hier eingehend befasst hat (mir 
fehlt die Zeit mich mit dem Bug/ Neucompilieren auseinander zu setzen), 
bitte eine fertige .hex Version des Projektes posten, die auf Hagens 
ursprünglichen Schaltplan passt?

Zu meiner Motivation....ich möchte nur ein hübsches Geschenk basteln, 
das nach Möglichkeit keinen Bug hat. Für das Hineindenken bleibt mir 
leider keine Zeit, um die hier aufgeführten Gedanken in den 
ursprünglichen Code einzuflechten.

Mit der Bitte um Nachsicht....
Hannes



PS: Vielen Dank!

Autor: DiscoStu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fänd ich auch klasse,wenn sich mal jemand die Mühe machen würde und eine 
aktuelle Version für das Programm und die Schaltung von Hagen zu posten. 
Hier sind so viele Änderungen was Software und Bauteile und Pinbelegung 
angeht, das es echt unübersichtlich geworden ist.Thx Olli

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> könnte jemand, der sich mit dem Thema hier eingehend befasst hat (mir
> fehlt die Zeit mich mit dem Bug/ Neucompilieren auseinander zu setzen),
> bitte eine fertige .hex Version des Projektes posten, die auf Hagens
> ursprünglichen Schaltplan passt?

Das habe ich nicht, ich kann nur sagen dass meine Variante im Beitrag 
vom 23.11.2009 schon seit Monaten funktioniert.

Randy

Autor: Stefan Grimm (dreamer83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Grimm (dreamer83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Grimm (dreamer83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Joachim R. (bastelbaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Grimm (dreamer83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nach dem
> Einschalten (LDR abgeklemmt) fangen verschiedene LEDs nach ca.20
> Sekunden an zu flackern

Das mit den 20 Sekunden ist ok, ich hab bei meiner Variante des Codes 
die Wartezeit reduziert um den Vorführeffekt zu verbessern - wer will 
schon 6 Minuten im dunklen Zimmer warten um den Effekt zu sehen. 20 
Sekunden waren der Kompromiss zwischen Stromverbrauch und erträglicher 
Wartezeit.
Zum Rest kann ich nicht viel sagen - vielleicht stimmt das so. Manchmal 
leuchten einzelne LEDs wirklich ein paar Sekunden am Stück. Und ab und 
zu ist auch mal alles aus.

HTH
Randy

Autor: Joachim R. (bastelbaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernhard M. (boregard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Bernhard,

danke für die schnelle Antwort !!!!!
Hatte gedacht das Du die Schaltung auf einer Platine aufgebaut hast.
Aber mit Lochraster komm ich klar.

Der Rest steht ja in firefly.h firefly.c und wave.h.

Welche Variante hast Du denn im Moment am laufen?

a) über Solarzelle
b) Messung über LDR mit (Reset-Pin) geschaltetem Pull-up
c) Messung über LDR mit Kondensator

Danke nochmal für die schnelle Antwort.

LG
Tom

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: René (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernhard/boregard,

kannst Du bitte Dein komplettes Projekt posten (Beitrag vom 21.10.2011 
13:24)?
Bei der Variante mit LDR ohne Reset PIN hört es irgendwann auf zu 
leuchten. die Software ist aber nicht abgestürzt, habe zu debugzwecken 
an PB4 eine LED im main loop immer blinken lassen, und check auf 
dunkelheit deaktiviert.
Welche WinAVR Version nutzt Du?

Vielen Dank,
René

Autor: Stefan Grimm (dreamer83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernhard M. (boregard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: René (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernhard,

Ich habe Deinen Code mit der gleichen tool chain übersetzt trotzdem 
stoppen die Tierchen ihre Arbeit nach ca. 4 Tagen. Da man den 8 Beiner 
so schlecht debuggen kann überlege ich einen externen Reset Mechanimus 
einzubauen (Supervisor Watchdog IC). Es soll möglichst alles autonom 
laufen da es ein Geschenk wird.
Könntest Du bitte Deine Hexfiles für einen letzten Dauertest posten, 
bevor ich diese Variante wähle.

Danke im voraus,
rené

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Da man den 8 Beiner
> so schlecht debuggen kann überlege ich einen externen Reset Mechanimus
> einzubauen (Supervisor Watchdog IC).

Der Tiny45 im Beitrag
Beitrag "Re: Glühwürmchen in Rotkohlglas gefangen"
macht genau das. Wenn 30 Minuten lang an Pin 5 nicht gewackelt wurde 
gibt es auf Pin 6 einen Reset-Impuls. Das musst das vielleicht noch mit 
der Dunkel-Erkennung kombinieren damit es nicht tagsüber dauernd 
Reset-Impule gibt. Obwohl, stören würden die vermutlich auch nicht?

HTH

Autor: Bernhard M. (boregard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: René (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernhard,

Vielen Dank für Deine Hilfe. ich mache gerade einen Test bis nach Ostern 
mit zwei Varianten einem HEX von Dir und parallel meine HEX Datei.
Eine Frage noch zum LDR, bei denen gibt es starke Schwankungen,
wie sollte die folgende Variable gesetzt werden, wenn der LDR einen 
höheren Widerstand bei Dämmerung als ein anderes Exemplar?
#define LIGHT_THRESHOLD 100
Ich habe mal zum Test 200 und 50 getestet aber bei einem LDR keinen 
Unterschied feststellen können. Also müsste doch bei hochohmigen 
Exemplaren der Schwellwert niedriger sein oder?

Gruß,
René

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tolles Projekt!

Ich suche noch ein last-minute Geschenk für Ostern. Hat jemand evtl. ein 
paar Platinen gefertigt/fertigen lassen?

Würde diese gerne gegen großzügige (;-))Aufwandspauschale erwerben, da 
ich selbst leider nicht ätzen kann und bis Ostern die Zeit für ne 
Bestellung knapp wird bzw. der Preis dann ein bisschen hoch wird.

Grüße,
Tom

Autor: René (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mitstreiter,

ich habe heute mein erstes Glas mit den Tierchen fertig bekommen. Ich 
nutze eine modizierte Schaltung von Bernhardt mit LDR, ohne Bootloader, 
den brauche ich nicht. Im Anhang findet Ihr den Code, Eagle 6.1 Projekt 
und ein paar Bildchen. Danke nochmal an alle die zu diesem schönen 
Projekt beigetragen haben. Ich nutze Eclipse CDT mit AVR Plugin 2.3.4 
unter Linux und AVR GCC 3.6.4.

Platine ist 4,5x5cm groß und hat Platz für 2xAAA Eneloop Akkus und 
Solarzelle.
Solarzelle 4,1V ist von Conrad Best.-Nr.: 191308 - 62.
LEDs habe ich von Reichelt G L29K :: OSRAM Smart LED, Low C., 0603, 5,6 
mcd, grün sind nicht die hellsten reicht aber für mich aus, Farbe ist 
gelbgrün.
Die LED Stränge und die Solarzelle habe ich mit 
Präzisionsbuchsen/Stiftleisten verbunden.
Die Solarzelle sitzt auf der Leiterbahn. Ok das Layout ist 
verbesserungswürdig aber es funktioniert. Leider hatte ich keinen grünen 
lötbaren Draht. Das werde ich im 2. Aufbau machen. Das schwerste war die 
LED Stränge löten ich habe 3 LED dabei verloren ein Windhauch und sie 
sind unaufindbar, habe dann mit Tesa die Drähte beim löten fixiert und 
Spezial Flußmittel genommen und mit 300 Grad unter starker 
Kaltlichtlampe gelötet.

Gruß,
René

Autor: René (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

anbei noch der Code ohne Bootloader Logik.
Der LDR Schwellwert ist noch experimentell.

Gruß,
René

Autor: Frank P. (mauz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es lebt!
Danke für das schöne Projekt.
Eine Frage habe ich noch. Ich wollte mal mit den Waves etwas spielen, 
nur der WaveEditor meckert beim Export nach .h, er könne "wave.template" 
nicht finden. Habe ich da was übersehen?
frank

Autor: Hagen Re (hagen)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
im Anhang alle Dateien.

Gruß hagen

Autor: Frank P. (mauz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank, nun geht es!
Mal schauen, ob ich für meine Käfer besser geeignete Waves hinkriege. 
Meine LEDs sind nämlich insgesamt doch recht dunkel.
frank

Autor: Björn B. (elmo)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

erstmal vielen Dank für dieses tolle Projekt! Inzwischen läuft mein 
erster Aufbau und einige weitere werden gerade zum Verschenken 
vorbereitet :-)

Da ich mir ein paar Platinen hab fertigen lassen, sind noch 5 Stück 
übrig. Bei Interesse bitte PN. Ich hätte gerne 3,- das Stück inkl. 
Versand.

Viele Grüße
Björn

Autor: Konrad S. (maybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Björn B.
Die Platine ist angekommen, vielen Dank!

Autor: Björn B. (elmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GCC 4.7.2 unter Linux produziert übrigens kein brauchbares Hexfile. 
Woran es liegt, konnte ich leider bisher nicht herausfinden.
Mit dem in FireFly_patched_231208.tgz enthaltenen Hexfile hingegen 
funktionieren  die original Hardware sowie mein Nachbau.

Autor: Björn B. (elmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwei Platinen wären noch zu haben. Diese jetzt inklusive MAX1724 für 
weiterhin 3,- Euro.

Gruß
Björn

Autor: Hans .. (Firma: Private) (erty21)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Björn
ich nehm Dir gerne zwei Stück ab .

melde dich doch mal bitte per Pm
Dank und Gruß Hans

Beitrag #3423314 wurde von einem Moderator gelöscht.
Beitrag #3423531 wurde von einem Moderator gelöscht.
Autor: Andy S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Obwohl der Beitrag jetzt schon einige Zeit auf dem Buckel hat, möchte 
ich jetzt doch meine Erfahrungen mitteilen um etwaigen Nachbauern nicht 
vor die gleichen Probleme zu stellen.

Die von Hagen angehängte Source ist soweit in Ordnung, nur ist immer 
wieder von komischem Verhalten der Schaltung berichtet worden, welche 
auch im Zusammenhang mit der Compiler-Version zu stehen scheinen.

Es wrid berichtet:

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

Da ich AVR Studio 5.1 mit AVRGCC 3.3.1.27 verwende, hat die Schaltung 
sämtliches mir bekanntes komisches Verhalten an den Tag gelegt.

z.b. dauerhaft leuchtetende Würmchen
zu hoher Stromverbrauch, bis sich der avr letzendlich "gefressen" hat 
und nur ein Hardware Reset abhilfe schaffen konnte.

Das Problem ist auf einen Fehlerhaften Pointerzugriff zurückzuführen. 
Der von mir verwendete Compiler kann mit der Struct definition in der 
wave.h nichts anfangen und lagert den code nicht in den progmem aus
die folge ist ein fehlerhafter speicherzugriff

ORGINAL:

typedef struct {
    const prog_uint8_t* start;
    const prog_uint8_t* stop;
    const uint16_t energy;
} wave_data_t PROGMEM;

FUNKTIONSFÄHIG:

typedef struct PROGMEM{
    const prog_uint8_t* start;
    const prog_uint8_t* stop;
    const uint16_t energy;
} wave_data_t ;

Das hat alle Fehler vollständig beseitigt!

Danke noch mal an Hagen für das Projekt !!

- Andy

Autor: chris_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mich interessiert zum Thema Glühwürmchen die Synchronisation. Kann das 
Gartenglühwürmchen das auch?

Hier gibt es eine Beispielimplementierung:
http://www.instructables.com/id/Synchronizing-Fireflies/

Und hier die Low-Power-Version:
http://www.seanet.com/~karllunt/fireflyLED.html

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris_ schrieb:
> Mich interessiert zum Thema Glühwürmchen die Synchronisation. Kann das
> Gartenglühwürmchen das auch?
>
> Hier gibt es eine Beispielimplementierung:
> http://www.instructables.com/id/Synchronizing-Fireflies/
>
> Und hier die Low-Power-Version:
> http://www.seanet.com/~karllunt/fireflyLED.html

Ja und Nein. Nein wenn du das Verhaltzen auf individuelle Ebene 
simulieren möchtest, dh. schon HW-mäßig besteht jedes einzelene 
Glühwürmchen aus einer eigenen Elektronik und eigener SW.

Ja aus Sicht der Verhaltenssimulation, das war ja auch einer der Gründe 
warum ich mich mit dem Thema beschäftigt habe, die Nichte zu beglücken 
kann ja nicht alles an so einem Projekt darstellen.

Schon im allereesten Posting mein Source implementiert alle wichtigen 
Strukturen und Variablen um eben das Behavior von Fireflys zu 
simulieren. Das umfasst also:

- die Datenstruktur FireFly_t
- die Member Energy, Hungry die für ein Grlühwürmchen berechnet werden 
und auch die Werte der anderen Glühwürmchen modifizieren kann.
- die Leuchtmuster = Waves in denen die LED leuchten. Diese Leuchtmuster 
enthalten einen Datenwert der die RMS-Energie-Abgabe beschreibt.
- somit kann man wenn ein Firefly leuchtet dessen Energiewert und 
Hungrywert entsprechen der nötigen Energie des Leuchtmusters updaten.

Das Behavior ist also ziemlich einfach definiert:
1 Glühwümchen leuchtet in einer zufällig ausgewählten Sequenz. Dabei 
verbraucht es entsprechend Enegie und wird hungrig. Gleichzeitig regt es 
das Energiepotential zum Leuchten, eg. die Schwelle ab dem die 
benachbartem Fireflys an indem die UpdateFireFlies() Funktion die 
verbrauchten Energiepunkte zum aktuelle FireFly anteilmäßig auch auf die 
benachbarten Glühwürmchen aufrechnet.
Die Zeitphasen in denen die Glühwürmchen nicht leuchten, sich die SW 
also im Power Down Modus befindet wird in Sücken a 16ms als 
Energie-Aufnahme wieder auf das Energiekonto des Glühwürmchen drauf 
gerechnet.
Desweiteren leuchten die Glühwümchens nur Nachts über was ebenfalls dem 
natürlichen Verhalten entspricht.

Sogesehen: in der ersten Version des Projektes sind alle Eigenschaften 
vorhanden die nötig sind um eine relatische Simulation durchführen zu 
können.

Würde man nun jedes FireFly separat mit eigner HW aufbauen dann käme man 
denoch zu ähnlichen Ergebnisen. Währen die HW-Variante die Solarzelle 
oder sowas wie physikalische Augen einbauen muß benötigst du dies bei 
meiner Variante nicht. Dort wird diese "Sensorik" wie auch die "örtliche 
Positionierung" der Fireflys zueinander in Software simuliert.
Mit einer HW-Lösung würde man dies natürlich in HW aufbauen wollen.
An den Simulationsergebnissen änderte dies aber nichts.

Meine inoffizielle Version, mein Experiment, geht aber noch einen 
Schritt weiter. Es wird der Gesamtenergieverbrauch und die Gesamtenergie 
die durch das Solarpanel aquiriert wurde berücksichtigt. Bekommmen die 
Glühwürmchen also tagsüber zu wenig Licht = Nahrung dann ändern sie ganz 
logisch ihr Verhalten indem sie nachts entsprechend weniger leuchten.

Das jetzt angestrebte Verhalten sollte folgendes Blinkmuster ergeben:
1. die Firefly leuchten nachts in unterschiedlichen Mustern
2. die Fireflys scheinen angeregt durch das Blinken eines Fireflys 
selber mit Leuchten auf diese Leuchten zu reagieren und entsprechend von 
der Komplexität dieses Reitmuster (Engergiebedarf) selbst darauf zu 
reagieren indem sie schneller antworten.
3. je nach Verdrahtung der LEDs sollte man erkennen können das diese 
Gegenreaktion durch LEDs in der Nähe der auslösenden LED erfolgt.
4. es sollten also längere Phasen geben in denen sich nur wenige 
FireFlys zu "Wort" melden und dann wieder Phasen in den sprunghaft aber 
zeitverzögert mehrere bis viele Fireflys leuchten. Diese regen 
ihrerseits dann wieder andere Fireflys zum leuchten an aber die "große 
Welle" an leuchten muß abnehmen dabei. Man kann also sowas wie ein 
gepulstes Nachleuchten wie eine Welle die durch den Schwarm läuft 
beobachten.

Gruß Hagen

Autor: Roland Ertelt (roland0815)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Lustiges Projekt.

Blöd nur, dass es keine LEDs gibt, die das typische Glühwürmchen 
GelbGrün ordentlich repoduzieren. Jeder, der schon mal ein echtes 
Glühwürmchen gesehen hat wird den Unterschied sehen.

Autor: chris_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>4. es sollten also längere Phasen geben in denen sich nur wenige
>FireFlys zu "Wort" melden und dann wieder Phasen in den sprunghaft aber
>zeitverzögert mehrere bis viele Fireflys leuchten.
Das scheint in dem Video mit echten Glühwürmchen der Fall zu sein:
http://phys.org/news197815725.html
Leider ist es etwas undeutlich. Ich meine mich an eine Reportage im 
Fernsehen zu erinnern, bei der ein ganzer Baum gleichmässig geblinkt 
hat.

Autor: chris_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Man kann also sowas wie ein
> gepulstes Nachleuchten wie eine Welle die durch den Schwarm läuft
> beobachten.
Dazu das Video 2 hier:
http://tinkerlog.com/2009/06/25/64-synchronizing-fireflies/
Ich vermute, dass der Lichtsensor des einzelnen "Glühwürmchens" nicht 
alle anderen sehen kann, sondern nur seine Nachbarn. Trotzdem entsteht 
keine Welle.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
als sich fortpflanzende Welle, meinte ich. Ich habe damals einiges an 
Abhandlungen zu Glühwürmchens gelesen, besonders war ich auf der Suche 
nach digitalisierten Leuchtmustern.

Das von dir angesprochene Viedeo zeigt beide angesprochenen Effekte. 1. 
werden sich lange Dunkelperioden ergeben und dann durch wenige 
Glühwürmchens veranlasst leuchten in deren Umgebung immer mehr 
gleichzeitig auf. 2. der Impuls, eg. die Wellenfront pflanzt sich fort. 
Ist eigentlich auch logisch da ja die Glühwürmchens evolutionär keinen 
Vorteil hätten wenn sie auf 100'erte Kilometer Entfernung einem Weibchen 
antworten würden. Aus Sicht eines größeren örtlich verteilten Schwarmes 
muß es also dann so aussehen das igrendwo im Schwarm das Leuchten 
einsetzt, die umliegenden Glühwürmchens angeregt werden und dadurch 
ihrerseits weiter entfernte Glühwümchens zum Leuchten bringen. Die Welle 
pflanzt sich durch den Schwarm fort.

Übrigens meine ich auch das deine verlinkte Simulation nicht korrekt 
modelliert wurde. Die Glühwürmchen antworten schon als Masse in Wellen 
auf ein Reizsignal. Das heist aber eben nicht das sie sich von ihrem 
Timing her auf die Zukunft betrachtet hin synchronisieren. So als ob sie 
einen inneren Zeitgeber hätten, am Anfang unsynchronisiert jeder mit 
seiner eigenen Frequenz und am Ende hin alle schlagartig.
Dies widerspricht dem evolutionären Sinn des Ganzen. Es geht um 
Fortplanzung und das Anlocken möglichst vieler Männchen aus Sicht der 
Weibchens. Was ich aus wissenschaftlichen Abhandlung weiß deutet eher 
darauf hin das es immer die Weibchen sind die das Leuchten auslösen. 
Ergo heist dies für ein gutes Modell: es müssen zwei unterschiedliche 
Arten von Glühwürmchens modelliert werden, einmal Weibchens und ein 
anders Mal Männchen. Und beide unterscheiden sich in ihrem Verhalten wie 
sie auf Leuchtmuster anderer reagieren werden.

Warum sollte in einem Schwarm aus par wenigen Weibchens und ne Handvoll 
Männchens auch die zur Zeit nicht blinkenden Weibchens entschließen, 
quasi Energie opfern, und synchron mit allen anderen Glühwürmchens 
zusammen zu leuchten ? Sie haben keinen Vorteil gegenüber ihrer 
Fortpfanzungskonkurrentinnen wenn sie so wie Männchen auf das Leuchten 
der Konkurrentinnen reagieren würden.

In einem guten Modell kann der Zustand "alle leuchten demnächst zum 
gleichen Zeitpunkt" garnicht vorkommen dürfen.

Gruß hagen

Autor: chris_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> es müssen zwei unterschiedliche
> Arten von Glühwürmchens modelliert werden, einmal Weibchens und ein
> anders Mal Männchen.

Wobei man vermuten könnte, das es ausreicht, wenn nur ein Geschlecht 
leuchtet.

Autor: chris_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hier beschriebene Verfahren
http://www.rlocman.ru/i/File/2007/10/24/2006_WSL_F...

zur Synchronisation der Glühwürmchen schein ja recht einfach zu sein, 
wie in dem Bild zu sehen ist:
http://cdn.instructables.com/FMB/LST2/F03GBAW2/FMB...

Es wird eine Phase linear bis zu einem Schellwert erhöht. Wenn der 
Schwellwert erreicht ist, blitzt das Glühwürmchen. Es kann früher 
blitzen, wenn es andere Glühwürmchen sieht.

Autor: chris_ (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal eine Simulation mit 8x8 Glühwürmchen.

Der Algorithmus für ein einzelnes Glühwürmchen ist im wesentlichen 
folgender:
phase++; 
phase+=seeLight(x,y)/20*phase/255;


Wobei seeLight(x,y) im die Summe der Helligkeiten der Farbe Grün der 
benachbarten Glühwürmchen zurück gibt.

Autor: Der_Kochloeffel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
eine Frage an jemanden der sich hier gut auskennt?

Habe die Glühwürmchen nachgebaut, und Funktioniert ganz gut.
Nun die Fragen:

1. was muss ich wo am Code weglassen, oder verändern, wenn ich keine 
Spannungsüberwachung des Akkus und der Solarzelle wünsche, so das die 
Würmchen gleich loslegen wenn ich einen Akku einsetzte, b.z.w. die 
Elektronik einer Gartensolarlampe auf Nacht schaltet und meinen mC mit 
Energie versorgt?
Also völlig ohne Tag/Nacht und Akku Überwachung.

2. wenn ich statt des Tiny 45 einen Tiny44 20 PU also einen mit 14 
Beinchen einsetzten möchte, habe ich den Code, also die Befehle 
entsprechend angepasst laut beiden Datenblättern, aber ich bekomme das 
Programm einfach nicht zum Laufen?
Das einzige das ich nicht anpassen konnte waren die 2,5v Interne 
Reverenz Spannung, bei meinem Tiny44 sind das 1,1V oder leitung zum 
entsprechenden Port mit VCC also 5V Legen, und hatte dann testhalber 
Akkuspannung von 1,2 V drann und auch 5 V aber das hat nicht 
funktioniert, oder es liegt an etwas anderem was nicht so ganz passend 
ist?


Ziel hiervon wäre ein bis Zwei mehr LED Ports und Externen Oszilator 
verwenden und dann auch eventuell noch mehr LED Ports zu verwenden.

Da aber das Programm auf meinem Tiny44 scheinbar nichts macht, also 
nichts an den LED's erkennbares, kann ich auch nicht Testen ob sich das 
Programm, wie weiter oben als Tip von Hagen beschrieben erweitern lässt?

Geflasht habe ich alles ohne Bootloader, einfach nur das Hexfile das 
nach anwendung von Make ensteht habe ich auf den mC übertragen.


Wäre sicherlich für andere auch Hilfreich, da eine Solarlampe schon fast 
alles mit sich bringt was man zum Laden und Tag / Nacht erkennung 
benötigt, und die Sorte die ich zum Basteln hier habe, hat eine sehr 
gute Diode verbaut, Spannungsverlust Solarpanel zum Akku 0,1 V konnte 
ich Messen.

Von da her ist es ja eigentlich einfacher das der Zweckentfremdetetn 
Electronic der Lampe zu überlassen oder?




Mit Freundlichem Gruß
Michael

Autor: Der_Kochloeffel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
hab das Problem selbst gelöst bekommen, hier der Code ohne die Solar und 
Akku Messung und damit Zwei freien Pin's ähem Port's!

Wenn es Jetzt Nacht ist bekommt der Attiny von der ehemaligen 
Gartenlampe, also der Stepup erst Energie, und dann läuft das Programm 
einfach und die Glühwürmchen fangen an zu Leuchten!

Lg
Michael
zuerst die firefly.c
#include "firefly.h"

firefly_t fireflies[12];                            // 12 fireflies
uint8_t   ocr_data[6];                              // OCR0A and DDRB datas for Timer0 Compare Match ISR, computed PWM Dutycycles
uint16_t  hungry_threshold;                         // threshold for lightning fireflies

// 12 fixed registers assigned to speedup ISRs, Timer0 Overflow and Output Compare
register uint16_t  _saveZ    asm("r2");             // save Z register
register uint16_t  _saveY    asm("r4");             // save Y register
register uint8_t   _saveSREG asm("r6");             // save SREG
register uint8_t   _zero     asm("r7");             // zero Register
register uint8_t*  _ocr_ptr  asm("r8");             // pointer to current ocr_data[] entry
register firefly_p _fly_ptr  asm("r10");            // pointer to current firefly[] entry
register uint8_t   _ddr_idx  asm("r16");            // index into ddr_data[] entry, 0 upto 15 in +4 steps
register uint8_t   flags     asm("r17");


static void init(void) {
  // init global registers
    _fly_ptr = (firefly_p)&fireflies;
    _zero    = 0;
    _ddr_idx = 0;
    flags    = 0;
  // enable watchdog ISR
    wdt_reset();
    WDTCR |= (1 << WDE) | (1 << WDCE);
    WDTCR  = (1 << WDIE);
  // Port
    PORTB  = 0;
  DDRB   = 0;
  // Power Reduction, enable ADC for setup
    PRR    = (1 << PRTIM1) | (1 << PRTIM0) | (1 << PRUSI);
  //  AC/ADC
    ACSR   = (1 << ACD);
    ADCSRA = 0;
    ADCSRB = 0;
    DIDR0  = (1 << ADC0D) | (1 << ADC2D) | (1 << ADC3D) | (1 << AIN1D) | (1 << AIN0D);
  // Power Reduction, enable Timer0
    PRR    = (1 << PRTIM1) | (1 << PRUSI) | (1 << PRADC);
  // Pin Change Mask on PB2, for calling Bootloader
    GIMSK  = 0;
    PCMSK  = (1 << PCINT2);
  // Timer0, Overflow & Compare Match ISR used
    TCCR0A = 0;
    TCCR0B = 0;
    OCR0A  = 0;
    TCNT0  = 0;
    TIMSK  = (1 << OCIE0A) | (1 << TOIE0);
    TIFR   = (1 << OCF0A) | (1 << TOV0);
  // init PRNG, load last seed from EEPROM, calculate next seed and store back to EEPROM, use another polynom as in lfsr()
    eeprom_read_block((uint8_t *)&seed, (uint8_t *)(0), 4);
    lfsr_poly(32, 0x8140C9D5);
    eeprom_write_block((uint8_t *)&seed, (uint8_t *)(0), 4);
}

static uint16_t update_fireflies(void) {

  // update waves
    firefly_p fly = (firefly_p)&fireflies;
    firefly_p cur;
    for (uint8_t i = 12; i > 0; i--) {
      if ((fly->wave_ptr == 0) && (fly->hungry == 0)) {
        uint16_t* data = (uint16_t*)&wave_data[lfsr(5)];                // choose wave for lightning from a set of 32 waves randomly
        cur = fly;
        uint16_t ptr = pgm_read_word_inc(data);
        cur->wave_end = pgm_read_word_inc(data);
        cli();
        cur->wave_ptr = ptr;
        flags |= FLAG_TIMER;
        sei();                                                          // update next energy points, each neighbor fly becomes half of energy points
        uint16_t energy = pgm_read_word_inc(data);
        while (energy > 0) {
          cur->energy += energy;
          if (++cur >= &fireflies[12]) cur = (firefly_p)&fireflies;
          energy /= 2;
        }
      }
      fly++;
    }
  // calc feeding step and update fireflies hungry value
    uint16_t food = 0xFFFF;
    uint16_t threshold = hungry_threshold;
    fly = (firefly_p)&fireflies;
    for (uint8_t i = 12; i > 0; i--) {
      uint16_t hungry = fly->hungry;
      if (fly->energy > 0) {
        if ((hungry == 0) || (hungry > threshold)) {
          uint16_t max = 0xFFFF - fly->energy;
          if (hungry < max) hungry += fly->energy;
            else hungry = 0xFFFF;
          if (threshold < 0xFFF0) threshold += 3;
        } else if (threshold > 1) {
          threshold -= 2;
        }
      }
      if (hungry < food) food = hungry;
      fly->hungry = hungry;
      fly->energy = 0;
      fly++;
    }
  // hungry_threshold ensures that fireflies with low hungry is ligthning early and so we get a ligthing in periodic intervals of groups of fireflies,
  // eg. or some longer delays of no lightning dependend on how many energy is consumed by the ligthning waves
    hungry_threshold = threshold;
  // feeding
    fly = (firefly_p)&fireflies;
    for (uint8_t i = 12; i > 0; i--) {
      fly->hungry -= food;
      fly++;
    }
  // return minimal watchdog timer cycles for sleep mode, eg. food
    return food;
}

static void measure_isnight(void) {

    flags &= ~FLAG_ISNIGHT;
  // enable ADC Noise Reduction Sleep Mode
    MCUCR  = (1 << SE) | (1 << SM0);
  // first dummy reading, VRef=2.56V

  // read battery voltage

 // read solar panel voltage
  flags |= FLAG_ISNIGHT;
  // disable ADC
    ADCSRA = 0;
    PRR    = (1 << PRTIM1) | (1 << PRUSI) | (1 << PRADC);
}

static uint16_t wdt_setup(uint16_t time) {

  // setup watchdog to next highest timeout that match time
    uint16_t res = 1;
    uint8_t  idx = 1;
    while ((res <= time) && (idx < 10)) {
      res += res;
      idx++;
    }
    res /= 2;
    if (--idx > 7) idx = (idx & 0x0F) | (1 << WDP3);
    idx |= (1 << WDIE);                                                 // enable WDT-ISR
    wdt_reset();
    WDTCR |= (1 << WDE) | (1 << WDCE);
    WDTCR  = idx;
    return res;
}

int main(void) {

    init();
    sei();

    uint16_t timeout = 0;   // remaining time in WDT cycles a 16ms upto next event
    uint16_t measure = 0;   // remaining time upto next measurement

    while (1) {
    // check for update, FLAG_UPDATE is set in Watchdog ISR
      if (flags & FLAG_UPDATE) {
        flags &= ~FLAG_UPDATE;
        if (timeout == 0) {
          if (flags & FLAG_ISNIGHT) {
            timeout = update_fireflies();
            if (measure <= timeout) {
              measure = MEASURE_INTERVAL;
              flags |= FLAG_MEASURE;
            } else measure -= timeout;
          } else {
            measure = MEASURE_INTERVAL;
            timeout = measure;
            flags |= FLAG_MEASURE;
          }
        }
        timeout -= wdt_setup(timeout);
      }
    // check iff we playing waves
      if (flags & FLAG_TIMER) {
      // enable PWM-Timer0, XTAL / 64
        TCCR0B = (1 << CS01) | (1 << CS00);
      // sleep mode idle
        MCUCR  = (1 << SE);
        sleep_cpu();
      } else {
      // disable Timer0
        TCCR0B = 0;
        OCR0A  = 0;
        TCNT0  = 0;
      // enable deep Power Down Sleep Mode
        MCUCR  = (1 << SE) | (1 << SM1);
      // enable Pin Change for Bootloader on PB2
        PORTB  = 0;
        DDRB   = 0;
        cli();
        GIMSK  = (1 << PCIE);
        GIFR   = (1 << PCIF);
        sei();
        sleep_cpu();
        GIMSK  = 0;
      // check iff we must measure battery and solar panel
        if (flags & FLAG_MEASURE) {
          flags &= ~FLAG_MEASURE;
          measure_isnight();
        }
      }
    }
}

dann noch die firefly.h
#ifndef FIREFLY_H
#define FIREFLY_H

#include <inttypes.h>
#include <avr/eeprom.h>
#include <avr/pgmspace.h>
#include "lfsr32.h"
#include "wave.h"

/*
   PB2 =      = InOut = LED0
   PB1 =      = InOut = LED1
   PB0 =      = InOut = LED2
   PB5 =      = InOut = LED3


   connection schemata for LEDs are:
   - two antiparallel connected LEDs to two wire, makes six such wires
   - connect these wires to PB0-PB1, PB0-PB2, PB0-PB5, PB1-PB2, PB1-PB5, PB2-PB5
   - the order of these connections are not relevant
   
   setup:
   - install AVRootloader.HEX on AVR
   - setup fuses to XTAL=8Mhz, no Brownout Detection, no WDTON
   - connect RS232 on PB2 and test Bootloader (reading/writing EEPROM)
   - setup fuses to disable RESET Pin and lockbits
   - connect with bootloader an program FireFly.HEX
*/

#define FLAG_WAVE           (1 << 0)                    // PWM is active for a LED
#define FLAG_TIMER          (1 << 1)                    // PWM is active
#define FLAG_UPDATE         (1 << 2)                    // Watchdog signaled a update
#define FLAG_ISNIGHT        (1 << 3)                    // is at night
#define FLAG_MEASURE        (1 << 4)                    // measure battery and solarpanel

#define MEASURE_INTERVAL    (uint16_t)(1 *  1200)       // each 6 minutes measure interval
#define BATTERY_OK          (uint16_t)(0 * 400)       // 0.9 Volt

// LED Rows, Pins connected to LEDs
#define R0  (1 << PB0)
#define R1  (1 << PB1)
#define R2  (1 << PB2)
#define R3  (1 << PB5)

// bitmasks for driving LEDs on PORTB and DDRB, first value are for PORTB (always 1), 
// next 3 values for DDRB to connect LEDs to GND (on) or as high-Z input (off)
// you can reorder this array iff needed so long as each row depends to only one PORTB value,
// means in each row you can savely reorder the colums and/or you can savely reorder the rows.
prog_uint8_t ddr_data[16] = {
    R0, R0^R1, R0^R2, R0^R3,
    R1, R1^R0, R1^R2, R1^R3,
    R2, R2^R0, R2^R1, R2^R3,
    R3, R3^R0, R3^R1, R3^R2};

// a Firefly
typedef struct {
    uint16_t wave_end;                              // pointer to end of wave samples
    uint16_t wave_ptr;                              // pointer to current wave sample == PWM Dutycylce of one LED
    uint16_t hungry;                                // energy points that must be feed to activate lightning of firefly
    uint16_t energy;                                // next energy points to add to hungry
} firefly_t;                                        // one energy/hungry point relates to one WDT cycle of 16ms

typedef firefly_t* firefly_p;

// some macros, don't use WinAVR GCC default macros because these produce inefficient compiled code
#define  wdt_reset()         asm volatile("wdr")
#define  cli()               asm volatile("cli")
#define  sei()               asm volatile("sei")
#define  sleep_cpu()         asm volatile("sleep")

// read word from FLASH with postincrement addresspointer
#define pgm_read_word_inc(addr) \
(__extension__({                \
    uint16_t __result;          \
    __asm__                     \
    (                           \
        "lpm %A0, Z+" "\n\t"    \
        "lpm %B0, Z+" "\n\t"    \
        : "=r" (__result),      \
          "=z" (addr)           \
        : "1" (addr)            \
    );                          \
    __result;                   \
}))


#endif

Autor: Der_Kochloeffel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
noch ne Frage, ich habe Versucht die Tierchen zu erweitern um genau Zwei 
LED Port's, alles war ein wenig extrem schwer für mich, und es tut sich 
absolut nichts an meinen LED's auch nicht wenn ich nur Einen Port mehr 
hineinschreibe, und 6 LED Ports scheinen gar unmöglich zu sein?

Mir gehen einfach die Register aus, also gehen bei diesem Programm 
scheinbar nur Maximal 4 eventuell 5 Port's für die LED's.

Kann das denn sein, ich hänge gerade mal mein beim Registerumherschieben 
entstandenes Wunderwerk als Datei an, und Hoffe auf Ratschläge?

Ach ja Umschreiben auf andere Mega's oder Tiny's scheint ja auch nicht 
so einfach, da andere Typen die Befehle oder gar andere Voraussetzungen 
garnicht erfüllen können?

Gibt's wirklich nur 32 Register, wo ich auch dann nur noch die oberen 15 
für einige Dinge verwenden kann und darf?

Über Antworten würde ich mich riesig freuen, versuche mich schon ne 
ganze Ecke an dem Projekt.
LG
Michael

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

was meinst Du mit 2 LED Ports? Willst Du um 2 LEDs erwitern, oder um 
wirklich um 2 Anschlüsse, also das Charlieplexing mit dann 30?? LEDs?
Da kommt doch vom Multiplexen gar nicht mehr viel raus, da wird das 
Puls-Pausen Verhältnis reichlich schlecht.

Bedenke dabei auch, daß Hagen hier das Charlieplexing in den 
Interruptroutinen ziemlich optimiert hat, mit fest vergebenen Registern 
u.ä.

Bevor Du den Code nicht genau verstanden hast (habe ich auch einige Zeit 
gebraucht ...), und nicht weisst, wie der Compiler mit den Registern 
umgeht, wirst Du das nicht erweitern können.

Dann ist allerdings das Umschreiben auf andere AVRs auch nicht mehr 
schwer.

Gruß,
Bernhard

Autor: Der_Kochloeffel (Gast)
Datum:
Angehängte Dateien:
  • isrs.S (10,7 KB, 140 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernhard,

ja das hatte ich eigentlich vor, ziel der Sache ist das es noch 
realistischer wirkt.

Es sollen eigentlich nicht mehr gleichzeitig leuchten, sondern eher das 
sich die Stellen an denen die Tierchen auf dem Grünzeug angebracht sind 
besser verteilen, so das es nach mehr Zufall aussieht.

Oder auch das mehr zur gleichen Zeit Leuchten?

Die Hardware ist schon fertig, 30 SMD LED's in Grün mit Schwarzen 0,1 mm 
Drähtchen die mit winzigen Heißklebetropfen auf einem recht echt 
aussehenden, aus Drei Verschiedenen Pflanzen bestehenden Gestrüpp 
sitzen, die Drähte sind sogar wenn man es weiß, nahezu unsichtbar um die 
Ästchen gewickelt, und damit es weniger Eckig aussieht hat jede LED 
einen winzigen Tropfen Heißkleb oben drauf bekommen, ich Schick meinen 
letzten Versuch, mit Änderungen an der isrs.S Datei mit, in dem ich 
Versuchte Zwei LED Ports auf 4 Register zu Packen, aber es hat sich 
nichts getahn.
LG
Michael

Autor: Der_Kochloeffel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

Hier noch die Bilder der Hardware, zur Zeit noch mit Kabeln zu einem 
mini Steckbrett, da die Fassung mitten in dem Gebüsch versteckt ist, und 
so das Testen einfacher ist.

Überlege noch ob ich die Tiere unter eine Art Käseglocke packen soll?
könnte eventuell noch besser aussehen, auf den Boden etwas Sand und Erde 
oder Torf???

Habe auch ein Video gemacht das halt nur 12 angesteuerte von den 30 in 
Aktion zeigt.
Einstellungen am Prescaler ziemlich unten in der firefly.c ist auf 8 
gestellt anstatt 64, und der eine Timerwert in der firefly.h ist auf 1 * 
250 gestellt.
Und das Programm hat das Batterie und Nacht Flag dauernd gesetzt.


Youtube-Video "Glühwürmchen"

LG
Michael

Autor: T.M .x (max)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wird es denn nochmal Platinen geben. Bestellt da vielleicht jemand 
welche in näherer Zukunft?

Autor: Der_Kochloeffel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
habe einen Versuch mit einem Tiny44 und der MIK Variante gemacht, indem 
ich die Spannungsmessung entfernt habe, und versucht habe 30 LED's 
anzusteuern, aber in der Firefly.h komme ich oben nicht über 26 und 
weiter unten nicht über 28 hinaus, sobald ich nur eine Zahl höher 
reinschreibe tut sich garnix mehr, und die Würmchen hören nach kurzer 
Zeit auf zu Leuchten und fangen nur wieder an wenn ich die Spannung 
unterbreche und wieder anschliese!

ALso es leuchten auf jeden fall mehr als die 12 Orginalen Würmchen, aber 
nicht alle werden angesteuert, woran kann das liegen???

Habe den gesammten Ordner mit allen Dateien angehängt.

LG
Michael

Autor: chris_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hackaday bastelt auch Glühwürmchen:
http://hackaday.com/2014/01/27/low-power-smd-fireflies/

Autor: Karsten M. (lsmod)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen Re schrieb:
>
> 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

Ein wirklich spätes interesse, aber diesen Teil der Schaltung finde ich 
sehr interessant.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.