Better Battery Life for Delightful Particle Mesh Deployments

[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]

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]

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!

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.

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]

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

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]

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.

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

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?

[gusgonnet]

impressive post, and who can dislike a Delightful Mesh Deployment? Nice choice of words.
Congrats and thank you, Jared.

[jaredwolff]

Not yet. It’s still a work in progress. Stay tuned

[jaredwolff]

Quick update.

After testing my PIR sensor for a while, I noticed that it went offline. (Stopped triggering)

At some point during the process the processor had reset when the battery voltage was lower than usual. This put the firmware into a perpetual lockout. i.e. The board starts up, sees that the voltage is low and resets. During this time it draws about 5mA which doesn’t allow the battery voltage to recover.

Despite my best efforts using the STARTUP macro, the voltage comparison code gets initialized before that either in the boot loader or in the system code.

The way around it is to modify the OS. Will report back what needs to be done where. I’m also trying to figure out where the sweet spot is in terms of update frequency. I shifted another device in the other room to updating if the room is occupied/not occupied. Less spam from Pushover.