Dropped packets with bt_nus_send

[clockis]

Greetings,

I am using the peripheral_uart Bluetooth nrf sample as a base for my custom application.

I have a ble_write_thread that just receives data on a message queue and calls the bt_nus_send function the same as the sample. And I also have a thread that produces the data and loads it to the ble message queue for transmission.

Recently because of a new requirement we need to send a lot more data via BLE than previously( to the central which is a mobile phone with the nRF Connect app). This has created issues with the integrity of the data packets we are sending. When the device is close to the edge of the Bluetooth range the device starts dropping packets.

As other members have previously informed me on the Zephyr discord this could be because while trying to resend the data (because of a poor connection on the edge of the range) new data are being queued in the BLE stack's buffers and the older ones that have still not been sent are overwritten thus they are never sent ( and appear as if they were dropped ) This only happens when the device is on the edge of the Bluetooth range & the issue is that the BLE stack is still trying to resend older packets.

I have increased the CONFIG_BT_BUF_ACL_TX_COUNT=200 & CONFIG_BT_BUF_ACL_TX_SIZE=251 (which is the maximum if I am not mistaken). I have also decreased the Supervision Timeout to the minimum (100 ms) so that the device disconnects for any transmission that takes more than 100 ms but this also seems not to solve the problem. I have also decreased the rate with which we queue new data to the ble_write_thread.

Is there something I am missing on the BLE operation or anything else I could do to eliminate this issue?

Thank you in advance!

Best regards,

Stavros

[Karl Ylvisaker]

Hello Stavros,

The best approach to handle this will depend on your applications requirements and constraints, could you elaborate on the requirements to your data transfer?
How much data will you generate, and how quickly will you do so, that you will be sending to the phone?

In any case, the best way to approach this is to implement a local error handling after the call to queue the data for sending over the NUS service, so that you can handle it in the case that the data fails to queue due to the buffer being full.
To handle this you could for example implement a ring-buffer, which you feed into the NUS service.
Alternatively, you could handle the data that fails to queue in another way - for instance, if it is not important for your application that every packet of data makes it across the link you could discard this data just as well. I mention both these approaches since I do not know enough about your application to know which one fits your use-case.

Best regards,
Karl

[clockis]

Hello Karl,

Kind reminder if you have any updates on this as this is a very important issue for our application.

Thank you very much

Best regards,

Stavros

[Karl Ylvisaker]

Hello Stavros,

Thank you for your patience with this.

clockis said:

Excuse me for the incomplete information.

No need to apologize, I will just ask if I have any questions.

Thank you for the clarifications.

I will get back to you tomorrow with an update.

Best regards,
Karl

[hmolesworth]

I didn't read this whole thread but something which might assist your basic lost packet issue: When a BLE disconnect/reconnect event occurs the data successfully sent to the Softdevice by the uart service handler but not yet physically transmitted in full via BLE using the uart code is simply discarded by the Nordic Softdevice without notification to the uart code. In our case this produces a single lost packet (we transmit in packets) for each disconnect followed by a connect, This happens more often near the edge of the BLE range.

The only workaround we know is to query Central for any missing packets (or Central simply informs Peripheral of any missing packets using an embedded packet sequence number) and re-transmit those missing packets. This is a pain; if you find a simpler solution we would be happy to hear of it.

[Susheel Nuguru]

Hugh, yes, that is one possible scenario where the uart data can be lost when you have a disconnect/connect sequence happening at the end of BLE range, but I did not think that this was the case as the description made me think that the data loss happens even without disconnect. Not sure how to handle such scenario when the softdevice just discards the packets. Seems like there is no error handling we can do here.

[hmolesworth]

Perhaps the user clockis could track the disconnect/connects; we found this helpful as it exactly corresponded to the number of missing packets. Something like this though this example is of course for the SDK not Zephyr

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
            ...
            // Indicate number of connections for checking against missing packets
            mBleConnectionCounter++;

[Susheel Nuguru]

How would be correlate mBleConnectionCounter to the number of lost packets? Maybe we can use this counter to tell the application of any possible data loss. Also, We cannot assume that every disconnect in such a scenario would definitely translate to data loss.

[hmolesworth]

Agreed; though in our case the number of disconnects exactly tracked the number of lost packets. The implication is that a packet could be queued while a disconnect was in progress and subsequently discarded perhaps when the connection was re-established. I forget now quite where I found that the stack knowingly discards queued data on a disconnect/connect, but there was something in the documentation.