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]

I think a good choice would be to have relatively short connection interval and a large slave latency. Then the softdevice will send your data over the BLE link with low latency, no matter when you perform your calculations, but it would still be relatively low current. Another method would be to get radio notification from the softdevice just before data is sent over the BLE link. In that case, you would not need a timer, the calculation procedure would be triggered when you get the radio event. This method requires though that you approximately know how long your calculation procedure will take at maximum, so you can finish the calculation in time and and hand your data to the softdevice before the BLE transmission begins. So if you decide on the method, we could try to dig up some code for it