Custom service design: irq vs timer

[michurin]

I have several asynchronous аperiodic sensors with their interrupt handlers. My service should gather the data from those sensors and do some math. The outcome of this math may be cause of alarm. Delays in few seconds are acceptable. Losing some alarm conditions are also fine - I need continuous event. I leaning towards launching my service via timer and not when one/each sensor interrupt has occur. The battery life is more important than some delay. Your suggestions please.

[Stefan Birnir Sverrisson]

General guidance on how to minimize current consumption is available on this thread.

I understand it so that you have multiple sensors on your PCB. The nRF51822 should gather sensor data from those sensors and send it wirelessly via BLE.

Do your sensors provide analog or digital output?

If the sensor output is analog, you can periodically wake up the chip with a low power RTC timer and sample the sensor voltage with the internal ADC. Instead of sampling periodically, you could use the LPCOMP to wake up the chip when an input voltage exceeds a certain threshold.

If the sensor output is digital, you can gather data on the UART interface, SPI interface or the TWI interface. Perhaps it is possible to provide a wakeup signal from your sensors to the nRF51822. The nRF51822 will then enable the UART, SPI, TWI interface and receive data, forward it to the softdevice in order to send it over the BLE link, and then go back to sleep. If you have the nRF51822 configured as SPI slave, then current is only consumed when the SPI slave interface is active, i.e. when the SPI master sets CSN (chip select line) high when sending/receiving data.

It might also be possible to periodically wake up the nRF51822, enable the communication interface, and send a GPIO signal to the sensors, indicating that they can send data.

[michurin]

I'm working on a family of devices. Different sensors, different configuration. But the same design, the same output - alarm. Devices are disposable so have to live long enough or in other words battery consumption is a key. My question asks how to design, and not how to reduce consumption: I'm familiar with that particular aspect but not mach with BLE. Based on what I read and know my plan is to go with very low sub-Hertz exchange rate to the client and thus allows me to deal with delays. The plan is to read from the sensor(whatever it happens to be) using interrupts and store the data and then using timer to do the math. Another option was to do the math using interrupts from the sensor(s), but they are aperiodic by default. Where can I find the wakeup event for the next scheduled comm to use this for my math? Thank you for your input.