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]

Yes, sorry :) Fixed

[michurin]

Sure, that is why I want to avoid doing math without communication on schedule! So, gathering data isn't an issue, wake up/sleep - not biggie, math is! How can I set up RTC to wake me up just before radio exchange? Do you have an example?

Thank you and appreciate you help.

[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

[michurin]

Here what I'm thinking: the client will communicate with my server at sub Hertz rate. I'll have large slave latency and can start to do my math on connection event. Does it sound reasonable?

[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.