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?
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.
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);
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.
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?
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.
@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!
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?
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.
@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.
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.
@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!
@rickkas7 - Can you provide an update on this investigation and where the development is at? I can appreciate the additional work that would be involved in deploying eDRX on the server side. I would hope this is being prioritized appropriately since so many IoT applications require low power/battery operations.
I am really hoping this can be address long term with firmware for the new SARA-R510S modems and this is somewhere soon on the roadmap!!!
In the meantime, is there any type of work around where I could enter/exit eDRX mode via AT Commands but just not have the ability from the cloud to be synchronized with it? In my use case, my main need is having to publish frequently (every 5 minutes). So entering a full sleep mode isn’t effective due to the short durations but burning an extra 25 mA on the BRN404X the other 4 minutes 58 seconds, is way too costly on the battery budget. My thought is could I enter eDRX on the device to enter a lower power mode and simply exit/re-enter that mode every time I need to publish?
Having followed this thread with interest, I would like to suggest this should be a major focus for Particle. It may be already, which would be great but, then more communication might be required.
As you know, my experience is primarily with devices that power down and only connect after an hour or so and, in this case, this is not a significant issue. However, I also see growing demand for devices that report “occupancy” rather than visitation and, in this case, you can’t predict when or how often the state will change. As my supplies of BRN402 and 402’s dwindle, I am starting to worry that Particle can’t provide a solution for this type of use case. As @jgskarda and @rickkas7 point out in this thread, the difference in power consumption is more than 2x.
I can understand that implementing eDRX could be a significant undertaking. But, are there other solutions to help bridge us to that point? If not, is there any way to make BRN404 inventory available for the “cellular network standby” use case? I would be helpful to get some statement about a roadmap to a solution to this issue.
It’s believed that it will be possible to reduce the power consumption in sleep mode with cellular enabled from its current level. It possibly will not be not all of the way to the R410 level, but much closer than it is now, on the R510, without having to enable eDRX.
Likewise, very much appreciate the update and I am excited to hear this is being investigated by the team! Getting back to a near R410 current consumption in sleep would be a huge improvement!
@rickkas7 - Just following up on this one. I noticed the latest Device OS 5.5.0 release notes in this thread makes reference of a new enhancement that references low power mode.
[Cellular] Enables UPSV=1 low power mode for R510 when idle for >=9.2s #2674
Is this what you were referring to? Is this some hybrid eDRX mode or what exactly is UPSV=1 Low Power Mode vs eDRX? I skimmed through the spec sheet of the R510 manual and seems like UPSV=1 allows for low Power mode of the radio correct?. I tried reading through the github repo pull request #2674 as details on how to leverage this new mode? The wording sure seems like it will allow a lower power mode though and this otti plot from the github pull request looks promising.
Is there anything special we need to do within our sketch to leverage this UPSV=1 Low Power mode for R510? Am I reading this right that we should expect 14.5 mA?
I'll try to repeat some tests later this week/next weekend. I'm excited to see the progress being made to address this by you and the team and Particle!
Yes, that is the power saving change that did not require enabling the full eDRX mode. It does not significantly affect power usage when transmitting and receiving, however it does reduce it when idle, and in sleep with network standby modes. The power usage should be lower with Device OS 5.5.0 or later and the R510 modem than it is with the R410. In network standby mode, the R510 usage is half to a third of the R410. The power improvement is 5.5.0 only for the R510.
I’m guessing this won’t happen overnight though.