Notification frequency

RE: Notification frequency

Hung Bui — Mon, 09 Jan 2017 14:12:12 GMT

Hi Eric,

There is no such term as "packet loss" with BLE. Packet if not ACKed will be re-transmitted until it's ACKed or the connection will time out.

What you described as packet loss here could be that the call to sd_ble_gatts_hvx() wasn't successful. Meaning the packet is not queued to be sent. You should always check for the return code of any API call. For example if the TX buffer is full you will receive BLE_ERROR_NO_TX_PACKETS and you will have to recall the hvx api again later (you can wait till TX_COMPLETE return to retransmit)

RE: Notification frequency

ericzhao — Mon, 09 Jan 2017 13:39:17 GMT

Yes. I was considering about the connection interval problem on android when I posted this question. Actually I'm developing a private android application and a ble application on nrf51. In current stage, the client didn't require a public application but the problem should be considered if they want it to be public in the future. Thank you wojtek! You helped me a lot!

RE: Notification frequency

Wojtek — Mon, 09 Jan 2017 13:15:47 GMT

Oh, just one more thought: if you are trying connection with android device, it is highly propable that you dont have 7.5ms connection interval! many smartphones dont accept that. However, they often allow more than one packet/connection interval. But you should not depend on that if you are developing public app, because it is not standarized between phones and some accept long connection interval and ex. only 2 packets/connection, and some allow shorter interval and for example 4 packets/connection. So, achieving high throughput between bluetooth smart device and smartphone could be quite problematic. as far as i know (i am not really into mobile development...) it also depends of android version installed - in 7.0 shorter connection intervals could be rejected.

RE: Notification frequency

ericzhao — Mon, 09 Jan 2017 12:19:32 GMT

OK. I will do more test on it. Thank you a lot Wojtek!

RE: Notification frequency

Wojtek — Mon, 09 Jan 2017 12:14:52 GMT

It should be easily achievable if your receiver is in good range. It is possible to send 133 notifications (assuming one packet per connection interval, 7.5ms interval), so even when there are some retransmissions, 100 packets should be send.

RE: Notification frequency

ericzhao — Mon, 09 Jan 2017 12:12:29 GMT

I checked the error code and it's the tx buffer problem as you said. Thanks a lot!

I solved the problem by this way: resent the packet if error code is returned until NRF_SUCCESS is returned. But in this way, 100 packets per second may not be able to achieve when there are tx buffer problems in 1 second. Is there any better solution to send 100 packets per second?

RE: Notification frequency

Wojtek — Mon, 09 Jan 2017 11:32:34 GMT

If transmission is not succesfull (not acked by the peer), transmission buffer may not be emptied, so adding another packets is probably not successful. buffering the data and trying to send it just a bit later should do the work :)

RE: Notification frequency

ericzhao — Mon, 09 Jan 2017 11:30:36 GMT

1-5 packets loss sometimes. not always receive 100 packets. I will try to check the return value. Thank you a lot!

RE: Notification frequency

Wojtek — Mon, 09 Jan 2017 11:26:46 GMT

Ok, so i see you are not checking sd_ble_gatts_gvx returned value. Check it and if it is not success, you should wait more time to send the notification. Also, how many packets you loose? I did succesfully manage to send about 133x20byte packets/second when using 7.5ms interval.

RE: Notification frequency

ericzhao — Mon, 09 Jan 2017 11:20:15 GMT

hi wojtek

Thank you for your reply.

This is the part of sending notification. I use a timer to control the time. In one second, the nrf51 reads the sensor 100 times and everytime it finished the reading, ble_mpu_update is used to notify the data. accel_values_t is a 20 bytes struct.

void ble_mpu_update(ble_mpu_t *p_mpu, accel_values_t * accel_values)
{
    // Send value if connected and notifying
    if (p_mpu->conn_handle != BLE_CONN_HANDLE_INVALID)
    {
        uint16_t               len = sizeof(accel_values_t);
        ble_gatts_hvx_params_t hvx_params;
        memset(&hvx_params, 0, sizeof(hvx_params));

        hvx_params.handle = p_mpu->accel_char_handles.value_handle;
        hvx_params.type   = BLE_GATT_HVX_NOTIFICATION;
        hvx_params.offset = 0;
        hvx_params.p_len  = &len;
        hvx_params.p_data = (uint8_t*)accel_values;  

        sd_ble_gatts_hvx(p_mpu->conn_handle, &hvx_params);
    } 
    
}

RE: Notification frequency

Wojtek — Mon, 09 Jan 2017 11:13:09 GMT

show code - it all depends how you send notifications. If you are pushing them even if there are no more tx buffers available, you will loose some of them. you have to wait till all buffers are emptied. there are plenty of topics here on devzone describing how to get high throughput - you should familiarize yourself with them