Académique Documents
Professionnel Documents
Culture Documents
Intro|
Docs|
Forum|
Book|
Shop|
About|
Archives|
RSS Feed
LowPower, Techniques
1/5
11/12/2014
Theres a Sleepy class in the Ports library, which manages the watchdog. It can be used to lose time
in a decently accurate way, and will use the slowest watchdog settings it can to get it out of powerdown mode at just about the right time. To not disrupt too many activities, the millis() timer is then
adjusted as if the clock had been running constantly. Great, works pretty well.
Its not enough, though.
As planned for the next implementation, a Room Node needs to sleep one minute between wakeups to
readout some sensors, but it also needs to wake up right away if the motion sensor triggers.
One solution would be to wake up every 100 ms or so, and check the PIR motion sensor to see
whether it changes. Not perfect, but a 0.1s delay is not the end of the world. Whats worse though is
that this node will now wake up 14,400 times per day, just to check a pin which occasionally might
change. This sort of polling is bound to waste some power.
Meet the pin-change interrupt
This is where pin-change interrupts come in, They allow going into full power-down, and then getting
woken up by a change on any of a specified set of pins. Which is perfect, right?
Eh not so fast:
2/5
11/12/2014
and then start the receiver and power down. The reception of an ACK or the watchdog will get us
back, right? This way we dont spend too much time waiting for an ack with the receiver turned on,
guzzling electrons.
The trouble is that the watchdog is not available at this point: we still want to let that original 8second cycle complete to get our knowledge of time back. Remember that the watchdog was started to
get us back out in 8 seconds, but that it got pre-empted by a pin-change.
Let me try an analogy: the watchdog is like throwing a ball straight up into the air and going to sleep,
in the knowledge that the ball will hit us and wake us up a known amount of time from now. In itself a
pretty neat trick to keep track of the passage of time, when you dont have a clock. Well, maybe not
for humans
The scenario that messes this up is that something else woke us up before the ball came down. If we
re-use that ball for something else, then we have lost our way to track time. If we let that ball bring us
back into sync, fine, but then itll be unavailable for other timing tasks.
I can think of a couple solutions:
Dribble never use the watchdog for very long periods of time. Keep waking up very
frequently, then an occasional pin-change wont throw us off by much.
Delegate get back on track by asking for an ack which tells us what time it is. This relies on a
central receiving node (which is always on anyway), to tell us how to adjust our clock again.
Fudge it dont use the watchdog timer, but go into idle mode to wait for the ack, and make
that idle period as short as possible perhaps 2 ms. IOW, the ACK has to reach us within 2
milliseconds, and were not dropping into complete powerdown during that time. We might
even get really smart about this and require that the reply come back exactly 1 .. 2 ms after the
send, and then turn off the radio for 1 ms, before turning it on for 1 ms. Sounds crazy, until you
realize that 1 ms of radio time uses as much energy as 5 seconds of power down time which
adds up over a year! This is a bit like what TDMA does, BTW.
All three options look practical enough to consider. Dribbling uses slightly more power, but probably
not that much. Delegation requires a central node which plays along and replies with an informative
ack (but longer packets take longer to receive, oops!). Fudging it means the ATmega will be in idle
mode a millisec or two, which is perhaps not that wasteful (I havent done the math on that yet).
So there you go. Low power stuff isnt always trivial, once you start pushing for the real gains
View 8 Comments
Before Scheduling multiple tasks Oct 17, 2010
AfterRoom Node next steps Oct 19, 2010
Recent Posts
Getting started
Thank you
Its been a year
Wrapping up
Flashback Anatomy of a transmission
Flashback Dive Into JeeNodes
Flashback Easy Electrons
Flashback Ports and I2C in JeeLib
Flashback The first JeeNode PCB
http://jeelabs.org/2010/10/18/tracking-time-in-your-sleep/
3/5
11/12/2014
Archives
November 2014
October 2014
October 2013
September 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
June 2011
May 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
http://jeelabs.org/2010/10/18/tracking-time-in-your-sleep/
4/5
11/12/2014
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
ARM
AVR
Book
Hardware
Linux
Musings
News
About
"Jee" stands for JC's Environmental Electronics. This blog is maintained by Jean-Claude
Wippler.
Search for:
Search
Tags
AC Mains Analog Arduino Audio CNC DIJN Displays Electronics Events Flashback Graphics
Heating Home
JeeMon JeeRev JeeSMD Linux Metering Musings MuxShield Network Oscilloscope POF Power
RBBB
http://jeelabs.org/2010/10/18/tracking-time-in-your-sleep/
5/5