Spark.wake() during Spark.sleep()?

We have the ability to sleep the WiFi chip of the Spark Core (http://docs.spark.io/firmware/#sleep-spark-sleep) and deep sleep the entire core but only for a set number of seconds.

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.

This sounds like something @peekay123 may know more about. @bko or @BDub may be able to help as well.

@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. :smile:

1 Like

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. :smiley:

1 Like

@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". :wink:

But, seriously, I am doing uptime/sleep testing for going completely untethered, so I'll also bring it up. :smiley:

@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 :open_mouth:

1 Like

Thanks for all your input folks.

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. :smile:

2 Likes

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.

Thanks,
Matt

3 Likes

Has there been any update for wifi.on/off?

Really want to use this with an interrupt.

Our new firmware that gives the user control of the connection will be released next week!

@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. :wink:

Understood, but as of next week this will be very possible without an explicit interrupt awakened sleep mode.

Here’s the spec:

For example:

System.mode(SEMI_AUTOMATIC);

int button = D0;

void setup() {
  attachInterrupt(button, sendSignal, CHANGE);
}

void sendSignal() {
  Spark.connect();
  Spark.publish("button");
  Network.disconnect();
}

There you go, interrupt driven wi-fi! Not saying that we won’t do a true interrupt-driven sleep mode, but at least there’s a short-term fix.

Also fair warning for anyone who’s reading this - this code won’t work until we release this new feature next week!

@zach super cool and amazingly delicious features! HOWEVER, power is the issue here - no more said :stuck_out_tongue:

2 Likes

Ok. So cool…I think?

So. Next week I’ll have more control of a lot of stuff using interrupts. Including network connectivity.

But I still can’t turn wifi OFF.

Yes, power is my concern.

Network.disconnect() will turn the Wi-Fi off!

1 Like