Oak not staying online

[AUAJ]

Thanks for the response exeng.

Is it correct to state the sleep command is to minimize the power needed by the Oak?

What if I didn't want to put it in sleep.  Such as first learning / playing with the Oak. 

I thought I could avoid the Oak going into sleep by only checking for a LOW knowing that I never changed the state of the pin.  Why is this incorrect / problematic? And how does the while loop fix this?  Wouldn't I still go into sleep after 150 seconds?

Why would the Oak not wake up when I connected the WAKE and RST pins? (I checked the dashboard and the LED didn't turn on).

Sorry for all the questions and thanks again.

[exeng]

You are correct deep sleep is designed to minimize power requirements typically when using battery power to extend the up time and life of the batteries. I have a pool temp monitor that sleeps for 30 minutes between readings that is powered by 4 AA batteries. It's been running for a couple of weeks now. I may eventually convert it to solar power through rechargeable NiCd's, but so far it's been running just fine on 4 AA's.

If you do not want to, or never need to sleep because you are running say from a wall wart (plugin power), than remove any code that supports the sleep, do your initialization in setup() and put your working code in loop(). If you are doing periodic updates to Particle, just use delay() as Pete suggested.

In your original code (were you test pin 5 low to enter sleep) you had set the pin mode for pin 5 as INPUT_PULLUP. This means pin 5 was always HIGH (unless you externally pull in to ground). Because it was always HIGH you never entered sleep but did enter an empty loop() where you code remained until the next power cycle. It's near impossible to upload a sketch when in this state.

If WAKE was connected to RST from the start and you entered sleep, the Oak should have reset when the sleep time expired. If you entered sleep without this connection and connected it before the sleep timeout, it should have reset. If you connected it after the sleep timeout, then I believe it would not wakeup the Oak as the timeout already occurred and attempt to trigger reset would not work because there was no connection between WAKE and RST to facilitate the reset. Make sense?

Hope this helps.

No worries. Don't mind helping those that want to learn and actually do. Many grab code examples without trying to understand what is going on or what the intent was, then sometimes struggle to figure out why things don't work as expected. My general advice when using or modifying example or someone else's code is to do a 'code review / walk through' first and ask why this and why that, until you have a good handle on how it works. My second piece of advice, to be applied if the code will be production (shipped) code, is to beat the living blank out of it and try to break it in any way you can think off. Sorry for the preachy part. Not directed at anyone but myself. Just the way I approach software. That said, I'm not perfect.

[PeterF]

Aw... I think you're pretty darn close after that last quip exeng!

lol... I misread the test in the deepSleep otherwise I would have realise it was inverted... Nice catch!

Yes indeed, deepSleep is only for low power (i.e. batteries), and should also be avoided untill your code is nearer to completion. Whilst working on code that would deepSleep, I instead just insert a 20 second delay, as even though the Oak will reboot and run both the setup() and loop() functions when waking up form sleep, I still write my code with setup() being the configuration section, and loop() being the work code, so I can pretend that the Oak has rebooted and is running another pass by just letting the loop keep... looping? :-D

Keep asking questions... great to know that it is starting to come together... this is what the forums are for, and it's great to hear back from people saying that it's working for them!

[AUAJ]

@exeng

What you said makes sense.  I also tried going through the code line by line to understand what was happening before I ran it.  Some of which (such as the sleep) didn't make whole lot of sense at the time.  I have used processing before where I didn't have to have anything in the draw() loop and I wasn't sure if this code was similar. 

I have also learned that sometimes it's a better learning tool to run the code, see what happens, and play with the sections that don't make sense to get a better understanding.  This way I can learn from trial and error.  Unfortunately, I was having problems getting the code to work properly from the beginning. 

My next step is to have another Oak subscribe to the data, read it, and publish it back.  With the long term goal of doing what you mentioned with displaying it on an LCD screen and then applying it to small electric cars.  At this point i don't know if subscribe will get whatever stream it seems, regardless of if it's new or not.  I'm trying to find if there is away to have the second Oak check the URL until the data stream (or time stamp) changes and then subscribe to the new data but I think the best way will to be trial and error.  If I can't figure it out, i'll probably come back to the forum but with code so I can learn where I went wrong.