I have been testing different methods of reducing Core power consumption for one of my projects. The project is required to take measurements every minute and publish them. I have tested three different approaches to reducing power:
Start with wifi/cloud OFF, wait 1 minute, sample the data, turn ON wifi/cloud publish then turn off wifi/cloud and loop. This works fine and most of the time, wifi comes up fine and sometimes I get flashing red but it will connect and publish.
Same idea but instead of controlling wifi/cloud, just use Spark.sleep(60) to put the core to sleep for 60 seconds at the end of the loop. However, Spark.sleep(60) is not blocking and does NOT “put the core to sleep” as documented. From what I can see, this sleep mode disables wifi for 60 seconds in the background, exactly like WiFi.off() does. This function may need to be rethought or properly documented.
Same as 2 but use Spark.sleep(SLEEP_MODE_DEEP,60) to put the core in standby at the end of the loop. This seems to work well, however wifi often blinks red after blinking green. Nonetheless, it always seem to connect (eventually) and publish. The extra connection time is also the time when the CC3000 consumes the most current.
So, I believe Spark.sleep() needs to be looked at a bit more. It would be good to understand the re-connection “glitches” after coming out of sleep cause any delay in connecting increases the overall power consumption (at least in my simple case).
Has anyone else worked with Spark.sleep() and willing to share their experience?
kennethlimcp, the fix was in regards to the deep sleep mode and in my testing, I found everything to work as expected in this mode.
However, the plain sleep() mode is confusing in that is does not sleep the processor whatsoever. Instead, it seems to be sleeping the wifi only, as if the user ran WiFi.off(). As it stands, user code keeps running after sleep() is called. This is confusing and should either a) be removed in favor of WiFi.off() or b) actually cause the user code to pause (as in delay) during the specified sleep period. As it stands, it is confusing IMO.
I guess it’s a matter of what Sleep() should really do.
In the docs:
Spark.sleep() can be used to dramatically improve the battery life of a Spark-powered project by temporarily deactivating the Wi-Fi module, which is by far the biggest power draw.
So i guess it’s implemented correctly as what the team wanted it do be.
This should be discussed and changed with the new Wifi on/off and Spark on/off i guess?
@satishgn can chip in since it’s on his list of to-do it seems.
I just find that calling it sleep() is misleading since by adding a single qualifier the processor actually goes in standby. If anything, it should be called sleepWiFi()!!
I’ve taken a look at the only other post I could find related to sleep, and I’ve been messing with sleep and deep sleep with plenty of success, but I’ve noticed that while Spark.sleep(x) does seem to disable the cc3000, I don’t get a green flash, but rather breathing cyan. I haven’t checked power consumption, but updates to api stop for the duration of the sleep while the loop continues to run. Deep sleep turns the light off as expected, and both sleep modes run code afterwards, so at least that doesn’t seem to be a problem anymore. Did we lose the flashing green during sleep?
Long pause doesn’t seem to change the situation. Even with Spark.sleep(100), breathing cyan and D7 LED flashes non-stop. I do get green flashes, but that seems to be a result of the core reconnecting to WiFi, not related to sleeping. Am I doing this wrong? Can I bug someone to confirm this?
I suppose it’s just a visual thing, since it does seem to reconnect to the cloud and update variables after a sleep. The visual indicator would be nice without writing more code for RGB.control. I have done some quick tests of draw and current does drop dramatically, so again, it’s merely aesthetic.
I’ve also tried the following with the same results. Code continues to run after the sleep statement, as I get one short LED flash, and one long one, supply current dropping for ~30 seconds, then the RGB flashes green for ~5 seconds and supply current comes back up, then breathing cyan…
char LED = D7;
void setup() {
pinMode(LED, OUTPUT);
}
void loop() {
delay(200000); //delay for 200 seconds
digitalWrite(LED, HIGH);
delay(100); //.1 second flash
digitalWrite(LED, LOW);
delay(100);
Spark.sleep(100); //sleep for 100 seconds
digitalWrite(LED, HIGH);
delay(1000); //one second flash
digitalWrite(LED, LOW);
}
brianr, kennethlimcp, the regular sleep function is the same as calling WiFi.off() which puts the CC3000 in standby mode. In my experience, the green breathing only occurs when wifi is ON but cloud is disconnected.
Some of the upcoming changes to the network code will help clarify the CC3000 modes.
As for deep sleep, I am still seeing irregular odd behavior upon waking where I get red flashes that usually lead to panic then reset then everything seems to restart properly. Because this happens irregularly, it is hard to capture. Perhaps the TI updates will help.
@peekay123, I think we agree on what's happening. I do indeed get green flashes when the sleep() timeout allows the CC3000 to come back on, but is not yet connected. The documentation states the following, which I wasted a bunch of time trying to figure out why it wasn't sleeping, as I was expecting the RGB to flash green the entire time it was supposed to be in sleep mode, whether or not code continued to run... I guess I was expecting the RGB to be an indicator of WiFi status, not whether or not my code was running.
// EXAMPLE USAGE: Put the Core to sleep for 5 seconds
Spark.sleep(5);
// The Core LED will flash green during sleep
With deep sleep, I don't get the red RGB very often at all, but I have seen it, although, like your observation, it's never hung the core and resolves itself almost immediately. For better or worse, though, deep sleep is not really a sleep, but more of a "shutdown for x seconds and then reset the core". It certainly does drop supply current to nil, and for a programmed amount of time, but nothing stateful is retained for use afterwards. As long as deep sleep is the last thing your core will do, and you don't need to retain any values (unless you write them to flash memory?), then I guess it's better than having an external timer circuit turn power to the core on and off!
team wanted it do be.
