SLOW THROUGHPUT in built-in bluetooth in computer, but almost DOUBLE the SPEED in nRF Connect for Desktop. How to match this high performance?

[BigJoe]

Good afternoon!

We are developing a BLE App that is communicating via bluetooth to a PCB board. The App uses the built-in Bluetooth module in our Windows laptops and the PCB has a STM32 micro and a BL652 BLE module w nrf52832 inside. The App acts as the central demanding data by sending commands to the PCB (our peripheral) and the latter responses with discrete values or streaming data until another command tells him to stop..

The problem comes with the data throughput. We tested the bluetooth communication by connecting to the PCB and asking for a stream of data from the nRF Connect for Desktop program and from Python, Matlab and even the App itself. The nRF Connect seems to perform at higher speed giving us double the throughput that we get in the other three. By sniffing the traffic of data via Wireshark, I found that both exchanges are very similar, but worth noting that the communication in nRF has a higher number of bytes captured, 126, and a length of 100 whereas the Python code only has 53 bytes captured and a length of 27 (see images below).

nRF Connect:

Python code:

We already got a great help some time ago from this forum, where the throughput improved considerably when increasing the NRF_SDH_BLE_GAP_EVENT_LENGTH in our bluetooth module in the PCB. We also got suggested to enable the 2M PHY, but I am not sure if our laptops support such hardware. Maybe someone has another suggestion that could help to give us the bit rates that we get in our nRF Connect.

We would appreciate any help.

Thank you very much!

[Simonr]

Hi

From the sniffer trace it seems like the master (your app) responds right away, but this is captured as an unknown response. Are you certain the Bluetooth module on your desktop supports other PHYs than 1MBPS?

As we don't expertise in desktop app development here in support I'm afraid I don't have much input except that the "PHY requested" device should respond with LL_PHY_UPDATE_IND with TX and RX set to use the 2MBPS PHY, which it does not seem like your app responds with.

Best regards,

Simon

[BigJoe]

Hello Simon!

Thank you for your reply! You are most probably right, changing to a device that we know supports Bluetooth 5 and therefore, 2MBPS PHY, seems to make the change the right way. However, there is still a delay that we find suspicious. We understand that for every package there should be approximately an inter frame space (IFS) delay between packets of 150us, which we see in the screenshots, but the delays occurring in the Empty PDUs' time sent from the Master are way too big compared to the delays in nRFConnect. 

BLE Application:

nRFConnect:

As you can see, the delays in the application are even 10 times the nRF. Any idea of the cause behind this phenomenon? I also attach the wireshark traces:

nrfConnect_2M_wireshark_333.pcapng

application_2M_delays.pcapng

Best regards.