Oak baseline current draw?

[exeng]

Question for Erik...

Has the baseline current draw for the Oak been determined? I put an Oak in service powered by a 9V battery through VIN/GND. Sketch was reading a DS18B20 (powered by VCC not parasitic) at 1 minute intervals and publishing to particle.io. So there was, the power LED on constant, onboard LED (held high for 1 second at 1 minute intervals), active wireless, and 1 minute interval posts to particle.io. It only lasted a few hours at best before going inactive. Can't be sure how long as I left and checked remotely 2 to 3 hours later. Could have been less.

I guess this means plug-in power is required for any usable in service up time.

[PeterF]

From the kickstarter page:

Code: [Select]

We'll have more exact figures soon but:
Full transmit: Up to ~220ma at max range/data transfer (but more like 115ma in normal use while sending/receiving data)
Running but not actively transmitting: About 15-50ma depending on load.
Running with WiFi off: about 15ma depending on load.
Sleep: (CPU suspended) About 1ma
Deep sleep: About 50-70ua

To achieve the last two you'll need to disable the power LED jumper.
9v batteries are not the best source of power for this sort of board unless you can get into the lower power modes for very long periods of time. Energizer state approximately 400-500mah at the typical load for the Oak. So at 'typical' loading, you'd be getting around 4.5 hours at best on a new battery. I would be much better to use a 6xAA pack... with NiMH or alkaline cells. You'd be looking at 2000-2500mah of capacity then. Or perhaps a pair of 18650 lithium cells with a protection circuit so they don't get over-discharged.

Regardless of that, to get more than say 4-5 days runtime on batteries without a massive bank of batteries, documentation on how to access the lower power states is needed. Even just turning the WiFi off for 50 seconds would amount to a significant improvement in runtime. With your unit in mind ... I can't see why it could't get down to the deep sleep state for about 55 seconds, and then power up, grab the new sensor data, transmit it, and then go back to sleep. And if this is anything like the deep sleep from NodeMCU... it is dead easy when programming, as to wake up from deep sleep, the MCU is rebooted - so your code runs from start to finish every time. In that situation... you be looking at getting several days use from a 9v battery easy.

[exeng]

pfeerick,

Thanks for the detailed info. I really hadn't given it much thought when I did this. It was more of an experiment and didn't know what to expect. I was leaving on a short trip and expected to see the readings remotely but when I reached my destination, the Oak was inactive. Upon return I found that the 9V battery had run down to about 6V and was unable to provide sufficient current to keep the Oak alive.

The info you have provided will be very useful for anyone planning to put Oaks into service for extended periods. Thank you.

exeng

[PeterF]

Aw, drats! I hate it when you slap a quick project together to access remotely, and it promptly falls over and you (obviously) can't do anything about it until you get back. Hence why I love solar-powered sensors and stuff... as long as there is sun, there is power! Slap a 18650 lithium battery, solar charge module  and battery protection board on that... and you have all the juice you need!

Better luck for next time? Round two, where you show it who's boss

[exeng]

RE: Deep sleep. This can get a bit tricking (correct me if I'm wrong). Assuming you do wake up every 1 minute or so to grab data and post it, will there enough awake time to allow for new uploads? May need an external signal (say a pin pulled high) to say don't sleep so that you can stay awake long enough to facilitate an upload. There is definitely a lag between the device changing state and particle's recognition of it.

[PeterF]

Indeed that would be a problem. Since the Oak is probably polling for an update, delay shouldn't be an issue there. However, I suspect that deep sleep on a oak is going to act very differently to previous NodeMCU behaviour due to the OTA programming nature - you may not  want the Oak to be in deep sleep for one hour intervals  and thus making it 1 hour before it detects an update.

[exeng]

OK (I'm learning here)... So back on the deep sleep wakeup thing, I'm I correct that I would need to connect pin 10 (wake) to reset in order for the wakeup facilitated by a call to
ESP.deepSleep(sleep_ms, WAKE_RF_DEFAULT); to work?

[PeterF]

lol... I think we're all learning here... Oak is still pretty green That sounds about right right. It certainly compiles without any errors. And because that is measured in microSeconds just to be awkward (ok, that's not the real reason!!), it might be easier to write that ESP.deepSleep(sleepTimeSec * 1000000, WAKE_RF_DEFAULT);

And if it goes to sleep and doesn't wake up again... just yank the power and start 'er up again... with a new program waiting to be loaded. At worst, you'll need to do a OakRestore if things go south. I would hope though that on boot up the Oak would check for firmware update, new user program, and if nothing needs updating, hand over to the user program. Giving it the necessary smarts to survive any nasty user programs.