After another week of testing (all of the above methods), still no consistency.
It appears there is no reliable way for the electron to enter deep sleep with 130uA current each and every time. Making it completely unusable.
modles,
I had fits with sleep too. What I’ve discovered after a lot of trial and error is that in 0.7.0, you don’t need to go through Particle.disconnect() and Cellular.off() in order to get the device into a proper, 130uA sleep mode. In fact, those seem to cause problems and were giving me buffer overflow errors.
Here’s what I do:
GoToSleep()
{
StopTimers(); // I find that any running timers can cause issues with sleep
Serial.flush();
Serial.end();
//sleep until top of next minute
System.sleep(SLEEP_MODE_SOFTPOWEROFF, 60-Time.second());
}
That’s it. System.sleep(…) handles all the disconnections by itself. I do have to explicitly reconnect when the unit wakes with something like:
bool NetworkConnect()
{
int tsecs;
boolean success;
tsecs = Time.local();
Particle.connect();
while (!Particle.connected() && (Time.local() < (tsecs+90) )) {
Serial.print("NetworkConnect: waiting to connect...\n");
delay(10); /*wait*/
if (Particle.connected()){
Serial.print("NetworkConnect: Connected to Cellular\n");
success = true;
gModemOn = true;
}
else {
Serial.print("NetworkConnect: Not connected to Cellular\n");
success = false;
}
return(success);
} //NetworkConnect;
I arbitrarily chose a 90 second timeout to return the to the calling function if the network fails to connect. That may be faulty, but that seems to work for now. The above has been reliable for me.
Apologies for the crazy formatting above. I’m not sure why this editor does what it does.
===================
Lastly,
Rickkas7 gave me the tip to initialize the cellular modem at startup. Without doing that, the modem will never sleep properly and you get the crazy approx 40mA current consumption instead of the 130uA sleep mode. My setup for this looks like:
STARTUP(System.enableFeature(FEATURE_RETAINED_MEMORY));
retained int bootCount = 0;
SYSTEM_MODE(SEMI_AUTOMATIC);
void setup() {
if (bootCount == 0 ){
Cellular.on();
bootCount++;
}
else{
Cellular.off();
}
} // setup()
The above has been rock solid for initializing proper, low-power mode. Sorry to hear about your problems. I know just how frustrating this is. Can’t thank Rickkas7 enough for straightening me out.
3 Likes
Very nice breakdown!
I have reformatted your code blocks.
If you want to know how it’s done, you can go into the post via the edit icon 
or look in this thread
Thanks for this. Although I still get random > 130ua results with this method on 0.7.0. Not often but enough to make it unusable.
I’m sticking with pulling the UC pin low to shut the modem down, its the only thing that’s worked consistently over 100s of consecutive runs.
How exactly are you pulling the UC pin low? In code right?
Like this…
void hardShutdownModem(void)
{
pinMode(PWR_UC, OUTPUT);
digitalWrite(PWR_UC, LOW);
delay(1500);
digitalWrite(PWR_UC, HIGH);
}
1 Like
I’ve done some logging now and over hundreds of wake/sleep cycles, I have yet to find a single occurrence of the sleep mode not correctly entering into 130uA of draw +/- about 3uA. This is after I implemented starting the modem on the cold boot as described above then allowing the sleep command to shut it down.
I would suggest that you try creating a separate program that only executes the sleep/wake sequence. You could also try a different electron module.
1 Like
Confirmed. After a few hundred test with different combinations of starting up the Electron and shutting it down the only method working 100% for my applications is turning on the modem at startup always and shutting it down with:
Serial.flush();
Serial.end();
System.sleep(SLEEP_MODE_SOFTPOWEROFF,SLEEP_MODE_SOFTPOWEROFF_SECONDS);
Hi James
I wonder why the
Serial.flush();
Serial.end();
are so important?
Dont know but I am very happy it works, cause I am days from rolling out my first 15 units and always had a problem with my battery life not corresponding with the theoretical calculations.
Yeah tell me about it, we have 400 units out in the field and having major issues with sleep mode. Im still sticking to hard shutting the modem down, can’t risk it, and despite what people are saying i still see around 2ma sleep sometimes.
I logged the usage over time with an Campbell data logger and thanks to your method of shutting down brought the total usage down to less than 5 mAH per day which includes the sending of one SMS. Theoretically i can go 6 months with one battery and now the problem is to find a small enough solar panel to charge not more than 10 mAH per day.
I have a solar powered device that has been shutting down and waking up like clockwork for days now. I dont disconnect I just put it in a deep sleep.
Suddenly these last few days it wouldn’t sleep it just reboots .it’s been cloudy outside so I think it’s when the Lipo and supply voltage are both weak,my Lipo voltage was around 3.7v .
This is a bit crazy because when the voltage is weakest that’s when I need to sleep the longest,not keep waking up!
Can someone else please validate this assumption .
What system mode are you running?
If the device tries to connect immediately after wake and the SoC doesn’t permit a successful connect, it might well be that this traps your device in a “deadly” trap which will just drain the battery even further.
If your SoC is going low, you should definetly disconnect before going to sleep and only re-connect after wake-up when the SoC is in a healthy range.
I think that is the problem.
It’s in automagic mode. We tried semi auto mode but, it’s connection then is not as robust for some reason, I think watchdog timer would kick in when it was trying to connect , we tried to manage the connection in code, but it wasn’t as reliable and it spawned other problems like the light blue led of death.
Auto mode suits us because if we don’t get an internet connection , there is no point waking up to take readings , our lidar draws about 300ma so it’s the last thing we turn on and the first thing we turn off.
Will take another shot at semi automatic mode , but don’t know how to handle the WDT.
I too was having issues getting the LTE module to sleep while it was trying to connect. I am running in semi-automatic, OS: 1.0.1, threading enabled.
I found this to work:
if (Particle.connected()) Particle.disconnect();
if (Cellular.ready()) Cellular.disconnect();
delay(500);
if (Cellular.connecting()) { //this is required to shut down the modem while connecting
Cellular.listen();
waitUntil(Cellular.listening);
}
// Cellular.off(); //option 1, does not work
//delay(2000);
cellular_off(NULL); //option 2, works seems to be best option as it checks multiple routes
//pinMode(PWR_UC, OUTPUT); //option 3, works
//digitalWrite(PWR_UC, LOW);
//delay(3000);
System.sleep(SLEEP_MODE_DEEP, 5);
FWIW. I actually revered to what jamesza did. As the module would not enter sleepmode correctly when there was a poor connection.
I think I got the same issue: after months on the field a device start to drain lot of battery during the SLEEP phase.
before 8th Aug the device was always running above 80%, loosing 1-2% during night cycle (it wakes up every hour for a couple of minutes) and recharging the battery during the day with the solar panel.
After that date the battery drain almost completely during the night, and during the day the charge never go above of 70% during sunny days.
Looks like an hardware failure (I didn’t changed the code). How can I troubleshoot it and maybe solve it?