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]

What are you actually trying to achieve? To answer your question it would be good to know if you are trying to achieve low current consumption, high throughput or anything else. You say that delay is not important, but what is important then? Also, what is your sensor output, digital signal, serial communication, or analog signal? How is your sensor interrupt generated? A more description of your scenario would perhaps be helpful in order for me to understand what you are trying to do.