SLEEP_MODE_DEEP not working with SYSTEM_MODE(SEMI_AUTOMATIC)

Troubleshooting
1

The problem is simply that the electron will not go to deep sleep, meaning that it will not lower the current consumption down to 100-130µA which it should be when the electron goes to deep sleep mode, instead I get strange current consumption values rangeing from 2,7mA-100mA most of the time it is either around 2,7mA or 50-60mA… I have found out that SLEEP_MODE_DEEP works if I don’t use SYSTEM_MODE(SEMI_AUTOMATIC) but use SYSTEM_MODE(AUTOMATIC) instead, if I do that (use SYSTEM_MODE(AUTOMATIC)) then my electron goes to sleep and only consumes 130µA… but I need my code to run offline and only connect and publish data if there has been a significant change on waterlevel (which I measure with pressure sensor). I have also used SLEEP_MODE_SOFTPOWEROFF but that does not work either if I have the mode set to SYSTEM_MODE(SEMI_AUTOMATIC) …

one other thing that I want to get confirmed. If my electron foes to deep sleep, then what is the correct/expected behavior of the RGB LED? should it start blinking green for a while (30sec-5min) and then flash cyan and then breath cyan? or what is it expected to do if the electron is really waking up from deep sleep

2

How about calling Cellular.off() before deep sleep?

That depends on your system mode, sleep time, whether you were connected pre sleep or not and your immediate action when waking.
But supposing you've slept long and want to connect immediately (as would be in AUTOMATIC), then I'd expect to see the colors you described.

BTW, what system version are you targeting?
With questions like this you should always provide this info as these topics are currently undergoing improvement with each update.

3

Thanks, I have tried using Cellular.off() but that does not make any difference

this is the simplest form of the test code and this does not put the electron to “a real” deep sleep

SYSTEM_MODE(SEMI_AUTOMATIC);
void setup() {
}

void loop() {
	Cellular.off();
	System.sleep(SLEEP_MODE_SOFTPOWEROFF, 30L);
}

I have firmware version 0.5.3 on my electron

4

I don’t know why, but I have figured out a way to go around this bug… the thing is that to be able to turn off the Cellular you will first have to turn it on :wink: … so if I add Cellular.on() before Cellular.off() and System.sleep(SLEEP_MODE_SOFTPOWEROFF, 30L); then it enters the deep sleep mode and only consumes 97µA :smile: I can even skip the Cellular.off() because System.sleep(SLEEP_MODE_SOFTPOWEROFF, 30L); probably includes that, but it is important to have the Cellular.on(); before the sleep command… so the code below is a working code, can you guys please have a better look of this and fix this bug.

SYSTEM_MODE(SEMI_AUTOMATIC);
void setup() {
}

void loop() {
	Cellular.on();          // baucuse of some strange reason, you first have to turn the Cellular on so you can turn it off
	System.sleep(SLEEP_MODE_SOFTPOWEROFF, 30L);  //otherwise the Cellular will stay on even after this sleep command
}
1 Like
5

Well I was a little bit too early celebrating! because I also need to use SYSTEM_THREAD(ENABLED); in my code and if I add that then again, the cellular wont turn off…

so this code here does not work (after I add the SYSTEM_THREAD(ENABLED); but it does work if I skip that)

SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);
void setup() {
}

void loop() {
	Cellular.on(); 			// because of some strange reason, you first have to turn the Cellular on so you can turn it off
	System.sleep(SLEEP_MODE_SOFTPOWEROFF, 30L);  //otherwise the Cellular will stay on even after this sleep command
}
6

That’s interesting, since for one AFAIK SEMI_AUTOMATIC should turn Cellular.on() implicitly on startup, so I don’t see why calling it again would make a difference :confused:
About SYSTEM_THREAD(ENABLED), how does the device behave with Cellular.on() followed by delay(10000) in setup()? Does adding Cellular.off() again with/without delay() change anything?

Nevertheless, that’s something for @BDub to look at too, I guess.

7

SYSTEM_MODE(SEMI_AUTOMATIC); does not turn on the network device at boot, much like MANUAL mode. When you call Particle.connect() a lot of things are automatically done for you, like turning on the network module, making it’s connection, then connecting to the cloud.

So you do need Cellular.on() before you can use System.sleep(SLEEP_MODE_SOFTPOWEROFF, 30L); because the way the modem is put in deep sleep is via AT commands. So it must be initialized properly via Cellular.on() to accept the power off commands.

I’ll look into the threaded case not working.

1 Like
8

SYSTEM_THREAD(ENABLED) is not blocking on calls to the modem, so the application thread doesn’t wait for the modem to finish before going to the next instruction in user code. Thus the SLEEP_MODE_SOFTPOWEROFF will not work properly with threading enabled currently.

As a work around you can break out the commands separately and add delays after the commands. The delays need to be longer than the commands could possibly take. 10 seconds after Cellular.on is typically enough, but there is an edge case where the modem doesn’t respond to the power pin being toggled and needs to then be reset after 10 seconds of trying to power it up. So in that case it could take more like 15 - 20 seconds max to power on. Here in code I’ve just used 10 seconds though:

SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);

void setup() {
}

void loop() {
  Cellular.on();
  delay(10000);
  Cellular.command("AT+CPWROFF\r\n");
  delay(2000);
  FuelGauge().sleep();
  delay(2000);
  System.sleep(SLEEP_MODE_DEEP, 15);
}
9

Thanks @BDub I will try your suggestion and let you know, but what I did was that I just skipped the SYSTEM_THREAD(ENABLED) and then it works for me at the moment, I will not be able to have a look until after two weeks or so.

10

Thanks for digging into this @Mquist and @ScruffR

FYI were are now tracking this issue here:

2 Likes
11

I’m also having problems with deep sleep but under slightly different circumstances:
-System 0.5.3
-Running Automatic mode

My “deep sleep” after the RGB led goes cold will still be drawing about 20mA @ 5V. This is not, obviously, in the coveted uA range specified. Even more aggravating - the Electron simply does not wake up after the specified interval. It stays good and mummified forever.

I followed the steps provided on this thread and now it doesn’t seem to ever enter sleep at all ;] I decided to hop on this hot thread because I couldn’t tell if any of the other sleep related posts are relevant to my environment.

Thanks and sorry!

12

Showing your code might be a good starting point.

2 Likes
13

Basically I’m just calling this subroutine every loop()

//TODO - disable pmic charging while asleep?
void ShouldIDeepSleep(){

    if(Time.hour() == 1){    // 1am detected...going into deep sleep until 7am.  Network will be lost
        for(int i=0;i<10;i++){
            digitalWrite(pwrLED,HIGH);
            delay(1000);
            digitalWrite(pwrLED,LOW);
            delay(1000);
        }
        System.sleep(SLEEP_MODE_DEEP, 21600);
    }
}

I have my time zone adjusted so that I’m getting the correct INT returned with hour. I do 10 long LED flashes to signal shutdown.

14

Are you hooked to the WKP pin? That can affect sleeps and wakes.

1 Like
15

Yes I am hooked up to WKP and it will stay high during sleep. No “rising edge” would occur unless the user releases then presses the button that applies 3.3V to it.

1 Like
16

So I disconnected the button controlled 3.3V signal from the WKP pin and the device is now successfully waking up from deep sleep.

Kinda stinks that you seemingly can’t use the WKP pin in combination with deep sleep mode and of course you can’t designate a separate pin for rising edge wakeup when using deep sleep. I’ll have to think of some circuit to get around it perhaps.

Maybe I can use the reset pin? It’s active low, yes?

2 Likes
17

I don’t see anything in the docs that says what should happen when you hold the WKP pin HIGH during sleep. Have you tried holding it LOW instead. Do you have a reason that it needs to be held HIGH?

18

Keeping WKP HIGH should not wake the device, but is it a clean stead HIGH, or might there be ripples/spikes strong enough to scratch the threshold and cause a rising edge?

19

Seldom do I reach for the scope but I could check the noise.

The “3.3V” node of which I speak is actually the unregulated positive terminal of the provided 3.7 li-ion battery. I’m told the WKP pin is 5V tolerant and the max charge voltage is 4.2V, yes?

20

I'm not sure if WKP doesn't get an internal pull-down attached when goind to deep sleep (System.sleep(wakePin, ...) does implicitly do that), to ensure the LOW level when left open, so you might violate this
https://docs.particle.io/datasheets/photon-datasheet/#peripherals-and-gpio