Für mein Vorhaben, einen batteriebetrieben Außensensor auf Arduino-Basis zu bauen, ist ein möglichst sparsames System von großer Bedeutung. Es wäre wenig praktikabel, alle paar Tage die Batterien erneuern zu müssen. Auch alle paar Monate nicht. Es wird eine Mindestlaufzeit von einem Jahr oder mehr angestrebt.

Es sollen die verbreiteten AA-Batterien (aka Mignon) verwendet werden. Sie stellen einen guten Kompromis zwischen größe, Verfügbarkeit, Kapazität und Prei dar. Unter der Annahme einer mittleren Kapazität von 2500mAh, darf die Platine incl. aller Peripherie nicht mehr als etwa 0,29 mA verbrauchen. Es soll jedoch möglich sein, einen Atmel (Arduino-CPU) mit wenigen µA (im Leerlauf) zu betreiben. Das ist mein Ziel.

Der erste Schritt besteht darin, ein möglichst sparsames Board auszuwählen. Meine Wahl fiel auf ein Arduino Pro Mini (http://arduino.cc/de/Main/ArduinoBoardProMini). Dieses Board hat keinen fest eingelöteten USB-Serial-Konverter, das allein spart schon etwas Energie. Dazu ist es sehr klein, was für meine Zwecke von Vorteil ist.

Der Stromverbrauch einer CPU steigt mit den höheren Spannung (quadratisch) und Frequenz (linear). Von Arduino Pro Mini gibt es Versionen mit 5V/16Mhz und 3,3V/8Mhz. Die zweite Variante muss definitiv genügsamer sein und lässt sich auch besser mit Batterien oder Akkus versorgen (z.B. 3 x 1,2V (Akku) ergibt 3,6V - praktisch perfekt). Leider besitze ich gerade jetzt kein solches Arduino, daher werde ich meine ersten Tests mit der 5V-Version durchführen.

Ein typischer Außensensor tut die meiste Zeit nichts. In weiten Abständen (mehrere Minuten können für einen Mikroprozessor eine halbe Ewigkeit bedeuten) werden angeschlossenen Sensoren abgefragt und die ermittelten Werte an die Basisstation übermittelt. Wie viell Strom bei der Auswertung und der Übertragung fliesst ist nicht so wichtig, denn genau das passiert im Vergleich mit der Ruhezeit sehr selten und dauert jeweils nur ganz kurz. Interessant ist der Verbrauch in der restlichen Zeit.

Was tut ein Prozessor, wenn er nichts zu tun hat?

Der einfachste Fall: CPU läuft in einer Schleife und tut gar nichts (sinnvolles). Um zu sehen, was dabei an Strom verbraucht wird, habe ich das Arduino Standardbeispiel 'Blink' leicht modifiziert. Mein Programm lässt eine LED in einer Endlosschleife für 1 Sekunde leuchten und anschließend wird sie für 4 Sekunden gelöscht. Die Werte 1 und 4 sind aus Bequemlichkeitsgründen gewählt. Zwar wären Werte wie 1 Sekunde (Auswertung und Übertragung) zu 5 Minuten (Inaktivitästszeit) realitätsnäher, zu Testzwecken sind jedoch kürzere Zeiträume wesentlich bequemer. 

// Pin 13 has an LED connected on most Arduino boards.
// give it a name:
int led = 13;

// the setup routine runs once when you press reset:
void setup() {                
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);     
}

// the loop routine runs over and over again forever:
void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(4000);               // wait 4 seconds
}

 

Die Messwerte sind ernüchternd: 18,95 mA (Ruhephase) zu 21,40 mA mit der leuchtenden LED. Der Unterschied liegt durchaus im Bereicht eines typischen Verbrauchs einer LowCurrent LED. Dem zweiten Wert wird ab jetzt nicht weiter Beachtung geschenkt.

Bei diesem Ruheverbrauch wird die Batterie nach ca. 132 Stunden leer. Das sind gerade mal 5,5 Tage. Völlig inakzeptabel.

 

Das Board im Bild wird von einem Programmer (USBasp) versorgt. Dieser tut an sich nichts zur Sache. Es war mir damit gerade einfacher, einen Ampermeter in Arduinos Stromkreis einzuschleusen (wollte gerade kein USB-Kabel aufschneiden).


Der zweite Ansatz führt in die Tiefe der Prozessor-Technik. Die CPU hat mehrere Stromsparmodi: "Idle", "Powerdown", "Powersave", "Standby" und "ADC Noise Reduction mode" (genauer nachzulesen z.B. hier). Der sparsamste davon ist der Modus "Powersave".

Nach einer kurzer Suche habe ich einen Beispiel gefunden, der praktisch alles an Funktionalität enthält, was ich für meine Zwecke benötige (link). Im Quellcode ist zu sehen, wie der Prozessor in den tiefen Schlaf zu versetzen ist und auch wie man ihn daraus wieder weckt. Letztere ist nicht so selbstverständlich, wie man zunächst denken kann. Denn eine tief schlummernde CPU führt keine Programme mehr und reagiert auch auf fast nichts. Um aufzuwachen muss diese "unterbrochen" werden. Dafür wird hier ein sogenannter "Watchdog" genutzt.Ein Watchdog ist eine Schaltung im CPU, die eine Art Countdown durchführt und beim Ablauf diesen einen Reset auslöst. Normalerweise wird im Programm der Timer immer ieder zurückgesetzt. Wenn der Prozessor "hängt", starter der "Wachhund" ihn neu. Eine dre Massnahmen, um eine hohe Systemverfügbarkeit zu garantieren. Der Wachtdog kann bei Atmel-Prozessoren auch dazu verwendet werden, um diese aus dem Schlafmodus aufzuwecken. Auch wenn diese Schaltung im aktiven Zustand selbst etwas Strom verbraucht, scheint sie in diesem Fall genau das richtige Mittel zu sein.

In dem (hoffentlich irgendwann) fertigen Gerät kann ich mich auch eine Taste gut verstellen (z.B. um die aktuelle Werte auf dem LCD anzuzeigen), die auch zum Wiederaufwachen führt. Dies wird wohl mittels eines Interraupts geschehen müssen. Dies soll aner an dieser Stelle ohne Beachtung bleiben.

Ich habe den gefundenen Beispielcode (s.o.) etwas für meine Zwecke modifiziert.

#include <avr/sleep.h>
#include <avr/wdt.h>

// Macros zum Setzen und Löschen von Steuer-Bits
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif

// Pin 13 has an LED connected on most Arduino boards.
int led = 13;

// Steuervariable. Erkennung des Timerablaufs (um z.B. andere Interrupts zu ignorieren)
volatile boolean f_wdt=1;

void setup() {                
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);    
 
  // CPU Sleep Modes 
  // SM2 SM1 SM0 Sleep Mode
  // 0   0   0   Idle
  // 0   0   1   ADC Noise Reduction
  // 0   1   0   Power-down
  // 0   1   1   Power-save
  // 1   0   0   Reserved
  // 1   0   1   Reserved
  // 1   1   0   Standby(1)

  cbi( SMCR,SE );      // sleep enable, power down mode
  cbi( SMCR,SM0 );     // power down mode
  sbi( SMCR,SM1 );     // power down mode
  cbi( SMCR,SM2 );     // power down mode

  setup_watchdog(8); 
}

// the loop routine runs over and over again forever:
void loop() {
  if (f_wdt==1) {  // wait for timed out watchdog / flag is set when a watchdog timeout occurs
    f_wdt=0;       // reset flag

    digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
    delay(1000);               // wait for a second
    digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  }
  
  pinMode(led,INPUT);          // set all used port to intput to save power
  system_sleep();
  pinMode(led,OUTPUT);         // set all ports into state before sleep
}

//****************************************************************  
// set system into the sleep state 
// system wakes up when wtchdog is timed out
void system_sleep() {

  cbi(ADCSRA,ADEN);                    // switch Analog to Digitalconverter OFF

  set_sleep_mode(SLEEP_MODE_PWR_DOWN); // sleep mode is set here
  sleep_enable();

  sleep_mode();                        // System sleeps here

    sleep_disable();                     // System continues execution here when watchdog timed out 
    sbi(ADCSRA,ADEN);                    // switch Analog to Digitalconverter ON

}

//****************************************************************
// 0=16ms, 1=32ms,2=64ms,3=128ms,4=250ms,5=500ms
// 6=1 sec,7=2 sec, 8=4 sec, 9= 8sec
void setup_watchdog(int ii) {

  byte bb;
  //int ww;
  if (ii > 9 ) ii=9;
  bb=ii & 7;
  if (ii > 7) bb|= (1<<5);
  bb|= (1<<WDCE);
  //ww=bb;
  //Serial.println(ww);


  MCUSR &= ~(1<<WDRF);
  // start timed sequence
  WDTCSR |= (1<<WDCE) | (1<<WDE);
  // set new watchdog timeout value
  WDTCSR = bb;
  WDTCSR |= _BV(WDIE);


}

//****************************************************************  
// Watchdog Interrupt Service / is executed when  watchdog timed out
ISR(WDT_vect) {
  f_wdt=1;  // set global flag
}

 

Schon besser.  Bei diesem Stromverbrauch hält die Batterie ca. 31 Tage. Immer noch Faktor 10 zu wenig, aber die Richtung stimmt.

An dieser Stelle denke ich an die hell läuchtende PowerLED. Diese kann sich durchaus 2-4 mA genehmigen. Leider kann sie nicht softwaretechnisch aufgeschaltet werden und mus daher ausgelötet werden. Dies ist nicht ganz einfach, denn es andelt sich hier um eine sehr kleine SMD-Version. Ich werde diese Tätigkeit in die Zukunft verschieben, wenn meine sparsame 3,3V Boards geliefert werden.

 

Der ober Code funktioniert schon recht gut, jedoch will man so ein Mix von Low-Level Anweisungen nicht unbedingt im geschäftslogik-Teil des fertigen Programms sehen. Es muss eine Bibliothek her. Bevor man jedoch eine neue schreibt, sollte man nachsehen, ob nicht schon so eine existiert.

Schnell sind mehrere gefunden: Narcoleptic, Low-Power, Enerlib.

Bei Narcoleptic gefiel mir ihre Einfachheit, geringe Größe und die Möglichkeit, den Inaktivitätsdauer frei vorzugeben. Die Bibliothek wird jedoch seit längerem nicht mehr weiterentwickelt und verursachte im Test einen etwas höheren Verbrauch alt der Code oben. Der Grund dazu ist nicht deaktivierter Analog-Digital-Wandler.

Enerlib hat mir auch nicht zugesagt. Diese könnte ich nicht ohne Modifikation verwendet, denn sie erlaub gar keine Zeitvogabe für den Tielschlaf.

Dafür ist die Low-Power ein Glückstreffer. Gut dokumentiert, mit vielen Hintergrunfinformationen fersehen, sehr mächtig und aktuell. Was mir nicht so gefällt, ist die starre Vorgabe des Schlafdauers. Es sind nur wenige feste Werte (max. 8 Sekunden) möglich (low-level, eben das, was der Watchdog-Timer bietet). Dafür kannn eine sehr feine Konfiguration bezüglich den abzuschaltenden Hardwarekomponenten vorgegeben werden. Gefällt mir sehr. Ich möchte allerdings eine Methode schreiben schreiben, um eine einfache und flexible "delay"-Funktion (etwa wie im Narcoleptic) zu erhalten. Bis dahin werde ich noch einige Test mit Narcoleptic durchführen. Zuvor schalte ich zusätzlich noch den A/D-Wandler mit ab.

#include <Narcoleptic.h>

#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif

// Pin 13 has an LED connected on most Arduino boards.
// give it a name:
int led = 13;

// the setup routine runs once when you press reset:
void setup() {                
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);    
}

// the loop routine runs over and over again forever:
void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                  // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  
  cbi(ADCSRA,ADEN);          // disable A/C-Converter
  pinMode(led,INPUT);       // set all used port to intput to save power 
  Narcoleptic.delay(4000);
  pinMode(led,OUTPUT);    // set all ports into state before sleep
  sbi(ADCSRA,ADEN);         // enable A/C-Converter
}

 

Eigentlich ist mein Board mit 16mHz nicht für 3,3V geeignet, es lief mit dieser Spannung jedoch stabil. Der Verbrauch sank auf 1,57 mA. Das entspricht schon ca. 66 Tagen.

 

 

Um den Verbrauch weiter zu senken, sind schon radikalere Maßnahmen notwendig. Dafür habe ich die Power-LED abgeschaltet. Dafür habe ich den LED-Vorwiderstand herausgelötet. (War etwas schwierig, die SMD-Bauteile liegen auf dem Boars recht eng).

Die Maßnahme wirkt. Der Verbrauch liegt bei 29,5 µA! Und das bei 5 Volt. Damit habe ich mein oben definiertes Ziel eigentlich schon erreicht. Bei den Werten darf die Batterie Jahre halten. Da fällt schon Selbstentladung ins Gewicht.

 

 

Aus dem sportlichen Interesse will ich wissen, was man noch ohne größeren Aufwand erreichen kann.

3,3 Volt-Test war zunächts misslungen. Im µA-Bereich hat das Messgerät wohl einen etwas höheren Widerstand, so dass sich das Board sofort wieder resettet hat. Das habe ich bestimmt dem Brown out Detector (BOD erkennt eine Unterspannung und bewirkt daraufhin Reset der CPU. Damit wird instabiler Betrieb verhindert) zu verdanken. In mA-Bereich war der Wert 0,02 mA angezeigt.

Also muss noch der BOD raus. Das soll aus dem laufenden Programm möglich sein, aber nicht mit Narcoleptic. Eine andere Methode führt über einen neuen Arduino-Bootloader. Eine gute Anleitung dazu liefert 'Rocket Scream', der Hersteller von Low-Power-Bibloithek (Link).

Ich habe die Datei 'boards.txt' (Arduino IDE, Verzeichnis 'hardware\arduino') um eine neue Sektion erweitert.

##############################################################

pro5v328BOD.name=Arduino Pro or Pro Mini (5V, 16 MHz) w/ ATmega328 without BOD

pro5v328BOD.upload.protocol=arduino
pro5v328BOD.upload.maximum_size=30720
pro5v328BOD.upload.speed=57600

pro5v328BOD.bootloader.low_fuses=0xFF
pro5v328BOD.bootloader.high_fuses=0xDA
pro5v328BOD.bootloader.extended_fuses=0x07
pro5v328BOD.bootloader.path=atmega
pro5v328BOD.bootloader.file=ATmegaBOOT_168_atmega328.hex
pro5v328BOD.bootloader.unlock_bits=0x3F
pro5v328BOD.bootloader.lock_bits=0x0F

pro5v328BOD.build.mcu=atmega328p
pro5v328BOD.build.f_cpu=16000000L
pro5v328BOD.build.core=arduino
pro5v328BOD.build.variant=standard

##############################################################


Damit kennt IDE jetzt ein 'neues' Board. Der einzige Unterschied zum Original ist eine anders gesetzt Fuse (Original: ...extended_fuses=0x05).

Nach dem Flaschen des Bootloaders (hier war der Programmer notwendig) war der BOD aus. Das sieht man gut an dem Stromverbrauch und an der Tatsache, dass das Board jetzt mit dem Ampermeter in µA-Bereich bei 3,3V problemlos funktioniert.

 


Der Wert ist zwar nicht so fantastisch, wie bei Rocket Scream beschrieben, aber dennoch sehr beeindrückend. Ich bin gespannt, wie das mit dem 8mHz Arduino aussieht. ;-) In jedem Fall ist der Prozessor nicht der limitierende Faktor für die Laufzeit. In einer fertigen Schaltung werden andere Komponenten über den endgültigen Verbrauch stärker entscheiden. So führt sogar ein angeschlossener FTDI-Chip (zuständig für USB-Anschluss) zu einem messbaren Mehrverbrauch. Dabei war der Chip nicht mal an die USB-Schnittstelle des Computers angeschlossen.

Eine weitere Möglichkeit wäre die Verwendung des internen Oszillators zum Erzeugen des CPU-Taktes. Da dieser nicht so genau wie ein Quarzoszillator ist, kann dabei zu Problemen z.B. bei seriellen Verbindungen kommen (zumindest bei höheren Baudraten). Aus diesem Grund will ich diesen Ansatz nicht weiter verfolgen.

 

Nachdem ich mit den Tests fertig war, habe ich den LED-Vorwiderstand wiedereingelötet. Es ist leider etwas schief geworden, war bei diesem kleinen Raster nicht ganz einfach. Merkwürdigerweise muss dabei der Bootloader Schaden genommen haben. Das Board lief nicht mehr und ließ sich auch nicht über USB bespielen. Mit einem Programmer konnte ich jedoch einen neuen über die ISP-Schnittstelle installieren. Jetzt läuft Pro Mini wieder einwandfrei. Ich verstehe nicht ganz, wie das passieren konnte. Evtl. hat das etwas mit statischen Elektrizität zu tun.

 

 Im Folgenden noch mein Testprogramm unter der Verwendung der LowPower-Bibliothek.

/* 
 * PowerSave
 *
 * Author: Alexander Schulz 
 * Version: 1.0
 * Datum:  17.07.2013
 *
 * Dieses Programm lässt die auf dem Arduino- Board vorhandene LED 
 * alle 4 Sekunden blinken. In den Pausen wird der Prozessor 
 * in den Schlaffmodus versetzt.
 * 
 */
 
#include <LowPower.h>

// Pin 13 ist auf den meisten Boards mit einer LED verbunden.
int led = 13;

void setup() {                
  // Definiert den LED-Pin als Ausgang.
  pinMode(led, OUTPUT);    
}

void loop() {
  digitalWrite(led, HIGH);   // LED an (Ausgang HIGH)
  delay(1000);               // eine Sekunde brennen lassen
  digitalWrite(led, LOW);    // wieder ausmachen (Ausgang LOW)
  
  pinMode(led,INPUT); // Alle benutzen Ports als Eingang definieren, das spart Energie
  delay(4000);
  pinMode(led,OUTPUT); // benutzte Ports wieder in den benötigten Zustand versetzen
}

/*
 * Versetzt den Prozessort für eine angegebene Zeitspanne ins Tiefschlaf.
 * Nach dem Auswecken wird geprüft, ob die gewünschte Zeit bereits abgelaufen ist
 * und wird ggf. wieder Schlafmodus aktiviert.
 * Man sollte bei der Dauer nicht mit einer besonderen Genauigkeit rechnen.
 */
void delay(int milliseconds) {
  while (milliseconds >= 8000) { sleep(SLEEP_8S); milliseconds -= 8000; }
  if (milliseconds >= 4000)    { sleep(SLEEP_4S); milliseconds -= 4000; }
  if (milliseconds >= 2000)    { sleep(SLEEP_2S); milliseconds -= 2000; }
  if (milliseconds >= 1000)    { sleep(SLEEP_1S); milliseconds -= 1000; }
  if (milliseconds >= 500)     { sleep(SLEEP_500MS); milliseconds -= 500; }
  if (milliseconds >= 250)     { sleep(SLEEP_250MS); milliseconds -= 250; }
  if (milliseconds >= 125)     { sleep(SLEEP_120MS); milliseconds -= 120; }
  if (milliseconds >= 64)      { sleep(SLEEP_60MS); milliseconds -= 60; }
  if (milliseconds >= 32)      { sleep(SLEEP_30MS); milliseconds -= 30; }
  if (milliseconds >= 16)      { sleep(SLEEP_15Ms); milliseconds -= 15; }
}

/*
 * Verwendet LowPower-Bibliothek zum Aktivieren des Schlafmodus der CPU.
 */
void sleep(period_t period) {
  LowPower.powerDown(period, ADC_OFF, BOD_OFF); 
}

 

Kommentare (7)

Cancel or

  • Alexander Schulz
    Hallo Miro,

    sieht gut aus, dein Aufbau. Jedoch ist schon von Prinzip her eher nicht für den Batteriebetrieb geeignet.
    Dauerleuchten von LED ist in jedem Fall nicht drin. Eine normale LED braucht bis 20mA, eine LowCurrent - ca. 2mA. Beides viel zu viel.
    Das Abschalten wird die Hardware nicht weiter stören, von den besonderen Fällen, wie unpassende Zeitpunkte (Schreibvorgänge etc.) u.ä. abgesehen.
    Genau so funktioniert ja das Stromsparen: durch Abschalten von nicht gerade benötigten Teilen der Schaltung.
    Man muss natürlich ggf. für die notwendige Initialisierung beim Aufwachen sorgen.
    Mit einem Bewegungsmelder könnte man schon probieren, die LEDs, den RFID-Teil und Arduino abzuschalten. Je nach dem, wie viel sich BM genehmigt, könnte das schon funktionieren.
    Schöner wäre natürlich doch eine stationäre Versorgung zu verlegen. Hast Du keine Möglichkeit, irgendwo ein USB-Netzteil zu platzieren? Wenn man ein dünnen Kabel nimmt, kann dieser sogar unsichtbar unter der Tapete verschwinden. Oder im Putz.

    Grüße,

    Alexander
  • Miro
    ...

    Da ich nahe zu keine Ahnung vom Programmieren habe, wird es mir sicher nicht gelingen, denn Sketch alleine zu ändern. Aber möglicherweise ist das auch überhaupt nicht möglich. Die größten Verbraucher der Schaltung sind definitiv die LEDs, der Arduino und die RFID Leser. Das Homematic Modul verbracht im Standby ja fast nichts. Was hältst du davon die „Großverbraucher“ über einen Bewegungssensor einzuschalten? D.h., dass das Homematic Modul dauerhaft laufen würde und die restlichen Komponenten nur, wenn man auch tatsächlich davor steht. Denn, wenn ich nicht davor stehe brauche ich weder leuchtende LEDs noch einen wartenden RFID Leser. ^^

    Ich habe einen China-Motionsensor bestellt, der bei Bewegung eine Schaltung für 20 Sek einschaltet und den Timer bei jeder Bewegung erneut startet. Die Arduino RFID Leser Kombination benötigt auch gerade mal 2 Sek nach dem Einschalten, bis der erste Lesevorgang ausgeführt werden kann.

    So müsste ich doch die maximale Energieersparnis erreichen oder ist das ständige Ein-/Ausschalten nicht gut für die Hardware? Ich gehe davon aus, das der besagte Bereich maximal 5 Mal täglich betreten wird, sodass die gesamte Hardware maximal 5 Min täglich laufen würde. Vermutlich müsste der Arduino aber trotzdem laufen, damit der Motionsensor ausgelesen werden kann.

    Mir wäre diese Lösung lieber, da ich so auch schon vor dem Einlesen des RFID Tags die aktuellen Status einsehen kann.

    Grüße,

    Miro
  • Miro
    Hallo Alexander,

    Vielen Dank für deine Antwort!

    Ich schreibe Dir meine Antwort nochmals hier in die Kommentare, weil ich nicht weiß, ob meine E-Mail bei dir angekommen ist.

    So schaut der erste Aufbau des Projekts aus:

    https://www.dropbox.com/s/dcxxcqn58gq2xyv/IMG_9888.jpeg

    Am Ende soll es eine auf Homematic basierte LED Status und Schalttafel werden, die in meinem Flur an Wand in der Nähe der Eingangstür montiert werden soll, um diverse Aktionen für FHEM zu schalten, wie u.a. meine Alarmanlage per RFID.

    Links im Bild befinden sich acht Dual LED mit den dazugehörigen Schaltungen. Diese sind mit einem Homematic HM-MOD-RE-8 8-Kanal Schaltmodul unten in der Mitte verbunden, der die Verbindung zu FHEM übernimmt. Die Kanäle 1-4 sind reine LED Status Kanal, die bis auf den ersten und den zweiten Kanal (Kanäle für die Alarmanlage, lokal schaltbar per RFID) nicht lokal schaltbar sind. Die Kanäle 5-8 werden noch mit lokalen Schaltern versehen und dienen u.a. der Heizungssteuerung.

    Über dem Homematic Modul befindet sich der RFID Leser, die dazu gehörige Status LED und darüber ein Arduino Nano.

    Ich habe heute mal den Verbrauch durch gemessen und es war sehr ernüchtern… Ich komme insgesamt auf circa 150mA. —.— Wenn ich die LEDs abschalte lande ich bei circa 80mA. Die Werte sind für einen Batterie Betrieb des Projekt viel zu hoch, denn häufiger als alle 6 Monate wollte ich die Batterien nicht wechseln…

    ...
  • Alexander Schulz
    Hallo Miro,

    danke für die Blumen ;) Ich möchte eigentlich noch viel mehr online beschreiben. Aber die Faulheit und Zeitmangel haben immer wieder etwas dagegen ;)

    So eindeutig kann ich Deine Frage nicht beantworten, aber vermutlich wird das schon gehen. Die Frage ist nur, wie aufwendig Dein Sketch umgebaut werden muss.
    Der Spareffekt wird ja dadurch erreicht, dass der µC (und möglichst die ganze Hardware) die meiste Zeit 'schläft'. Der Controller muss also in Tiefschlaf versetzt und bei Bedarf wieder geweckt werden. Ideal wäre wahrscheinlich, wenn der RFID-Reader diese Aufgabe per Interrupt übernehmen könnte. Dann müsste µC wirklich nur dann aktiv werden, wenn jemand einen Tag davor hält. Wenn der Reader das nicht kann und gepollt werden muss, muss der µC deutlich mehr tun. Wird ggf. aber trotzdem gehen. Sagen wir 2-3 mal pro Sekunde den Reader aktivieren und danach fragen, ob ein RFID-Tag erkannt wurde. Im Sinne der Usability (wie lange man den Schlüssel vorhalten muss) ist das ausreichend. Hier hängt alles davon ab, wie lange der Auslesevorgang dauert. Das bestimmt dann das Verhältnis zw. Aktivsein und Schlaffen. Wenn man nur das Ergebnis abholen muss - wird das gut gehen, wenn man länger aktiv etwas steuern muss - wird der Verbrauch hoch. Also die Frage ist, wie viel Intelligenz der RFID Reader mitbringt? Ich kenne das Teil leider nicht, erwarte aber doch relativ viel 'Eigenlogik'.


    Grüße,

    Alexander
  • Miro
    Hallo Alexander!

    Erstaunlicherweise werde ich bei meinen Projekten immer auf deiner Seite fündig. :)

    Ist es möglich diese Energiesparoptionen mit jedem beliebigen Sketch zu nutzen? Ich habe einen Arduino Nano mit einem Mifare RC522 RFID Reader verbunden und würde gerne den Energieverbrauch soweit drosseln, dass es möglich ist, alles über 4 AA (2500mAh) Batterien zu betreiben.

    Wenn man beim Nano die von Dir gemessenen Werte erreichen könnte, würde sich der Energieverbrauch deutlich bessern, da der Mifare RC522 im Sleep Modus auch nur <80uA verbrauchen soll. Allerdings bin ich mir nicht sicher, ob man diesen gesondert aktivieren muss. Angenommen, dass die Herstellerangaben zum Mifare RC522 stimmen, müsste mein Aufbau mit einer Batterieladung ewig laufen.

    Hältst du das für möglich?
  • Alexander Schulz
    @Johannes

    Hallo Johannes,

    ich weiß jetzt nicht, wie viel Strom verbrät der Regler beim Speisen mit 6V. Aber das könnte schon recht viel sein. Es muss ja 1 von Deinen 6 Volt verheizen. 40 mA erscheinen mir dafür jedoch etwas viel. Beim Nano ist ja auch noch der FTDI-Chip drauf, müsste man messen, was er schluckt. Aber bestimmt auch nicht so viel. Sicher dass keine LEDs mehr leuchten? Aber auch dafür wären 40mA zu viel.

    Probiere mal mit einer 5V Quelle über +5V Pin.
    Wenn man BOD (per Fuze) ausschaltet, sollte der ATmega328 trotz 16MHz stabil mit 3,3V laufen. Da würde den Bedarf wieder senken.

    Grüße,

    Alexander
  • Johannes
    Hallo Alexander,
    voller Begeisterung habe ich dein Tutorial gelesen und machte mich sofort voller Tatendrang ans Programmieren.
    Jetzt musste ich voll Enttäuschung feststellen, dass ich trotz deiner letzten vorgestellten Lösung immer noch eine Stromaufnahme von ca. 41mA bei meinem Arduino Nano zu verzeichnen habe.
    Ok, ich arbeite nicht mit 3V sondern mit 6V (auf vin) und besitze auch nur einen Nachbau aus China, aber kann das eine Abweichung von über 40mA ausmachen?
    Ich habe auch schon die Stromaufnahme von "Blink" gemessen und diese liegt bei mir ca. bei 60mA...

    Ich hoffe du weißt Rat...

    Gruß
    Johannes