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

Just to make sure I understand this correctly. Your Python code uses the internal BLE module in the computer you're using, right? The nRF Connect for Desktop app uses a connected nRF5x DK and the radio on the nRF device as the radio and forwards data to the computer. If so, the most likely reason for the low throughput is that the computer is likely not prioritizing BLE events as highly as the nRF device. It could also be (as you say) that your laptops don't support the latest Bluetooth versions and thus not the 2MBPS PHY and Data Length Extensions from Bluetooth 5 that makes this possible.

If you want to maximize throughput just in general, this NovelBits blog post shows how to achieve the best possible throughput over BLE.

Best regards,

Simon

[BigJoe]

Hello Simon! 

First of all, thank you very much for your quick reply!

That is correct, the Python code uses the internal BLE module in the computer and the nRF Connect uses a nRF52840 dongle. I will have a look at the link, but how could I know in the bluetooth code for my PCB whether the 2MBPS PHY function is enabled or not?

Kind regards,

Alonso

[Simonr]

Hi Alonso

The PHY used in a connection (for both central and peripheral) can be done by doin a PHY update on the central side. The nRF52832 (on your peripheral side) supports 2MBPS, so if the central requests it, that shouldn't be an issue.

How this is done in the Python code you're working on I'm not sure about I'm afraid, but perhaps how the function works in the nRF Connect SDK might be helpful? It should only be part of the connection parameter update as far as I know. https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/connectivity/bluetooth/api/connection_mgmt.html?#c.bt_conn_le_phy_update 

Best regards,

Simon

[BigJoe]

Hi Simon,

After some research, I found out that the PHY can be set either from main or peripheral. I found the excerpt in the code of the nRF52832 (peripheral) where the PHY update is made and I changed the code from BLE_GAP_PHY_AUTO to BLE_GAP_PHY_2MBPS:

case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
        {
            NRF_LOG_DEBUG("PHY update request.");
            ble_gap_phys_t const phys =
            {
                .rx_phys = BLE_GAP_PHY_2MBPS,  //used to be AUTO,
                .tx_phys = BLE_GAP_PHY_2MBPS,  //used to be AUTO,
            };
            err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
            APP_ERROR_CHECK(err_code);
        } break;

By sniffin with Wireshark, I expected to have at least a LL_PHY_REQ (request) where the two parts tried to switch from 1M to 2M, but I did not get any. I tried with the python code, the BLE App we are developing in a laptop with Bluetooth 5.0 and even the nRF52840 Dongle and it did not work. Is there another change in code that I am missing?

Your help is much appreciated.

Best regards. 

[Simonr]

Hi

I'm not sure I understand. Do the devices switch PHY without the sniffer picking it up, or does the switch simply not occur? Is the PHY update request sent from either side at all or not? If you could upload the sniffer trace that might help as well.

Best regards,

Simon