Timing of measurements in dependency on last radio event

RE: Timing of measurements in dependency on last radio event

muhkuhns — Wed, 06 May 2015 14:00:25 GMT

Thanks for your answer! I didn't find anything related to HVX in the example you mentioned but in another one I were more lucky. I also made a separate question for this: devzone.nordicsemi.com/.../ But already answered it myself.

RE: Timing of measurements in dependency on last radio event

Stefan Birnir Sverrisson — Wed, 06 May 2015 13:51:11 GMT

You can enable notifications on Android nRF MCP. If you for example flash the ble_app_hrs example to the nRF51 device, then you should see it in MCP and be able to connect to it. When you are connected, you can select i.e. the battery service. The battery service has two properties, READ and NOTIFY. If you press the notify button you are enabling notification on the battery service, which will allow the peripheral device to send notifications with sd_ble_gatts_hvx. The MCP will start to receive periodic messages for the battery status.

RE: Timing of measurements in dependency on last radio event

muhkuhns — Fri, 01 May 2015 15:42:41 GMT

I will stick as close as possible to everything you linked. Thanks :)

For the start I took the multilink_perpipheral example and added SPI,UART and changed the characteristic. Works fine so far.

Can you recommend any links or give some more details by yourself about this part of your answer: "Then the central will need to enable services in order to get notifications from the peripheral. The peripheral device can then send notifications to the central with sd_ble_gatts_hvx"

I can easily get the measurement once. Can i "enable notifications" with the nRF Master Control Panel (Android)?

RE: Timing of measurements in dependency on last radio event

Stefan Birnir Sverrisson — Thu, 30 Apr 2015 11:24:07 GMT

We are happy to help. I would recommend to post a separate thread for unrelated questions you may have. If you have a SPI question, look for the answer here on devzone and post a separate thread if you can not find adequate answer. For more info, (1) (2) (3)

RE: Timing of measurements in dependency on last radio event

muhkuhns — Wed, 29 Apr 2015 18:55:20 GMT

I don't know why but I didn't got any email notifications for your answers. (It worked fine on all other questions as far as I noticed.)

Thank you so much for your long answer Stefan and of course also thank you Ulrich for your contribution!

I am currently struggling with getting SPI to work as at the moment it does not for unknown reasons..

I guess the timing is not the first thing on my ToDo, It just came to my mind. Of course it would be nicer to keep them recent but in the end it doesn't really matter if the measurement is already 3,9seconds old.

But for the software part of this part (~5 weeks) of my thesis the priority is to make it work, improvements can follow later. So I guess priority order is:

Peripheral: Get Softdevice110+SPI working flawlessly -> Get sensor raw data -> Compute pressure/temp -> Create connectable service that can send the pressure/temp
Central: SD120+UART+connects to 4 peripherals and collects all the data.

RE: Timing of measurements in dependency on last radio event

Ulrich Myhre — Wed, 29 Apr 2015 13:33:23 GMT

I am not sure if radio notifications could solve this, seeing the measurements taking 10ms + math time, and the maximum distance of notifications is around 5.5ms. Considering noise/CRC errors, a high slave latency would probably be better than a long connection interval as well - at the cost of higher current consumption in the central. It could be possible to use radio notifications or a hook on TX_COMPLETE to set a timer for the next data gathering though, but the timings have to be found experimentally.

RE: Timing of measurements in dependency on last radio event

Stefan Birnir Sverrisson — Wed, 29 Apr 2015 11:56:21 GMT

Sounds like an exciting project.

Yes, definitely try to get each part to work separately before combining them. I should be easier to debug that way.

In order to save current, please look at the current consumption guide.

In order to save current you can set your connection interval to 4 seconds, since you only need to send data every 4 seconds. You can enable radio notifications in order to perform the sensor measurements just in time before each radio event. There is a radio notification example available on this thread.

The peripheral devices can request for a connection parameter update from the central, see this thread.

For you scenario, I guess it would be convenient to let the peripherals be servers and the central act as client. Then you would let the characteristics containing your sensor data on the peripheral send notification messages to the central. This is done in most BLE examples in the nRF51 SDK, including the ble_app_uart example. The compatible ble_app_uart_c_120 example is available on Nordic Github page. Perhaps also the ble_app_hrs_c example on the central side could demonstrate how to connect to multiple peripherals, i.e. start scan after connecting.

The way it works is that the peripheral will start with advertising. The central will connect to the peripheral and discover services. Then the central will need to enable services in order to get notifications from the peripheral. The peripheral device can then send notifications to the central with sd_ble_gatts_hvx