Timing of measurements in dependency on last radio event

[muhkuhns]

Hello,

Let me first try to describe my whole project I just started with today (Hardware just arrived).

I want to use the nRF51-DK as a central device to handle 4 peripherals.

4 Peripherals (modules based on revision 2 nrf51822) - not accessible when in place:

1. They are connected with either SPI (most likely) or I2C (TWI) with a sensor. Once at start they need to perform some communication with the sensor to set it up and get some coefficients.
2. About every 4 seconds they shall
   initiate two measurements (~10ms combined), get the results, do some fancy maths with it,
   and then send the results to the
   central.
3. Get a command from the central (e.g. is moving/not moving) and then eventually change their connection interval and/or TX power based on this
4. They need to last as long as possible from a single coin cell (>900mAh CR2477) (ideally 4+ years)

Could be useful: DFU support (Possible to enter this mode when a secret command is received or something like that?)

1 Central (nrf51-dk, so revision 3) - remains accessible:

1. Shall connect to all 4 peripherals and get their measurement results every 4 seconds

2. Maybe do some more magic math with it

3. Send data out via UART (and maybe display them on a display) (At first the raw data from the peripherals, for creating an algorithm based on it, and later on the result of the algorithm)

I am still trying to figure out what will be the best way to achieve this with little previous knowledge in a short time (Thesis, but only a small first part of it..). So far I guess I will start trying to make the SPI Part work on its own (or mixed with UART for debugging, but probably the debugger would be better for that purpose), then try to setup an own service that could send the data via BT and later on then mix this into the Multilink Example and try to get it all working together. Any recommendations are very welcome!

At this specific time I was wondering how to time the measurements... They should preferable take place as soon as possible before the central asks the peripheral for its data.

Provided that it shall be a closed system of 4peripherals+1central in connection, I guess the connection interval can be kinda fixed. So probably this could be achieved by something like this:

Start a Timer after the connection. Let it count till <"4s interval" minus "time for measurement" minus "a little buffer"> and then start the measurement, so the new data is ready for the next connection. Any hints on how to implement this?

What would be the most useful in GATT: let the peripherals act as servers and the central as client? But then: Which of these events can be used for my task??

BLE_GATTS_EVT_WRITE = BLE_GATTS_EVT_BASE,       /**< Write operation performed. @ref ble_gatts_evt_write_t */
  BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST,             /**< Read/Write Authorization request.@ref ble_gatts_evt_rw_authorize_request_t */
  BLE_GATTS_EVT_SYS_ATTR_MISSING,                 /**< A persistent system attribute access is pending, awaiting a sd_ble_gatts_sys_attr_set(). @ref ble_gatts_evt_sys_attr_missing_t */
  BLE_GATTS_EVT_HVC,                              /**< Handle Value Confirmation. @ref ble_gatts_evt_hvc_t */
  BLE_GATTS_EVT_SC_CONFIRM,                       /**< Service Changed Confirmation. No additional event structure applies. */
  BLE_GATTS_EVT_TIMEOUT                           /**< Timeout. @ref ble_gatts_evt_timeout_t */

Why is there no such thing as a "Read performed event"? Don't the client "reads" the data from the server?

Thanks in advance!

[Stefan Birnir Sverrisson]

Hi

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

[Ulrich Myhre]

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.

[muhkuhns]

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:

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

[Stefan Birnir Sverrisson]

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)

[muhkuhns]

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)?