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!

[BigJoe]

Hi Simon,

Thank you for the reply. The PHY request was not being sent from either side until this new change in the code flashed into the nRF52832 (peripheral) :

 case BLE_GAP_EVT_CONNECTED:
        {
        	ble_gap_phys_t phy_chnange = {0u};
        	BluetoothStatusFlags.isBluetoothConnected = BLE_IS_CONNECTED;
        	if(BluetoothStatusFlags.isLudiSleeping == false)
        	{
        		ble_event_payload[0] = BluetoothStatusFlags.isBluetoothConnected;
        		ble_event_payload[1] = BluetoothStatusFlags.isLudiBonded;
				for(uint8_t i = 0u; i < 2u; i++)
				{
					do
					{
						err_code = app_uart_put(ble_event_payload[i]);
						if ((err_code != NRF_SUCCESS) && (err_code != NRF_ERROR_BUSY))
						{
							NRF_LOG_ERROR("Failed receiving NUS message. Error 0x%x. ", err_code);
							APP_ERROR_CHECK(err_code);
						}
					} while (err_code == NRF_ERROR_BUSY);
				}
        	}

            NRF_LOG_INFO("Connected");
            err_code = bsp_indication_set(BSP_INDICATE_CONNECTED);
            APP_ERROR_CHECK(err_code);
            m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
            err_code = nrf_ble_qwr_conn_handle_assign(&m_qwr, m_conn_handle);
            APP_ERROR_CHECK(err_code);


            NRF_LOG_INFO("PHY update after connection");
            phy_chnange.tx_phys = BLE_GAP_PHY_2MBPS;
            phy_chnange.rx_phys = BLE_GAP_PHY_2MBPS;
            err_code = sd_ble_gap_phy_update(m_conn_handle, &phy_chnange);
            APP_ERROR_CHECK(err_code);

            break;
        }

After adding the last paragraph before the break, nRFConnect for Desktop (main) was succesfully switching automatically to 2M PHY, however in the App we are developing it did not. You will see in the sniffer trace that the request LL_PHY_REQUEST (no. 3806 in Wireshark) is sent from the slave to the App (master), but stays in 1M. Maybe you are able to spot something that we are missing.

code_phy_request_9_21.pcapng

Kind regards.

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

[Simonr]

Hi

Well, this time is the time from the end of the last packet to the start of this packet, so this time will also include any processing on the Master side, since the Master is the source of this longer delay the processing on the computer side is longer than for the nRF. Likely because a computer has stricter timeslots for BLE activity and more processing between BLE events.

Best regards,

Simon

[BigJoe]

Hi Simon,

Thank you very much for your help and time. 

Kind regards.