Hi guys,

Starting to look at the docs one concern I have is that it seems like the ONLY sleep mode available for using "Pin Change" is IDLE (i.e. can't use Power-save, Standby etc modes).  Is this your interpretation of Table 9-1 of ATmega168 data sheet?

The issue here is that based on the current measurements I've been taking on my Arduino Pro in various sleeps modes, that the life time of a 9V battery to power the door open/closed detector would only be able 1 DAY using IDLE mode (i.e. it would jump to 20 days if I can sleep to POWERDOWN mode).

Table (I measured this using the 9V battery when the unit was in each of the modes)


thanks

PS.  I'd really want my remote battery based door detector units to last 6 months, but based on the readings above it doesn't seem you could ever do this with an Arduino anyway (i.e. still chews 1mA even when in powerdown mode).  Might raise a separate question re this rather than diverting focus on this thread.

thanks Ben - sounds like good advice - I'll google & read up on "pin change interrupts" - was there a particular good example or reference you have in mind (just in you have one you recommend)

Thanks again

Re  the 2nd problem suggestion, thanks, I'll look into this.  My feeling is you're probably right about whats going on here.

Re the 1st problem you refer to, I don't really see this as a problem as the interrupt technique works, but just suffers from a probable race condition I think. Make any sense?

 A pin change interrupt will give you what you want (an interrupt from low-to-high and an interrupt from high-to-low).

Thanks. Do you understand specifically what the issue I'm having and how this will fix it?  The penny hasn't dropped for me yet still  

thanks guys - an update

a) re triggering using Mode = LOW,  the only issue for me here is that I'm using a Reed Switch to send door open/close.  So I want to wake the arduino up in both the cases when the door has just been open, or just been closed.  So I'm just using the reed switch to help set the interrupt pin to either high or low and using this.  (in my latest tests I was actually using mode = CHANGE, as opposed to RISING too, but still with the same issue).  So I'm not sure how I'd use the trigger on LOW (i.e. would miss out on the "door open" event)

b) re taking out the detachInterrupt - I took this out but this didn't help - I can still simulate the issue - in fact I'm not sure what happens in this case - what happens if there's another interrupt come whilst you are still processing the previous interrupt?  (i.e. the unit hasn't been put back into sleep yet) - does it get ignored or buffered?

c) re putting in the attachInterrupt in setup() - tried this but this didn't help - I can still simulate the issue


So for the moment the 2 things that come to mind for the issue are:

i) the period where the interrupt wasn't enabled (so there was a blind spot) - but testing with the detachInterrupt taken seems to have shown this isn't the issue (but assuming the interrupts buffer here perhaps?)

ii) the other point I note is that in the code is that the actual status of the door is read several lines after the interrupt occurs - so it's possible that the door status changed between the interrupt being received and then the code reading the state - but than if the status was read later, then you would think it would be more likely to be correct if it was the last interrupt in a string of them in succession no... so this doesn't explain it either


So overall I'm still not really sure how the incorrect state occurs  :-?

If there is a true blind spot picking up state changes (from idea i) above) then that might imply I can never really fix it.  So in this case would the only work around be to have a separate watchdog timer come in on the 2nd interrupt, so every so often a double check on the state is performed perhaps?  Don't really want to have to go to the trouble of implementing this for this edge case, but it would be interesting to know if this was the only real way to make the design really robust.

Re "I would put the call to attachInterrupt in the setup function and leave it at that (no detach is needed). The handler could be an empty function."

Thanks, but how would this solve the issue I have?  Don't quite follow.

EDIT: I see you referred to leaving the interrupt in place the whole time. I'll try but i think i had other side effects when I was trying it this way

this is the problem I'm trying to fix - I just wanted to make sure I made it clear the code is working fine except the use case when I toggle the button on/off very fast (where in this situation the issue appears)

umm, but the code works fine for me - the only issue I had was (being pedantic) if I press the button on and off really quickly you can end up with the last message not reflecting the final state of the button.  I assume this is due to perhaps the final button state change occurring in the short interval before the interrupt was enabled again...

So my question was if I just wanted to avoid this how to best do this?

Hi,

Re the code below, I'm finding that if I continually press the button I have setup to trigger the interrupt with code as it is the program kind of locks up after it goes into sleep.

BUT if I move the "detachInterrupt(0);" statement out of the call back function, and just put it at the bottom of the enterSleep() method than things seems to work robustly.

Anyone have any ideas why this is?

Code:

#include <avr/sleep.h>

int wakePin = 2;                 // pin used for waking up
int ledPin =  13;
int sleepStatus = 0;             // variable to store a request for sleep
int count = 0;                   // counter

void setup()
{
  pinMode(wakePin, INPUT);
  pinMode(ledPin, OUTPUT);  
  Serial.begin(9600);
}

void wakeUpNow()        // here the interrupt is handled after wakeup
{
   detachInterrupt(0);      // disables interrupt 0 on pin 2 so the
}


void sleepNow()         // here we put the arduino to sleep
{
    Serial.println("sleepNow");
    attachInterrupt(0,wakeUpNow, RISING); // use interrupt 0 (pin 2) and run function
    delay(100);    
    set_sleep_mode(SLEEP_MODE_PWR_DOWN);   // sleep mode is set here
    sleep_enable();          // enables the sleep bit in the mcucr register
    sleep_mode();            // here the device is actually put to sleep!!
                             // THE PROGRAM CONTINUES FROM HERE AFTER WAKING UP

    sleep_disable();         // first thing after waking from sleep:
}

void loop()
{
  // display information about the counter
  digitalWrite(ledPin, HIGH);
  Serial.print("Awake for ");
  Serial.print(count);
  Serial.println("sec");
  count++;
  delay(1000);                           // waits for a second
  digitalWrite(ledPin, LOW);

  // check if it should go to sleep because of time
  if (count >= 5) {
      
      Serial.println("Timer: Entering Sleep mode");
      delay(100);     // this delay is needed, the sleep
                      //function will provoke a Serial error otherwise!!
      
      count = 0;
      sleepNow();     // sleep function called here
  }
}

Hi,

This code works, however if I press the on/off switch that triggers the interrupt quickly, I can end up with the final status being sent incorrect.  Any advice re how to avoid double-bounce here, or more correctly how to ensure that the last message that goes out does truely reflect correct start of button (i.e. on or off)...

Code:

#include <WString.h>
#include <VirtualWire.h>
#include <avr/sleep.h>

#define REED_SWITCH  2
#define REED_SWITCH_INTERRUPT  0
#define LED 13
#define RF_POWER_PIN 3

void setup()
{
    // Debugging
    Serial.begin(9600);        // Debugging only

    // Pin Modes
    pinMode(REED_SWITCH, INPUT);
    pinMode(LED, OUTPUT);
    pinMode(RF_POWER_PIN, OUTPUT);

    // VirtualWire Setup
    vw_set_ptt_inverted(true);   // Required for DR3100
    vw_setup(2000);               // Bits per sec
}

void updateBase() {
    digitalWrite(RF_POWER_PIN, true);
  
    int val = digitalRead(REED_SWITCH);
    
    String door_status;
    if (val == HIGH) {
      door_status = "OPEN";
    } else {
      door_status = "CLOSED";
    }
    
    String msgPre = "The door is now: ";

    msgPre.append(door_status);
    
    char *msg = door_status.getChars();
    
    vw_send((uint8_t *)msg, strlen(msg));
    vw_wait_tx(); // Wait until the whole message is gone
    
    digitalWrite(RF_POWER_PIN, false);
}

void loop()
{
    sleepNow();
    delay (10);
    updateBase();
}

void wakeUpNow()        // here the interrupt is handled after wakeup
{
}

void sleepNow()         // here we put the arduino to sleep
{
    Serial.println("sleepNow");
    set_sleep_mode(SLEEP_MODE_PWR_DOWN);   // sleep mode is set here

    sleep_enable();          // enables the sleep bit in the mcucr register
                             // so sleep is possible. just a safety pin

    setupInterrupt();

    sleep_mode();            // here the device is actually put to sleep!!
                             // THE PROGRAM CONTINUES FROM HERE AFTER WAKING UP

    sleep_disable();         // first thing after waking from sleep:
                             // disable sleep...

    detachInterrupt(REED_SWITCH_INTERRUPT);      // disables interrupt 0 on pin 2 so the
                             // wakeUpNow code will not be executed
                             // during normal running time.

}

void setupInterrupt() {
  attachInterrupt(REED_SWITCH_INTERRUPT ,wakeUpNow, CHANGE); // use interrupt 0 (pin 2) and run function
                                       // wakeUpNow when pin 2 gets LOW
}

thanks - I really like the "look into powering your RF transmitter from an Arduino digital output"...great idea

Hi,

Any recommendation how to keep to a very minimum usage of battery for an Arduino board that will be powered by battery and monitoring door open/closed status (use of magnetic reed switch for detector & RF transmitter using virtualwire library).

For example:
a) should I use polling or interrupt (I assume an interrupt would be better)?
b) if using an interrupt what best to do in the main loop?  e.g. put a long delay? nothing?
c) anything else I should do in the setup() method to help reduce power usage?  

Some notes:
i) I was assuming I'd use a 9V batery
ii) I'm using the "Arduino Pro 328 - 5V/16MHz DEV-09219" http://www.littlebirdelectronics.com/products/Arduino-Pro-328-%252d-5V%7B47%7D16MHz.html.  This seemed to be the cheapest board for what I need (?)

thanks

for the remote XBee do I need the "XBee Explorer Regulated"?  http://www.littlebirdelectronics.com/products/XBee-Explorer-Regulated.html.  Or can I just plug say 3 x AA batteries directly into the XBee itself?  

Thanks again - is there something easier than the xbee by the way?  Or is this the only real obvious choice for what I'm doing?

Have you used a multimeter to see just how much current the arduino is drawing?

yes - see my original post at the top

What is the microcontroller doing in this application?

Well I'm new to this stuff. I started out looking at X10 devices.  The sensors seemed OK but I couldn't find the display panel I wanted.  I stumbled across Arduino and thought they be good to let me customize my display of things.  Then rather than trying to get an X10 RF receiver interfaced to an Arduino I thought just to use Arduinos for the sensors too. :-/

A stand-alone XBee could easily give a few years on 2-AA cells.

Wow thats great if it's an option  ;D  I had come across an XBee as just a way to get wireless comms from one Arduino to another.  Because they were a bit expensive I've actually been using the cheap RF transmitter & receivers that are available.  I've got a basic reed switch setup from Arduino to Arduino using these, but my issue I'm seeing now is the lifetime of the batteries to power the remove sensor.

Do you know off hand which is the cheapest XBee unit I'd need to be able to use it to send door open/close messages back to a base Arduino (with a mounted XBee), noting I'm planning to have several (< 10) monitoring points transmitting back to the base.  I see there are quite a few options for them at: http://www.sparkfun.com/commerce/categories.php?c=111&sidx=retail_price&sdir=ASC&sipp=100&x=0&y=8