ask for advice on how to evaluate and improve the connection quality

[TTN]

Hi,

I am writing to ask for your advice on how to evaluate and improve the connection quality of an application that uses two Bluetooth modules.
Each Bluetooth module transmits 210 bytes (MTU) per second via notify to an Android app that is currently using the
https://github.com/NordicSemiconductor/Android-BLE-Library.

The current connection quality between the device and nrf52832s is worse than that of commercial tablets with Bluetooth 5.0 specifications,
and it is prone to disconnections and packet loss.

The devices we are using are purchased from an external supplier. The Bluetooth chip used is AP6256, and the specifications we found using nrf connect are as follows.

They show me the HCI log, as shown below 
The supplier insists that they are using the Bluetooth 5.2 specification. 

We have limited control over this supplier, so we have already increased the TX power, which has improved the RSSI.

err_code = sd_ble_gap_tx_power_set(BLE_GAP_TX_POWER_ROLE_ADV,m_advertising.adv_handle,4);

In addition to hardware improvements, we are not sure what else we can do to improve connection quality.
At the same time, I am also curious about other ways to evaluate the quality of a connection.

SDK17.0.2
module nrf52832
segger embedded studio 5.42a

We would appreciate your suggestions.

Thank you,

[Sigurd]

Hi!

We have limited control over this supplier, so we have already increased the TX power, which has improved the RSSI.

err_code = sd_ble_gap_tx_power_set(BLE_GAP_TX_POWER_ROLE_ADV,m_advertising.adv_handle,4);

This is only during avertising. If you want higher tx-power during connection as well, you need to call

err_code = sd_ble_gap_tx_power_set(BLE_GAP_TX_POWER_ROLE_CONN ,conn_handle,4);

The current connection quality between the device and nrf52832s is worse than that of commercial tablets with Bluetooth 5.0 specifications,
and it is prone to disconnections and packet loss.

Would you be able to provide a nrf sniffer trace of this? This should reveal more about what is happening on-air.

https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le

[TTN]

Hi Siguad,

Thanks for your reply.
The device isn't byside.So i sniffer trace between commercial tablet and one of 2 nrf52832s,
i will update once i get the device.

2DeviceConnectToApp_23231025_1744.pcapng

I also record HCI log from the commercial tablets, but i can't find a software to open it now..
btsnooz_hci_202310251744.cfa

[Sigurd]

Ok, great, let me know when you get sniffer traces for the AP6256.

[TTN]

Hi,

I sniffer the one of the connect of AP6256.

The  follow is
nrf52832 advertise  -> connect to app -> sent data -> close app -> nrf52832 advertise.

OneOf2_NRF52832_conect_AP6256_2.pcapng

[Sigurd]

Hi!

A lot of packet retransmits are happening in the log. If you are in a noisy RF environment this could happen. Could also be that the Sleep Clock Accuracy of the AP6256 is not entirely correct. Not sure if you have control over this on the AP6256 side, but you could try to "compensate" for this on the nRF52 side, by setting NRF_SDH_CLOCK_LF_ACCURACY to 1 in sdk_config.h

[TTN]

Hi,

We only can control the Android app, 
Could you teach us how to use wireshark evaluate the connection quality?

[Sigurd]

Hi!

Yes.

Here is a screenshot of the Wireshark trace.

Under Bluetooth Low Energy Link Layer ->  Data Header -> Sequence Number, you can see if the packet is a Retransmit or not. I have applied this field as a column, so that I can easily see what packets are retransmissions. 

In the trace you have uploaded, the central is often sending retransmissions, meaning it did not receive the packet from the peripheral. But the sniffer sees that the peripheral actually did send the packet, so it looks like it's the central that is having issues with receiving packets it should have received.