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

[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.

[Sam.Art]

Thanks, this is also interesting,

but I think you are referring to a software application for smartphones, or am I wrong?
In my case I have a doongle with my firmware and the other device managed by its firmware and there is no automatic reconnection mechanism between the two, the connection is always initiated by the user... or are you referring to some low level BLE mechanism that I don't know ?

[Hieu]

Sam.Art said:

if you have any other suggestions on the matter, they are welcome.

Adding the fact that other devices don't have issue with the Orba 2, it becomes more likely that the problem lies on the nRF side.

If the sniffer check shows that all packets are transmitted, then you might want to have an extremely rudimentary handler that just count packets, see if something that basic works in the first place.

With the sniffer, you can also check what connection parameters the commercial devices are having success with and use it as a reference. In the same online course that has the sniffer lesson I linked, there is also a lesson on all other connection parameters, if you want to have a deeper understanding.

[Sam.Art]

Hi Hieu

I was checking my code, tell me if I associated the defines correctly

• GAP Data Length = NRF_SDH_BLE_GAP_DATA_LENGTH (244 in my case)
• GATT MTU = NRF_SDH_BLE_GATT_MAX_MTU_SIZE (247 )
• GAP Connection Interval = NRF_SDH_BLE_GAP_EVENT_LENGTH (3)

thanks

[Hieu]

Hi Sam.Art,

Sam.Art said:

• GAP Data Length = NRF_SDH_BLE_GAP_DATA_LENGTH (244 in my case)
• GATT MTU = NRF_SDH_BLE_GATT_MAX_MTU_SIZE (247 )

These are correct.

As for connection interval, you were tweaking it in your opening post. See MAX and MIN_CONN_INTERVAL macro defined in most examples and how they are used.