Electron sleep problems, yet again


#16

any insight?


#17

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.


#18

no afraid not, this is 2hrs after :frowning:


#19

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?


#20

Through the Lipo input


#21

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.


#22

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.


#23

Very nice breakdown!


#24

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 :memo: or look in this thread


#25

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.


#26

How exactly are you pulling the UC pin low? In code right?


#27

Like this…

void hardShutdownModem(void)
{
pinMode(PWR_UC, OUTPUT);
digitalWrite(PWR_UC, LOW);
delay(1500);
digitalWrite(PWR_UC, HIGH);
}


#28

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.


#29

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);


#30

Hi James

I wonder why the

Serial.flush();
Serial.end();

are so important?


#31

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.


#32

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.


#33

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.


#34

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 .


#35

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.