Better Battery Life for Delightful Particle Mesh Deployments

[jaredwolff]

Over the past weekend and earlier this week, I had a chance to characterize the low current capabilities of the mesh boards. I was particularly interested in seeing if I could run a Xenon off a single cell battery for extended deployments.

The idea of my project is simple. Create a motion sensor board that can last years on a single CR2032 battery. It would detect motion, send a message over mesh and go back to sleep. The device would spend >95% of it’s life in sleep mode. Unfortunately that 95% has to be optimized or it’ll never laster more than a few months at best.

I measured the devices in the two different sleep modes. Unfortunately it was not as promising as I had hoped:

Li @ 3.4V (mA)	Deep Sleep (uA)	Stop Mode (uA)
Xenon	834	846
Boron	1387	1978
Argon	846	1333

Side note this is extremely dependent on hardware and the firmware involved. I used DeviceOS 1.4.0 for this particular experiment. I also know that this hardware is extremely capable of getting down in the µA range. It just takes some elbow grease and time.

I understand that these boards are not meant for low power deployments through convention means. There is a way around it though…

Bypassing all the power circuitry.

At this point you may think I’m wacko, but the fact of the matter is, most of the chips on a Xenon can actually tolerate a wider voltage range. Officially, using data sheets, it’s 2.7V to 3.6V.

This means, for the most part, a CR2032 can be connected directly to the 3.3V signal. Testing in the same modes as above, I found the Xenon went from 846µA to 49µA. That’s a 17x improvement.

Since making that decision, I’ve had my freshly assembled motion sensor spamming me with Pushover messages. There’s still some more optimization to do but it’s getting there.

I wrote up a much more lengthy guide on the subject. For folks wanting to eke out every single µA in their batteries you should check it out.

Important note: this should go without saying but using a Xenon outside it’s normal operating mode could prove disastrous if you’re not careful. I’ve bottled my years of experience building embedded hardware into this guide. If you decide to do it yourself proceed with caution! (and make sure you never put more than 3.6V on the 3.3V rail!)

Here are a few more pictures of the “naked” assembly:

[Rftop]

Great Post. Thanks for sharing.

My testing showed 47 µA for a Sleeping Xenon when using the 3V3 pin, which is confirmed by your results.

But I never found a CR2032 datasheet that could support the 8 mA demand (operating) for any reasonable life (before the voltage sag causes a brown-out condition).

Have you had a chance to test the Total number of Xenon cycles for (1) CR2032 ?

Exciting stuff…thanks again for sharing!

[jaredwolff]

I haven’t been able to stress test the CR2032 + Xenon. One thing that will prevent 3.3V from going below 2.8 is the power supply supervisor. Currently it’s set in hw_config.c under platform/mcu/nRF52840/src. The best way around it is to use a STARTUP macro changing the value to something lower or disabling it all together.

STARTUP(sd_power_pof_threshold_set(NRF_POWER_THRESHOLD_V20));

If I have a chance to cycle the Xenon with a fresh battery, I’ll share the results here.

[armor]

Thanks you for sharing this journey into ultra low power. Using a LiPo battery (which could be quite a bit bigger energy storage wise than the CR2032) do you think it would be possible to do the same or is it a binary choice with using 3V3 as Vin or the Li+?

I have been working on a more sophisticated presence detection using an AMG8833 - LR-TAS - the Xenon allows some fairly sophisticated feature extraction and scene activity detection. The downside is the processing time and power! Next step is to sleep/stop as much as possible - the sensor has a nice feature whereby it can periodically read the thermopiles and then generate an interrupt if any have detect a temperature over a threshold.

I am guessing that a X-SOM when/if it arrives would allow much better power control since the power management circuitry is not on the SOM.

On the PIR side of the equation had you considered using a low power MCU to do the digital signal processing and then wake the Xenon for a bit mesh comms when it has detected some movement. I am guessing the analog signal path does some difference to create a detect signal to the Xenon?

[Rftop]

@armor

Using a LiPo battery (which could be quite a bit bigger energy storage wise than the CR2032) do you think it would be possible to do the same or is it a binary choice with using 3V3 as Vin or the Li+?

@armor, my results showed only a 1 µA increase in sleeping current when moving to the Li-Po Connector.
But as you know, Current (mA) doesn't tell the whole story.
In reality, the Power (mW) is 1/3 more when using the onboard regulator during Sleep:

Direct Drive the 3V3 Pin @ 3.29V, "NO Li-Po"
Xenon:  Sleeping using System.sleep( {}, {}, 600);  = 47 µA (0.047 mA) @ 3.29V = 0.15 mW

Li-Po @ 3.90V resting, on Li-Po Connector.
Xenon:  Sleeping using System.sleep( {}, {}, 600);  = 48 µA (0.048 mA) @ 3.90V = 0.19 mW

Sleeping at 0.19 mW isn't a "Bad" option considering the additional headroom for battery voltage/chemistry if you need it.

But @jaredwolff's detailed explanation of the power supply supervisor in his linked Guide has me itching to find a reason to test a CoinCell Xenon.

[jaredwolff]

@armor

I have been working on a more sophisticated presence detection using an AMG8833 - LR-TAS

The GridEye is an awesome little part. A company I regularly work with uses it in one of their designs. Unfortunately (sorry to be the bearer of bad news) I had spoken with Panasonic's engineering team and they said not to deviate from 3.3V at all. So, running it on a CR2032 directly is out. But, you can add your own regulator connected to the CR2032 that will keep it consistent. It's highly likely that it will draw much less than the Xenon in sleep mode!

@armor

I am guessing that a X-SOM when/if it arrives would allow much better power control since the power management circuitry is not on the SOM.

You are correct. You'll have much more control over it. I have other NRF52 design that sip current in stop mode because they're optimized from the ground up.

@armor

On the PIR side of the equation had you considered using a low power MCU to do the digital signal processing and then wake the Xenon for a bit mesh comms when it has detected some movement. I am guessing the analog signal path does some difference to create a detect signal to the Xenon?

You're spot on! My next plan of attack, since 49µA isn't great, is to use a load switch to remove power from the Xenon completely. I would run the PIR and onboard RTC which would trigger the load switch on an event. This would effectively reduce the current to something like 3µA!

[armor]

I had spoken with Panasonic’s engineering team and they said not to deviate from 3.3V at all.

Strange you mentioned that, I have found that when the LiPo is recharging for some reason the 3V3 dips and then the AMG8833 doesn't go into normal mode - the command returns an error which only a complete re-power will cure. My current strategy for using the sensor is to manually read every 2 seconds whilst there is presence but to go to standby and reading every 10 seconds with Xenon sleeping waiting for interrupt when there hasn't been any for a short while, on receiving the interrupt the Xenon wakes and puts the sensor in normal mode and starts the cycle again. I am thinking of using a on/off schedule managed by the RTC (a DS3231) that has its own coin cell power.

[jaredwolff]

@armor

Strange you mentioned that, I have found that when the LiPo is recharging for some reason the 3V3 dips and then the AMG8833 doesn’t go into normal mode - the command returns an error which only a complete re-power will cure.

Yikes. I'm not surprised you're having the issue

@armor

I am thinking of using a on/off schedule managed by the RTC (a DS3231) that has its own coin cell power.

That's one way to go about it! You can also use a separate PI to trigger a wakeup. After waking up you could put the GrideEye into normal mode. Using an external RTC though is always a great option.

[shanevanj]

This RTC is a great candidate - SRAM and EEPROM for you to store data during shutdown, brownout time stamps - two programmable wake up features etc. Discussion here as well

Boron / Xenon / Argon Carrier for Outdoor Applications

@shanevanj, OK, but what if we connected the RTC to the EN pin instead of the D8? That way, the Alarm would turn on the power for the device itself. For now, we can table this but it could be something to look at in the future. So, proposal is to go with @rickkas7 RTC and library integrated into this board. Chip Chip

[armor]

DS3231 is a highly accurate I2C RTC - I haven’t seen any mention of SRAM and EEPROM in the datasheet - did you mean registers?

[shanevanj]

Sorry didn’t include the link, its the MCP79402 I wanted to mention

https://www.microchip.com/wwwproducts/en/MCP79402

[armor]

No worries - just thinking I had missed something rather useful. The MCP79402 isn’t as accurate and for prototyping means building your own feather (as per RK’s design).

[chipmc]

Very cool design. I am using the PYD1798 in my designs. What are you using for the PIR sensor?

Where did you get those sweet SMD headers. Is there a part number you can share?

Thanks, Chip

[picsil]

Yes, those SMD headers are very nice! I was looking for some like that.

[jaredwolff]

@chipmc

Very cool design. I am using the PYD1798 in my designs. What are you using for the PIR sensor?

Thanks @chipmc I'm using a IRA-S210ST01.

@chipmc

Where did you get those sweet SMD headers. Is there a part number you can share?

@picsil

Yes, those SMD headers are very nice! I was looking for some like that.

Headers are:

91601-412ALF
91601-316LF

[picsil]

Oh boy, I don’t think I want SMD headers that badly. I’m paying Adafruit about $1 per set right now for through-hole headers. I guess I’ll keep hand soldering them.

[jaredwolff]

Yea, they come at a cost… In my case I couldn’t have anything on the top side except for that PIR sensor. So, SMD was the solution.

[picsil]

That’s what makes us engineers! We find the most optimal solutions with the most acceptable tradeoffs in design, function, and cost. Every project is different in each!

[chipmc]

@jaredwolff,

Thank you for sharing!

Chip

[emile]

Great post! @jaredwolff did you share the final code anywhere?