Ideally we need a way to interrupt this sleep when certain events happen. For example a PIR may wake the core so the event can be published to the cloud.
Essentially it feels like we need a more flexible way to enable and disable WiFi based on events rather than time.
I agree. I can imagine scenarios where the Spark will form the heart of a remote data-logging system which needs to call home after certain triggering events, but otherwise remain in a deep sleep to preserve power.
@scottsweb, Spark.sleep() does essentially the same thing as WiFi.off() with the existing firmware. The difference is that with Spark.sleep() you specify the time after which a WiFi.on() is essentially done.
All this to say that you can control the CC3000 power mode using WiFi.on() and WiFi.off() and decide when and under what conditions these will be executed.
As for deep sleep, at this time there are no other events except the sleep timer that will wake the Core. I do agree that it would be nice to have other definable events which would wake the Core. If it has not been brought up yet, I will do so at the next Spark Team/Elite hangout.
So in the case of something like a PIR sensor output going LOW... this could be tied to a digital input that has been attached to an interrupt (already a function for that)... Interrupts typically can be configured to wake up a sleeping microcontroller. This sounds like the most ideal way to process a sensor as fast as possible, and then you can make the Core deep sleep for long periods of time without worrying about missing your sensor event.
From the STM32 Reference Manual:
Exiting Sleep mode
If the WFI instruction is used to enter Sleep mode, any peripheral interrupt acknowledged by
the nested vectored interrupt controller (NVIC) can wake up the device from Sleep mode.
If the WFE instruction is used to enter Sleep mode, the MCU exits Sleep mode as soon as
an event occurs. The wakeup event can be generated either by:
enabling an interrupt in the peripheral control register but not in the NVIC, and enabling
the SEVONPEND bit in the Cortex-M3 System Control register. When the MCU
resumes from WFE, the peripheral interrupt pending bit and the peripheral NVIC IRQ
channel pending bit (in the NVIC interrupt clear pending register) have to be cleared.
or configuring an external or internal EXTI line in event mode. When the CPU resumes
from WFE, it is not necessary to clear the peripheral interrupt pending bit or the NVIC
IRQ channel pending bit as the pending bit corresponding to the event line is not set.
This mode offers the lowest wakeup time as no time is wasted in interrupt entry/exit.
Just need to get the interrupts set up correctly to work with Deep Sleep mode.
@BDub, this is a job for @mohit or @satishgn! To me this is a very important requirement and would make low power operation much more achievable. Perhaps we need to push for this in the next Sprint.
@zachary said that this feature (wake on interrupt) was added to the backlog in his response to a question back on December 13. Is this something we can hope to see soon? I agree with @peekay123 that this is a very important feature for low power monitoring applications.
If @peekay123 gets to pushing it, it'll get done (because he's so darn persistent!). Just ask any of the Spark Staff the first thing that comes to mind when they think of @peekay123, and I can guarantee that it will either be "RAM" or "Canadian".
But, seriously, I am doing uptime/sleep testing for going completely untethered, so I'll also bring it up.
@wgbartley, I resemble that remark! They say the squeaky wheel gets the grease but in my case, it’s the RAM! There is no reason to have such a powerful processor and not have flexible power management so that is my next mantra
I think the above comment by @peekay123 should get added to the Spark.sleep docs. It is handy to know that WiFi.off() is essentially the same tool. This may also be enough for me when I get playing around to the next stage of my project.
To be able to interrupt from deep sleep would also be very nice to have. I can see lots of ways I could make use of this as saving power is going to feature heavily in most of my projects.
@scottsweb, at this time the WiFi.on/off functions are in “limbo” as the entire wifi/network components of the firmware are undergoing renaming/restructuring. We don’t want to add documentation for stuff that may disappear. That work will be completed relatively soon and the documentation will reflect the final functionality.
Hello Folks, this is my first post in these forums.
I am a HUGE fan of the SC board and I am working with three of them at the moment to prototype a research device like a toothbrush that monitors some behavior and then lets me pull the data from devices in the field via a web dashboard.
The challenge as many of you also have is power, and my particular problem is that I’m using the device to study test subjects who may or may not be attentive to plugging the device back in after use. So even if I turn wifi off, given the space constraints for batteries inside the device, I can get maximum 5 hours before memory loss and device shutdown.
My last resort option at the moment is to have two spark core boards, one in the device, one in the charging station. Then, if the device is about to lose power because of not being charged, it bounces it’s data over to the base station so I don’t lose the data, and I can then call the test subject to tell them to charge the device.
This is really non-optimal because I don’t necessarily want the test subjects to be reminded of my “big brother” eye in the sky, because it does impact their normal behavior to some degree.
Therefore, the interrupt enabled deep sleep mode is VERY VERY important to me. Just wanted to throw my two cents into the ring.
Currently, I’m struggling to solve this issue, but if I can get it solved, I intend to buy a lot of these boards (like 50-100) as they offer me such a quick easy solution for remote monitoring.
@zach, I believe @the_root_of_matt is looking for a sleep mode which is interrupt “awakened”. I have been pushing for this since the last two hangouts and believe it is a really important feature to implement.