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
Schickes Projekt!
Gut um sich m al genauer mit der Energeispaarproblematik
auseinadnerzusetzen ;)
Ist nen schönes Geschenk, mal gucken wann ich das baue :D
>Schickes Projekt!>Gut um sich m al genauer mit der Energeispaarproblematik>auseinadnerzusetzen ;)
Danke, und ja das Projekt hat einiges Potential das erstmal nicht so
offensichtich ist, bei dem was man lernt.
1.) Wachtdog, was ist der Unterschied wenn man WDE und WDIE Bits setzt
im WDT Interrupthandling ?! Habe lange danach gesucht. Der WDT wird
aktiviert wenn man WDE oder WDIE oder WDE und WDIE setzt, Punkt 1. Setzt
man WDE und WDIE so wird in der WDT-ISR autom. das WDIE Flag gelöscht.
Beachtet man dies nicht so heist dies das der nächste WDT Timeout also
einen WDT-RESET auslösst und nicht in die WDT-ISR verzweigt. Setzt man
von Anfang an nur WDIE so wird die WDT-ISR ausgelösst und dann das WDIE
Flag nicht autom. gelöscht. Die nächsten WDT-Timeouts lösen also
weiterhin die WDT-ISR aus.
2.) Brownout Detection kann beim ATtiny45 per Software deaktiviert
werden, aber welche Reihenfolge vor einem Sleep ist die richtige um
diese Detection auch wirklih abzuschalten ? Ich habe sie per Fuse ganz
abgeschaltet da die Powerup Zeiten aus einem Deep Power Down Modus stark
verlängert werden und somit ab einem bestimmten Breakevenpoint mehr
Strom verbraucht wird. Dh. zb. die abschaltbare Brownoutdetection macht
nur dann Sinn wenn der AVR längere Zeit im Power Down Modus ist, bei mir
musste der AVR weit länger als 8 Sekunden im Power Down sein, also weit
länger als die macimal Zeit des WDTs. Die verlängerte Startup Zeit der
MCU bei zuschaltbarer Brownout Detection frass dann mehr Strom als ohne
diese.
Davon mal abgesehen muß ein ganz gewisses Timing beim Scheiben der
Register beachtet werden damit das Mistding auch wirklich per Software
abgeschaltet wird. Ach und ganz wichtig !! möchte man mit abschaltbarer
Brownout und WinAVR GCC arbeiten dann vergesst ganz schnell die Sleep.h
zu benutzen. WinAVR GCCs Sleep Makros machen alles falsch in diesem
Fall.
3.) PWM Erzeugung für 12 LEDs, quasi Charlieplexing, die aber nur
durchschnitlich 0.85% CPU Last hat. Die von mir implementierte PWM
Routine dürfte wohl das Minimum an Rechenzeit benötigen das möglich ist.
Jedenfalls sehe ich kein weiteres Optimierungspotential mehr um das noch
kürzer zu bekommen. Leuchten alle LEDs permanent in ihrem Muster so
verbraucht die MCU dafür nur 1.45% an Rechenzeit. Pro weiteren LED
Kanal, also dann 20,30,42,56 LEDs, werden dann nur weitere +0.11% mehr
an MCU zeit benötigt. Also eine 20 LED Ansteuerung würde dann minimal
0.85% statt 0.74% und maximal 1.56% statt 1.45% an MCU Zeit benötigen.
Der Zusammenhand ist linear.
4.) variable Watchdog Zeiten um einen genauen Zielzeitpunkt anzusteuern,
natürlich nur in der Genauigkeit die man vom WDT verlangen kann.
5.) wie ist das mit der WDTON Fuse ? löscht man sie muß dem AVR der Saft
abgedreht werden damit das auch wirkt.
6.) PinChange ISR. Man muß sehr vorsichtig damit umgehen, besonders wenn
man diese ständig ein/ausschalten möchte. Aktiviert man eine PinChange
ISR so sollte das in einem CLI()/SEI() Block erfolgen und man muß immer
die ISR-Flags in GFIR explizit löschen. Gleiches sollte man auch in der
PinChange-ISR immer machen. Sollte man kurz vor der Aktivierung einen
PullUp am zu überwachenden Pin aktiviert haben dann ist es ratsam je
nach MCU Takt par NOPs danach einzufügen und erst dann den PinChange zu
aktivieren.
Gruß Hagen
Ja das mit dem Watchdog hab ich beim tiny13 durch.
Ich habe so eine LED kerze mit RGB LED gebaut, besonderheit ist der
Kapazitive näherungsschalter zum ein und ausschalten.
Dort benutze ich den Watchdog interrupt um die Kapazitive taste zu
"entprellen" (Das Sensorergebnis muss Stabil sein, damit ein wirklicher
absichtlicher Druck erkannt wird)
Wenn ein Tastendruck erkannt wurde wird die Hauptschleife mit der PWM
durchlaufen. Ist schon nen bisschen her, aber ich glaub die zwischenzeit
verbringt er im Idle.
Wenn die Lampe dann wieder ausgeschaltet wird, verbringt er wieder die
meiste Zeit im Tiefschlaf.
Ist ein Problem da ich keine bessere Cam habe und mit der Kamera meines
HTC Touch bekommt man im Dunkeln keine guten Bilder hin. Und tagsüber
ist der Eindruck den die LEDs erzeugen auch nicht der gleiche wie
nachts. Ergo, nachbauen ist die Devise ;)
Du kannst dir aber im beigelegten WaveEditor
(\FireFly\FireFly\Windows\WaveEditor.exe) die von mir benutzten Waves
anschauen und auch austesten. Starte die EXE, lade die Wave.dat und
doppelklicke mit der Maus in die Liste der einzelnen Waves. In der
schwarzen Box leuchtet dann ein grüner Kreis in der ausgewählten Wave.
Gruß Hagen
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 ?
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
>>Das dient zum Schutz vor Tiefenentladung aber auch um die Funktonsweise der >>"idealen Diode" zu gewährleisten.
und natürlich auch für den MAX1724 der ab 0.8V erst beginnt sauber zu
arbeiten.
Die BAV70 kann bzw. muß durch Widerstände ersetzt werden wenn man
schnellere Schaltvorgänge hat. Da aber der Tag/Nachwechsel bei diesem
Projekt so arsch langsam ist kann man auch die BAV70 nehmen um Strom zu
spraen. Insgesamt ist die Schaltung enorm hochohmig und damit auch
störanfällig. Dumm nur das man deren korrekte Funktionsweise mit
Amateurmiteln nicht ausmessen kann da jedes Multimeter/Oszi dessen
Funktionsweise durch die Messungen verändert. Ich habe sie demzufolge
nur per Simulation überprüft und dann über Monate mit einem Akku +
Solarpanel + Amperemeter praktisch ausgemessen, sie funktioniert.
Gruß Hagen
Als Alternative für den MAXIM1724 könnte man den PR 4402 (0,63€) von
Reichelt nehmen. Eigentlich ein LED-Driver (bis 40mA). Mit einer Z-Diode
am Ausgang sollte es gehen...
PR4402
Quiescent Supply Current Vcc > 950mV ist 8 mA.
Wenn der Akku auf mehr als 0.9 Volt aufgeladen wurde zieht das Teil ohne
irgendeine Last am Ausgang, also nur für sich selber zum Eigenbedarf, 8
mA. Das ist das 400 fache dessen was der AVR im Durchschnitt brauch. Zum
Vergleich der MAX1724 benötigt 0.0015mA für sich selber.
Ich mag diese Teile nicht sonderlich, für billige LED Anwendungen sind
sie super, aber nicht für mehr. Desweiteren ist das ein Stepup der am
Ausgang eine Stromsenke, sprich LED, erwartet und kein Regler der auf
eine definierte Spannung regelt. Das ist schon ein Unterschied. Mit dem
Vorschlag der Z-Diode vernichtet man also exakt die wertvolle Energie
die man mit dem Rest der Schaltung mühsam vesucht hat einzusparen.
Jeder kann das halten wie er will. Ich würde diesen LED-Treiber nicht
als Ersatz für einen Lowcurrent Highefficiency Stepup benutzen.
Gruß Hagen
Ich überlege gerade es mal mit 2x 1,2V NiMH Akkus zu versuchen. Es wird
zwar vermutlich etwas knapp (grüne LEDs: typ 2,2V), könnte aber
funktionieren.
Das größte Problem dürfte sein, dass die Helligkeit stark von der
Spannung abhängt. Beim Goldcap dürfte das noch extremer sein, denn NiMH
haben eine vergleichsweise flache Entladekurve.
Eventuell könnte der AVR auch die PWM Werte abhängig von der
Akkuspannung kompensiert ausgeben ?
>Ich überlege gerade es mal mit 2x 1,2V NiMH Akkus zu versuchen.
Na dann kannst du auch 3 solcher Akkus nehmen, das passt lässig in den
Deckel rein. Mein Batteriehalter (das güne Teil) war ursprünglich für 3
AAAs gedacht. Die Platine selber ist ebenfalls so breit und lang wie 1x
AAA.
Bei vollgeladenen Akkus wären das 4 Volt und 2.7 Volt bei fast
entladenen Akkus. Dann geht das Ganze auch komplett ohne
Spannungsregler, was weniger Verluste bedeutet. Das Problem düfte halt
das Solarpanel sein. Meines hat einen Innenwiderstand von 3k, eine
Überladung von NiMH Akkus ist damit ausgeschlossen da immer die Spannung
des Solarpanels rapide einbricht. Mein Solarpanel lieferte bei voller
Sonnenbestrahlung ~6 Volt, ohne Last. Mit Last dann 3.5 Volt bei ~10mA.
Aber eben nur bei vollster Sonnenbestrahlung. Bei normalem Tageslicht in
einem Wohnraum (also hinter Glasscheiben) sieht das schon wieder ganz
anders aus. Dann fließen bei 1.35 Volt vollgeladenem AAA Akku nur noch
200-280µA aus dem Solarpanel. Das nimmt dann zu wenn der Akku zb. nur
noch 1.1 Volt Nennspanung liefert. Grundsätzlich ist die gemessene
Spannung am Akku wenn er geladen wird immmer nur die aktuelle
Akkuspannung. Nur über den Strom kann man den Ladevorgang ausmessen. Der
hohe Innenwiderstand des Solapanels sollte also sicherstellen das der
Akku nicht leiden muß.
>Eventuell könnte der AVR auch die PWM Werte abhängig von der>Akkuspannung kompensiert ausgeben ?
Würde ich anders machen, bzw. das ist der letzte Feinschliff an diesem
Projekt der noch fehlt. Erstmal folgt jetzt ein Dauertest bei dem ich
alle 7 Tage das Teil ausmesse. Danach kommt die letzte Änderung und die
ist folgende:
Beim Tag/Nachtwechsel wird der Akustand der letzten Messung mit dem
aktuellen verglichen. Ist der aktuelle Akkustand kleiner als der des
Vortages wird ein Zähler inkrementiert ansonsten der Zähler
dekrementiert. Dieser Zähler ist in der Nacht ein Limit der
Schnelligkeit wie oft die Glühwürmchen blinken dürfen. Im Grunde ist
dieser Zähler schon vorhanden, nämlich Hungry_Threshold. Exakt so würde
dieser 2. Zähler arbeiten nur eben das er das zeitliche Limit darstellt
was die Glühwürmchen abwarten müssen bis sie wieder leuchten dürfen.
Somit stellt sich das Leuchten der Glüwürmchen Nachts auf einen Wert ein
der direkt zur gesammelten Energie am Tag proportional ist. Dabei wird
auch zwischen den Jahreszeiten oder der örtlichen Position (Lichtmenge)
des Glases ünterschieden. Es entsteht eine Energiebilanz die ausgewogen
ist, nur die Energie wird verbraucht die per Solarpanel erbracht wurde.
>Wie siehts mit der Laufzeit aus wenn man einen Supercap/Goldcap (50F)>anstelle des Akkus verwendet?
Habe ich mal durchgerechnet, geht nicht, bzw. zu teuer. Die Entscheidung
auf AAA Akkus fiel auf Grund ihres Preise, Bechaffbarkeit,
Unempfindlichkeit und nicht zuletzt weil ich auch ein Ladegerät für die
Teile habe ;)
Bei GoldCaps muss man auf den Innenwiderstand achten und die maximale
Ladespannung. Besser wären dann diese sogenannten SuperCaps, allerdings
reichen 50F nicht aus. Man kann sich das leicht selber ausrechnen: alle
15 Sekunden leuchtet ein Glühwürmchen für 1 Sekunde mit durchschnittlich
2.5mA Stromverbrauch. 1/15s*2.5mA*360=60mAh Worstworstcase. Das wird mit
SuperCaps einfach zu teuer besonders weil mit den Sanyo AAA NIMhLi Akkus
eine bessere Alternative vorhanden ist.
Ich hatte aber auch kurzeitig diese Alternative in Betracht gezogen. Die
Energieausbeute in Ratio zur Baugröße/Preis hats entschieden.
Gruß Hagen
>Das größte Problem dürfte sein, dass die Helligkeit stark von der>Spannung abhängt.
Die LED-Vorwiderstände nicht zu klein machen und die regeln dann den
Strom und nicht die Spannung ! Ergo keinerlei Schwankungen, die aber
auch garnicht stören würden, sondern ein Feature sind bei Glühwürmchen
die ja sowieso mit ihrem chemischen Prozess Schwankungen in der
Leuchtintensität erzeugen.
Bei Lowcurrent LEDs können diese Vorwiderstände sogar ziemlich groß
sein. Denn je stärker die LEDs leuchten desto unrealistischer wird es im
Vergleich zur Natur. Der PWM Dutycycle kann dann nicht mehr einen weiten
Helligkeitsbereich abfahren und das bedeutet das die Waves sehr
undifferenziert aufleuchten. Der Trick ist ja gerade das die LEDs quasi
nur glimmen sollen damit es Nachts echt aussieht. Tagsüber bringt das
leuchten garnichts und wird ja auch deaktiviert. Es ist schon doof wenn
Nachts die halbe Fensterbank grün ausgeleuchtet wird, das schafft in der
Natur kein Glühwürmchen, mal davon abgesehen das wir gerade im grünen
Farbspektrum auch am empfindlichsten sind.
Über die Helligkeit oder deren Schwankungen würde ich mir die geringsten
Sorgen machen ;)
Gruß Hagen
PS: als LEDs keine dieser Ultragrünen/TrueGreen oder sowas benutzen. Die
normalen LEDs mit 2.2V haben exakt das gewünschte Farbspektrum das nach
Neongrün aussieht. Übrigens gibts auch Leuchtkäfer die Karminrot, Orange
und Türkis glühen ;)
Glaube ich nicht. 1000 Jahre später wird dieses Plastikimmitat immer
noch exitieren und das Glas schon zu Milchglas korrodiert sein, der Akku
samt Schaltung sich selber weggeätzt haben und das Solarpanel nur noch
10mV bei Sonne liefern, eventuell sogar die LEDs schon von den
Kupferlitzen abgefallen sein da mein Flußmittel sie abgeätzt hat ;)
Gruß Hagen
Ich bine gerade am zusammenlöten der Schaltung. Allerding komme ich
nicht so recht weiter:
- Mir ist nicht ganz klar, wie man die 12 LEDs verdrahten muss. Ich habe
4 Ausgänge, wie schließt man da die 12 LEDs an ?
- Wie funktioniert das mit dem Bootloader, wo bzw. wie schließt man den
an ?
- Kann es sein, dass im Schaltplan die Bezeichnungen von Batterie und
Solarzelle etwas durcheinander sind ? Bzw. was ist BAT1+ und BAT2+, und
wiso gibt es keine BAT- sondern nur SOL1- und SOL1- ?
- Sollte der Akku nicht eigentlich direkt an den Eingang der Stepups
(also hinter die "Diode" ? So wie es momentan gezeichnet ist, ist der
Akku direkt parallel zur Solarzelle und die "Diode" hat keinen Nutzen.
Ich habs gerade mal ausprobiert:
Grüne LEDs leuchten bereits bei 2V ordentlich hell.
Ich denke ich werde es einfach mal mit 2x 1,2V NiMH Akkus probieren. Ich
habe noch eine 6V Solarzelle mit ein paar 10mA rumliegen, die ich vor
Jahrzehnten mal gekauft habe.
Erstmal muß ich mich entschuldigen, der Schaltplan war eigentich nur für
mich gedacht und deshalb ist er so ein "Gewusst-wie-Ding".
1.) Falsch im Schaltplan sind PB3 und PB4, dieses sind in der Realität
vertauscht. Das liegt daran das im Schaltplan ein ATTiny15 herhalten
musste. Das macht aber nichts, wichtig ist die Pinzuordnung und da beide
Pins nur den ADC1/ADC2 betreffen wird das in der Software schon richtig
gemacht.
>- Mir ist nicht ganz klar, wie man die 12 LEDs verdrahten muss. Ich habe>4 Ausgänge, wie schließt man da die 12 LEDs an ?
Ganz einfach. Nehme 2 LEDs und 2 Kupferlitzen. Am Ende dieser zwei
Litzen nun eine der LEDs angelötet. In der Mitte der Litzen dannn die 2.
LED aber antiparallel zur ersten. Als praktisch hat sich erwiesen mit
einem Multimeter das auch LEDs ausmessen kann (sie glimmen dann leicht)
zu arbeiten. So kannst du die antiparallele Polung der LEDs
sicherstellen. Antiparallel bedeutet Anode der einen LED an Kathode der
anderen LED und umgekerht. Nun verdrillst du nur noch die zwei Litzen
und fertig hast du ein von sechs nötigen Leuchtmittel. Du baust das 6
mal so auf und hast somit 12 LEDs verbaut.
Nun haben wir 4 Pins am AVR, sind mit LED? bezeichnet.
An PB0-PB1 eine dieser 2 fach LED Litzen, also an PB0 ein Ende und an
PB1 das andere Ende. Es sieht am Ende so aus
PB0-PB1
PB0-PB2
PB0-PB5
PB1-PB2
PB1-PB5
PB2-PB5
Umsoriert sähe es so aus
PB0-PB1
PB1-PB2
PB2-PB5
PB0-PB2
PB5-PB5
PB0-PB5
es ist egal wie herum du die 2 Enden einer 2 fach LED Litze an die Pins
anschließt, die 2 LEDs sind ja antiparallel verschaltet.
Zwischen einem jeden Pin-Paar, in allen möglichen Kombinationen aus
PB0,PB1,PB2,PB5 befinden sich also 2 LEDs die antirallel geschaltet
sind. Male dir mal 4 waagerechte Linien auf dem Papier auf, bennen sie
PB0,PB1,PB2,PB5 und zeichne nun senkrecht alle 12 LEDs so ein das man
jede einzeln ansteuern kann.
Die PWM geht nun so vor das sie 4 Rows abbildet. Jeweils Row für PB0,
PB1,PB2,PB5. Die Row wird als Ausgang geschaltet und auf VCC gesetzt.
Die zugehörigen Columns stellen dann alle restlichen 3 Pins dar.
Wennn Row PB0 auf Ausgang/VCC ist dann kann ein Strom fließenen zu den
Pins PB1,PB2,PB5. Also 3 LEDs können gleichzeitig leuchten. In der
Timer0 Overflow ISR wird also PB0 auf High Ausgang gesetzt und nun
anhand der nötigen Dutycycle der 3 LEDs in Richtung PB1,PB2,PB5 die DDRB
Bits berechnet. Soll die LED von PB0 nach PB1 also leuchten dann ist
PB0=1 und PB1 als Ausgang mit GND Pegel. Soll die LED nach PB2 nicht
leuchten dann wird im DDRB Register dieser Pin als Input ohne Pullup,
ergo High-Z gesetzt. Somit besteht die Gesamt-PWM aus 4 Phasen. In jeder
Phase wird die Timer0 Overflow ISR aufgerufen, also 4 mal für einen
kompletten PWM Zyklus =122Hz effektiv. In diesen Phase wird nacheinander
PORTB auf PB0,PB1,PB2 und PB5 High/Ausgang gesetzt, alle anderen Bits
auf 0. Nun werden max. 3 DDRB Werte berechnet. Diese 3 Registerwerte
bestimmen welche LED zu welchem OCR0A Wert zu leuchten hat indem über
DDRB die Pins als Ausgang-Low/Eingang-HighZ gesetzt werden. Zu diesen 3
DDRB Werten können maximal 3 OCR0A Werte enstehen die sortiert werden.
Also angenommen LED0 hat Duty 100, LED1 hat 150, LED2 hat 50. Also alle
3 LED dieser aktuellen Row sollen leuchten. Dann muß folgendes Muster
erechnet werden. Zum Timerzeitpunkt 255-150 muß DDRB so gesetzt sein das
LED1 auf Ausgang geschaltet wird. Bei Timerwert 255-100 die LED0 und
LED1 auf Ausgang gesetzt, und bei 255-50 die LED0,LED1 und LED2 auf
Ausgang gesetzt werden. Bei Timerwert 256 = Overflow greift die Overflow
ISR, diese setzt DDRB erstmal auf 0 und dann den entsprechnenden neuen
PORTB Wert für die nächste Row, hier also PB1.
Die Timer0 TOF ISR lädt also zu 3 FireFly Einträgen aus der Struktur
Fireflies die Samples aus der zugeordneten Wave -> FireFly->wave_ptr.
Das sind die OCR0A Werte = Dutycylce der LEDs. Danach lädt sie zur
aktuellen PWM Phase (0,1,2,3) aus ddr_data[] den PORTB Wert und die 3
möglichen DDRB Werte zu den LEDs an den Pins. Durch Umdefiniton dieser
ddr_data[] Tabelle kann man also zu den FireFlys andere physikalische
LEDs zuordnen. Nachdem die ISR diese Werte geladen hat werden diese
Paare aus OCR0A/DDRB Wert nach deren OCR0A Werte absteigend sortiert.
Danach negiert man die OCR0A Werte man rechnet also 255-x aus. Somit
besteht die Dunkelphase einer LED mit Dutycylce 200 aus 255-200=55. Ab
Timerwert 55 beginnnt die LED zu leuchten bis der Timer auf 256
überläuft. Nach der Sortierung werden noch die mitsortierten DDRB Werte
ver-odert. Dann noch diese 3 Wertpare in das array ocr_data[]
gespeichert da diese in der Timer0 Output Compare Match ISR als Input
dienen zum Setzen des nächsten OCR0A und aktuellem DDRB Wert. Damit
benötigt die OC-ISR nur 18 Taktzyklen. Sie wird minimal 0 mal aufgerufen
nämlich immer dann wenn keine der 3 LEDs leuchten sollen (wave_ptr =
nil). Oder aber maximal wird diese OC-ISR 3 mal aufgerufen wenn nämlich
alle 3 LEDs leuchten sollen und deren Dutycylce sich alle voneinander
unterscheiden. Sollten also zb. 3 LEDs leuchten deren Duty ist aber
identisch dann wird die OC-ISR nur einmal pro Timerdurchlauf aufgerufen.
Die TOF-ISR benötigt die meiste Rechnenzeit, minimal 122 Takte, maximal
185 Takte, jenachdem wieviele LEDs pro Zeile leuchten sollen. In 64*256
Takten pro Timerdurchlauf werden so nur minimal 0.74% und maximal 1.45%
an rechenzeit für diese ISRs verbraten. Dabei macht aber die TOF-ISR
auch noch das Laden und Inkremetieren des FireFly->wave_ptr und
überprüft ob dieser Zeiger FireFly->wave_end erreicht hat. Sobald alle
12 LEDs aufgehört haben in ihrer Wave zu leuchten (wave_ptr=nil bei
allen) wird in Flags das Bit FLAG_TIMER gelöscht. Ab diesem Moment wird
der Timer0 samt ISRs deaktiviert und der AVR geht vom Idle-Sleep-Mode in
den Power-Down-Sleep-Mode über, bis das/die nächste/n FireFly/s leuchten
soll/en.
Die TOF ISR benötigt maximal 185 Takte. Das bedeutet bei Prescaler 64
für Timer0 auch das sie quasi 3 Timerzyklen lang dauert. Und das
bedeutet das der Dutycycle der LED nur von 0 bis 252 gehen kann. Deshalb
werden die OCR0A Werte auch negiert. Die PWM beginnt also für alle LEDs
bei OFF und schaltet dann bei 255-Dutycycle die LEDs erst ON. Somit kann
der Dutycylce von 0=aus bis 252=hellstes Leuchten gehen. Da durch unser
logaritmisches Sehen wir eh keinen Unterschied beim Leuchten einer LED
mit Dutycylc 252 bis 255 sehen ist dieses Vorgehen akzeptabel. Wichtiger
war mir das die kleinen Dutycycles bei 0 bis 128 ausgeprägt sind da das
zarte Leuchten einer LED viel schwieriger zu bewerkstelligen ist. Und
eben der Fakt das das komplette Wavebasierte Leuchten der LEDs samt
Multiplexing etc. pp. voll in den ISRs im Hintergrund ablaufen kann.
Nicht in einer schwer synchronsierbaren Main Funktion oder sonstwo, und
das die Synchronistation beim Setzen neuer Waves in den FireFlies auch
sauber ohne Störungen und Zeitverlust durch Sperrung per CLI()/SEI()
Blöcke vonstatten geht. Achte mal drauf wie die Waves in
update_fireflies() aktualisiert werden.
Man könnte die kompletten ersten drei Blöcke in der TOF-ISR entfernen
und auf ein Array[12] of uint8_t ersetzen. Statt also mit Waves zu
arbeiten würde man dann dort den Dutycycle der 12 LEDs eintragen. Und
fertig wäre die effiziente PWM für 12 gemultiplexte LEDs an 4 Pins die
nur 1.45% MCU Zeit benötigt, wahrscheinlich sogar weniger da nun das
Laden der Wavesampoles usw. entfallen würde.
Ups, dieser Text ist eine längere Umschreibung der Funktionsweise als
die Anzahl an Sourcezeilen die es dann real umsetzt in Hardware.
> Wie funktioniert das mit dem Bootloader, wo bzw. wie schließt man>den an ?
PB2 ist der Bootloader Pin an diesen Pin direkt lötest du das 1-Wire
RX/TX Kabel, hat 330k nach Vcc dran (denke das der Pullup sogar
weggelasen werden könnte). Der Bootloader arbeitet im 1-Wire-RS232,
siehe hier Beitrag "AVR-Bootloader mit Verschlüsselung"
Du nimmst eine RS232 Buchse und benutzt die Schaltung im 1-Wire.jpg. Am
anderen Ende der PC auf dem AVRootloader.exe läuft.
Im ersten Step musst du per ISP den AVR einmalig mit
\FireFly\HEX\AVRootloader.hex programmieren. Dann erstmal die
PC-Software mit dem soeben programmierten AVR austesten, also eine
Verbingung zum Bootloader herstellen und mal EEPROM/SRAM auslesen,
verändern und zurückschreiben in den AVR und nochmal lesen zur
Verfikation.
Wenn das alles geht nochmal per ISP ran und die Fuses setzen. Diesesmal
RESET Pin als normalen Pin fusen und die Lockbits vorher setzen wenn
gewünscht. Danach kannst du ISP vergessen und ablöten, geht eh nicht
mehr. Du müsstest dann also schon im Highvoltage Modus den AVR
zurücksetzen !!
Übrigens da wo bei mir im Borad die 4 LEDs drankommen, also PB0,PB1,PB2
und PB5 liegen auch die ISP Pins MISO,MOSI,RESET,SCK.
Nun kannst du die \FireFly\HEX\FireFly.hex über den Bootloader flaschen.
Ein RESET des AVRs ist danach nicht nötig da die Software im Power Down
Modus den PB2 Pin auf PinChange überwacht. Sollte also die PC-Software
versuchen mit dem Bootloader im AVR zu verbinden und der arbeitet gerade
die FireFly Software ab und befindet sich im Power Down Modus dann
schlägt die PB2 PinChange ISR zu und ruft direkt den Bootloader auf.
Diesen kannst du auch fürs Debugging benutzen indem du über das SRAM HEX
Window den SRAM des AVRs ausliest. Du kannst dir also globale SRAM
Variablen definieren und dort deine Debugwerte reinschreiben. Im MAP
File schaust du nach welche Adddresse sie belegen und kannst dann direkt
in der PC-Software deren SRAM Inhalt auslesen.
>- Kann es sein, dass im Schaltplan die Bezeichnungen von Batterie und>Solarzelle etwas durcheinander sind ? Bzw. was ist BAT1+ und BAT2+, und>wiso gibt es keine BAT- sondern nur SOL1- und SOL1- ?
Jain ;) BAT1+ BAT2+ sind SMD Pads und die haben eine gewisse Größe.
Schlußendlich also aus Layoutgründen so gemacht. Es ist ganz einfach: an
BAT1+/BAT2+ das ist ein großes Pad kommt Akku+ und Solar+ dran. An
SOL1-/SOL2-, ebenfalls ein gemeinsammes großes Pad kommt -Pol vom
Solarpanel dran. Damit liegt dieser Pol an ADC2 und am Drain des
MOSFETs.
-Pol des Akkus geht nach Masse, das ist das Via in der Mitte meines
Boards. Exakt daran kommt auch noch Masse des Bootloader Kabels, benötgt
also GND und PB2. Im Schematik befindet sich Masse da wo auch GND des
MAX1724 ist. Habe ich nicht eingezeichnet sorry.
>- Sollte der Akku nicht eigentlich direkt an den Eingang der Stepups>(also hinter die "Diode" ? So wie es momentan gezeichnet ist, ist der>Akku direkt parallel zur Solarzelle und die "Diode" hat keinen Nutzen.
Der Akku liegt mit Pluspol wie auch das Solarpanel mit Pluspol am
Eingang des Stepup, da wo der BAT/SHDN (Shutdown) Pin des MAX sind. Die
Doppeldiode BAV70 liegt mit beiden Kathoden ebenfalls an dieser
Versorgungsleitung, also sehr hochohmige Pullups für die beiden
Transistoren T1/T3.
Wie gesagt das Schematik ist nicht so dolle, aber ich dachte mir das ich
es trotzdem so veröffentliche statt mit dem Projekt hinterm Berg zu
halten.
Gruß Hagen
Du kannst den ganzen Quatsch mit der idealen Diaod auch weglassen und
durch eine Schottkydiode ersetzen. Diese mit der Anode dann nach GND der
der Schaltung. An Kathode kommt -Pol des Solarpanels und der geht auch
an ADC2 des AVRs.
Beim Fusen bitte die interne PLL mit 8Mhz benutzen, also CDIV8 raus. Den
Brownout deaktivieren da dieser zu viel Strom frisst und wir selber
darauf achten das keine Tiefenentladung der Akkus erfolgt. Nicht WDTON
aktivieren, wir wollen den Watchdog ja im Interrupt Modus benutzen, und
ausschließlich nur in diesem Modus. Dann setzt du die Lockbitfuses wenn
gewünscht, LPM/SPM muß noch ausführbar bleiben ! Wenn das alles geht als
letzten und wirklich überprüften Schritt den RESET Pin als normalen Pin
fusen. Ab diesem Moment kann man den AVR nur noch über Highvoltage
zurücksetzen.
Gruß Hagen
Danke für die Erklärung. Ich habe gemerkt, dass die meisten Antworten
auf meine Fragen irgendwo in deinen Texten versteckt drin stehen. Ich
glaube ich sollte erstmal alles gründlich durchlesen. Aber so ist das
halt, wenn man alles so schnell wie möglich am Laufen haben möchte...
Ich habe alles jetzt aufgebaut und die Software geflashed, nur es tut
sich nichts. Fusebits passen, der Bootloader läuft.
Die Software musste ich etwas anpassen, wegen der geänderten
Betriebsspannung.
Kommentiere ich die Zeile
if (flags & FLAG_ISNIGHT)
aus, dann sehe ich die LEDs "blinken", und zwar immer den ganze Schwarm,
ziemlich genau im 17s Rhytmus.
Aus irgendeinem Grund wird also das ISNIGHT Flag nicht gesetzt.
In measure_isnight() setze ich daher das Flag immer (unabhängig von den
ADC Werten, um das als Fehler auszuschließen). Es geht aber trotzdem
nicht. Anscheinend wird measure_isnight() nie aufgerufen.
Was könnte ich falsch gemacht haben ?
Also erstmal ist das doch schon super, ich meine für einen
Übernachtaufbau ;)
Jetzt kommentierst du alle in "measure_isnight()" aus und lässt nur
drinen
flags |= FLAG_ISNIGHT;
Somit ist der ganze ADC Kram deaktiviert und wir simulieren das es immer
Nacht ist.
Nun conntectest du einmal mit PC-Booloader, Button "Conect to device"
und wenn Verbindung steht wieder ein "Disconnect". Damit machen wir
quasi ein RESET per PC-Software. Das führt dazu das alle 12 FireFlies
Einträge auf alle 0 stehen. Sie beginnen also alle mit einem Schlag zu
leuchten. Schau dir an ob sie
1.) im alerersten gemeinsammen Leuchten mit unterschiedlichem Muster
leuchten
2.) das sie nach dem ersten Leuchten erst einige Zeit später erneut
leuchten
3.) das dann eine Phase eintritt mit längerer Dunkelheit aller LEDs
4.) danach dann vereinzelt die LEDs beginnen zu leuchten, so alle 15
Sekunden
Wenn das geht nochmal mit PC-Software ein "Connect"/"Disconnect" machen
und das Spiel nochmal von Vorne.
Gruß Hagen
PS: sorry, bin noch übernächtig, wer Tippfehler findet darf sie behalten
Achso, ein Connect zum Bootloader ist immer erst dann möglich wenn das
hauptprogram im Power Down Sleep Modus ist. In Main() der letzte IF
Block. Solange also noch eine LED leuchtet muß der Bootloader
(PC-Software) noch warten.
Gruß Hagen
Ich habe jetzt
measure_isnight();
durch
flags |= FLAG_ISNIGHT;
ersetzt.
Ergebnis: Es passiert garnichts.
Nur wenn ich das Flag von Anfang an setze, blinken die LEDs.
Sorry, du musst jetzt bis zu 12 Minuten warten bis was passiert ;)
Das FLAG_ISNIGHT wird erst gesetzt wenn der Measure Timer =
MEASURE_INTERVAL abgelaufen ist, das sind momentan 6 Minuten.
Ändere in FireFly.h
#define MEASURE_INTERVAL (uint16_t)(10)
um. Das wären dann 10*16ms an Interval, geht dann alles ein bischen
schneller vom Ablauf her ;)
Dann solltest du aber trotzdem obige 4 Punkte beobachten können. Erst
wenn wir das verifiziert haben machen wir Schritt für Schritt weiter.
Gruß Hagen
PS: die LEDs blinken nicht, sondern leuchten in einer Wave ;) hoffe ich
doch.
Dank, jetzt läufts ! Es lag an den 12 Minuten. 6 Minuten hatte ich immer
gewartet, dass es 12 Minuten sein müssen, darauf wäre ich nie
gekommen...
Ich werde jetzt die ADC Routine noch etwas anpassen, damit das ganze mit
2,4V läuft.
>Dank, jetzt läufts
Dh. du sieht nach einem "RESET" per PC-Software erstmal alle 12 LEDs
leuchten, in einem jeweils anderen zufälligen Muster. Dann verlöschen
diese im Leuchten so langsam bis keine merh leuchtet. Dann entsteht ein
längere Phase, so bis 1 Minute wo alles dunkel bleibt und danach
beginnen die LEDs so eine nach der anderen oder auch par in Gruppen zu
leuchten. Wenn dies so ist ist erstmal alles richtig.
Du solltest jetzt dein Amperemeter mal benutzen, Meßbereich 50mA bis
10µA. Während der Bootloader verbunden ist sollten es um die 20mA sein,
während alle LEDs leuchten so um die 15mA maximal (hängt aber von deinen
LEDs und Vorwiderständen ab). Und wenn dann alles dunkel ist sollte der
Strombedarf (Power Down Mode) rapide sinken, < 20µA.
Nun machst du folgendes:
In measure_isnight() kopieren wir die Deklarationen von
uint16_t bat_volt;
uint16_t sol_volt;
raus und setzen sie als globale Variablen vor diese Funktion. Dann
kompilisert du alles und öffnest die Datei FireFly.MAP. Suche in dieser
die Einträge für bat_volt/sol_volt raus und merke dir deren
SRAM-Speicheraddressen. Sollten so bei 0x00CC liegen.
Über die PC-Bootloader-Software das HEX flashen und dann kannst du auf
der "SRAM Content" Page mit "Read from Device" Button den SRAM Inhalt
des AUVs auslesen. An der Speicheraddressee 0x00CC oä. stehen dann die
bat_volt und sol_volt.
Du kannst auch mal den EEPROM mehrmals auslesen. Du solltest dann sehen
das sich die ersten 4 Bytes ständig verändern. Das ist der gespeicherte
Startwert des LFSR-Zufallsgenerators. Diese dürfen niemals auf
0x00,0x00,0x00,0x00 stehen !
Nun stellt sich die Frage: Welche Spannungen wirst du erwarten am
ADC3/ADC2 ?
Bei 2 AAA NiMH Akkus sind das maximal 1.35*2 = 2.7 Volt. Das wäre zu
hoch für die ARef=2.56V. Du solltest also auf ARef = VCC gehen aber das
ist ein Problem da du ja keinen Spanungsregler drinnen hast. Du kannst
nicht VCC messen mit VCC als ARef.
Ergo must du in deinem Falle für das Messen der Akkuspannung einen
Spannungsteiler benutzen 1/2 und dann denoch mit 2.56V ARef messen, die
sind dann ja ein stabislisierter absoluter Bezugspunkt zu deiner
veränderlichen Vcc=Akku.
Problematisch wird das Ausmessen des Solarpanels werden. Falls du die
Idela Diode aufgebaut hast haben wir ein Problem mit dem Messen per ADC.
Denn ein Spannungsteiler müsste vom
ADC->Widerstand->SolarPanelMinusPol->Widerstand->GND gehen. Der
Widerstand von Solar- nach GND würde aber unsere Diode überbrücken, das
ist schlecht.
Also müssen wir das anders machen bei deinem Aufbau. Das Solarpanel ist
mit Plus an Akku+=ADC3 und mit Minus an ADC2. Das habe ich absichtlich
so gemacht. Denn du kannst die Solarpanel Spannung nun per
differentiellem Messen über ADC3-ADC2 versuchen auszumessen. Wichtig ist
dabei ja nur der Fall das diese Spannnung wenige Millivolt betragen
sollte für die Erkennung der Nacht. Sollte das Solarpanel tagsüber mehr
als 2.56V ARef/2 liefern so wird der gemessene ADC Wert saturieren auf
0x03FF.
Deshalb empfehle ich dir den Trick mit dem Auslesen des SRAM per
Bootloader damit du nachschauen kannst ob die Messwerte des ADC auch
stimmig sind.
Gruß Hagen
>Dank, jetzt läufts ! Es lag an den 12 Minuten. 6 Minuten hatte ich immer>gewartet, dass es 12 Minuten sein müssen, darauf wäre ich nie>gekommen...
sein können. Minimal sind es 6 Minuten maximal 12 Minuten - x
Millisekunden*16. Zuzüglich die Schwankungen in der Ungenauigkeit des
WDT-Oszillators und die können schonmal 25% betragen.
Du musst dann noch das #define BATTERY_OK an deinen Aufbau anpassen. Und
eventuell die Abfrage
if ((sol_volt > bat_volt) && (sol_volt >= BATTERY_OK)) flags |=
FLAG_ISNIGHT;
abändern, da du ja nicht mehr über das Solarpanel die Akkuspannung
indirekt messen kannst. Es sollte dann eher so aussehen bei dir
if ((bat_volt >= BATTERY_OK) && (sol_volt < par Millivolt)) flags |=
FLAG_ISNIGHT;
Mache deinen Spannungsteiler hochohmig um Strom zu sparen.
Gruß Hagen
Nochmals danke für die Hilfe !
Ich habe das ganze jetzt mit 2x NiMH Akkus am laufen. Die Vorwiderstände
habe ich weggelassen, da die Ports des AVRs bei niedrigen
Betriebsspannungen relativ hohe Innenwiderstände haben (ein paar 10
Ohm). Bis hinunter zu 2V kann man die LEDs noch deutlich glimmen sehen.
Bei 2,4V zieht eine aktive LED etwa 1mA, was optimal ist.
Der Ruhestromverbrauch liegt bei 3µA +/- ein paar µA Messfehler. Also
nahezu unmessbar und warscheinlich geringer als die Selbstentladung von
den billigen Akkus die ich verbaut habe.
Die Messung der Akkuspannung habe ich über einen kleinen Trick erledigt
und so sogar noch einen Pin eingespart: Ich verwende Vcc als ADC
Referenz und messe die interne Referenzspannung.
Jetzt kommt der für mich schwierige Teil: Grünzeug besorgen und das
ganze optisch schön zusammenbauen...
>Der Ruhestromverbrauch liegt bei 3µA +/- ein paar µA Messfehler. Also>nahezu unmessbar und warscheinlich geringer als die Selbstentladung von>den billigen Akkus die ich verbaut habe.
Dachte ich mir schon. Ich habe nämlich zu voreilig bei meinem Board
vergessen das ich auch mal den Strom des AVR nach dem Stepup messen
möchte mit vorzusehen. Da mein Stepup nicht ideal dimensioniert ist,
sprich keine Low ESR Kondensatoren und die Spule wohl eher ne Drosssel
ist komme ich auf 22µA. 22µA / (3.1V Vout/1.35V Vin/0.8 Effizienz) =
~7.5µA - 1.5µA IQ Stepup = 6µA des AVRs. Das kann aber nicht stimmen da
laut meiner Rechnerei er auf unter 3µA kommen sollte. Sprich mein Stepup
benötigt 3µA mehr an Power auf Grund der falschen Dimensionierung. Mein
Multimeter hat als unterste Meßbereiche 200µA und 20µA.
>warscheinlich geringer als die Selbstentladung von den billigen Akkus die>ich verbaut habe
Ich werde demnächst auf die neuen Sanyo Teile umrüsten.
>Die Messung der Akkuspannung habe ich über einen kleinen Trick erledigt>und so sogar noch einen Pin eingespart: Ich verwende Vcc als ADC>Referenz und messe die interne Referenzspannung.
Super Idee muß ich mir merken. Mit dem zusätzlichen freien Pin kannst du
ja 5 LED Ausgänge machen, somit wären mit der gleichen Methode 20 LEDs
an 10 Strippen möglich.
Wie kommen die Waves rüber ? Ich habe bisher noch nicht soviel Zeit
gehabt meine Wave.dat besser zu optimieren. Die kleinen Helligkeiten in
der PWM kommen bei mir zu hell rüber, undifferenziert, eben zu kleine
Vorwiderstände verbaut.
Hast du den 330k Pullup an PB2 verbaut für den Bootloader ? Der könnte
eventuell weggelassen werden.
Ähm, da fällt mir auf: du misst aber am Solarpanel per ADC immer noch im
Single Ended Modus bei 2.56 VRef ? Das bedeutet das bei voll geladenen
Akkus = 2.7V schon bei 2.56V der ADC saturiert. Ergibt 2.7V - 2.56V =
140mV die du schon als Nacht-Spannung am Solarpanel erkennst. Das wäre
bei mir noch regnerischer Tag.
Eventuell wäre es also besser die Schaltung anderst aufzubauen.
Solarpanel- an Masse, Solarpanel+ and Schottk Anode und Kathode an Vcc.
ADC misst nun an Solarpanel+/Anode Schottkydiode. Dann kannst du wieder
ohne Probleme mit Single Ended ADC und VRef 2.56V messen, sogar 1.1V
VRef um die Auflösung bei kleinen Spannnng am Solarpanel = Nachts, zu
erhöhen.
Alles in Allem dürfte dein Aufbau sogar noch eleganter sein, da weniger
komplex. Wenn ich das richtig verstanden habe wäre es ganz vereinfacht
so:
- 2x 1.2V NiMh Akkus in Reihe
- Parallel dazu Solarpanel mit - an Masse und + an Schottky Diode Anode
und deren Kathode an VCC.
- parallel dazu AVR
- Ein ADC vom AVR geht zwischen Solarpanel+ und Anode Schottky Diode
- LEDs direkt ohne Vorwiderstände an AVR, 5 Pins für 20 LEDs wären damit
verfügbar
Gruß Hagen
Hi.
Echt ein schönes und lustiges Projekt!
Ich hab letzte Woche mein altes Händi geschlachtet, und der Li-Pol Akku
bietet sich dafür an. Liefert 4 Volt und ist nur 7mm dick.
Hab etwas an dem Code rumgebastelt, um das in den ATtiny25
reinzubekommen. Aber jetzt geht's und ich hab's jezt auf genau 2048
Bytes runter schwitz . Natürlich ohne Bootloader und nur mit avr-gcc
3.4.6.
Momentan ist ja Glühwurm-Zeit, und ich hab die Tierchen neulich auf ner
Nachtwanderung beobachten dürfen, wirklich beeindruckend wenn die in
grösseren Mengen auftreten! Allerdings leuchten die recht entspannt und
ausdauernd und sind kaum hektisch am blinken -- ok, kommt vielleicht
noch wenns mit dem Poppen losgeht...
@Hagen:
Gibt's da noch Optimierungspotential? Ich würd gerne 11 LEDs
anschliessen und die eine, die nicht antiparallel ist, zur
Helligkeitsmessung nehmen. Vom Prinzip her geht das, hab das schon mal
gemacht. Allerdings braucht man da einiges an Code (Input-Capture).
Was ich bisher optimiert hab ist:
-- TIM0_OVF_vect: Laden von _a, _b und _c in eine Funktion ausgelagert
-- Zeug für Bootloader-Support entfernt
-- Kleinigkeiten, um GCC bei der CSE-Optimierung zu helfen.
-- Sortierung von _b gegen _c in eigener Funktion
Dann, soweit ich sehen kann, können alle Daten im RAM ebensogut
uninitialisiert sein nach RESET? Hab mal die .init4 rausgekickt
(clear-bss + copy-data). Das funzt genauso mit anderem Startmuster und
würd nochmal satte 40 Bytes bringen!
An den Waves, den leuchtmustern, muß noch verbessert werden. Dazu ist ja
der beigelegte Waveeditor von mir auch da. Bisher bin ich noch im
Langzeittest, zwecks Energieverbrauch und diesen ausgewogener
hinzubekommen.
>>-- TIM0_OVF_vect: Laden von _a, _b und _c in eine Funktion ausgelagert
Hat das was gebracht ? Du musst auch immer darauf achten das die maximal
nötige Anzahl an Takten dabei nicht größer 192 wird. Ansonsten benötigt
die TOV ISR nämlich nicht mehr 3 sondern zb. 4 Timerzyklen und dann darf
der höchste PWM Wert in den Waves 251 nicht überschreiten.
>>-- Sortierung von _b gegen _c in eigener Funktion
Wieviel hat es eingespart ? FLASH zu Taktzyklen ?
Es sind 3 Elemente zu sortieren.
[asm]
// now sort each pair of DDRB/OCR0A values descending to OCR0A value ==
PWM dutycycle for each LED
cp _b_ocr, _c_ocr
brsh 50f
movw _y, _b
movw _b, _c
movw _c, _y
50: cp _a_ocr, _b_ocr
brsh 51f
movw _y, _a
movw _a, _b
movw _b, _y
cp _b_ocr, _c_ocr
brsh 51f
movw _y, _b
movw _b, _c
movw _c, _y
51:
[/asm]
Es sind maximal 3 Vergleiche auszuführen und in 50% der Fälle werden
tatsächlich nur 2 der obigen Vergleiche real durchgeführt. Pro Vergleich
fallen 3 Takte, bzw. 6 Takte an und benötigt 10 Bytes FLASH. Lagert man
dies in Funktionen aus so gewinnt man wirklich nur marginal an FLASH
Speicher erhöht aber überproportional die Anzahl der nötogen Takte,
wegens rcall/ret Opcodes und verbraucht mehr Stack.
Zeig doch mal deinen Source damit man das besser beurteilen kann, aber
aus meiner Sicht wäre das die letzte Stelle an der ich irgendwas
optimieren würde, da der Gewinn einfach nicht den Aufwand rechtfertig.
Da ist die Optimierung das Laden der PWM Dutycylce für a,b,c am Anfang
dieser ISR wirklich lohnenswerter.
>>Gibt's da noch Optimierungspotential?
Wenig. Man kann immer noch was optimieren, allerdings bin ich nicht der
Typ von Programnmierer der Stunden damit verbringt um schlußendlich das
letzte 0.1% an besseren Code noch rauszuquetschen. Der Source dürfte für
ein AVR GCC C Projekt schon ziemlich kompakt sein. Ich stand eben auch
vor der Entscheidung den Source noch nachvollziehbar zu halten. Man
könnte so einige C Funktionen noch nach Assembler portieren, meistens
gewinnt man so nach meiner Erfahrung bis zu 50% an FLASH und es wird
auch noch effizienter.
2k FLASH sind halt ziemlich schnell verbraucht wenn man in C
programmiert.
>>Ich würd gerne 11 LEDs>>anschliessen und die eine, die nicht antiparallel ist, zur>>Helligkeitsmessung nehmen.
Ich kenne deinen konkreten Aufbau nicht. Du kannst erstmal nichwas an
der HW verbesseren (habe ich schon getestet).
Man kann einen ADC Pin einsparen und hätte somit noch einen freien Pin
zur Verfügung. Das geht so:
Wir benötigen nur einen ADC Eingang der die Spannung am Solarpanel
misst. Damit hast du deine Tag/Nacht==Helligkeitserkennung drinnen. Das
Messen der AKKU Spannung wird geändert und erfolgt gegen die interne
AREF von 2.56V/1.1V. Statt also mit einem eigenen ADC Pin zum AKKU
dessen SPannung zu messen, mesen wir VCC gegen AREF, denn du arbeitest
ja ohne Stepup Wandler direkt den AKKU am VCC Pin, richtig ?
Man könnte aber auch die Messung des Solarpanels noch wegoptimieren.
Dann so wie du es vorschlägst über die LEDs selber. Dabei ist es egal ob
die LEDs single oder double-antiparellel angeschlossen sind, denn man
misst dabei ja die Kapazitive Ladungsmenge der LEDs um die Helligkeit zu
ermitteln. Dürfte also auch mit antiparelle verschalteten LEDs gehen.
Allerdings würde ich halt die Mehtode des Solarpanels benutzen, dürfte
weit exakter sein.
>Dann, soweit ich sehen kann, können alle Daten im RAM ebensogut>uninitialisiert sein nach RESET?
Ja das geht schon und ich habe bei den Datenstrukturen/Register
Belegungen/Initialisierung exakt darauf geachte das es uninitialisiert
sein könnte. Allerdings habe ich das Linkerskript nicht dahingehend
angepasst, einfach weil es dann für unerfahrene Leute nicht mehr
verständlich wäre.
Es macht also aus Sicht des programablaufes nur den Unterschied aus das
dann die Fireflys quasi schon zufällig initialisiert wären, und das
beeinflusst nur das Delay der erste Dunkelphasen der Glühwürmchen, mehr
nicht.
>Momentan ist ja Glühwurm-Zeit, und ich hab die Tierchen neulich auf ner>Nachtwanderung beobachten dürfen, wirklich beeindruckend wenn die in>grösseren Mengen auftreten! Allerdings leuchten die recht entspannt und>ausdauernd und sind kaum hektisch am blinken -- ok, kommt vielleicht>noch wenns mit dem Poppen losgeht...
Nee leider nicht. Wie üblich finde ich es bei solchen Projekten eben
auch spannend mich mit der Materie drumherum intensiv zu befassen (plane
sogar meinen Vietnamurlaub eventl. neu um die nur dort existierenden
roten Glühkäfer zu sehen :) Ich habe also auch im WEB intensiv
recherchiert um das Leuchtverhalten der Simulation an die Realität
anpassen zu können. Das zu planen/herauszufinden hat übrigens die meiste
Zeit gekostet ;)
Nungut, ich selber bin mit der Simulation auch unzufrieden. Die Waves
müssen länger und ruhiger leuchten, was aber über den Waveeditor ja
leicht anpassbar ist.
In der Fortpflanzungszeit verändert sich das Leuchtverhalten nur
unmerklich. In der Natur ist es so das eine Gruppe von Männchen um
ein/zwei Weibchens buhlen muß. Dabei sind die Weibchen defakto die
Auslöser der Leuchtmuster, dh. die Männchen antworten im Grunde als
Gruppe (am Anfang unsynchronisiert bishin zu vollständigen
Synchronisation) auf die Weibchen. Das ist ein wesentlicher Unterschied
zu meiner Simulation.
Ein weiterer Unterscheid ist die Anzahl, mit 12 LEDs ist man im Grunde
schon unrealistisch beschränkt.
Da ich nun schon drei Aufträge aus meiner Familie habe für einen Nachbau
arbeite ich nebenbei an einer neuen Version. Diese wird einfacher
aufgebaut sein und mit 20 LEDs funktionieren. Der Aufbau ist sehr
simpel, ein Solarpanel das mehr Spannung liefert (5V-6V) wird mit
Pluspol direkt an einen ADC Pin des AVRs angeschlossen. An VCC kommt ein
3.7V LiPo Akku ohne jedweige Schutz/Ladeelektronik. Über den AVR Pin und
die Software im AVR wird der Akku dann vom Solarpanel Pluspol -> AVR ADC
Pin -> nach VCC -> Akku aufgeladen. Wenn man bestimmte Kriterien
beachtet so geht das hervoragend und erste Langzeittest laufen schon.
Dh. der AVR stellt sowas wie ein Solar-LiPo-Laderegler dar. An die
restlichen Pins dann die 20 LEDs im Charlieplexing. Somit kein Stepup,
keine ideale Diode, keine Shottkydiode mehr.
Übrigens denke ich das du deinen zeitlichen Aufwand enorm reduzieren
könntest wenn du 20 Cent mehr investieren würdest, nämlich in einen
ATTiny45V statt einem 25'er. Das beseitigt all deine Problem mit dem
geringsten Aufwand ;) (ich weiß das man als Hobbybastler immer das
verbauen möchte was man da hat, aber in einem solchen Fall denke ich
pragmatisch).
Gruß Hagen
Achso, du könntest auch die Wave[] kürzer machen. Statt mit 32 Waves zu
arbeiten zb. nur mit 16 Waves. Das spart dann schonmal in Wave_Data[]
exakt 96 Bytes FLASH. Dann noch Wave[] selber verkürzen. Starte einfach
mal im Ordner \Windows\ die WaveEditor.exe und lade dort die Wave.dat.
Du kannst dann mit der Maus oben im Waveeditor die Samples verschieben
und somit kürzere Waves bzw. deren Anzahl verändern.
Es sollten dabei 8,16,32,64 Einzelwaves entstehen (links in der Listbox
die Anzahl der Einträge). Sollte die Anzahl nicht eine Potenz von 2 sein
so musst du im AVR Source in uprdate_fireflies() den Aufruf von lfsr(5)
verändern. Bei 16 Waves dann lfsr(4) (4 Bits = 16). Bei zb. 24 Waves
dann so: lfsr(4) + lfsr(3) == 2^4 + 2^3 = 16 + 8 = 24.
Gruß Hagen
Und dann könnte man die Art der Erzeugung der Waves noch verändern.
Statt nun die Wave als Samples mit fester Samplingfrequenz (122Hz)
abzuspeichern, speichert man quasi nur Stützstellen mit zb. 12Hz. Wenn
man sich die Wave genau anschaut so erkennt man lange Phasen in denen
die Samples identisch sind. Das lässt sich wegoptimieren indem man quasi
einen Bresenham-Linien/Spline-Algorithmus anwendet. Bei langsammeren
Wavemustern (was ja erwünscht ist) könnte man so mindestens 90% der Wave
einsparen und hätte den gleichen Effekt wie jetzt. Mein Waveeditor
arbeitet ja auch mit einem Splinealgorithmus. Allerdings wollte ich mir
das zeitlich nicht antun ;)
Gruß hagen
Hagen Re wrote:
> An den Waves, den leuchtmustern, muß noch verbessert werden. Dazu ist ja> der beigelegte Waveeditor von mir auch da. Bisher bin ich noch im> Langzeittest, zwecks Energieverbrauch und diesen ausgewogener> hinzubekommen.>>>>-- TIM0_OVF_vect: Laden von _a, _b und _c in eine Funktion ausgelagert>> Hat das was gebracht ? Du musst auch immer darauf achten das die maximal> nötige Anzahl an Takten dabei nicht größer 192 wird. Ansonsten benötigt> die TOV ISR nämlich nicht mehr 3 sondern zb. 4 Timerzyklen und dann darf> der höchste PWM Wert in den Waves 251 nicht überschreiten.>
In wave[] ist der größte Wert 0xFA=250, also ist da noch einiges an
Luft, was die Ticks bis >251 (also >=252) angeht. Und Werte auf 251
kappen wäre auch nicht schlimm, weil man in dem PWM-Bereich eh kaum
einen Unterschied wahrnehmen dürfte. Kritischer wäre, wenn kleine
PWM-Werte nach unten beschränkt wären.
Das Laden in eine Func auszulagern dürfte nur unmerklich mehr an Strom
kosten, bringt aber 52 Bytes -- n Haufen Holz, wenn man um jedes Byte
kämpfen muss!
>>>-- Sortierung von _b gegen _c in eigener Funktion
Schon wieder raus, waren nur 4 Bytes. Wie gesagt, wenn's Program nicht
passt, passt's eben nicht. Hab aber inzwischen den Code anderwärtig
verändert.
> Da ist die Optimierung das Laden der PWM Dutycylce für a,b,c am Anfang> dieser ISR wirklich lohnenswerter.
Sieht so aus jetzt:
1
load_fly:
2
clr _c_ocr
3
ldd _zl, y + WAVE_PTR // if fly->wave_ptr == 0 goto 1: Fly don't ligthing
4
ldd _zh, y + WAVE_PTR+1
5
sbiw _zl, 0
6
breq 1f
7
ori _flag, (1 << FLAG_WAVE) // any fly is ligthning
8
lpm _c_ocr, z+ // load next wave sample = fly->wave_ptr
9
ldd _c_ddr, y + WAVE_END // check if fly.wave_ptr >= fly.wave_end, finished lightning ?
10
cp _zl, _c_ddr
11
ldd _c_ddr, y + WAVE_END+1
12
cpc _zh, _c_ddr
13
brne 0f
14
clr _zl // if finish setup fly.wave_ptr = nil
15
clr _zh
16
0: std y + WAVE_PTR , _zl
17
std y + WAVE_PTR+1, _zh
18
1: adiw _y, SIZEOF_FLY // increment _fly_ptr by 1 fly
19
ret
20
21
...
22
rcall load_fly
23
movw _a, _c
24
rcall load_fly
25
movw _b, _c
26
rcall load_fly
27
...
>>>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:
1
SECTIONS
2
{
3
.nirvana : { *(.init4) }
4
}
Beim Link-Aufruf (avr-gcc als Linker) gibt man zusätzlich als Optionen
an
> 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.
> 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
>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
> 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
>mit mehr LEDs spürbar interessanter aussieht?
Nein nicht probiert. Je nach Betrachtungsabstand kann man ab 2 Meter eh
nicht mehr exakt unterscheideen welche der 12 LEDs gerade geblinktert
hat. Mehr LEDs würden also nur dann Sinn machen wenn man sie auch
räumlich weiter voneinander entfernen möchte, sprich größerers Glas
benutzen möchte. Dann leidet aber die Glaubwürdigkeit der Konstruktion,
denn keiner fängt Glühwürmchen in einer Vitrine ;)
>Beim Tiny44 könnte man ja zwei getrennte Ketten machen.
Das wiederum ist möglich und man könnte die Software dahingehend
anpassen.
Gruß Hagen
Hallo,
da ich gerade eine bestellung bei Reichelt fertig mache wollte ich mir
auch mal eben die paar sachen für dieses nett Projektchen hier mit in
den Korb werfen. 10µF Keramik-Kondensatoren habe ich noch rum liegen.
Der Maxim sollte auch irgendwann kommen.
Nun muss ich noch die passende Drossel für L2 finden.
Welches model von Reichelt wäre denn da empfehlenswert und würde ins
layout passen?
Ich hätte zwar noch eine sehr kleine Würth Speicherdrossel da, aber die
hat nur 2,2µH. Das Datenblat bleibt da leider etwas schwammig, was die
Induktivität angeht.
Ach ja, in Hagens Schaltplan stehen 150µH dran, das ist ja nun ganz
ordendlich mehr. Was denn nun richtig?
viele Grüße
Aike
So, Drossel und leds sind da, 0603 sind doch recht klein ;-)
Mal sehen wie lange Maxim bruacht bis der 1724 da ist.
wenn ich erfolg habe oder auch nicht sag ich mal bescheid
vielen Dank
Aike
Super, es scheint aber noch einen kleinen Bug in der Software zu geben.
Die Art und Weise wie per ADC die Akku-Spannung und Solarzellen-Spannung
gemessen wird muß ich nochmal umändern. Es scheint so das wenn der Akku
schön voll ist, dann Nachts über die Schranke zum Einschalten des
Blinkens der LEDs, also die Messung der Solarzellenspannung,
fehlschlägt. Das führt dazu das mehrere Tage lang die LEDs nachts nicht
leuchten wenn sie es eigentlich sollten. Nach par Tagen fängt sich dann
die Software und das Projekt läuft anstandslos, bis zum nächsten
"Aussetzer". Nungut, ich verkaufe es gerne als Feature, aber es ist ein
Softwarefehler denn ich demnächst nochmal korregieren muß.
> 0603 sind doch recht klein ;-)
Jupp und dann noch 0.2er Kupferlitze dranlöten kann eine Herausforderung
sein. Ich habe es meditativ gesehen und fast 5 Stunden für die 12 LEDs
an 6 Strippen benötigt, und war dann kurz vorm Nirvana fertig ;)
> Mal sehen wie lange Maxim bruacht bis der 1724 da ist.
eine Woche. Ich habe noch in der selben Woche der Bestellung die
Lieferung erhalten.
> So, Drossel...
Du redest immer von Drossel, meinst aber hoffentlich eine
Speicherdrossel bzw. Induktor. Wichtig ist für den MAX1724
- Induktivität ca. 10µH mit 500mA Strombelastbarkeit, also
Sättigungsstrom
- am Eingang und Ausgang nicht zu große Kondensatoren, Low-ESR
selbstverständlich, ich habe X7R verbaut geht auch, sie sollten aber
nicht mehr als 4.7µF haben, ich habe 1µF drinnen sekundär und 470nF
primär weil dort ja auch der leistungsfähige Akku sitzt
Über die Vorgehensweise der ersten Test habe ich oben schon was
geschrieben. Zuerst deaktiviert man in Software die ADC Messungen, also
Spannungsüberwachung Akku und Solarpanel. Das Projekt wird also so
laufen als wenn es permanent Nacht ist. Damit saubt man einen extern
voll geladenen Akku beim ersten Langzeittest vollständig leer. Man misst
dabei die Zeitspanne die dafür benötigt wird. Dann aktiviert man in
Software die ADC Messungen, aber nur die Akku Überwachung. Nun wird das
Projekt immer dann leuchten, egal ob Tag oder Nacht, wie der Akku im
vorgesehen Spannungsbereich liegt. Nun misst man wieder die Zeitspanne
bis der Akku aufgeladen ist. Als letztes dann auch die ADC Messung des
Solarpanels aktivieren.
Gruß Hagen
Hallo,
so ein Bug ist natürlich nicht so schön, wie oft kommt der denn vor? Wie
das mit dem messen der Solarspannung genau funktioniert muss ich mir
nochmal genauer ansehen wenn ich das aufgebaut habe. Habe den Code auch
noch nicht so genau gelesen, mache ich dann wenn ich auch mal nachmessen
kann. Vielleicht kann ich dann ja auch selber was dran tun.
2 Stunden habe ich für die Leds nicht gebraucht, aber mir sind leider 5
Stück Kaput gegangen jetzt habe ich noch genau 12 über für ein
eventuelles 2. Glas für meine Freundin ;-) man muss die doch sehr
vorsichtig behandeln.
Ich habe mir vorher die stellen an die ich die leds löten wollte mit nem
großen Lötkolben mit 460° abisoliert und dann habe ich die dräte an
diesen stellen verlötet und die Dräte dann verdrillt. Danach dann das
Lötzin wieder weg machen, dann ist es nicht mehr so schwer die leds
richtig zu positionieren.
> Du redest immer von Drossel, meinst aber hoffentlich eine
Speicherdrossel bzw. Induktor.
Ja, ich meine eine Speicherdrossel. Habe die L-PIS2408 von Reichelt
genommen, die sollte gehen denke ich.
> am Eingang und Ausgang nicht zu große Kondensatoren, Low-ESR> selbstverständlich, ich habe X7R verbaut geht auch, sie sollten aber> nicht mehr als 4.7µF haben, ich habe 1µF drinnen sekundär und 470nF> primär weil dort ja auch der leistungsfähige Akku sitzt
Nanu? Ich habe eigentlich vor 10µF X5R zu nehmen, die habe ich halt noch
da. Ich hätte jetzt nicht unbedingt gedacht das da größere Kondensatoren
schaden können. Was ist denn da der Grund für?
Deine Erläuterungen zur Inbetriebnahme hier im Thread habe ich schon
aufmerksam gelesen, bin mal gespannt ob das alles auf anhieb klappt. Ich
habe mir bei Pollin jetzt auch 3 Solarlampen und zwei von diesen neuen
NiMhLi Akkus geordert, hast du da schon drauf umgerüstet?
viele Grüße
Aike
Wer Lust hat, kann sich ja mal diese Links ansehen. Auch die
Google-BILDERsuche nach pummer brngt einiges zu diesem Thema.
In anderen Ländern existiert eine regelrechte und nicht kleine Szene,
die sich ausgiebig mit diesen Dingen beschäftigt. Hier isn D ist mir das
nicht bekannt, oder hat da jemand andere Infos?
Die Links bringen jede Menge Schaltungen und Anregungen, besonders auch
Ladeschaltungen für Accus und Goldcaps:
http://www.solarbotics.net/http://www.solarbotics.net/bestiary/1120_pummer_gal.html
Jochen Müller
>so ein Bug ist natürlich nicht so schön, wie oft kommt der denn vor?
so 1-2 mal im Monat, dann für 2-3 Tage.
> Nanu? Ich habe eigentlich vor 10µF X5R zu nehmen, die habe ich halt noch> da. Ich hätte jetzt nicht unbedingt gedacht das da größere Kondensatoren> schaden können. Was ist denn da der Grund für?
Passt schon so. Viele denken mehr ist besser, stimmt aber nicht. Ein
Stepup erzeugt Stromspitzen die ausgeglichen werden müssen. Dabei
entscheidet primär die Kombination aus Input Kondensator + Spule +
Output Kondensator über die Effizienz, Frequenz und max. Leistung des
Stepups. Um mit dem MAX1724 bei möglichst kleinen Spannungen schon
arbeiten zu können empfiehlt der Hersteller die Inuktivität ein bischen
größer zu dimensionieren. Der AVR läuft schon ab 2.7V stabil und der
Stepup sollte der 3V oder 3.3V Typ sein, selbst bei 300mV Ripple am
Ausgang des Stepups also kein Problem. Die Größe der Kapazitäten hat nun
einen entscheidenden Einfluß auf die Verluste die durch den Stepup
entstehen. Auf Sekundärseite haben wir den Akku, meistens ein NiMH mit
1200mAh und damit ein guter Energielieferant für einen Stepup. Wir
können also die Eingangskapazität des Stepups kleiner halten und kommen
so einfacher an Caps. mit kleinem ESR ran. Dieser ESR ist für die
Verluste im Cap verantwortlich. Gleiches gilt auch für die Sekundärseite
des Stepups.
>NiMhLi Akkus geordert, hast du da schon drauf umgerüstet?
Nein bisher nicht und es zeigt sich auch das bei meinem Aufbau der Akku
ständig gut geladen ist. Das Problem ist halt das man über die
Solarpanelspannng die Entscheidung trifft ob es Tag oder Nacht ist.
Viele der besseren Gartenleuchten benutzen dafür einen Photowiderstand,
die billigeren Leuchten werten ebenfalls das Solarpanel aus. Dies kann
aber problematisch sein da auch Infrarotstrahlung eine Spannung im
Solarpanel erzeugt. Dh. wenn es Nachts sehr dunkel ist aber auch sehr
warm bzw. aufgeheizte Wände noch Wärme abgeben, dann liefert das
Solarpanel zuviel Spannung und die Software kann die Nachtphase nicht
als solches erkennen. Ich denke das dies auch der "Bug" in der Software
ist. ZZ. verändere ich die Meßmethode für das Solarpanel und Akku und
passe die Thresholds besser an. Man könnte die Schaltung auch umbauen
und mit einem Photowiderstand + Spannungsteilerwiderstand erweitern,
aber das wollte ich vermeiden um Strom zu sparen.
Gruß Hagen
Hallo mal wieder,
ich habe jetzt obwohl mir noch die Solarzelle, der richtige akku und der
Max1724 fehlen mal einen kleinen Test gemacht.
Ich habe einen noch hier zu testzwecken rumliegenden TPS61200 genommen,
den auf 3,0V eingestellt und an VCC und Masse gehängt.
Dann die Software angepasst so das immer Nacht ist.
Soweit so gut, nach 12 Minuten fangen die Leds an zu leuchten, sieht
schon ganz nett aus.
Leider ist das leuchten noch viel zu dunkel, was wohl an den
Vorwiederständen liegt, die ich verwendet habe. Hatte nurnoch 1k
Widerstände da, das macht dann 1mA, die Leds würden aber 2 mA benötigen,
sind ja sowiso nicht so sehr hell die Lowcurrent-Leds.
Daher muss es wirklich stockduster sein, damit man was sieht.
Naja, Habe gerade noch ein paar 472Ohm miniMelfs gefunden, mal sehen ob
ich die irgendwie auf die Pads bekomme ;-)
Eine sache ist allerdings noch seltsam. Wenn ich den Programmier-Adapter
anstöpsel dann ist sofort Ende mit leuchten. Auch die Stromaufnahme von
4µA im Standby auf ca. 25µA.
Nach dem Programmieren steigt dann die Stromaufnahme auf irgendwas
größer 1mA was das Multimeter dann nicht anzeigt.
Programmieradapter ab, reset und dann gehts los.
Dafür habe ich noch keine rechte Erklärung.
Auf jeden Fall schonmal ein sehr cooles Projekt!
viele Grüße
Aike
Kleiner Nachtrag,
hatte bei meinen Vorwiderständen natürlich total übersehen, das das ja
ne Matrix ist. Habe jetzt auf 100Ohm reduziert, jetzt sind die Leds auch
was heller.
>Eine sache ist allerdings noch seltsam. Wenn ich den Programmier-Adapter>anstöpsel dann ist sofort Ende mit leuchten. Auch die Stromaufnahme von>4µA im Standby auf ca. 25µA.>Nach dem Programmieren steigt dann die Stromaufnahme auf irgendwas>größer 1mA was das Multimeter dann nicht anzeigt.>Programmieradapter ab, reset und dann gehts los.>Dafür habe ich noch keine rechte Erklärung.
1. Sobald der Adapter angeschlossen ist wird ein Strom für die RS232
verbraucht.
2. die effektive Stromaufnahme kann also nur exakt ermittelt weren wenn
der
Adapter nicht angeschlossen ist
> Habe jetzt auf 100Ohm reduziert...
könntest sie ohne Probleme noch weiter reduzieren.
Gruß Hagen
Hallo mal wieder,
leider bin ich immer noch nicht fertig, der Max1724 ist leider noch
nicht da :-(
Dafür sind heute von Pollin die solar-Lampen gekommen.
So ne schöne Solarzelle wie bei dir ist da aber leider nicht drin, da
sind einfach vier von diesen Streifen in den Deckel eingegossen. Habe
gerade mal gemessen, in der prallen Sonne bringt die 2,5V und 50mA
Kurzschlussstrom.
So muss ich dann mal schauen, wie ich die möglichst elegeant da raus
sägen kann und hoffen, das das reicht.
viele Grüße
Aike
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
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?
Stimmt. Ich habe zuerst nur den Stepup aufgebaut, also ohne AVR. Diesen
dann getestet und ging auf anhieb. Danach AVR drauf und programmiert.
Wenn es also bei dir nich geht dann vermute ich das deine "Drossel" +
Kondensatoren nicht ganz passen, oder du hast nicht richtig verlötet.
>Ich messe am Ausgang nur 0,8V.
Wieviel Spannung hast du am Eingang des Stepups ? Es sollten erstmal
mehr als 0,8V sein da ansonsten der Stepup nicht anschwingt. Wenn er
erstmal läuft dann saugt er den Akku auch unter 0.8V leer, bei mir bis
0.65V runter.
Gruß Hagen
Hagen Re wrote:
> Wenn es also bei dir nich geht dann vermute ich das deine "Drossel" +> Kondensatoren nicht ganz passen, oder du hast nicht richtig verlötet.
Werde ich morgen nochmal gründlich prüfen. Vielleicht sitzt doch noch
irgendwo ein Tropfen Lötzin. Induktivität und Kondensatoren sollten
eigentlich passen. Aber wer weiß.
> Wieviel Spannung hast du am Eingang des Stepups ?
1,29V frisch von Akku.
viele Grüße
Aike
Meine Güte, wie früh bist du denn wach?
Nun gut, mein Stepup läuft jetzt auch, die Spule war an einer Seite wohl
nicht richtig verlötet.
Leider funktioniert jetzt der µC nicht mehr, aber den Grund dafür finde
ich hoffenlich noch. Der hat ja vorher mit externer Versorgung
funktioniert.
>Meine Güte, wie früh bist du denn wach?
Meine Güte, wie früh bist du denn noch wach? wäre die richtige Frage.
Wenn es nach mir ginge würde ich am liebsten 24h pro Tag wach sein ;)
Ansonsten: du wirst das Ding schon zum Laufen bringen, toitoi.
Gruß Hagen
Oder auch so ;-)
Nun denn, ich will jetzt nicht mit allen Details rumnerven, aktueller
Status ist das es jetzt läuft, der Tiny hat wohl was ab gekrigt und
wurde nun ersetzt.
Ich muss jetzt mal ausgibig testen.
Vielen vielen Dank auf jeden Fall für dieses tolle Projekt und die viele
Hilfe von dir!
Aike
Hallo doch nochmal,
ich habe mich jetzt zu den etwas interessanteren Problemen vor
gearbeitet.
Also erstmal ein paar grundsätzliche Fragen damit ich weiß, das ich das
alles richtig verstehe.
1. Wenn ich die Spannung der Solarzelle zwischen SOL- und BAT+ messe,
dann werde ich max. eine Spannung knapp über der Batteriespannung messen
können, also ca. 1,3V? Weil die Spannung der Solarzelle mit last
einbricht.
2. Wenn ich mit im RAM die werte für sol_volt und bat_volt ansehe, dann
sinkt der wert bei steigender Spannung der Solarzelle. Bis
sol_volt=bat_volt ist?
Gut, so kann ich es jedenfalls nachvollziehen.
Dann also zum Problem. Das Programm wechselt offensichtlich nicht in den
Nachtmodus. Wenn ich das Solarpannel umdrehe, dann habe ich im Speicher
sowas stehen wie: e5 01 und für bat_volt f5 01. Also 485 zu 501.
Da scheint es mir auch logisch das sol_volt>bat_volt nicht erfüllt
werden kann.
Wo ist also mein Fehler?
viele Grüße
Aike
Mach mal
if (sol_volt >= bat_volt) &&
draus. Wir messen BAT+ minus Solarpanel Spannung. Wenn es Nacht ist
liegt ja SOL- über die Diode an Akku-. Exakt an SOL- messen wir mit dem
ADC. Bei Nacht degradiert das Solarpanel zu einem Widerstand, dh. an
SOL- messen wir quasi die Akkuspannung abzüglich der minimalen
Solarpanelspannung.
Du könntest, um den Source an dein Solarpanel anzupassen, es auch so
abändern:
uint16_t sol_volt = ADC + x; // x für Spannung des Solarpanels bei
Dunkelheit
Aber Recht hast du, denn an diesem Punkt vermute ich auch bei meinem
Projekt noch eine Schwachstelle. Solarpanels sind halt nicht besonders
gut als "Tag/Nacht" Sensor geeignet.
Gruß Hagen
Edit: aber Vorsicht mit dem Messen durch ein Multimeter. Die "ideale
Diode" die SOL- von AKKU- trennt falls Solarspannung < Akkuspannung ist
enorm hochohmig, ergo sehr empfindlich. Das Multimeter/Tastkopf Oszi
beeinflusst diese Schaltung. Defakto kann man die korrekte Funktioon
dieser Diode nur per Strommessung korrekt messen.
Hallo,
seltsames Problem. Ich habe jetzt mal Probehalber zum sol_volt wert 200
hinzu addiert, damit komme ich einen bereich bei dem einfaches umdrehen
des Panels dazu führt das ich einmal einen sol_volt Wert habe der
deutlich über bat_volt liegt und einmal einen der deutlich darunter
liegt. Ich habe mir jetzt mal alle wichtigen Werte ins SRAM geschrieben
- auch ein flag das mit das ergebnis der If Abfrage ausgibt.
Aus den Werten im SRAM geht eindeutig hervor, das isnight gesetzt ist,
aber nix passiert.
Schreibe ich allerdings als letzte Zeile in die funktion measure_isnight
flags |= FLAG_ISNIGHT
dann glimmen die Leds direkt los, so wie es am Anfang sein soll. Leider
durchblicke ich den rest des Programms noch nicht so weit, das ich da
einen Grund für erkennen könnte.
Weißt du noch Rat?
viele Grüße
Aike
Jo, warte par Minuten ;) Der Test auf Nacht wird ja nur so ca. alle 6
Minuten durchgeführt. Es kann dann noch weitere 6 Minuten dauern bis das
System loslegt und blinkt. Ich habe dies absichtlioch so konstruiert da
man so quasi einen "Lowpass Filter" erhält und das System nicht sofort
jedesmal anfängt zu leuchten nur weil kurzzeitig eine Verdunklung der
Solarzelle erfolgte. Und zusätzlich sparrt es Strom da der AVR nach dem
ADC auslesen erstmal für 6 Minuten in den Powerdown geht.
Ansonsten wäre es angebracht wenn wir per Mail weiter machen. Denn dann
kannst du mir auch entsprechende Source senden und ich schaue drüber.
Gruß Hagen
Hallo,
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
> 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
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
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.
> 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
>> 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
> 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
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
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
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
> 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):
1
uint16_tres=1;
2
uint8_tidx=1;
3
while((res<=time)&&(idx<10)){
4
res+=res;
5
idx++;
6
}
7
// wenn diese Schleife verlassen wird hat idx einen Wert
8
// von 1..9 (inklusive)
9
// Gerade bei einem Wert von time>=128 bekommt idx den Wert 9
10
res/=2;
11
if(--idx>7)idx=(idx&0x0F)|(1<<WDP3);
12
// idx hat nach dem -- einen Wert zw. 0 und 8, d.h. der Wert 8 ist der
13
// einzige bei dem das if in den "then" Zweig läuft
14
// im then-Zweig wird idx durch das &0x0F nicht verändert(!),
15
// wenn man sich die Bits im Register WDTCR ansieht, würde ein
16
// idx & 0x07 logischer erscheinen
17
// Bit 3 ist naemlich "Watchdog Enable" (s.47/48 im Datenblatt)...
18
idx|=(1<<WDIE);// enable WDT-ISR
19
// ...und das macht in Kombination mit "WDIE" keinen Sinn ("If WDE is set,
20
// WDIE is automatically cleared")
21
22
wdt_reset();
23
WDTCR|=(1<<WDE)|(1<<WDCE);
24
WDTCR=idx;
Ob die Änderung von 0x0f in 0x07 das Problem behebt probiere ich am
WoEnde aus.
Randy
> // 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
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)
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)
if (--idx > 7) idx = (idx & 0x07) | (1 << WDP3);
ist natürlich richtig. Idx enthält die "Bitcodierung" des WDT Timeouts
umgerechnet aus dem der Funktion übergebenen Timout Wert in WDT Ticks.
Dazu dienen ja die WDP? Bits. Davon liegen 3 Bits im untersten Nibble
aber das WDP3 Bit liegt eben pysikalisch woanders. Ergo Idx muß mit 0x07
maskiert werden und dafür das WDP3 Bit rein-ge-odert werden.
Beim Setzen der verschiedenen WDT Betriebsmodis muß man aber aufpassen.
Wir benötigen nur den periodischen WDT Interrupt. Dazu darf WDE nicht
gesetzt werden und statt dessen nur WDIE. Setzt man WDIE und WDE dann
wird nur einmalig ein WDT IRQ ausgelösst. Wird in dieser ISR nicht
explizit erneut das WDIE Bit gesetzt, es wird bei der Kombination WDIE +
WDE autom. per Hardware vor dem Einsprung in die WDT-ISR gelöscht, dann
würde der nächste WDT Timeout einen echten WDT-Reset auslösen. Benutzt
man nur WDIE, also ohne WDE, so wird das WDIE Bit nicht mehr per
Hardware vor dem Einsprung in die WDT ISR gelöscht. Somit bleibt der
WDIE permanent aktiviert ohne das man sich darum weiter kümmern müsste.
Und exakt diesen Modus wollen wir benutzen, da der WDT nur als, zwar
rel. ungenauer, Timer benutzt wird der aber eben auch im Power Down
Sleep Modus noch arbeitet.
Wird also in wdt_setup() das WDE Bit ebenfalls gesetzt so verhält sich
das Projekt garaniert nicht so wie es sein sollte. Nach dem ersten
Auslösen der WDT-ISR, in Datei isrs.S -> WDT_vect, würde der AVR beim
nächsten WDT Timout einen HW-Reset machen.
Danke für das Aufspüren dieses Bugs (es gibt keine Software ohne Fehler
;)
Das Projekt basiert also darauf das es die minimale Zeitdauer bis zum
nächsten Aufleuchten eines/mehrer Glühwürmchen, so effizient wie möglich
in variable WDT Timouts umrechnet und somit im Power Down Sleep Modus
verbringt. Diese Zeitspannen sind variabel und somit auch die WDT Phasen
im Sleep Modus.
Bei WDT Timouts die gestaffelt als Potenz zur Basis 2 vorliegen ist
zwangsläufig die binäre Codierung der effizienteste Pfad um mit wenigen
WDT Timouts einen Gesamttimout zu zerstückeln. Pure Mathematik.
Gruß Hagen
Allerdings muß man beim ersten Setzen des WTCRs die Kombination WDE +
WDCE benutzen und beim zweiten Setzen des Registers darf dann das WDE
Bit nicht mehr gesetzt sein. Das wäre aber bei der Maskierung mit 0x0F
uU. aber der Fall.
Warum ich diesen Fehler bei meinem Projekt nicht sofort bemerkt habe ist
mir aber selber ein Rätsel ;)
Gruß Hagen
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
> 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
@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
> 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
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
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...
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...
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):
1
130c135
2
<uint16_tsol_volt=ADC;
3
---
4
>uint16_tsol_volt=ADC+50;
5
147c159,162
6
<if(--idx>7)idx=(idx&0x0F)|(1<<WDP3);
7
---
8
>if(--idx>7)idx=(idx&0x07)|(1<<WDP3);
9
160,161c176,177
10
<uint16_ttimeout=0;// remaining time in WDT cycles a 16ms upto next event
11
<uint16_tmeasure=0;// remaining time upto next measurement^M
12
---
13
>int16_ttimeout=0;// remaining time in WDT cycles a 16ms upto next event
14
>int16_tmeasure=0;// remaining time upto next measurement
15
167c183,186
16
<if(timeout==0){
17
---
18
>if(timeout<0){
19
>timeout=0;
20
>}
21
>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
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
1
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
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
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
>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:
1
uint16_tt=wdt_setup(timeout);
2
3
if(t>timeout)printf("Error");
4
5
timout-=t;
Falls die Meldung "Error" erscheien sollte dann ist definitiv irgendwas
in wdt_setup() noch falsch.
Gruß Hagen
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
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.
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-Tutorial:_Equipment#Selbstbau)
- 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
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_id=68108&package_id=66543&release_id=411822
Aber vielleicht weiss das ja auch schon jeder - außer mir. ;)
Nochmals Dank an Hagen für seine wertvollen Tipps!
In diesem Sinne
Lothar
Lothar Merl schrieb:
> Damit nicht noch andere Nachbauer verzweifelt nach Fehlern suchen:>> Mit der aktuellen Version des Winavr (Stand Mai 2009) läßt sich der> Source meiner Erfahrung nach NICHT wunderfrei compilieren. Es kommt zu> allerlei bunten Effekten.
Einen Bug bekommt man mit -fno-split-wide-types weg. Probleme machen
aber u.U auch globale Register. GCC 4 optimiert die teilweise gnadenlos
weg, auch wenn man sie per -ffixed- "reserviert". Ob das nun ein Bug
oder ein Feature ist...?
> Die von Hagen benutzte, ältere Version mit AVR-GCC 3.4.6 führt zu> verlässlichen Ergebnissen. Z.B. von hier:
Jo, nud der Code ist oft sogar dichter. Und Bugs hab ich bei dem noch
keine gefunden. :-)
Johann
das ist der Grund warum ich diese Version am häufigsten einsetze. Man
muß halt dann die nötigen Libs/Includes manuell auf den neusten Stand
halten.
Gruß Hagen
Hallo,
ich bin noch blutiger Anfänger, und wollte Fragen ob mein Gedanke
richtig ist?
Wenn ich die Glühwürmchen auf einen ATMEGA32 draufmache und den Code
abändere, kann es sein das dann statt der 4 Ausgängen für LED's dann 32
zur verfügung stehen würden?
LG
Michael
> 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
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
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).
1
// now sort each pair of DDRB/OCR0A values descending to OCR0A value == PWM dutycycle for each LED
2
cp _b_ocr, _c_ocr
3
brsh 50f
4
movw _y, _b
5
movw _b, _c
6
movw _c, _y
7
50: cp _a_ocr, _b_ocr
8
brsh 51f
9
movw _y, _a
10
movw _a, _b
11
movw _b, _y
12
cp _b_ocr, _c_ocr
13
brsh 51f
14
movw _y, _b
15
movw _b, _c
16
movw _c, _y
17
51:
Sortiert nun die 3 OCR/DDR Paare, du musst 7 solcher Paare nach dem OCR
Wert sortieren.
1
// OCR0A values must be negated
2
neg _a_ocr
3
neg _b_ocr
4
neg _c_ocr
5
// setup PINs
6
or _b_ddr, _a_ddr
7
or _c_ddr, _b_ddr
Negiert OCR Werte und verodert die DDR Pins für 3 LEDs, du 7 LEDs.
1
// store calculated OCR0A/DDRB pairs to ocr_data[] for Output Compare ISR
2
ldi _yl, lo8(ocr_data)
3
ldi _yh, hi8(ocr_data)
4
movw _ocr_ptr, _y
5
cp _a_ocr, _b_ocr
6
breq 60f
7
st y+, _b_ocr
8
st y+, _a_ddr
9
60: cp _b_ocr, _c_ocr
10
breq 61f
11
st y+, _c_ocr
12
st y+, _b_ddr
13
61: st y+, _zero
14
st y+, _c_ddr
Speichert die 3 -1 OCR/DDR Paare in den SRAM für die Output Compare ISR.
Du für 7 -1 solcher Paare.
In deinem Falle musst du diese unrolled Loops wieder in Schleifen
verbauen da dir die Register des AVRs ausgehen werden.
Gruß Hagen
Danke für die sehr ausfürliche Antwort. Leider kann ich damit nichts
anfangen, denn das Ganze überschreitet meinen derzeitigen Kenntnisstand
bei Weitem.
Ich habe jetzt erst mal die "Originalschaltung" aufgebaut um erst mal zu
sehen, wie es so aussieht. Leider bin ich schon an der Programmierung
des uControllers gescheitert. Dieses mitgelieferte Progamm, mit dem man
die firefly.hex brennen soll, kann keine Verbindung zum Chip aufbauen.
Ich schätze mal, dass man dafür einen ISP oder JTag-Programmer braucht?
(Ich verwendete bisher immer das Pollin Evaluationsboard mit Ponyprog)
Du kannst das FoireFly.hex auch ohne den Bootloader flashen. Dann über
ISP usw. Willst du den Bootloader benutzen dann musst du diesen
natürlich als erstes drauf programmieren. Danach, also nach den Tests
seiner Funktionen, kannst du das ISP vom AVR trennen.
Du musst aber die Bootloader Software neu kompilieren da du ja einen
anderen AVR Prozessor benutzen möchtest. Ich würde dir dann empfehlen
mit der aktuellesten Bootloader Version zu arbeiten, findest du hier:
Beitrag "Re: AVR-Bootloader mit Verschlüsselung"
Gruß Hagen
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
> 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
> 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
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.
>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
> 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
> 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.
> 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/umweltpraktikum/solar/node9.html
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.
> ... 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.
Korrekt, und ab einer gewissen Unterschreitung muß die interne Bodydiode
leiten. Aber es geht ja garnicht um den Fall wenn die Akkuspannung zu
klein zum Öffnen des MOSFETs ist, sondern um den Fall darüber.
Normalerweise sollte der Akku Nachts über also nicht unter die Gate
Threshold Spannung des MOSFETs entladen werden. Tags über soll möglichst
alle Eneregie in den Akku fließen ohne den Voltagedop von min. 200mV
wenn man eine Shottkydiode benutzen würde. Sogesehen sollte der Akku
nicht unter 0.7 Volt entladen werden. Ein Grund der Vorltagedrop der
interen Bodydiode des MOSFETs falls dieser bei 0.7V am Gate nicht mehr
ordentlich leitet. Der andere Punkt ist der Stepup Wandler der nur bis
>0.7V runter anschwingt und nur wenn er schon läuft auch unter 0.7V
arbeitet.
Gruß Hagen
1206'er SMD, sind übrigens nur 4.7µ verbaut worden.
BSS123 hat mit 1V höhere VGS(th), der BSS138 hat laut Datenblatt 0.5V.
Ansonsten sind bei diesen kleinen MOSFETs nur 2 Dinge wichtig: Gate
Threshold Spannung und das es N-Kanal MOSFETs sind.
Du kannst auch ganz auf diese Schaltung verzichten und mit einer
besseren Schottky Diode arbeiten. Bei dieser Schaltung geht es nur um
die 200mV Spannungsabfall an der Schottky Diode der entstehen würde und
der mit dieser Schaltung auf ~10µV reduziert wird.
Gruß Hagen
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.
Der RDS(on) ist relativ unwichtig solange er nicht im kOhm Bereich liegt
und das Solarpanel nicht ganze Ampere an Strom liefert. Beides bei
diesem Projekt nicht der Fall. Die VGS(th) ist der wichtigste Parameter
und sollte so niedrig wie möglich sein, mindestens < 0.7V. Die per ADC
ermittelte Abschaltspannung sollte demnach > VGS(th) und > 0.7V Startup
Voltage des Stepups sein. Der normale Arbeitsbereich der "iealen Diode"
liegt also bei > 0.7V bis maximale Akkuspannung. In diesem Bereich
wünschen wir uns das der Voltagedrop über diese Diode möglichst 0V ist
da somit die volle Energie des Solarpanels benutzt wird. Wie gesagt, wer
mit 200mV Verlust in diesem Bereich leben kann nimmt eine Schottky
Diode.
Gruß Hagen
Hallo und Sorry,
also irgendwie tue ich mich mit dem Schaltbind Schwehr, also wenn ich
mit Zwei Akkus direkt reinfahre ohne den Max??? und der schaltung dazu,
dann sollte doch die Schaltung wenn ich es richtig gelesen habe etwa so
aussehen, zumindest die LED Anschlüsse?
Im Anhang habe ich das Schaltbild mitgeschickt.
Und hier noch die Erklärung zu den Anschlüssen:
LED Paar:
-->|--
--|<--
1A und 1B = LED Paar 1 PB0-PB1
2A und 2B = LED Paar 2 PB0-PB2
3A und 3B = LED Paar 3 PB0-PB5
4A und 4B = LED Paar 4 PB1-PB2
5A und 5B = LED Paar 5 PB1-PB5
6A und 6B = LED Paar 6 PB2-PB5
und an + und GND 2x 1,2 V = 2,4 V
Habe ich das richtig verstanden weil wenn ja dann kommt man auch mit nur
Drei Wiederständen aus?
In der Schaltung steht Tiny13 einen 45er hatte das Programm nicht in
seiner Bibliothek.
Im vorraus schon einmal vielen Dank.
LG
Michael
Hatte mich vertahn war wohl zu früh hier das verbesserte Schaltbild,
sind doch Vier Wiederstände.
1A und 1B = LED Paar 1 PB0-PB1
2A und 2B = LED Paar 2 PB0-PB2
3A und 3B = LED Paar 3 PB0-PB5
4A und 4B = LED Paar 4 PB1-PB2
5A und 5B = LED Paar 5 PB1-PB5
6A und 6B = LED Paar 6 PB2-PB5
LG
Michael
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
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
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-Tutorial:_Equipment#Selbstbau)
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
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.
@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:
1
> "make.exe" all
2
3
-------- begin --------
4
avr-gcc (GCC) 4.2.2 (WinAVR 20071221)
5
Copyright (C) 2007 Free Software Foundation, Inc.
6
This is free software; see the source for copying conditions. There is NO
7
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
c:/winavr/bin/../avr/include/avr/eeprom.h:268: undefined reference to `seed'
17
c:/winavr/bin/../avr/include/avr/eeprom.h:268: undefined reference to `seed'
18
firefly.o: In function `init':
19
C:\Dokumente und Einstellungen\tw\Desktop\glühtest/firefly.c:64: undefined reference to `lfsr_poly'
20
firefly.o: In function `update_fireflies':
21
C:\Dokumente und Einstellungen\tw\Desktop\glühtest/firefly.c:75: undefined reference to `lfsr'
22
make.exe: *** [firefly.elf] Error 1
23
24
> Process Exit Code: 2
25
> 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
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
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
> 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
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
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!
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
> 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
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
1
if(--idx>7)idx=((idx&0x07)|(1<<WDP3));
2
idx|=(1<<WDIE);// enable WDT-ISR
3
wdt_reset();
4
WDTCR|=(1<<WDE)|(1<<WDCE);
5
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
1
MEASURE_INTERVAL(uint16_t)(625)
gesetzt. Die LED'S beginnen nach 1 Minute zu blinken. Jedoch ist es nun
nach etwa 70 Minuten dunkel und auch nach 3 Stunden hat nichts mehr
angefangen. Die Spannung liegt bei etwa 1.2, also vollkommen im grünen
Bereich.
Wer hätte nen Tip?
Gruß Stefan
Desweiteren ist mir im Datenblatt auf Seite 49 aufgefallen, das WDP
maximal auf 1001 stehen darf, alle höheren Bit-Kobinationen sind
reserviert. Allso müsste die Zeile doch folgendermaßen lauten ?
1
if(--idx>7)idx=((idx&0x01)|(1<<WDP3));// neue Idee ??
2
// if (--idx > 7) idx = ((idx & 0x07) | (1 << WDP3)); // max timeout setzen
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
1
prog_uint8_twave[827]={...
somit hat sie ja 827 Stellen, adressiert wird aber von 0... 827
1
wave_data_twave_data[32]={
2
{&wave[0],&wave[26],832},
3
{&wave[0],&wave[99],865},
4
...
5
{&wave[534],&wave[827],987},
6
{&wave[693],&wave[827],927}
Das ganze sollte evtl. in den Umsetzungen bedacht werden.
Stefan
@Stefan:
Tja, Unterschied zwischen Simulation und Realität. In der Simulation mit
LTSpice zeigte sich das mit den Dioden der geringste Stromverbrauch (µA
Bereich) zu erreichen ist. In der Realität ist das Ganze viel zu
hochohmig und deshalb erwähnte ich irgendwo hier das man besser
Widerstände dafür nehmen sollte. Bei mir geht es aus irgendeinem Grund
bei mehreren Aufbauten, ich schätze das mein selbstgeätztes Layout daran
"Schuld" ist.
Danke für den Tipp.
Ansonsten kann man ja auch diese "ideale Diode" auch einfach komplett
durch eine Shottky ersetzen.
Gruß Hagen
>somit hat sie ja 827 Stellen, adressiert wird aber von 0... 827>wave_data_t wave_data[32] = {> {&wave[ 0], &wave[ 26], 832},> {&wave[ 0], &wave[ 99], 865},>...> {&wave[ 534], &wave[ 827], 987},> {&wave[ 693], &wave[ 827], 927}>Das ganze sollte evtl. in den Umsetzungen bedacht werden.
Nein ist richtig so, musste aber auch erstmal drüber nachdenken da du
mich im ersten Moment überrumpelt hast ;)
Das sind Zeiger in die Wave-Tabelle. Der Zeiger &Wave[827] zeigt damit
hinter das letzte Byte der Wave Tabelle und somit an das Ende.
wave_data[] enthält also einen Zeiger mit dem Start der Wave und einen
Zeiger auf das Ende der Wave +1 Sample. Der Start wird geladen und
solange inkrementiert bis er auf Ende steht.
Nur der erste Zeiger (Start) wird zum Zugriff auf die Waves[] benutzt.
Der zweite zeiger dient als Vergleichwert mit dem internen Zeiger der
mit Start initialisiert wird und immer +1 inkrementiert wird bis er eben
auf Ende steht.
Man hätte nun statt einen Ende-Zeiger einen Samples-Zähler benutzen
können. Das führt aber dazu das man entweder
1.) eine Endevariable auf Start + Sample_Count initialisieren muß oder
2.) in der Zählschleife sowohl den aktuellen Samplezeiger +1 wie auch
Sample_Counter -1 rechnen muß
Somit ist das eine Optimierung durch Vorausberechnung und man lädt
einfach Start in den Samplezeiger und vergleicht diesen mit dem Ende
Zeiger und inkremeniert nur eine Variable den Samplezeiger.
Das dient der Codeoptimierung letzendlich. Denn ich lade die Wave Sample
mit LPM r,Z+ also mit implizitem Postinkrement. Nach dem Laden steht der
Zeiger Z also, wenn er das Ende erreicht hat, auf +1 Samples hinter der
Wave. Danach wird er mit Ende verglichen.
Ein Marker in den Samples geht nicht. Dh. man definiert einen speziellen
Samplewert der als Endemarke in den Waves[] drinnen steht. Das geht
nicht weil die verschiedenen Leuchtmuster alle in Waves[] gespeichert
sind und sich überschneiden, also Teile des einen Leuchtmusters werden
durch ein anderes Leuchtmuster mit benutzt.
Gruß Hagen
Hi Leute, ich habe ein kleines Problem mit der Schaltung von Randy. Ich
habe die Version nachgebaut. Nur läuft sie nicht richtig. Nach dem
Einschalten (LDR abgeklemmt) fangen verschiedene LEDs nach ca.20
Sekunden an zu flackern und gehen teilweise in Dauerleuchten über. Also
keine 6 Minuten bis es losgeht. Dann irgendwann gehen sie aus und das
Spiel beginnt von vorne.
Ich habe den Code auch schon selbst kompiliert, ohne Erfolg. Die Fuses
habe ich kontrolliert und glaube sie stimmen (L=E2, H=DF, E=FF).
Geflasht hab ich versuchsweise mit BASCOM und avrdude, beidesmal ohne
Fehler. Verify gegeneinander war auch ok.
Irgendjemand ne Ahnung wo ich suchen könnte.
> 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
Also ich bin weiter. Das Hex-File scheint mit 15 Sekunden
MEASURE_INTERVAL kompiliert zu sein. So steht es auch im Quelltext.
Ich habe jetzt mal die Sourcen neu kompiliert bei der ich die
measure_isnight Routine fest auf flags |= FLAG_ISNIGHT; gesetzt habe.
Damit klappt es schonmal so weit, dass die Würmchen aufleuchten und
nicht mehr flackern. Ein Problem hatte ich noch beim Kompilieren mit
einer ignoring Warnung in der wave.h.
(gcc version 4.3.3, WinAVR 20100110)
Das stand:
typedef struct {
....
} wave_data_t PROGMEM;
muss aber jetzt
typedef struct PROGMEM {
....
} wave_data_t ;
sein.
Jetzt werd ich das mit der ADC-Geschichte in der insnight-Routine mal
durchsehen und auch mal schauen ob ich ein wenig mehr "Action" bekomme.
Bei mir ist nur selten mehr als ein Glühwürmchen aktiv. Und das Ganze
mit langen Pausen ohne Aktivität dazwischen.
Hallo,
ich habe die Glühwürmchen etwas verändert / vereinfacht nachgebaut:
- 2 * AAA Eneloop Akkus,
- Solarzelle mit Shottky Diode abgekoppelt
- Messung der Batteriespannung über interne Bandgap, dadurch bleibt der
Reset Pin frei
- Doppelt lange Wave, damit sie nicht so nervös blinken....
- verschiedene Varianten der Helligkeitsmessung,
a) über Solarzelle, geht bei manchen Solarzellen anscheinend schlecht
(infrarot?), deshalb
b) Messung über LDR mit (Reset-Pin) geschaltetem Pull-up
c) Messung über LDR mit Kondensator
Deshalb gibt es drei Schaltbilder, im Code wird über #ifdef
umgeschaltet.
Gruß,
Bernhard
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
Tom schrieb:> Hallo Bernhard>> bin hier absoluter Neuling.> Kannst Du mir mal das Layout der Platine und die genaue Anleitung ins> Board stellen?> Wäre Dir sehr dankbar.>> LG> Tom
Hi Tom,
ich habe kein Layout, weil ich die auf Lochraster aufgebaut habe.
Was brauchst du noch als Anleitung?
Gruß,
Bernhard
Hi 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
Hi,
am laufen habe ich a) und c), b) hatte ich kurzzeitig.
Ursprünglich habe ich eines mit a) gebaut, das geht ganz gut.
Ein weiteres mit einer anderen Solarzelle hat "Nacht" unzuverlässig
erkannt, deshalb der Umstieg zu c).
c) deshalb, damit man den Reset noch für ISP behalten kann.
Gruß,
Bernhard
Hallo 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é
Hallo René,
iah hatte mir die Version mit Solarzelle als Sensor nachgebaut.
Hatte das Problem das es immer gut anlief und nach einer unbestimmten
Zeit nocht mehr reagiert hat, so zumindest der anschein. Mit dem Loader
kam ich aber immer ohne Probleme drauf.
Wenn du ne recht aktuelle Version von WinAVR verwendest solltest du
einmal beim kompletten neukompilieren kontrolieren ob von der "wave.h"
ein warning kommt bezüglich Definition/Reihenfolge von "Progmem".
Sieh dir dazu mal den Beitrag von Joachim am 19.07.2011 13:25 an.
Beitrag "Re: Glühwürmchen in Rotkohlglas gefangen"
Bei mir war nur dies der Fehler das es als "ausgestiegen" ist.
Viel Erfolg
Stefan
Hi,
angehängt noch mal alle sourcen.
Ich programmiere unter Linux. Da es dafür kein bootloader Programm für
Hagens bootloader gibt verwende ich Peters bootloader, das hat aber
keinen Einfluss.
Kompiliert habe ich mit gcc 3.4.6, ziemlich alt aber relativ
"fehlerfrei" (andere Projekte kompilere ich z.Zt. mit 4.4.2, der könnte
hier auch gehen).
Ansonsten laufen beide Varianten (Solarzelle als Lichtsensor und LDR mit
Kondensator) seit Juli / August dauerhaft und leuchten immer noch...
Gruß,
Bernhard
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é
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
> 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
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é
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
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
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é
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
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
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
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.
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_id=68108&package_id=66543&release_id=411822
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
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
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.
>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.
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten