I'm currently waiting for some PCB's to arrive for a TH Mote which I've based on the RFM69CW radio and the CR2032 battery, thus significantly reducing size over the Tino (
https://lowpowerlab.com/forum/index.php/topic,1269.0.html). I've also adopted Tom's more attractive round design (
https://lowpowerlab.com/forum/index.php/topic,1254.0.html), coming out at a 11mm radius - it looks a lot smaller than both the Tino and Tom's TH Mote.
However the CR2032 gives me only around 1/3rd of the capacity of the CR2450 I had used in the Tino. And I still want to solder the battery on for tightest form factor. Finally I did't want to add a tpl5010 or the am1805 because I want to create many of these and I want my home "manufacturing process" to have a good yield.
In short better battery life than with listen mode alone was needed. I still wanted some of the benefits of listen mode: interactive access to the mote when needed, synchronized collision free updates and no updates unless server active.
Kobuki had an idea some time back (
https://lowpowerlab.com/forum/index.php/topic,1325.0.html) which I had previously prototyped but not yet in deployment. It occurred to me that this method could be combined with listen mode (
https://lowpowerlab.com/forum/index.php/topic,1136.0.html) to yield a very efficient mode of operation while mostly preserving my requirements:
When the gateway sends the wakeup burst it includes a sleep time in the burst command. Nodes send their update and then sleep for the specified time using Kobuki's method. When they wake from sleep they switch on listen mode again - just in time for the next wakeup burst from the gateway.
As you can see this preserves the synchronized updates. When the gateway is down motes don't try to send anything (although they will fall back to the more expensive regular listen mode during that period). And when I'm about to configure/update my motes I just change the sleep interval to 0 seconds in my crontab to switch to normal listen mode at next wakeup burst.
I measure current consumption of 1.2uA during sleep - which is probably as good as it gets without additional HW. Add maybe 500nA for the actual updates (this could still be optimized) and you end up with around 15mAh per year. Given that the CR2032 has a capacity of 225mAh this satisfies my requirement of multi-year battery life.
Tom has my code so with some luck this will appear (together with the noise robustness changes) in his library at some point.
Joe