Custom service design: irq vs timer

RE: Custom service design: irq vs timer

Stefan Birnir Sverrisson — Fri, 22 Aug 2014 14:26:15 GMT

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.

RE: Custom service design: irq vs timer

michurin — Fri, 22 Aug 2014 14:14:05 GMT

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?

RE: Custom service design: irq vs timer

Stefan Birnir Sverrisson — Fri, 22 Aug 2014 14:07:23 GMT

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

RE: Custom service design: irq vs timer

michurin — Fri, 22 Aug 2014 13:54:33 GMT

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.

RE: Custom service design: irq vs timer

Stefan Birnir Sverrisson — Fri, 22 Aug 2014 13:49:37 GMT

Yes, sorry :) Fixed

RE: Custom service design: irq vs timer

michurin — Fri, 22 Aug 2014 13:48:09 GMT

"...but in System off you will draw less current than in System off." Is this typo?

RE: Custom service design: irq vs timer

Stefan Birnir Sverrisson — Fri, 22 Aug 2014 13:42:40 GMT

The overhead of waking up and going to sleep is small, at least if going into System On low power mode, the overhead is bigger if you enter System off low power mode, but in System off you will draw less current than in System On. So if you wake up once a second or 10 times per second from System On does not matter that much, the main thing is to make your code efficient so that the execution of it takes minimal time, to stay awake is what will cost you power.

RE: Custom service design: irq vs timer

michurin — Fri, 22 Aug 2014 13:40:25 GMT

"I think it is a good option to collect sensor data into a buffer and then periodically process the data." I think so too. You're saying RTC because other timers are in the sleep mode?

RE: Custom service design: irq vs timer

Stefan Birnir Sverrisson — Fri, 22 Aug 2014 13:37:01 GMT

I think it is a good option to collect sensor data into a buffer and then periodically process the data. You can do that with starting a RTC timer that periodically wakes up the chip to perform the calculations.

RE: Custom service design: irq vs timer

Stefan Birnir Sverrisson — Fri, 22 Aug 2014 13:35:15 GMT

I still have the feeling that you are asking questions I have already answered. Anyhow, I can point you to a code example which shows how to wake up the chip with a press of a button. By pressing one button, the device is put to sleep, and by pressing another button you can wake the device up again, github.com/.../nrf51-powerdown-examples Look at the system-on-wakeup-on-gpio example. If you would use SPI slave to collect data from a sensor, the event is triggered when the sensor sets CSN line high (see SPIS chapter in the nRF51 Series Reference Manual). For see how this is done, look at the spi_slave_example in the nRF51 SDK. When the SPI transaction is complete and the SPI master sets the CSN line high, you will get a callback into the spi_slave_event_handle where you can fetch your data that was received on the MOSI line.

RE: Custom service design: irq vs timer

michurin — Thu, 21 Aug 2014 12:27:40 GMT

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.

RE: Custom service design: irq vs timer

Stefan Birnir Sverrisson — Thu, 21 Aug 2014 08:43:44 GMT

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.

RE: Custom service design: irq vs timer

Peter Myerscough-Jackopson — Thu, 21 Aug 2014 08:19:56 GMT

michurin, you clearly state that battery life is more important than some delay, so telling you how to minimize power consumption is the correct answer.

RE: Custom service design: irq vs timer

michurin — Wed, 20 Aug 2014 13:22:32 GMT

Stefan, You're telling me how to minimize power consumption for collecting data. It is not the subject of my question. Let me ask it again: when is it better to process collected data at the time of the interrupt for collecting the data from each/some/one sensor( in this case I'll need to do math probably more often than I need to or unknowingly aperiodic) or to do it periodically using timer interrupts( extra wake ups and interrupt handling but low frequency less than !Hz). As I mentioned above I can deal with delays.

Appreciated, thank you.

RE: Custom service design: irq vs timer

Stefan Birnir Sverrisson — Wed, 20 Aug 2014 13:07:18 GMT

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.