NRF52840 Central lost some packets

[Sam.Art]

Greetings
starting from the 'ble aggregator' example I developed a BLE central on NRF52840 with NRF5 SDK 17.02, capable of managing multiple peripherals which, once connected, periodically send MIDI data over bluetooth. But I have performance problems with devices that overload the channel by sending many packets in a short time and some packets are lost.
I tried to optimize the application by acting on the following parameters:

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(5, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(35, UNIT_1_25_MS)
#define MIN_PERIPHERAL_CON_INT       6
#define MAX_PERIPHERAL_CON_INT       MSEC_TO_UNITS(10, UNIT_1_25_MS)

Something has improved, but every now and then some packages don't arrive.
I wanted to know if it is possible to act on other parameters or adopt other strategies useful for improving performance.

[Hieu]

Hi Sam.Art,

BLE as a communication protocol does not allow lost packets, so we can be confident that the packets arrive at the central device.

You are working with the nRF5 SDK v17.0.2, which is a version that has been in deployment for many years now. We can be quite confident that there would be no issue there.

After those considerations, I would say it is most likely the buffering logic you have isn't able to handle the worst-case scenario.

I recommend increasing the buffer size and adding a buffer full warning flag to know when the buffer is filled.
The event handler logic should also be implemented in a way that let it returns as quickly as possible.

Hieu

[Sam.Art]

Hi Hieu and thanks for your reply

The Midi over BLE standard involves the use of the Notification method, which if I remember correctly is less reliable than the Indication, but allows for greater performance.

I have already checked the entire buffer chain of my application by increasing them but the anomaly remains. I also minimized the time spent in the interrupt and disabled USB management, but it doesn't seem to have brought any benefits.

Furthermore, I also tried to divert the raw BLE traffic to a serial port for debugging and I always find some packets lost at times of greatest traffic... the strange thing is that it always and only happens with one type of device (even with just one connected), while I have never encountered this problem with other midi over BLE devices even if I have connected many of them ( 2 to 10); it is also true that that type of device is the only one that generates high peaks of traffic.

Because of this, I was asking if there were other parameters on which to act on softdevices.

Sam

[Hieu]

Hi Sam,

Sam.Art said:

the Notification method, which if I remember correctly is less reliable than the Indication, but allows for greater performance.

You remember correctly. There can only be one Indication each Transmit Window/Connection Interval, but there can be multiple Notifications.

Sam.Art said:

I have already checked the entire buffer chain of my application by increasing them but the anomaly remains. I also minimized the time spent in the interrupt and disabled USB management, but it doesn't seem to have brought any benefits.

Furthermore, I also tried to divert the raw BLE traffic to a serial port for debugging

I understand you said you have optimized the event handling. However, I would like to be sure, is the serial debug print done in the BLE handler?

Sam.Art said:

the strange thing is that it always and only happens with one type of device (even with just one connected), while I have never encountered this problem with other midi over BLE devices even if I have connected many of them ( 2 to 10); it is also true that that type of device is the only one that generates high peaks of traffic.

How much control do you have over this device?

I understand that you know what this device is supposed to send. However, have you been able to confirm that the device has transmitted such data?

That might be a helpful thing for troubleshooting this issue. If you need a guide to sniff the data transmission, we have one here: Lesson 6 - Bluetooth LE sniffer - Nordic Developer Academy.

Sam.Art said:

Because of this, I was asking if there were other parameters on which to act on softdevices.

There are a number of parameters, but for the vast majority of cases, these three are the main concerns:

• GAP Data Length
• GATT MTU
• GAP Connection Interval

GAP Data Length is how many bytes there are in each Link Layer (LL) packet, which is directly related to the physical packet. 

GATT MTU is the maximum number of bytes in a GATT operation.

One of the most common use cases where high throughput is concerned is firmware update, where a large binary is transferred over multiple GATT write.
For it, the optimal GAP Data Length is 251, maximum. The optimal GATT MTU is 498, which can be segmented into two LL packets after overhead.

I am unfamiliar with the MIDI over BLE standard, so I don't know which value would be best for it.
I don't think it is a standard specified by the Bluetooth SIG. Is the one listed in this link: MIDI Transports – MIDI.org?

For Connection Interval, the optimal value depends on the physical environment. In particular, whether packet losses happen frequently or not.
When a packet loss happens, no more transmission will happen within the same Transmit Window/Connection Interval. Shorten Connection Interval minimizes the worst-case time spent not transmitting when a loss happens.
Meanwhile, every Transmit Window, there is some overhead. Lengthen Connection Interval minimizes the time share of such overhead.

Depends on the kind of issue, this might not really matter.

[hmolesworth]

You might find incrementing a counter on BLE connection loss and reconnection worth comparing with the number of missing packets on a specific peripheral. I forget the exact details but on one project we saw that a queued packet at the peripheral was silently discarded if there happened to be an unexpected disconnect-reconnect before that packet transmission was completed. That could if so be handled by the App retransmitting the packet.

[Sam.Art]

Hi Hieu

I'll answer your questions right away:

I understand you said you have optimized the event handling. However, I would like to be sure, is the serial debug print done in the BLE handler?

Yes, in the BLE interrupt handler, I only copy the raw data coming from the ble into a buffer which is then sent to the UART from the main.

How much control do you have over this device?

None, it is a commercial device called Orba 2 which generates midi music via finger touches, it has some settings but nothing useful, I only understand that the BLE is managed by an ESP32.

I understand that you know what this device is supposed to send. However, have you been able to confirm that the device has transmitted such data?

If I connect it directly to the PC or to other commercial BLE doogle (which however manage few simultaneous connections or just one) I do not encounter any packet loss; however, with my implementation on the NRF52840 donglee I experience data loss even when only it is connected.

Thanks for the sniffer, I'll see how it can be useful to me.

I am unfamiliar with the MIDI over BLE standard, so I don't know which value would be best for it.

I don't think it is a standard specified by the Bluetooth SIG. Is the one listed in this link: MIDI Transports – MIDI.org?

Yes the midi.org authority has codified MIDI over BLE as a standard for years (in reality it is a native Apple specification), you can find the documentation in the center of the page under the heading 'MIDI OVER BLUETOOTH LOW ENERGY (BLE-MIDI)'

But essentially the typical BLE packet is the following, it is 5 bytes (seee the photo below), but it has the possibility of being concatenated but never beyond the maximum length of the BLE packet... but essentially I have seen that from the BLE interrupt in the worst moments they do not arrive never more than 24 bytes at a time (24 I'm not sure I should look, but in any case I'm slightly wrong)

For this reason I think that for now I will focus on GAP Data Length, GATT MTU, GAP Connection Interval,In fact, if you have any other suggestions on the matter, they are welcome.