Still having no end of sleep issues with electron, despite being on 0.7.0 i still have many many occurrences of SLEEP_MODE_DEEP and SLEEP_MODE_SOFTPOWEROFF not shutting the modem down properly, making devices unusable for long life battery operations, due to inconsistent sleep current.
So when cellular_off fails, what is left to do?
Can I manually turn the module off using PWR_UC pin?
Before I call the SLEEP commands, I call this function to ensure I am disconnected and the cellular modem is off. Perhaps you could give this a try:
bool disconnectFromParticle()
{
Particle.disconnect(); // Disconnect from Particle in prep for sleep
waitFor(notConnected,10000);
Cellular.disconnect(); // Disconnect from the cellular network
delay(3000);
Cellular.off(); // Turn off the cellular modem
return true;
}
Hope this helps,
Chip
Thanks Chip, but already doing disconnect. 
Also, I would not use celluar_off(). It does not do the same thing that Cellular.off() does, and I found that it can leave the modem in a bad state. I’ve found Cellular.off() (possibly with a 2000 ms delay before sleep) to be the most reliable way of having the modem shut down all the time.
And I don’t step down, disconnecting each layer. I go directly from Particle.connected() to Cellular.off(). I’ve found that to work the best for me, but your mileage may vary.
@rickkas7 Thanks, The reason for using cellular_off was that I thought it was blocking, whereas Cellular.off was not? and I'm running SYSTEM THREAD enabled.
Oh and by bad state, do you mean anything like this?
Occasionally the modem turns off goes into a limbo state with complete system pulling 40ma with slow pulsing green led and code lockup. I have to rely on external watchdog timer to reset it, at which point it enters proper sleep.
Yes, that would be the bad state. And yes, cellular_off is blocking, which is handy for SYSTEM_THREAD(ENABLED) but the bad state problem makes it not worth it.
I use cellular_on(NULL) as that works great, but still use Cellular.off().
Very interesting! I will try that then, so do you put a delay after Cellular.off? I’m running 0.7.0
Also, do you think shutting down by pulling PWR_UC low is a bad idea? as it seems to work, although only tested with about 50 monitored shutdowns.
And just out of interest is Cellular.off not just an abstraction of cellular_off? then both seem to just send the AT shutdown command no?
I had the delay with 0.6.x but I’m not sure it’s necessary anymore. I haven’t done enough tests with 0.7.0 to be absolutely sure it’s not necessary, but I don’t think it is. But 2 seconds at 40 mA isn’t a lot of power either, so I haven’t removed it.
Pulling PWR_UC low might work, but I’m worried it will go into the state it’s in during cold boot with cellular off (1 mA) instead of SLEEP_MODE_DEEP state (130 uA). I haven’t actually tested it, though, so maybe it’s fine.
Ok thanks again, all I want is a bullet proof way of going into 130ua sleep, 4 months of trying and still not there! I have around 200 prototype devices out in the wild and the number of them not going into sleep properly is killing my product.
So, sorry to go over one more time, but… aside from the possible PWR_UC option, do you think this in your experience is the most robust method to go into 130ua deep sleep. …?
//Do whatever, connect to gsm, send sms, cloud connection etc.
cellular_result_t result = -1;
result = cellular_on(NULL);
if (result) {
if (serialdebug) Serial.println("ERROR: Failure powering on the modem!");
} else {
if (serialdebug) Serial.println("Modem ON!");
}
Cellular.off();
delay(2000);
System.sleep(SLEEP_MODE_SOFTPOWEROFF,1440);Yes, I believe that will go into 130 uA sleep always.
Though the jury is still out on whether the delay(2000) is necessary with 0.7.0 or later, it certainly doesn’t hurt anything (except for a little battery life).
Also, you only need to turn on and off the modem on cold boot. I use a retained variable to know that I’ve already powered on and off the modem and don’t go through that again if I already know the modem is off. It’s 0 on cold boot, and I put a magic value in it after waking up the modem.
Yeah I’m keeping tracking of that with a retained variable, got that from your other post 
Ok i will run through it again, but I’m 99.9% sure that i’ve run with…
Cellular.off();
delay(2000);
System.sleep(SLEEP_MODE_SOFTPOWEROFF,1440);
on 0.7.0 and got occurrences of this… https://photos.app.goo.gl/qMzGUYeSjNv19X1c2
Yep sorry, just tried it again, and I’m in that current draw again, as per video
arghhhhh!
Going to have to run with the below, not ideal, but seems the most reliable.
void hardShutdownModem(void)
{
pinMode(PWR_UC, OUTPUT);
digitalWrite(PWR_UC, LOW);
delay(1500);
digitalWrite(PWR_UC, HIGH);
}In that case, run with
SerialLogHandler logHandler(LOG_LEVEL_TRACE);
and capture the USB serial debug output. I’m curious what the modem is doing in your situation.
ok giving that a quick go now and see if i can capture it in that state
Ok I have it in that state now. Nothing coming in on serial obviously, but i do have complete log from cold boot to this state, have PM’d
any insight?
Is that video just after you run the cellular.off() code?
I remember seeing this also for like 30 seconds or so after calling cellular.off() before the modem actually turned OFF and the 130uA sleep current kicked in.
It’s been awhile since I’ve tested this though.
no afraid not, this is 2hrs after
Sounds like the modem is still on and communicating with the tower or something.
What pins are you feeding the 3.8v to from the power supply?
Through the Lipo input