BME680 + BSEC lib + ARM Cortex M0+ (STM32L071) optimization for battery powered applications?

Hi there!

To verify that my integration is correct, I used the BSEC configuration "generic_33v_3s_4d" and the sampling rate BSEC_SAMPLE_RATE_LP (one sample every 3 seconds).

The BSEC library wakes up every 3 seconds to take a BME680 reading and report the calculated values (IAQ, eCO2, VOC, ...). The whole operation takes a whopping 281 ms out of 3000 ms and that will kill the battery in no time 😞

I then proceeded to use the BSEC configuration "generic_33v_300s_4d" and the sampling rate BSEC_SAMPLE_RATE_ULP (one sample every 300 seconds).

The BSEC library still wants to wake up every 3 seconds, but only wastes 3 ms each time. Every 300 seconds it takes a reading and reports calculated values. This operation takes 2031 ms, not 281 ms. This is still bad if the application is supposed to last for years.

Why does the BSEC library want to wake up every 3 seconds? Can I safely ignore and only call it once every 300 seconds?

Are there BSEC library settings to improve battery life, i.e. sleep for a long time, wake up to take a measurement and perform a calculation quickly and then go back to sleep?

Why must the time stamps be in 64-bit nanosecond resolution? It feels like overkill and a waste to me on a 32-bit architecture. Why would a 32-bit millisecond time stamps not suffice?

Thanks in advance,

Pieter

piconomix wrote:

I suspect that my Makefile did not pick up the change to the "bsec_serialized_configurations_iaq.c" file and used an old object file. After fixing it, the BSEC lib expects to be called every 300 seconds.

Good to hear 🙂

piconomix wrote:

Why does the IAQ value vary so much between readings?

Honestly hard to say from 3 data points, and without knowing the environmental conditions during the 15 minutes observed here. What I can tell from this little amount data is that:

The IAQ is reacting to stimuli in the raw rag resistance signal, thus it seems to behave as expected,
It looks like IAQ accuracy is still at 1. This typically indicates that BSEC hasn't experienced significant enough stimuli (yet?), thus the self-calibration status is uncertain and could explain such variations. If the second value shows sIAQ with less significant variations, this could consolidate this hypothesis.

piconomix wrote:

If we were not interrested in IAQ, because of the excessive calculation burden, but only eCO2 and VOC, would there be a simpler formula / procedure available to calculate it from the gas resistance?

Which outputs are enabled will not impact the integration efforts. In fact, eCO2 and bVOC_eq are derived from the sIAQ output, thus the same internal calculations would still be needed.

piconomix wrote:

FYI: we are using the BME680 in a battery powered IoT device that must take a measurement and send an RF packet with the data to a gateway that relays the info to a server. It is vital that the device's battery last as long as possible.

Since you mention it, a valid integration is also to collect only raw BME680 data at the edge, and run BSEC in your gateway or server. Of course of the BME680 needs to be operated with the appropriate settings, and an absolute timestamp is still mandatory. If BSEC outputs are still needed at the edge (e.g. to be displayed on a screen), you would need to consider how to stream the relevant data back to your device though. Pros and cons must be defined for your specific use-case.