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

Neither of those examples will work properly.

The first because Cellular.off() is not blocking in system thread enabled mode and you will go to sleep before the modem is fully powered down, leaving it running.

The second should have even lower current, but because you’re using SYSTEM_MODE(SEMI_AUTOMATIC) the modem is not turned on, and putting it into sleep in that state won’t get it into the lowest power mode.

If you are running 0.7.0 then 300 byte will be too little, due to some extra work done on reset in order to report reset reason and system diagnostics you should go with something about 1536 byte.

1 Like

ok thanks for the tip!

@rickkas7 do you know of any calls to verify when the cellular is turned off? Like waitfor(!cellular.powered) . I also tried e above code by removing the cellular calls and I had the same results.

I’ll have to check you tips page tomorrow to test those

We need to get this worked up into the Wiring API, but you can get a return value from the cellular HAL. You may not always be able to use the following code, but it should work right now (as of 0.7.0 & 0.8.0-rc.3). Note: these will also block with SYSTEM_THREAD(ENABLED), which might be a good thing :wink:

if (cellular_on(NULL) != 0) {
    Log.error("Could not turn cellular modem on!");

if (cellular_off(NULL) != 0) {
    Log.error("Could not turn cellular modem off!");
1 Like

Im currently using the Ugold meter to measure the current and have been trying to use the tutorial too, but the best I could achieve was about 500uA after the e0 connected to the cloud then went to sleep.

Then I looked through my hardware pcb to determine if there are any circuits that could be causing battery drain. I had a 10k pull-up on the TX line that was eating 300uA. I removed the pull-up then discovered this issue. Not sure if sleep could be affected by this.

I’ve done some minimal testing now trying to verify the battery consumption with the e0. With the minimal setup I’m still measuring around 900uA in Deep Sleep.

Can someone else please confirm this?

system version: 0.7.0
e0 version: v0.0.5

This is the test code:

#include "application.h"


void setup() {
  System.sleep(SLEEP_MODE_DEEP, 20);

void loop() {

And heres a picture of my setup:

With the E series running Tinker and powered by USB, I double-tapped the MODE button to go into soft power off mode.

Once powered off I enabled the meter in uA scale and unplugged the USB power. Consumption was 109.7 uA, what I’d expect.


@rickkas7 I just tried your setup (running Tinker and powered by USB, I double-tapped the MODE button to go into soft power off mode) and still can’t get it to that.

Did you perform this test at version 0.7.0?

I’m running out of ideas to try.

It was running 0.6.2, but I just repeated the test with 0.7.0 and it was 109.7 to 109.9 uA.

thanks I’ll have to try to recheck.

I just realized the only differnce between my and yours is that I added the external flash to the chip. I’m wondering if this is causing excess draw.

I’ll have to next try to remove it and retest.

It will have some effect, but it shouldn’t make that big of a difference. From the MX25L4006E data sheet:

  • Low active read current: 12mA(max.) at 86MHz and 4mA(max.) at 33MHz
  • Low active programming current: 15mA (typ.)
  • Low active sector erase current: 9mA (typ.)
  • Low standby current: 15uA (typ.)
  • Deep power-down mode 2uA (typ.)

Going into or out of deep sleep is just SPI commands sent to the chip so it should be pretty straightforward. But even without sleep it should only use 15 uA.

Cool thanks for looking into that.

ok i just verified the issue, it was infact the external flash chip soldered on the board.

I am now measuring 114.4uA draw AFTER I removed the flash chip.

I’m guessing that it was never powered-up correctly as per the data sheet causing it to draw excess power.

That was a long road to get there. Thanks for the help!

1 Like

@wesner0019, glad you found the issue but this statement leads me to think that this is may be related to the hardware surrounding the flash. Does it need RC delays on power or other pins? Which flash are you using?

@peekay123 I’m using the MX25L8006E-12G

From the data sheet it looks like the when it powers up the #CS must be high to function properly. Since this was never the case it likely never powered up correctly.

@wesner0019, it may also be the power down sequence:

During power down, CS# need to follow the voltage drop on VCC to avoid mis-operation

I cannot see any specs on the E0 flash. I wonder if the CS# pull-up is not installed by default.

The external flash uses SPI1 which are pins D2 (MOSI), D3(MISO), D4(SCK), D5(SS).

So D5 would need to be pulled up with power on and this is not the case with the E0

1 Like