BRN404 vs BRN404X - 2.4X increase in power consumption?

jgskarda · February 15, 2023, 5:29am

After having several of the new shiny BRN404X Boron’s deployed on battery in the field, I quickly noticed how much faster the battery was draining. Tonight I finally had a few minutes to spare and hooked each one up to my “Current Ranger” and I was very surprised and disappointed to see nearly 2.4X increase in power consumption on the BRN404X.

To rule out any aspect of my particular firmware and my own PCB, I placed two Boron’s side by side in their respective breadboards and then flashed Tinker V5.2.0 via: Device Restore USB | Tools | Particle I hooked each one separately up to current ranger. Given a different cellular radio, I was expecting a slight difference but was shocked to see 2.4X the increase in Operating Current. Any ideas what is causing this? Is this a known issue? Is this expected to be addressed in a future firmware release?

BRN404: ~15.5 mA
BRN404X: ~36.5 mA

rickkas7 · February 15, 2023, 10:07am

I can reproduce that the BRN404X consumes more power with cellular on, cloud-connected, and idle than the BRN404. This doesn’t seem right, but I don’t know the cause.

Tested with 5.0.2 and Tinker on both. Powered by LI+ at 3.6V.

Green line is BRN404X
Red line is BRN404

I also repeated the test with the BRN404X using 4.0.2 and the power consumption is the same as 5.0.2.

jgskarda · February 15, 2023, 2:50pm

I was hoping you were going to say that. I sure hope this isn’t normal and can be addressed via device OS.

This is a big deal for me! A device that used to last 7-8 days in “always on” mode now only lasts maybe 3 days for a full battery. Trying to not let it go below 10% makes it requiring charging the battery every 2 days or so. I have sleep modes as well to extend battery life for multiple weeks but many times we need the device connected/awake to provide frequent Publish updates (every 5 minutes) as well as the ability to call particle functions for “on demand” readings. I also have a solar panel option but the solar panel is much too small now. I’m crossing my fingers that this will be fixed in a new device OS point release.

@rickkas7 Do you know if the ULP sleep with keeping network up is also affected by this? Do you think it’s coming from the network/cellular radio or the microcontroller itself? If you already tested this let me know, otherwise, I’ll run a test myself.

I.e. would something like this still observe the much higher current?
config.mode(SystemSleepMode::ULTRA_LOW_POWER)
.network(NETWORK_INTERFACE_CELLULAR)
.flag(SystemSleepFlag::WAIT_CLOUD);
SystemSleepResult result = System.sleep(config);

rickkas7 · February 15, 2023, 3:07pm

It appears that there is a higher baseline current whenever cellular is on, so using sleep mode with cellular standby is also higher for the BRN404X than the BRN404, tested with 4.0.2. The highlighted part is when in sleep mode with cellular standby, and the spiky parts after it are after wake.

With cellular off, the power consumption appears to be the same.

Test firmware:

#include "Particle.h"

Serial1LogHandler logHandler(115200, LOG_LEVEL_INFO);
SYSTEM_THREAD(ENABLED);
SYSTEM_MODE(SEMI_AUTOMATIC);

void setup() {
    Log.info("setup called");
    delay(15s);

    Log.info("turning cellular on");
    Cellular.on();
    delay(15s);

    Log.info("connecting to cellular");
    Cellular.connect();
    delay(15s);

    Log.info("connecting to cloud");
    Particle.connect();

    waitFor(Particle.connected, 120000);

    Log.info("connected to cloud");


}

void loop() {
    delay(20s);

    SystemSleepConfiguration config;
    config.mode(SystemSleepMode::ULTRA_LOW_POWER)
        .duration(30s)
        .network(NETWORK_INTERFACE_CELLULAR)
        .flag(SystemSleepFlag::WAIT_CLOUD);
    
    SystemSleepResult result = System.sleep(config);
    Log.info("sleep returned %d", result);
}

jgskarda · February 15, 2023, 3:46pm

@rickkas7 alright! Thank you very much for the update. I won’t waste my time testing sleep modes then.

In my haste 5 minute google search. Seems like the SARA-R510S is for ultra low power

In comparing the spec sheet, I am not sure what I’m all looking at but maybe device OS is not leveraging any of the cyclic idle/active modes and it just always has it in “active”. Per the spec sheet “Active Mode” is a 16 mA increase. (9 mA vs 25 mA)

Can we not leverage any of the “Cyclic idle/active modes”?

I suspect, you and the team at Particle are closely investigating this. I’m sure way early to tell but in your first pass technical judgement, is this addressable through updating device OS or is this a unintended/unforeseen consequence of the new supply secure hardware using the new SARA-R510S?

rickkas7 · February 15, 2023, 4:04pm

DRX/eDRX are currently disabled on all LTE Cat M1 devices on all versions of Device OS, so they are by default in active mode when connected to the network. However, that does point to a potential solution by enabling eDRX mode, which would dramatically reduce power consumption through a software change. In any case, Particle hardware and software teams are looking into the power consumption issue now.

jgskarda · February 15, 2023, 4:09pm

Thanks for the update Rick! I’m sure you and the team are on it!

Going from say 25 mA to 1.5 mA using eDRX would certainly be welcomed fix! I’m guessing this won’t happen overnight though.

jgskarda · February 17, 2023, 4:36am

@rickkas7 I know it’s only been 2 days but is there any update you could share on what was discovered so far and what the next steps are. If the team is still investigating, when could we expect an update? I am just trying to plan accordingly as I have many devices coming online the next several weeks many of which are reliant on battery power. If necessary, I want to prepare and communicate the scenario to my customers in advance. It would be greatly appreciated! Thanks again!

jgskarda · February 27, 2023, 5:11pm

Just to tie a few threads together… this use case seems a perfect application for eDRX mode: Trying to extend battery life on Boron - #2 by gusgonnet

Can you provide an update on where this is at? I’m not expecting a fix right away as I’m sure there is a lot of complexity in this one but just recognition that it’s being investigated and hopefully a plan is being developed to correct the significant power increase?

chipmc · February 27, 2023, 6:59pm

@jgskarda ,

Thanks for popping this thread.

For those (like me) who did not know how extended discontinuous reception, eDRX or power saving mode, PSM, works or what the potential could be, take a look at about the 30 minute mark for a 12 minute demo. In this segment Chris Gammell shows how you can tailor the way that a “modem shell” from Nordic can reduce the power required to maintain a connection to a cell tower.

While some of this is specific to the Nordic platform, these approaches could result in a significant reduction in the power required by the cellular modem. They allow you to negotiate a specific window when you will transmit to or receive data from the cellular network or reduce power consumption on reconnection. This could be very relevant to IOT applications.

I can appreciate how hard this might be to implement, but, like @jgskarda points out, it does not make sense to have the BRN404X take us backward in power consumption.

I understand that Golioth is a quasi competitor to Particle and this is a Particle forum. But, Particle and Golioth are quite different in their approaches and who they will appeal to. I am very happy with Particle but, I do think there are some things we can learn from their approach to make the Particle platform better.

Thanks, Chip

jgskarda · March 24, 2023, 2:54pm

@rickkas7 - Would you be able to provide an update to this ticket please? Is Particle investigating this and formulating plans/beginning development to reduce the power constraints? This 2.4X power is restrictive as it comes to battery operated IoT applications.

I don’t necessarily need an exact date or device OS we expect the fix to be in. I just would appreciate knowing if knowing this will be address or won’t be addressed in future firmware release. If it is addressed is it in the range of 1-2 months or more like 6 months? A 2.4X power consumption is significant and will need to plan accordingly if this is the new normal.

rickkas7 · March 24, 2023, 2:56pm

As it turns out, full support of eDRX is not an immediate possibility because it’s not just a matter of turning it on. It requires changes both on the device side and cloud side.

However it may be possible to change something short of full support, but this is still being investigated.

jgskarda · March 24, 2023, 3:02pm

@rickkas7 - Ok, I appreciate your response here. So in your technical judgement, will Particle eventually support eDRX on both cloud and device side. Say 6 months from now, 12 months from now or not at all?

I’d be interested in hearing more about possible to change something short of full support? Is this eDRX on device side only meaning the device can enter the mode and still stay connected to the cloud but the cloud can’t send data to it? Whatever work around or development is possible would be great to learn more and especially share rough timing to when something would be available to test.

Thanks again for the response and keeping us in the loop!