11/12/2014

Tracking time in your sleep JeeLabs

Computing stuff tied to the physical world

Intro|
Docs|
Forum|
Book|
Shop|
About|
Archives|
RSS Feed
LowPower, Techniques

Tracking time in your sleep

In AVR, Software on Oct 18, 2010 at 00:01

No, this isnt a story about bio-rhythms :)

One of the challenges Ill be up against with Room Nodes is how to keep track of time. The fact is
that an ATmega is extraordinarily power efficient when turned off, and with it a JeeNode under a
few microamps if you get all the little details right. That leads to battery lifetimes which are
essentially only determined by self-discharge!
But there are two problems with power off: 1) you need to be 100% sure that some external event will
pull the ATmega out of this comatose state again, and 2) you can completely lose track of time.
Wireless packets are of no use for power-down mode: the RFM12B consumes many milliamps when
turned on to receive packets. So you cant leave the radio on and expect some external packets to tell
you what time it is.
Meet the watchdog
Fortunately, the ATmega has a watchdog, which runs on an internal oscillator. It isnt quite as
accurate, but itll let you wake up after 16 ms, 32ms, up to 8 seconds. Accuracy isnt such a big
deal for Room Nodes: I dont really need to know the temperature on that strict a schedule. Once
every 4 .. 6 minutes is fine, who cares
http://jeelabs.org/2010/10/18/tracking-time-in-your-sleep/

1/5

11/12/2014

Tracking time in your sleep JeeLabs

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:

Q: What time is it when the pin-change occurred?

A: No idea. Somewhere between the last watchdog and the one which will come next?
IOW, the trouble with the watchdog is that you still dont really track time. You just know
(approximately) what time it is when the watchdog fires again.
If the watchdog fires say every 8 seconds, then all we know at the time of a pin-change interrupt, is
that were somewhere inside that 8s cycle.
We can only get back on track by waiting for that next watchdog again (and what if the pin change
fires a second time?). In the mean time, our best bet is to assume the pin change happened at the very
start of the watchdog cycle. That way we only need to move the clock forward a little once the
watchdog lets us deduce the correct moment. FYI: everything is better than adjusting a clock
backwards (timers firing again, too fast, etc).
Now as I said before, I dont really mind losing track of time to a certain extent. But if were using 8second intervals to get from one important measurement time to the next, i.e. to implement a 1-minute
readout interval, then we basically get an 8-second inaccuracy whenever the PIR motion detector
triggers.
Thats tricky. Motion detection should be reported right away, with an ACK since its such an
important event.
So were somehere inside that 8-second watchdog cycle, and now we want to efficiently go through a
wireless packet send and an ACK cycle? How do you do that? You could set the watchdog to 16 ms
http://jeelabs.org/2010/10/18/tracking-time-in-your-sleep/

2/5

11/12/2014

Tracking time in your sleep JeeLabs

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

Tracking time in your sleep JeeLabs

Flashback Batteries came later

Flashback RFM12B wireless
Flashback Discovering the Arduino
LevelDB, MQTT, and Redis
The LevelDB database
Small Gravity Plug update
In search of a good graph
Animation in the browser
Working with a CSS grid
Responsive CSS layouts
In praise of AngularJS

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

Tracking time in your sleep JeeLabs

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

Alphabetical and Chronological index of weblog posts.

RSS Feed

Tags
AC Mains Analog Arduino Audio CNC DIJN Displays Electronics Events Flashback Graphics
Heating Home

automation HouseMon ISP JavaScript JeeBot JeeDay JeeHub JeeLink

JeeMon JeeRev JeeSMD Linux Metering Musings MuxShield Network Oscilloscope POF Power
RBBB

Reflow RTOS Sensors Solar Teardown Toolkit What-If X10

Theme: DePo Masthead by Derek Powazek

http://jeelabs.org/2010/10/18/tracking-time-in-your-sleep/

5/5