Author Topic: OAK low power Sleep  (Read 14947 times)

defragster

  • Sr. Member
  • ****
  • Posts: 467
OAK low power Sleep
« on: May 29, 2015, 09:10:47 pm »
Just saw a note on Sparkfun about Low power and seemed like a good comparison with implementation details to work with on the ESP platform.

Quote
In deep-sleep mode I can get the ESP8266 Thing down to about 77µA.

https://www.sparkfun.com/news/1842

Question to Digistump: Does the OAK require a wire to have it wake from Sleep state?

Quote
To wake itself up, the ESP8266 uses the XPD pin to trigger its reset line, so those two pins need to be connected together.

Also of interest in this battery operated usage case will be examples reading the voltage level coming into the system.
« Last Edit: May 30, 2015, 03:52:25 pm by defragster »

BobC

  • Newbie
  • *
  • Posts: 12
Re: OAK low power Sleep
« Reply #1 on: May 30, 2015, 02:24:10 am »
To maximize battery life, I plan to have my Oak in deep-sleep as much as possible.  The ESP8266 "see" a pulse on its hardware reset input to come out of deep-sleep.  Which means every "wakeable" interrupt source must somehow get a pulse onto the Reset line.

The first interrupt source will be an RTC timer event, to have the chip wake up every so often (1x/hr)  to check its state, mainly its temperature (onboard sensor) and battery voltage.  These both require ADC use, and the ADC works only when the radio is off (or, at least a zero power output level).  The RTC timer output (XPD) pin can be connected to Reset to make this scenario work.

The second interrupt source will be a simple switch, which should cause a reset whenever it changes state (open->closed or closed->open).  Now, most of the ESP8266 GPIO pins can be configured to generate an interrupt on edge transitions, but these don't work in the deep-sleep state.  But they do work in all other power states, from light-sleep to full power.

My desire to be in deep-sleep is simple: I want to get multi-year life from a disposable lithium battery.  Going with rechargeables (and their high self-discharge rate) means adding a solar charger, which multiplies the cost of the node.

But deep-sleep is just one of several ways to maximize battery life.  The other ways all involve minimizing power use while awake, such as by minimizing wake time and minimizing power use by the RF circuitry.

When the node wakes from the RTC timer, it will normally see temperature and battery voltage are OK, restart the RTC timer, and return to deep-sleep.

A message will be sent under three conditions:
1. Whenever the switch changes state.
2. When either the temperature or battery voltage are out of their normal ranges.
3. When it is time to send a "Still here!" packet (1x/day).

Node design will include the following power management features:

1. Save RF and network state in RTC SRAM, so the network doesn't need to be reinitialized at each wakeup.

Avoiding network reinitialization requires work at several levels:
a) The node must have a persistent IP address (either statically assigned, or an infinite DHCP lease, or some other equivalent means).
b) The protocols used in the node must have no timeouts.   Most session-oriented and connection-oriented protocols have timeouts (though some can be disabled), so otherwise the protocols used must be connectionless (UDP+DTLS?).
c) No channel-hopping!

Using a connectionless protocol may require that, after transmission, the node stay awake for an ACK packet before returning to sleep.  This packet may also include commands, such as "Stay awake for a firmware update!".

2. Control transmitter power and use.

It appears the next version of the Espressif SDK includes at least basic support for RF transmit power control.  I'm not sure if this is explicit RF amplifier power management, and/or forcing the RF encoding.  Either way, the goal will be to communicate using the least energy per bit.

Part of node installation will be reducing transmit power to the minimum needed to ensure robust communication.

3. Write efficient code.

While this seems obvious in general,  there do appear to be some gotchas:  Folks on the ESP8266 Community Forum have reported seeing some anomalous power spikes when using various Espressif API functions.  The spikes appear to be a mix of flash writes and unexpected transmissions (possible reinitializations).  So it wil be important not only to avoid intentional power waste in the code we write, but to also avoid it in other code.

4. Disable/remove the Power LED (if present).


Given all the above, and assuming there are solutions for the software-related items, the one thing I haven't yet solved is creating a circuit for the switch to generate a reset pulse.  The circuit must use extremely low power when nothing is changing, and must present a high impedance to the Reset pin when not generating a pulse (so it won't affect the pulse from the RTC).

Sigh.

For the moment, it may be simpler to stay in light-sleep (no need to save/restore to/from RTC SRAM, no need to Reset) and use bigger/more batteries.

defragster

  • Sr. Member
  • ****
  • Posts: 467
Re: OAK low power Sleep
« Reply #2 on: May 30, 2015, 03:45:18 pm »
Good info Bob, did you sign up for the Beta?

This is all so promising and nebulous waiting to get the first one.  So many cheap lesser modules out there and the huzzah and thing shipping with minor repackaging with different foci and access to the current builds of general evolving software.

I'm focused on the lights as they are already outdoor packaged.  Will need to keep power usage down, but having free daily input of a hundred or more mAh from the sun and installed PIR good too. Could wire up an AtTiny to watch the PIR 24/7 for a few microAh and decide when to wake the OAK to broadcast - but if the others are sleeping that might limit the utility.
« Last Edit: May 30, 2015, 03:51:07 pm by defragster »

BobC

  • Newbie
  • *
  • Posts: 12
Re: OAK low power Sleep
« Reply #3 on: May 30, 2015, 11:00:36 pm »
No, I'm not in the beta.  But my code is small enough that it will easily fit in my ESP-01 and ESP-07 boards.  Ideally, if Digistump does a release in parallel with the Beta, I may be able to trim parts of it enough to fit in the available RAM.

digistump

  • Administrator
  • Hero Member
  • *****
  • Posts: 1465
Re: OAK low power Sleep
« Reply #4 on: June 01, 2015, 11:56:44 am »
A few notes on power usage considerations we've taken:

The LEDs can but disconnected by cutting the solder jumpers on the bottom of the Oak

RESET and WAKE (GPIO16) can be joined together by bridging the solder jumper on the bottom of the Oak - this allows for RTC based wakeups.

defragster

  • Sr. Member
  • ****
  • Posts: 467
Re: OAK low power Sleep
« Reply #5 on: June 01, 2015, 10:11:30 pm »
Cool - based on the Pro I expected to be able to drop the LED, having the jumper to Wake on RTC simplifies that issue! 

Would be cool if the LED had a pad to solder to another fixed IO point for program control ([ 8)] and if LED not cut you could read that pin and tell when the module was powered [ ::)] )

dougal

  • Sr. Member
  • ****
  • Posts: 289
Re: OAK low power Sleep
« Reply #6 on: June 02, 2015, 07:58:48 am »
...and if LED not cut you could read that pin and tell when the module was powered [ ::)] )

Thanks. Now my brain hurts, you goofball. :)

defragster

  • Sr. Member
  • ****
  • Posts: 467
Re: OAK low power Sleep
« Reply #7 on: June 02, 2015, 02:02:00 pm »
BrainFreeze!  Hey at least I know this thing is ON!  Good to see you in the same thread again @dougal - did you sign up for OAK?

It may be too late for Erik to edit the PCB - but it occurred to me that cutting the LED would be an easier decision if there was a way to use that LED for BLINK or other HeartBeat feedback when it was powered and active.  Then I had to think what the worst case would be if you failed to cut the LED but soldered the jumper - VOLTS all over that pin!

dougal

  • Sr. Member
  • ****
  • Posts: 289
Re: OAK low power Sleep
« Reply #8 on: June 02, 2015, 03:36:23 pm »
Yeah, I've got a trio ordered from the Kickstarter.

There was a stretch of time where I didn't have time for electronics fun. I was just really busy with work, then we bought a new house and moved, and spent a couple of months fixing up the old house to get it ready for sale. Oh, and in the middle of all that, I got laid off, spent a couple of months looking for a new job. So yeah, I had been quiet here for a while.

I've been working on-and-off on a little project that I've currently prototyped with an Adafruit Pro Trinket, but my end goal is to move it to a Digispark. I've just been having trouble getting IRLib to transmit

defragster

  • Sr. Member
  • ****
  • Posts: 467
Re: OAK low power Sleep
« Reply #9 on: June 08, 2015, 01:24:39 am »
I went nuts again -like with the PRO. This time a 10 pack - then asked about beta so signed up for that.  If the Acorns were in less than a 10 pack I'd probably get some of those.  Thinking of building a Stealth OAK LiPo[3 cell NiMh] power board, still looking for Acorn layout details.  Not sure if its pins are oriented to match OAK/PRO ordering - or if they route from a standard ESP type layout to minimize changing the reference design.  My first time with EAGLE so hoping for easy, just need Rx/Tx/VCC/GND and a couple I/O pins minimum. Leave the antenna end clear

BobC

  • Newbie
  • *
  • Posts: 12
Re: OAK low power Sleep
« Reply #10 on: August 14, 2015, 06:14:19 am »
To understand the available low power modes, it's time to look at ESP8266EX power use in detail.  Which means looking at the datasheet, specifically Table 4 in Section 2.3 on Page 13.

First, it is important to realize the numbers in Table 4 should be viewed as "best case" values.  The Oak values will likely be higher (possibly MUCH higher) for several reasons, including PCB layout choices and the overall circuit design (what loads are present on which ESP8266EX pins).

In particular, I would not expect to ever see a 10 ua current draw when in Deep Sleep.  The 5V-to-3.3V LDO linear regulator will have some additional minimal current drain even if the ESP8266 itself is drawing only 10 ua.  And a power LED could draw 20 ma, or 2000 times more than the processor.  So assuming you disconnect the LED, and tristate all ESP8266EX GPIO pins (except the RTC pin), I'd expect you may be able to get down close to 100 ua (0.1 ma) absolute minimum power drain (perhaps a bit less).

Also, Deep Sleep is a PITA, since it requires a full reboot to recover.  Which means when the CPU wakes, it has no idea what it was doing just prior to going to sleep.  The work-around is to save the program state prior to entering Deep Sleep, and restoring it upon waking.  The RTC (Real-Time Clock) module (which stays awake during Deep Sleep) appears to have some SRAM in it we can use for this purpose.

Before looking at the other low-power modes, it is important to know why and when they are needed.  If you are operating from a wall wart, the wall wart itself could be wasting a fair amount of power anyway, so restricting the power use of a mains-powered Oak may not buy you much overall power savings unless you have an extremely efficient wall wart.

That leaves non-mains (battery) power as the main reason to try to minimize Oak power use.  But before even thinking about using any particular sleep mode, it is critically important that the application itself isn't wasting any power whatsoever.  Let's look at Table 4 again.  The biggest use of power is transmitting (up to 170 ma, which again is not a worst-case value), so it would make great sense to bend over backwards to minimize the transmissions that are needed.  Basically, the more you transmit, the deeper and longer you'll have to sleep to get good battery life.

But minimizing transmission is tough:  When a node boots, it must do a few handshakes with the AP (WiFi Access Point) before it is allowed to send data to the local network.  These handshakes involve basic access (SSID and Password), configuring encryption, using DHCP to get an IP address lease, and there may be more I'm not remembering at the moment.

So a good transmission conservation goal is to prevent having to repeat any part of the boot-up handshake when an Oak wakes up to send data.  Fortunately, there are ways to do this!  But it isn't well documented, and I haven't yet done it myself with any of my ESP boards.

Next comes sending the data itself.  Pretty much the entire Internet uses TCP/IP, which is a Good Thing, since TCP provides "guaranteed delivery" (every packet sent is eventually received).  But that guarantee comes with some connection timeouts and overhead, which our battery-powered Oak nodes should avoid.  Which means using UDP.  But that has its own problems: UDP is a "connectionless" protocol that has no packet delivery guarantees, so we must add our own minimal ACK protocol to let the node know it's data has been received and it can go back to sleep.

But for Home Automation and Security, we'd want our protocol to do a bit more than just "ACK".  Since WiFi encryption isn't all that secure, we should consider adding our own encryption layer (Highly Recommended!).  And the protocol should also protect against MITM (Man In The Middle) attacks as well as Packet Injection attacks.  Fortunately, once the link is encrypted, adding a pseudo-random packet serial number can provide these safeguards.  (I've just described some of the key features in the Thread and CoAP protocols, which both use DTLS.)

The last thing the protocol must do is support "NAK", which means the recipient got a packet, but it may have been corrupted in some way (possibly due to an attack), so a NAK tells the sender to do a retry. After sending a packet, the sending node must wait some pre-determined time for the ACK or NAK to arrive.  This wait is done in Receive mode, which uses much less power than Transmit mode (~60 ma, vs ~200 ma).

Whew!  Clearly, the CPU is going to be busy.  Fortunately, when the radio is off ("Modem Sleep") the CPU is still running, and it uses "only" 15ma.  So when there is lots of computation to do, it is best to do it with the radio off.  Or, conversely, turn the radio on only when needed, but be sure to wait the 3ms radio wakeup/warmup time before sending data.

OK, now we can discuss a simple but realistic minimal battery-powered Oak scenario:  A gate monitor.  The only thing connected to the Oak is a switch that opens when the gate is opened.  When the gate opens, the Oak wakes up to send a single packet, then waits up to 1 second for a reply. If the gate isn't opened for 1 hour, the Oak will send an "I'm Still Here!" packet and wait for a reply.  In either case, when the ACK is received, the Oak immediately goes back to "sleep" (the kind of sleep isn't yet defined).

Yes, the above description is just a sketch, and omits many important things: How the switch can wake up the Oak, what to do when no reply arrives, what to do if a NAK arrives, what to do when the gate closes (or if it doesn't).  These are left as exercises for the Reader.  ;^)

One important detail must be defined now:  The power source.  To keep things as simple as possible, let's use 3 AA alkaline batteries in series, connected to the USB power pins.  Any other power source would be more complex and require its own analysis.  Our batteries will be Eveready Energizer AA, which have this datasheet and a nominal 2500 mah rating.

Let's now pick a "typical day" for our gate: If nothing at all happens, it will wake up 24 times to send "I'm Here!" packets.  Let's say the gate is opened 4 times each day.  We can view each "open" event as an interruption of the one hour "I'm Here!" packet timeout cycle.  Skipping the basic statistics,  this means our typical day will see 26 packets sent.  And let's say our transmissions never fail, and that we always get an ACK 100 ms after the packet is sent.

So when the Oak wakes (either due to the gate switch or the timeout), it will power on the radio, and during the 3ms warmup period it will prepare the packet to be sent.  Then the packet will be transmitted, which may take 3 ms.  Then the Oak listens for the reply, which it sees 100 ms later.  After verifying the ACK, the Oak powers off the radio and goes back to "sleep".

How long does this take?  Assuming the CPU wakes in zero time (which may not be the case), we have 3ms radio power up, then 3 ms transmit, then 100 ms listening.  We'll also assume it takes zero time to go to "sleep".  That's a total of 106 ms awake.  This happens 26 times a day (on average, for our scenario), which is 16 * 106 ms = 2756 ms.  That's less than 3 seconds awake for the entire day to monitor a gate!  Not bad.

But how much power does the awake time consume?

We need to calculate this from the perspective of the battery, not the ESP8266EX.  It is important to understand that the batteries start out at 1.5v*3 = 4.5v, and that value will decrease until the LDO cuts out at about 3.4v.  But how do we account for the LDO that sits between the batteries and the ESP8266EX?  I don't want to get into the details of linear regulator operation here, but suffice it to say that the LDO "wastes" the difference between the battery voltage and 3.3v, meaning the current is the same at the battery.

So, each wakeup has 3ms @ 60 ma (radio warmup, packet prep), 3 ms @ 200 ma (send packet), 100 ms @ 60 ma (wait for reply).  Our average current consumption during our 106 ms awake time is: (3*60 + 3*170 + 100 * 60)/106 = 63 ma.  Since we're measuring our battery capacity in mah (milliamp-hours), let's see how much of our battery we're consuming each day while awake: It's simply  63 ma * 106 ms = 6678 mas (milliamp-seconds), which we divide by 3600 to get 1.855 mah.

Now, let's figure out how much current we'd consume for each of our 3 sleep modes for the rest of the day.  First, how long will the Oak be sleeping each day?  That would be: 24 hours - awake time = 24 hours - 2756 ms = 23 hours, 59 minutes, and 57.244 seconds, or 23.9992 hours.  To keep it simple, we'll just round to an even 24 hours.  (No, that's not cheating!)

Deep Sleep: 100 ua * 24 hrs = 2400 uah = 2.4 mah
Light Sleep:  1 ma * 24 hrs = 24 mah
Modem Sleep: 15 ma * 24 hrs = 360mah

Notice that even Deep Sleep mode uses more power than the awake power. That's not to say that Deep Sleep is expensive, but rather it says that we have done a good job minimizing the power used while awake.

The next step is to figure out our total daily current consumption for each of the three scenarios. We just add the awake mah to the sleep mah for each sleep mode:

Deep Sleep = 1.855 mah + 2.4 mah = 4.255 mah/day
Light Sleep = 1.855 mah + 24 mah = 25.855 mah/day
Modem Sleep  = 1.855 mah + 360 mah = 361.855 mah/day

Now, let's figure out our battery life for each of the three sleep scenarios.  The "right" way to do this is to use the average current for each scenario and follow the "constant current" discharge curve in the battery datasheet.  But I'm up way past my bedtime, and we'll just assume a fixed battery capacity of 2500 mah.  Since the batteries are in series, the current is common to all three batteries, so it's still 2500 mah for the set (but at a starting voltage of 4.5 v instead of 1.5 v).

For each of our scenarios, we'll divide 2500 by the daily mah consumed to get the battery life in days:

Deep Sleep = 2500 mah / 4.255 mah/day = 588 days (Over a year and a half!)
Light Sleep = 2500 mah / 25.855 mah/day = 97 days (About 3 months)
Modem Sleep  = 2500 mah / 361.855 mah/day = 7 days (A week)

And, there, finally, at long last, you have it.  The effect of sleep mode on battery life for the absolute simplest-but-realistic Oak application I can think of.  (It gets worse, perhaps much worse, if your Oak needs to do anything remotely intelligent.)

What have we learned?  Consuming 3 batteries each week adds up, so even if we turn off the radio (but keep the CPU awake), we'll still want to use a wall wart.  Which in turn means that all battery-operated Oak applications should plan on at least using Light Sleep, which should be easy to program (SRAM stays powered). 

Now. imagine that you had 10 Oaks running on batteries.  Then even Light Sleep would go through 120 AA batteries each year!

Using Deep Sleep will take some work to save persistent values before sleeping (sincs SRAM is powered off), and restoring them upon waking.  And our 10 Oaks would  use just 20 AA batteries in a year.

Bottom line?  Deep Sleep is a Win.  We need the Oak to fully support it, including a safe interface to the RTC SRAM.  Otherwise, the Oak is truly useful ONLY when plugged in, or when connected to a battery system that costs much more than the Oak itself.

Enjoy!
« Last Edit: August 14, 2015, 07:42:29 am by BobC »

BobC

  • Newbie
  • *
  • Posts: 12
Re: OAK low power Sleep
« Reply #11 on: August 14, 2015, 07:46:28 pm »
I was really depressed after finishing that last post, seeing just how much work will be needed to make the Oak more battery-friendly (eliminate WiFi handshakes, eliminate TCP, and correctly implement the Deep Sleep save/restore operation).  I'm thinking it may not be worth it at this point, so for now I will plan to tether all my Oaks to wall warts. (Or perhaps put them inside wall warts!  Coooool.)  This will let me focus on applications rather than infrastructure (let Particle handle that).

But I still need battery-operated nodes.  I decided to look around for other non-ESP but Oak-like boards and SoCs that may be more battery-friendly.  (Basically, an ARM CPU paired with a radio.)

I stumbled across the Nordic nRF51422 chip, which is quite an amazing gizmo, supporting not only BTLE, but also the ANT protocol.  It's maximum power consumption during transmit is under 20ma, making it a natural fit for battery operation.

BTLE also supports mesh networking!  Well, almost: It will soon, when the BT specification is updated.  But working test implementations are available for the nRF51422.  Though I still think 6LowPAN is the better long-term solution, my phone already contains BTLE and ANT radios, which means I can get more development and testing done sooner.  And I have a bunch of Garmin ANT stuff, so integrating that into my home automation/security system could be fun.

The free/open SDK (toolchain and libraries) for the nRF51422 is not exactly polished, but should be good enough for some basic tinkering.

Then I found this board.  Bought a few to see if they are usable.  There is a similar board on Tindie, but it costs $25.  And there are less expensive boards that use the version of the chip without ANT support.

An early project could be to combine one of these boards with an Oak to build a tiny all-protocol solution.  Perhaps create a hub to relay data between each of the protocols.  Hmmm...  Maybe something that will let my BT keyboard also work as a WiFi keyboard!  Hmmm...  My car has a BT hands-free interface, and also a BT ELM327 clone: Putting my car on WiFi for $20 could be cool.

But what I'd really like to see is a better battery-powered solution from Digistump that uses this chip, or something similar from CSR, TI, ST and others.

Digistump's next Kickstarter?
« Last Edit: August 14, 2015, 10:21:44 pm by BobC »

defragster

  • Sr. Member
  • ****
  • Posts: 467
Re: OAK low power Sleep
« Reply #12 on: August 18, 2015, 12:48:24 am »
Interesting numbers Bob - if not a good showing for disposable batteries.

The voltages don't hit a sweet spot with rechargeable batteries either - for the voltage - except maybe four NiMh's and then it would be a (bi-)monthly item to swap the pack.  A pair of LiPo's might last that long too - but being over 6.4v then means more regulator waste.  And with NiMh's for 10 devices comes 40 cells and extras for swapping to recharge - either 10 more sets - or less if you do partial swaps every 1 or 2 weeks - but ideally they'd last 10-20 years.  If the OAK can monitor the voltage they could show when they are due for a recharge.

I've seen a couple solar charging lights ($24-30) but they run one 18650 LiPo or three NiMh's - but that works better with an Acorn and custom regulator setup to run at a lower ~3.3 volts to VCC rather than the 4.5v to VIN. And with a PIR it wouldn't waste energy to the lights (like some that stay on each night until the battery quits) - and would provide motion data if you can hack into it okay and also run the ESP8266 while the lights are off without disturbing the charge circuit.  I got a couple of these 3*NiMh units already and ordered more Acorns than OAK's hoping to get that to work - and have enough sun each day to keep reserve in the batteries - with light sleep.

BobC

  • Newbie
  • *
  • Posts: 12
Re: OAK low power Sleep
« Reply #13 on: August 18, 2015, 11:49:44 pm »
Yeah, for batteries, three 1.5v alkalines is the way to go.  The problem with 4 NiMH is that the cutoff voltage (3.4v) would be below the individual cell discharge limit of 1v (3.4/4 = 0.85v).  Alkalines can go this low, but I'm not sure if the Oak LDO is rated for 6V in.  LiPo also has the too high / too low problem.

The Oak LDO input window (what we know of it so far) seems too narrow for anything but alkalines.  Fortunately, the Oak has a 3.3v input power pin, so the LDO can be bypassed (no need for an Acorn if you already have an Oak).

I really like 18650 cells, but they have less capacity than 3 alkalines, and good ones ("protected") cost almost as much as an Oak.

I think the best overall non-mains Oak power solution may be to piggy-back the Oak on a larger system.  For example, I have a pair of solar-powered 60-LED security flood lights that I got on sale for $30 each.  Putting an Oak in each of them lets me turn them into wireless motion alarm sensors.  The LEDs are run directly from the battery, which means the Oak would need a switching regulator, which can be had for $5.

I was thinking my gate could also use a remote-controlled latch, so more power would be needed out there.  Which means it probably will also get a security flood light (when they next go on sale).

defragster

  • Sr. Member
  • ****
  • Posts: 467
Re: OAK low power Sleep
« Reply #14 on: August 19, 2015, 01:48:37 am »
I was looking at 3 NiMh's in the Solar LED housing: With my Beta rebate bucks I already changed reward to ACORN 10 and 6 OAK assuming I was going to try build my own power circuit with a 50 cent LD1117DT33TR 3.3v LDO on an oak'ish minimal board with fewer pins brought out, [I'm not an EE - but I know one so hope to learn something].  I'm not sure how long the power curve on 3 (healthy) NiMh's would hold above 3.3v?  This chart says with ~200mAh current holds over 1.2v for 80% and I might get 90+% before a cell drops below 1.1v to recharge:   If it works that way then the simpler to charge 3 cell NiMh system like in those Solar LED motion lights (you? and) I got will be a good match to empty the batteries as needed - but not ruin them. <Of course the lights came with only 600mAh NiMh's>

I installed Eagle CAD and made a pencil sketch for the power board - but have been distracted with life stuff.  I should order an ESP8266-12 to layout prototype on - I have a month (or more) yet to work before OAK's likely ship.

I should have put the full link - it shows AA discharge as well - they drop of faster with higher currents than the NiMh : http://www.powerstream.com/AA-tests.htm
« Last Edit: August 19, 2015, 01:59:33 am by defragster »