Direct Oak to Oak communication & sleep

[aidave]

I have a project in mind and have a couple oak's from kickstarter...
The project would involve one oak on a 12v system (car) and a lipo battery powered handheld device.  I would like to get 8 hours of life of it .. but, I may be missing something.
When doing oak to oak (no 'cloud' or other wifi server/router/etc) -- it seems waking the oak from deep sleep takes a long time.  I want to send (or get) an update ever 1/2 second (roughly) but the best I can get is about 1 update per second (usually a little longer).
Is there a guide to A) getting an oak to talk directly to another and B) best practice for sleeping/waking the oak?

[defragster]

Starting and restarting the radio to connect at some point will take more power than just keeping it alive. And unless the radio pretends to pick up where it left off it seems it would do a full net join on power up which will take more than a second or 3.

You can have it not connect to Particle on power up: http://digistump.com/board/index.php/topic,2132.msg9834.html#msg9834 with SYSTEM_MODE(SEMIAUTOMATIC) or SYSTEM_MODE(SEMIAUTOMATIC).

But I think that leaves you with no WiFi, then you'd need to do a standard WiFi.begin - and it seems under particle that always involves using the save connect info that I assume means it will then want to hit the cloud before coming back?

[PeterF]

Considering the oak on it's own when not actively transmitting is only consuming around  15-50ma depending on load as opposed to worst case 220ma, but more likely around 115ma when transmitting, that should be of itself enough of a power saving... You can get it down to 1ma if you suspend the CPU (so no reboot when waking up), or 50-70ua via deep sleep, but then as defragster pointed out, you will have to go through the whole wifi renegotiation at power up, so it's not worth the hassle. Factoring in 120ma power consumption per hour (and will probably be a little less than that if you are pulsing at 0.5 second intervals instead of continuous), you need roughly 960ma of power for 8 hours. I reckon a single cell 2200 mAh 18650 lithium battery should do the job with a decent reserve. It depends what else you need to stick onto the portable device.

EDIT: Oh, and btw, SYSTEM_MODE(SEMIAUTOMATIC) will prevent an automatic connection to Particle, but still try to connect to the registered wifi network. SYSTEM_MODE(MANUAL) will prevent both automatic connection to wifi, and connection to Particle. Have a look here if you want to see more on that - since you're not interested in Particle for this application, the SYSTEM_MODE(SEMIAUTOMATIC) mode may be desirable as it would have some power-saving effect due to not looking for Particle, and the Oak would be more responsive as far as time sensitive code.

Pete

[aidave]

Thanks.   I had (assumed) that I could set one up as "host mode" or use ad-hoc type network.
Obviously; the one with the constant power supply I want to bear the brunt of the load, so rather than the base (for lack of a better word) would become the wifi server and just wait; where the handheld would send the data every 1/2 second.

I will do the timing w/o the particle; thank you for the api calls.  That should cut down time (and power) dramatically. 

So sleeping (at all / any type of) would require re-negotiation for the network?  Bummer; but if I can squeeze the time out; I guess it doesn't matter too much.

Thanks again!

[PeterF]

Yes, basically anything that shuts down the radio will require renegotiation with the AP. So the best thing you can do is do your best to make sure the portable oak is idling when it doesn't need to transmit. I'm not sure what the best way to do that is... as I think a delay would still have some CPU overhead (say if you had to delay for 250ms, and then some processing and transmit). Maybe you'd be interested in the Ticker library, which is  for calling functions repeatedly with a certain period (there should be two examples included with the IDE core). That may help in designing something to run more closer to the 1/2 second interval you're looking for. You'd have the ticker firing every 0.5 seconds, which would set a flag, and in the main loop, it would check for that flag, and then process whatever needed to be processed. meaning the loop would be doing nothing but checking for that flag/semaphore the rest of the time. Something to think about anyway

Pete

[aidave]

Thanks Pete.  I think the ticker library uses a lot of cycles; hopefully I can sleep the cpu independently of the radio