Can I Turn the CC3000 OFF? [solved]

Troubleshooting
103

Dave, I thought that only disabled the Spark Cloud connection, not the Spark-to-router connection. My understanding is he wants to decide when he connects to a router because there is not always one available.

1 Like
104

@Dave -- @peekay123 is correct. Imagine you wanted to do your WiFi scanning, but wanted to walk around your neighborhood instead of staying at your house/lab (e.g. wardriving). @peekay123 mentioned WiFi profiles stored on the CC3000. If there was a way to clear those profiles out such that the CC3000 would not attempt to connect to a WiFi Access Point first then perhaps it would be a bit more cooperative?

Here's the other part of my project (performing scanning -- edited) :

105

@satishā€‹gn THANK you.

106

@peekay123 @Dave, I took your advice and utilized the Spark.sleep(30) and it got similar results to turning off WiFi. I was doing a spark serial monitor and it kicked me out of the session. I saw this come back just before the device started flashing red:

events.js:72
        throw er; // Unhandled 'error' event
              ^

Once I re-connect serial monitor I can see the device going through itā€™s setup() again. Code looks like this:

    #include "spark_disable_wlan.h"
    #include "spark_disable_cloud.h"
    #include "application.h"

void setup(){
  Spark.disconnect();
  WiFi.on();
  Serial.println("here we go...");
}

void loop(){
        structSSID();
        Spark.sleep(30);
}

Any help you can provide would be truly appreciated.

107

gcoffee, I had previously written about waiting for wifi commands to complete:

You still need to do that around WiFi.on(). I don't see any Serial.begin() in your setup() so you won't get any serial connection and the serial port will not appear on the PC.

The flashing red (panic) is most likely caused by loop() being uncontrolled. What I mean by that is after your call to structSSID(), sleep is called and returns immediately. Only a flag is set for the wifi to go to standby. You then loop and do this endlessly which causes the processor to run out of memory. I suspect you thought the processor would go to sleep on that call but the documentation states:

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.

Perhaps if you explain what you are trying to achieve, I may be able to help you more. :smile:

108

@peekay123 ā€“ you did mention that; and I had that code in there when I was doing the WiFi.on/off() commands. I didnā€™t think I still needed it with the Spark.sleep() command. Sorry to have bothered you on that.

You also mentioned that the WiFi.on() command will attempt to get an IP address. Iā€™m assuming that if it doesnā€™t get an IP address then it will return a status of WIFI_CONNECTING?

109

gcoffee, I would venture to say yes, WiFi.status() will return CONNECTING though I am not sure there is a timerout. You may want to use a Serial.print() to see what it does.

110

With the new changes to firmware to accommodate all this WiFi.on and off, is spark.sleep(x) no longer working in itā€™s simplest form? Sleep ā€œseemsā€ to disconnect from the cloud for a specified amount of seconds, but power supply current doesnā€™t seem to drop like it did last week? Iā€™m using a Dr Watson, so not getting the best of resolution of power consumption, but this code last week would go from .08 amps to .02 amps during the sleep cycle. There doesnā€™t seem to be any drop in power consumption at all, just stays at .08 amps all the time. Sleep was very convenient to go into a low power mode, and while the wifi.on and off seems to be more configurable, thereā€™s a lot more code to go into a power saving mode. Can anyone confirm that there is no drop in supply current using this simple example? I could very well be overlooking somethingā€¦

char LED = D7;

void setup() {
pinMode(LED, OUTPUT);
digitalWrite(LED, HIGH);    //LED on initially
}

void loop() {    
//Do something
    delay(25000);           //delay for 25 seconds

//Start sleep cycle    
digitalWrite(LED, LOW);     //LED off to indicate sleep
Spark.sleep(30);            //sleep for 30 seconds
delay(30000);               //delay for 30 seconds
digitalWrite(LED, HIGH);    //LED back on
//End sleep cycle
}
111

brianr, your call to Spark.sleep(30) simply sets the CC3000 standby flag. Then, in the delay(30000), the Spark actually calls the SPARK_WLAN_Loop() background task which will see the sleep flag and put the CC3000 in standby. So the delay() will sit there and at about the time the delay finishes (30s), so will the CC3000 standby time and the CC3000 will wake.

Your loop() basically has the CC3000 ON for 25s then STANDBY for 30s and so on. During the ON time, the WiFi will attempt to connect to a router if a profile exists. You should see power go up and down from about 30-40ma to 150+ma when the CC3000 is attempting to connect. So you are saving power half the time of the loop(). :smile:

112

Agreed, I should see full power consumption for 25 seconds, and then D7 should go off, CC3000 should go to ā€œstandbyā€, and power consumption should drop. Last week I saw exactly what was expected. Iā€™ve been testing different scenarios for several days, even tried the second core that I have, and power consumption doesnā€™t change during the 30 seconds that the CC3000 is supposed to be in standby. Iā€™m playing with the wifi.on and off right now, and I can get power consumption to drop to expected levels when the CC3000 is off.

113

Not sure why I didnā€™t do this before, but running the above code while doing a ping -t to the IP address of the core, it continues to ping while the core is supposed to be sleeping. I lose a few pings at the end of the sleep timeout, while the RGB flashes green to reconnect. I added in a variable that counts, which I can curl while the spark is awake, but canā€™t get while itā€™s sleeping. This confirms my fear that while Spark.sleep(30); might be disconnecting from the cloud, it is not turning off the CC3000, and thus saving no power. Since this code is ultra simple, I canā€™t fathom that Iā€™m overlooking something, am I?

114

@brianr,

Thanks for doing the test! I replicated the scenario and will bring it up to the :spark: team tomorrow.

Will post an update if i hear anything!

115

There seems to be a lot of chatter and people interested in the low power modes of the CC3000 and the core in general. It might be worth checking into the Wifi.off() functions, as my ping testing reveals the same results, disconnects from the cloud, but continues to ping except for when reconnecting.

116

Cool. Iā€™ll bring it up tomorrow :slight_smile:

1 Like
117

@brainr,

So the :spark: Elites have brought this to the attention of the team and we will continue to push for this to be on the higher priority. Sit back and hope for good news the soonest possible :smiley:

1 Like
118

Have you heard any word from the team on this? Iā€™ve got a spark coded and ready to go out into the field, but itā€™s battery powered, so canā€™t put it out there till it actually sleeps in low power modeā€¦

119

I donā€™t mean to complain that the spark doesnā€™t work for my particular situation, and I realize Maker Faire has people traveling, but any update on this topic would be greatly appreciated!

Low power mode seems pretty important for an IoT sensor, no? Any device that will be battery or solar powered stands to be very, very affected by the coreā€™s inability to go into low power mode. @satishgn, power requirements needed during sleep worked as documented a while ago, but stopped working. Could the changes made to 0.2.2 firmware to do all the WiFi.off() and #include ā€œspark_disable_wlan.hā€ stuff to work have broken low power modes?

120

Brianr, I have not looked at the wifi.off () power recently but I do know that deep sleep power is about 7-8ma.

Give me a couple of days to do some testing and Iā€™ll report back with my findings. Like you, low power is important to me as well. :slight_smile:

121

Thanks so much for taking the time to look into it, @peekay123. @kennethlimcp ran the simple test code that I posted and agreed with my findings. Doesnā€™t seem like anything has changedā€¦

122

@brianr,

Let me say that we have heard you guys loud and clear and we discuss till late midnight, 2-3am on how we can resolve all these issues.

We are not asking for credit for the amount of work and time we spend but some issues requires lots of effort and testing to improve :slight_smile: