Number of received data via BLE is mismatched with my code.

[seunghun]

Hello.

I'm developing some kind of wearable device with using nRF52832.

I'm using Segger Embedded Studio for developing.

I write my code by modifying ble_app_template.

My device is sending datas 5 times in second. 

Here is my code as follows.

#define OUR_CHAR_TIMER_INTERVAL APP_TIMER_TICKS(200) // 200 ms intervals, 

static void timer_timeout_handler(void * p_context)
{
// Step 3.F, Update temperature and characteristic value.

read_sensor_data(); // *modify where sensor measurement function goes
sd_temp_get(&temp_data);

data_set[0] = store2[0];
data_set[1] = store1[0];
data_set[2] = store4[0];
data_set[3] = store3[0];
data_set[4] = store6[0];
data_set[5] = store5[0];

our_sensor_characteristic_update(&m_our_service, data_set); // make a call to characteristic update function
//check_cap_value();
nrf_gpio_pin_toggle(17);

}

As you can see, there is timer for 200ms, and when timer is reached, device update datas.

However, when I try to analyze sampling data by using nRF Sniffer, I see there is some strange data what is not received for 200 ms delay.

Can you tell me why it happen?

if you need to get full code for understanding situation, just let me know.

Best regards,

Seunghun.

[Vidar Berg]

Hi Seunghun,

The BT stack can send multiple notifications in a single connection event if multiple notifications are queued in the outgoing buffer.

Best regards,

Vidar

[seunghun]

Hello Vidar.

Thank you for your kind replying.

But I wonder why there are multiple notifications in the outgoing buffer.

Data interver is 200ms, and connection interval is from 100ms to 200ms.

here is code about connetion interval.

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(100, UNIT_1_25_MS) /**< Minimum acceptable connection interval (0.1 seconds). */
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(200, UNIT_1_25_MS) /**< Maximum acceptable connection interval (0.2 second). */

Can you explain why it happens?

Best regards,

Seunghun.

[Vidar Berg]

Hello Seunghun,

seunghun said:

But I wonder why there are multiple notifications in the outgoing buffer.

If the notification was not received during the preceding connection event, it will be re-transmitted in the next connection event. This is expected and will occur occasionally due to interference from other RF sources, such as WiFi, or poor link budget. You can reduce the connection interval to mitigate this. 

Best regards,

Vidar

[seunghun]

Hello Vidar.

Thank you for your reply.

I understand what you explain about this issue.

I have one more question.

In past, I tried to transmit lots of data (240byte / 4ms interval)

In that case, I found there is many missing datas. (almost 40%)

Link budget is not poor (Because I used nRF52840DK, and distance from evaluation board to dongle is almost 50cm)

And connection interval was set to 7.5ms becuase it's minimal value that I know.

What can I do for this solving this problem?

Best reagrds,

Seunghun.

[Vidar Berg]

Hello Seunghun,

Data will not be lost if your app successfully adds the notification packet to the Softdevice's output queue, but from the code snippet you initially posted it seems like you are not checking the return code from your send function.

The data will only be sent if our_sensor_characteristic_update() returns NRF_SUCCESS.

uint32_t err = our_sensor_characteristic_update();
if(err != NRF_SUCCESS) 
{ 
    NRF_LOG_ERROR("Failed to send data. (err 0x%x)", err);
]

Best regards,

Vidar

[seunghun]

Hello Vidar,

I don't try to use that code yet.

But I have some point about that.

Data is from another IC via SPI to nRF52. 

To prevent nRF is stucked in SPI protocol, I set SPI interrupt priority is higher than BLE interrupt priority.

In my opinion,  If SPI protocol and BLE characteristic update is conducted in same time, BLE notification can be cancled, and it leads device to fail to send notification.

If my assumption is true, what can I do for solving this issue?

Is there any way that I can try to send notification again if it is failed?

Best regards,

Seunghun.

[Vidar Berg]

Hello Seunghun,

As long as you avoid selecting interrupt priorities reserved for the Softdevice, application interrupts should not interfere with the transmission of your notifications. In general, it is safest to use the same priority for all application interrupts to avoid potential race conditions. 

seunghun said:

Is there any way that I can try to send notification again if it is failed?

This is up to the application to handle. 

Best regards,

Vidar