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.

[Stefan Birnir Sverrisson]

You can read more about how slave latency works in the first link I pointed you to on this thread, look at the "Tuning connection parameters" section. Method 1: large slave latancy and short connection interval. Set up RTC timer to calculate periodically and then give data to softdevice. Method 2: Set up radio event that will trigger your calcualation (happens also periodically) and then you give your data to softdevice just before connection event. I think both methods are equally low power. On second thought, I think that the former method is easier to implement, and additionally, you do not need to worry about time constraints of the connection event.