Reasons and Solutions for Unstable Bluetooth Connection

When designing BLE related products, it is often encountered that the connection is suddenly disconnected, for example, the connection is disconnected immediately, and the transmission data is randomly disconnected after the connection is successful.

Normally, there are four reasons: antenna matching, chip compatibility, connection parameters, and code logic.

1. Antenna matching

Generally, there is no problem in strictly following the reference design of the official DEMO board, but some modifications are made in order to adapt to the requirements of your own board, which will cause problems such as antenna matching problems, unstable signal, and small signal range, which will eventually lead to unstable connections.

This requires impedance matching, finding antenna manufacturers to match antennas, etc. In addition, the parameters of the crystal oscillator (especially the frequency offset) may also affect the performance of the RF radio frequency, so it is best to use the crystal oscillator recommended by the official DEMO board or the crystal oscillator with the same parameters instead.

2. Chip Compatibility

It can be improved by adjusting the connection parameters. If it still doesn't work, you can only try another chip, or directly find the original FAE support.

The above two reasons are hardware problems, which need to be solved by specific debugging.

3. Connection parameters

Broadcast interval, maximum connection interval, minimum connection interval, connection listening time, etc. will affect the stability of the connection.

4. Code logic

There are generally two cases. One is that the connection is disconnected immediately, and there is a problem with some code executed after the connection is successful. You can directly check the function executed after the connection.

Another situation is that after the connection is successful, data can be transmitted, but it will be disconnected randomly, and sometimes the connection is very stable.

Especially when sending data regularly, when the time interval is adjusted a little longer, the stability is obviously improved;

When the time interval is short, the stability is obviously reduced. This happens because BLE needs to receive the confirmation signal from the bottom layer before sending the next time. If the confirmation signal from the bottom layer is not received, the sending function will be called. An error is reported, which triggers a watchdog reset and disconnects.

In the case of high data rate communication, after calling the BLE sending function, the BLE sending function must be called again to send the next data after receiving the acknowledgement signal from the bottom layer.

Taking the Bluetooth serial port routine of NRF52832 as an example, when we call the sending function ble_nus_string_send to send data, if the sending is successful, it will enter ble_nus_on_ble_evt (ble event interrupt of serial port service), and one event in this function is BLE_GATTS_EVT_HVN_TX_COMPLETE.

For the above problems, connection parameters and code logic problems can be preferentially excluded, because these modifications are easy and low-cost.

If the problem still exists, it is the antenna and compatibility problem, and then concentrate on solving it later. Finally, it is best to directly contact the technical support of the original factory if possible.

5. Other abnormal disconnection

BLE communication process is based on connection. According to different roles, it can be divided into Bluetooth master device and Bluetooth slave device, also called central device and peripheral device. A Bluetooth communication is usually initiated by the host and the slave responds.

In the above picture, device A is the Bluetooth host, B is the Bluetooth slave, and the BLE connection process is roughly divided into 6 steps:

1)      The master enters the connection state and listens for the broadcast packet of the device to be connected. If it does not listen within the specified time, it will cause the connection to time out. This time is specified by the developer;

2)      The master successfully receives the broadcast packet from the slave;

3)      The master sends a connection request packet;

4)      After the master sends a connection request packet, regardless of whether the slave receives it or not, it will immediately switch to the connected state, and at the same time report a "connected" message to the user layer, which is 4A in the figure. If the slave machine can receive this connection request packet, the slave machine also immediately switches to the connection state and reports a "connected" message to the user layer. If the slave fails to receive the connection request packet, it will not send a 4B message.

5)      The master sends a synchronization packet;

6)      After the slave receives the synchronization packet, it returns a synchronization packet to the host, and then repeats the two steps of 5 and 6, and the connection is really established. If any packet of 5 and 6 is lost, the connection establishment will fail, and the disconnection reason of 0x3e will be reported. The packet from step 5 or step 6 is lost, causing the connection establishment to fail. The loss of these two packets usually occurs when there are many Bluetooth devices around, resulting in a very crowded channel. Through experiments in an open place without redundant Bluetooth devices, it is found that the probability of this phenomenon is greatly reduced, which verifies this inference. When there are inevitably too many Bluetooth devices around, the application layer can circumvent this problem by reconnecting multiple times.