[solved - beta electron issue] SLEEP_MODE_DEEP but still using 2,7mA while it should be 0,13mA

so this is my code, as simple as it gets, I am just doing tests on the power consumption of my electron, if I run this code then my electron will consume 2,7mA and flicker up to 8mA and even sometimes up to 35mA (just for split second) and then back to 2,7mA… wich is rather strange, but then there is another strange thing that “fixes” the problem… I have my multimeter measure the current and set it to mA scale (shows 2,7mA) but if I switch the meter to A (amper) scale and then back to mA then all out of sudden the deep sleep current is only 0,13mA (just like it should be) and stays there (not flickering up to 5-35mA) and even though I press the reset button on the Electron the deepsleep current will maintain at 0,13mA, however if I unplug and plug the battery then the strange behavior starts again, consuming 2,7mA in deepsleep and flicker up to 5-35mA once in a while. I have tested this on two electrons, and I don’t have this issue if I use a photon, to me it seems to be something in the “power supply” part of the electron, but I don’t know… anyone else had this problem?

 SYSTEM_MODE(SEMI_AUTOMATIC); 
    
    void setup(){
                         //nothing to setup
    }
    
    void loop() {
    delay(500);
    System.sleep(SLEEP_MODE_DEEP,60);   //go to deepsleep every minute (and wake for 1second)
    delay(500);
    }
1 Like

@BDub Any thoughts about this? I know you’ve spent the most time working on deep sleep current consumption on the Electron.

one thing propably worth to mention that I have found out… if I don’t run the electron in offline mode (allow it to connect using the cellular modem) then the deep sleep will only work once the cellular has connected one time… it seems like the eletron first “needs to see” a voltage drop before it will be able to turn of the cellular modem… when I was running the electron in offline mode, then the voltage drop caused by switching scale on the current meter (switching scale caused a larger series resistor beeing connected and thus giving a voltage drop) and when running the electron in “online” mode then the voltage drop is caused by the relatively large powerconsumption when the electron is connecting/publishing… after this first voltage drop then the electron is able to power off the cellular modem but not before… to confirm this I just found out that this 2,7mA and flickering up to 50mA is the same as if I would put the electron to sleep (not deep sleep) with the cellular kept on during sleep… but why the electron need to first get this voltage drop is a big mistery, and in many cases does not matter if you start your program by connecting before taking the first sleep.

Sorry forget what I just said before… it must have just been a coincidence that the deep sleep did seem to work when I was online… now I was testing again with another code and it does not work, the cellular does not turn off (or that is my believe atleast) atleast the current consumption is jumping from 2,7 up to 80mA… this is the code I am using now

SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);
char publishStr[20];
int sleepInterval = 1;
int maxChange = 5;  //the ammount in centimeters that the waterlevel has to change so it will be published

uint16_t waterlevel;
uint16_t oldWaterlevel;
uint32_t start;

void publishData() {

  Cellular.on();
  Cellular.connect();
  if (waitFor(Cellular.ready, 100000)){
    Particle.connect();
    if (waitFor(Particle.connected, 100000)){
      sprintf(publishStr, "%i cm", waterlevel);
      delay(1000);
      Particle.publish("Waterlevel", publishStr, PRIVATE, NO_ACK);
      delay(1000);
      Particle.process();
      }
  }
  delay(1000);
  Cellular.off();
  delay(1000);
}//void publishData()

void getWaterlevel(){
  //has not been implemented yet
  //read waterlevel sensor and put the outcome in the waterlevel integer
  waterlevel=102;   //for test purposes
  oldWaterlevel=94; //for test purposes so that the differnce between new and old waterlevel is more than maxChange, resulting in particle.publish
}

void setup() {
  //nothing to setup
}//setup()

void loop() {

  EEPROM.get(0, oldWaterlevel);                           //get the last published waterlevel to be able to compare
  getWaterlevel();                                        //get new waterlevel
  if (abs(waterlevel-oldWaterlevel)>maxChange){           //publish data if waterlevel has changed by more than maxChange
    publishData();
    oldWaterlevel=waterlevel;
    EEPROM.put(0, waterlevel);                            //safe Waterlevel in EEProm because deep sleep will reset the MCU
    }
  System.sleep(SLEEP_MODE_DEEP,60 * sleepInterval);       //go to Deep sleep for "sleepInterval" minutes
}//loop

What firmware version are you running?
Have you updated to 0.5.2 already?
If not, do.

This is a production Electron and not a beta unit (if you were a beta user back then)?

Yes I had already updated to 0.5.2 few days ago (it was 0.4.8 before)

Just tested this example code and measured 118uA when off.

SYSTEM_MODE(SEMI_AUTOMATIC);

void setup() {
    delay(1000);
#if (PLATFORM_ID == 6) || (PLATFORM_ID == 8)
    System.sleep(SLEEP_MODE_DEEP, 60);
#elif (PLATFORM_ID == 10)
    System.sleep(SLEEP_MODE_SOFTPOWEROFF, 60);
#endif
}

void loop() {

}

SLEEP_MODE_SOFTPOWEROFF is the same thing as double tapping the MODE button, and will ensure the Fuel Gauge is put to sleep as well.

When you put your current meter in uA and mA modes, it will have a high burden voltage (I*R drop in the meter) that will not allow the Electron to boot up properly. Start by booting the electron with the meter set to the largest measurement range (10A) typically. Then wait for the reading to drop to 0A… then switch your meter to mA or uA modes. You’ll need to ensure that when you switch modes, your meter does not open the current path to the battery. This can typically be achieved by bridging the A and mA/uA inputs together or when in (10A) mode, bridge your battery connection back together… then switch your lead on the meter from 10A to mA/uA… then unbridge the battery connection.

I avoid the bridging hurdles by using a better current meter, the uCurrent Gold designed by Dave Jones.


You should not need the Cellular.on/connect/off sequence in SEMI_AUTOMATIC mode. Just Particle.connect() and System.sleep(). If you are only sleeping every 60 seconds, you should use sleep stop mode and just keep the cellular modem on to avoid the heavy power and data usage of reconnecting to the cellular network and re-handshaking with the Particle cloud. Deep sleep should be used when you are sleeping for long periods of time, such as hours.

2 Likes

Thanks for the reply BDub,

I will try your example code and see what I get, can you explain to me what these platform IDs mean and why you use sleep mode deep for ID==6 or == 8 and then use Sleep mode softpoweroff if the ID is 10 (I am guessing that platform 10 means Electron and ID 6 and 8 are Core and Photon)

the goal is to only take few measurements per day once per hour Max, end even down to once per 24 hours if there is nothing happening with the waterlevel and it stays the same. that is the reason why I want to turn off the cellular, because I want the electron to wake up and check the waterlevel and only go online if there is something “interesting” to publish e.g. if the waterlevel has increased or decreased by more than 5cm. maybe worth mentioning that the pond that I am measuring is pretty big, around 100m3 reservoir for a micro hydro project I am working on, so the waterlevel changes slowly, and can sometimes almost stay the same for days, and then I only need a “confirmation” once or twice per day that the waterlevel is the same.

Here is a readable list of PLATFORM_IDs
https://github.com/spark/firmware/blob/develop/platform/shared/inc/platforms.h

And you’r right 10 is Electron which is currently the only one that features that sleep mode.

As it turns out you got similar advice about sleep modes of @BDub here as in your other thread :wink:
How to get Electron to publish value if value has change by more than X, and then enter deep sleep?

OK So based on @BDub code

you should use SLEEP_MODE_SOFTPOWEROFF instead of SLEEP_MODE_DEEP for electron? because that is the only way to reliably shut down the cellular modem (and also the Fuel gauge which is even better) can I somewhere read about the SLEEP_MODE_SOFTPOWEROFF? I tried to do a search but all that comes up is this thread...

do you have any logical answer about why the cellular does not turn of in deep sleep mode if I use the code that I posted above? even though I call Cellular.off(); before going to deep sleep

I added an issue to add this to the docs: https://github.com/spark/docs/issues/439

I’m not sure why at the moment the modem would still be on after calling SLEEP_MODE_DEEP, but if that is easily repeatable we should file an issue in the firmware github repo with a minimal code example.

I am still having problem with my electron not shutting down the modem (or atleast it still uses 18mA, and sometimes up to 50+ mA) when in SLEEP_MODE_DEEP or SLEEP_MODE_SOFTPOWEROFF. It should only be consiming around 100µA when in this mode, and it seems like it the modem that is the problem, why do I say that? it is because When it really enters deep sleep and shuts everything down and goes down to 100µA then when it wakes back up then it will blink the green LED for awhile 1-5 minutes or so before flashing and then breating cyan, but how it behaves on my electron then it only gives a short blink of green when it wakes up and then flashes the cyan and then breaths cyan. I have managed to get it to deep sleep (so it only consimes 100µA) by increasing the burden resistor on my current meter (switching to µA scale and then switching back or bridgeing the ampermeter) and if I do that then the electron will keep consuming only 100µA even though it wakes up and goes back to sleep (without ever connecting to the mobile network) but if it connects then the problem starts over again and the electron can not go back to real deep sleep mode unless I switch my current meter to µA scale and then back again…

My guess is that you are running into this issue: If you use a meter in the low-amperage range (nano or microamp), the meter cannot pass enough current to operate the Electron properly. The Electron requires as much as 1.8A, 1800 mA. The thing is that the Electron almost works, however it gets into a weird state caused by insufficient current to operate properly. In particular, it often will not connect to the cellular network (blinking green forever) and the cellular modem will not go to sleep properly. Whenever I need to measure the sleep current I make sure to short the meter leads together until it actually goes to sleep, then I can test the sleep current in a low-current range.

HI rickkas thanks for the suggestion, but that is just what I have also been doing (shorting the meter leads together until the elecrton is in sleep) but I also figured out, (just with “luck”) that if I did not short them and changed to µA scale then the electron did finally turn off the modem… anyway if there is someone that is willing to share a code with SLEEP_MODE_DEEP or SLEEP_MODE_SOFTPOWEROFF that works then I would really much like to see that code and try it on my electron and see if I get it working… I think that the flashing green is normal after returning from deep sleep, or am I wrong with that?

Yes, you go through blinking green, blinking cyan, fast blinking cyan, and then to breathing cyan over the long cycle (30 seconds to a few minutes) if you’ve successfully entered deep sleep or soft power off.

There’s not much to the code:


void setup() {
}

void loop() {
	System.sleep(SLEEP_MODE_DEEP, 30L);
}

Thanks, yes this code works (giving me 130µA while in sleep), now I have narrowed my problem down a bit… if I add SYSTEM_MODE(SEMI_AUTOMATIC); in the beginning then I get the problem back… and I need my code to run offline and check a pressure sensor and only go online and publish the reading if it has changed…
so your code works but not this…

SYSTEM_MODE(SEMI_AUTOMATIC);
void setup() {
}

void loop() {
	System.sleep(SLEEP_MODE_DEEP, 30L);
}

can any of you guys maybe try this code and measure the current your electron consumes while in sleep_mode_deep? mine is consuming 2,8 and up to 80mA… then after a while of running it seems to get almost stable at 2,8mA… but it should be 0,13mA… any idea why this is not working in SYSTEM_MODE(SEMI_AUTOMATIC); ?

@Mquist I have been trying to achieve this deep sleep target current as well.It appears as though the issue of the current being unstable when in sleep mode is dependent on whether the Electron has connected to the cloud before shutting down. So your issue above with starting SYSTEM_MODE(SEMI_AUTOMATIC);, or in my case MANUAL is not the point, the problem will go away if you do a full Particle.connect() and then shut down.
I realise in your case, and in mine this is not a good thing because we do not want to waste power connecting to the cloud when we may just be coming up every so often to check a sensor and see if we need to connect to the cloud. The deep sleep runs the code from the start so there is no way of avoiding the connection to the cloud.
I have experimented with System.sleep(A7,CHANGE,60); and the instability of the sleep current is solved by ensuring that a cloud connection is made once, then because coming back from sleep and not deep sleep does not start the program from the beginning it is possible to avoid the cloud connection. In this case the sleep current is stable every time the unit goes to sleep. I suspect this would be so with deep sleep also, it just needs that one connection to the cloud and then the current is stable.
But why? @BDub , you seem to be a keeper of all wisdom, what is it that the Electron needs from the cloud to stop it wanting to do something extra and cause fluctuating sleep current?
@rickkas7 in order to reduce the Electron current to around the 2.7mA in sleep mode I had to turn off the battery charging and flashing red led as per your helpful post Disabling the Electron red charging LED when not using the LiPo
I also seemed to have to set the pulldown on all inputs on the Electron which were ‘floating’ when in sleep mode. This did significantly lower the sleep current, seems to make no difference in deep sleep but normal sleep it does.
I can confirm in my case it has nothing to do with the resistance of the current meter, I get the same results on high and low range and it is a very good meter.
However, no matter what I try, I cannot get deep sleep current down to fractions of a milliAmp. It stubbornly refuses to drop below the 2.7mA, which is roughly what it is in ordinary sleep mode. I have pulled apart the circuitry surrounding the Electron, cutting tracks and measuring currents to the peripherals and the 2.7mA is all being consumed in the Electron.
I will keep on trying but I suspect that @rickkas7 simple code above
void setup() {
}

void loop() {
System.sleep(SLEEP_MODE_DEEP, 30L);
}
does not work on an Electron with 0.5.3 firmware
Thanks for any help. You guys back at HQ are fantastic.

See this bug, it may be related

@wesner0019 thanks for that, there could be some linkage, it certainly seems odd that the devices need some reassurance that the cloud is still there before going to sleep. My grandchild seems to need some reassurance that I am around when he comes to visit before he goes to sleep too so maybe a child psychologist can help?

1 Like

Have you seen this thread?

On the Electron you won't need a full Particle.connect() but only a Cellular.on() in order to fully switch it off before sleeping (odd but true - for now).
So you won't see any data/power penalty, since you don't actually connect to the cloud and not even to the cell tower.