I am trying to diagnose a B523-based product, where we are seeing around 4,97 mA current consumption during a ULTRA_LOW_POWER sleep with all peripherals turned off and on DeviceOS 3.0.0. I've tried isolating it on a SoM eval board but to no avail.
You can see the energy consumption graph here (logged using a Nordic Semi Power Profiler 2):
The sleep code that I am using in the following (SYSTEM_THREAD(ENABLED) and SYSTEM_MODE(SEMI_AUTOMATIC)):
// Initialize Power Configuration
SystemSleepConfiguration measurementSleepConfig;
// Ensure module is powered off.
Cellular.off();
delay(2000);
// Power Configuration
measurementSleepConfig.mode(SystemSleepMode::ULTRA_LOW_POWER)
.duration(sleepTime);
// Go to sleep
SystemSleepResult result = System.sleep(measurementSleepConfig);
It seems to match the following mode from the B523 datasheet:
Parameter
Symbol
Min
Typ
Max
Unit
Operating Current (uC on, peripherals and radio disabled)
Iidle
4.47
4.48
4.51
mA
It seems like the Quectel module is shutting down, but the Nordic nRF52840 is continuing to run.
Short update - I have an almost identical E-Series based board with same onboard peripherals as the B5-SoM board. However, I am successful in setting the sleep modes on that board (both ULTRA_LOW_POWER and HIBERNATE).
In addition, setting the B-Series board to HIBERNATE gets the consumption down to 4,63 mA from ULTRA_LOW_POWER’s 4,97 mA.
If I placed the B523 in the eval board and run the following:
// Initialize Power Configuration
SystemSleepConfiguration measurementSleepConfig;
// Ensure module is powered off.
Cellular.off();
delay(2000);
// Power Configuration
measurementSleepConfig.mode(SystemSleepMode::HIBERNATE);
// Go to sleep
SystemSleepResult result = System.sleep(measurementSleepConfig);
I am also experiencing higher-than spec’ed sleep current (610uA measured), but using the Boron LTE Feather module with deviceOS 3.0.0, as noted in my post here.
There are some others in the Forum experiencing similar with Argon hardware and deviceOS 3.0.0.
There seemed to be lots of Forum activity around sleep current issues around deviceOS 1.5.0; Based on the comments at the end of that thread, I may target some older versions and see if there was a regression in terms of sleep current. If I do, I will post my findings.
The issue above was identified as an issue with the Eval board - the W5500 Ethernet IC never shuts off and is responsible for the excess current, not the BSOM. Removing (desoldering) the W5500 brings the current down to the expected levels. (There are some nuances around the BSOM current ratings since it does not include a PMIC on the SOM)
I’ll respond to your post on current draw. High-side current measurements are not reliable when done passively. My tests with the Otii Arc revealed no issues on DeviceOS 3.x.
Pre 1.5 sleep current was atrocious - up to 75mA. 1.5 actually fixed most of it. I won’t recommend anything below LTS for sleep and 3.x if you need to disable charging. 1.5.x introduced many improvements to cellular connectivity and pivoted metrics away from raw signals strength to focus on quality as well. LTS/3.x is honestly the version you want to be on.
Thanks for updating the thread! As Chris mentioned in part 1. it turned out to be the W5500 Ethernet IC drawing a lot of current on the eval board. However, desoldering this only allowed us to check what min. power consumption that we should be able to reach with our own product, which was around 215 microamps.
We have done a bit more digging into it and it seems like radio etc. is off, but the nRF52840 is idling (4,67 mA on average doing ULTRA_LOW_POWER sleep) - which fits somewhat nicely with the stated operations current draw here: https://docs.particle.io/datasheets/boron/b523-datasheet/#power-consumption
Parameter
Symbol
Min
Typ
Max
Unit
Operating Current (uC on, peripherals and radio disabled)
A slight update, we did a comparison of the eval board vs. our own board without the B523/B524 and every peripheral desoldered incl. fuel gauge. Only thing pretty much left on the board is the BQ24195 PMIC and XC9258A33EER-G voltage regulator and it is still drawing ~ 4.7 mA
Another update, removing the XC9258A33EER-G voltage regulator (powered from the PMIC) makes the power consumption drop down to 38,05 µA - now looking at why the regulator is using so much power without any peripherals and the B-series board.
Update: we confirmed that the switching regulator was the issue, why? We do not know as it is the only remaining active component and datasheet specifies a significantly lower power-draw, so we are switching it out with a low-power chip.
