A BLE disconnection issue occurred randomly after the device had been functioning without any problems for many hours

[Tai]

Hi everyone,

We have devices using the BLE module (nRF52) deployed in clinics for testing. They have been functioning without issues until recently when we noticed occasional BLE disconnections. The following image shows data from one of the affected devices. Its RSSI value dropped significantly to -90 dBm, indicating weak BLE signal strength that could explain the disconnect. However, the device was positioned close to a tablet running the application connected to it, where the BLE signal strength should have remained strong. This inconsistency is what we find puzzling.

In another case, the RSSI value was within acceptable range (-68dBm), which couldn't lead to the BLE disconnection. 

We're thinking of if any issue with code optimization. Any suggestions to further investigate this issue would be greatly appreciated. Thanks!

[hmolesworth]

We had a similar issue with a disconnect due to RSSI when the sensor was supposed to be next to a tablet/gateway and it turned out to be a large body of water placed in close proximity to the tablet ie someone picked the tablet up and turned away from the sensor to better read the data and the human body blocked the 2.4GHz signal pretty well. 2nd case looks odd though unless a local microwave got switched on .. SDK or nRFConnect?

[Tai]

Thanks for the reply, hmolesworth ! We're using the latest SDK 17.1.0.

Since deploying it in the clinics, people being around the device might be inevitable. Moreover, some other equipment that have interference might be introduced in the room as well. In this situation, it'd be great if you can suggest any solutions to protect the device from being disrupted by human body or other sources of interference! Thanks!

[Tai]

Thanks for the suggestion! I forgot to mention about the settings. Blankets and surgical drapes are also used, covering entire patient and the BLE device. However, I don't think it would affect the BLE signal. Please give your thoughts!

I'm using the BLE module with chip antennas as well. Regarding the data streaming, it's real-time with no lag. The following picture is a closer look of the device worn on the foot. The device's antenna is placed on the left side of the device. Any suggestions for the tablet location in this case would greatly appreciate.

I read some posts you shared which I noticed that changing to 1M PHY could mitigate the BLE disconnection. In our case, since the distance between the tablet and the device is very short. Any thoughts if this change would help?

Last thing, by looking at those posts, I checked again our schematic and found that our Xtal capacitors (C3, C4) doesn't seem correct.

Please correct me if I calculated this correctly or not.

• The load capacitance (Cload) for our crystal is 9pF
• The input pin capacitance (Cpin) for the BLE chip (nRF52833) is 3pF.
• I'd pick the PCB capacitance (Cpcb) of 1pF.
• C3 = C4 = 2*Cload - Cpin - Cpcb = 18 - 3 - 1 = 14pF

Will this affect the crystal stability, potentially posing the BLE disconnection issue?

[hmolesworth]

Coded PHY is more resilient than 1M or 2M PHY, but of course the on-air packet time increases. Forward Error Correction (FEC) with coded PHY helps with that. Regarding location and orientation, it has to be tested to get the optimum result as all antennas have directional variations; some orientations will rely on reflections (multipath) from walls, floor and ceiling. Any covering degrades performance, but not by much; worse case is usually adjacent humans blocking the direct line-of-sight; worth testing that with different device orientations.

Load capacitance is slightly arguable, given board capacitance is distributed and hard to quantify. Pin capacitance adds directly to the two individual load capacitors:

CL = (CaCb)/(Ca+Cb) + Cstray where Ca=Cb=9pF+Cpin=12pF and Cstray (not pins) say 1 or 2pF = net CL of 7 or 8pF
Yes that could be improved, but no I would argue it doesn't matter that much. Too large a value slows down the crystal, too small speeds up (pulls) but by very little. The actual frequency is more affected by temperature; on the covered foot will be higher temperature than in free air and this may compensate for the load capacitance, best to accurately measure a long time interval derived from the 32kHz crystal.

[Tai]

Unfortunately, I'm using iPad Pro right now to test, but it doesn't equip Code PHY.

Thanks a lot for giving me insightful thoughts for this issue, hmolesworth !

My last thought of avoiding the BLE disconnection is to boost the TX power using PL/LNA. Not sure if it'd be an overkill approach. Moreover, it requires a major update on our device. 

[hmolesworth]

I wouldn't bother, just boost to max Tx +4dB. What are these set to? They will affect the reliability.

// Connection interval: Determines how often the Central queries data from the Peripheral.
//   Peripheral may request an update between between minimum 7.5 ms and maximum 4 sec
// Slave latency: A Non-zero slave latency allows the Peripheral to not answer when the
//   Central asks for data up to the slave latency number of times. However if the Peripheral
//   has data to send it can send data at any time. This enables a peripheral to stay sleeping
//   for a longer time, if it doesn't have data to send, but still send data fast if needed
// Connection Supervision Timeout: Determines the timeout from the last data exchange untill
//   a link is considered lost. A Central will not start trying to reconnect before the timeout
//   has passed, so a short timeout is preferred for devices often going out of range

    gap_conn_params.min_conn_interval = MIN_CONN_INTERVAL;
    gap_conn_params.max_conn_interval = MAX_CONN_INTERVAL;
    gap_conn_params.slave_latency     = SLAVE_LATENCY;
    gap_conn_params.conn_sup_timeout  = CONN_SUP_TIMEOUT;

[Tai]

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(7.5, UNIT_1_25_MS) /**< Minimum acceptable connection interval (0.1 seconds). */
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(15, UNIT_1_25_MS) /**< Maximum acceptable connection interval (0.2 second). */
#define SLAVE_LATENCY 0                                    /**< Slave latency. */
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS)   /**< Connection supervisory timeout (4 seconds). */

Please take a look at it above.

I guess I didn't mention that the tablet is actually connecting two BLE devices using the same BLE module. However, the most of BLE disconnection happens in the device worn on the foot.

The second set for the second BLE device is listed the following

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(15, UNIT_1_25_MS)             /**< Minimum acceptable connection interval (20 ms), Connection interval uses 1.25 ms units. */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(30, UNIT_1_25_MS)             /**< Maximum acceptable connection interval (75 ms), Connection interval uses 1.25 ms units. */
#define SLAVE_LATENCY                   0                                           /**< Slave latency. */
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS) 

I'm not sure if having 2 devices, it could potentially increase the possibility of having BLE instability.

Edit: I also boosted the TX power up to +8dBm by using sd_ble_gap_tx_power_set()

    ret_code_t err_code = sd_ble_gap_tx_power_set(BLE_GAP_TX_POWER_ROLE_ADV, m_advertising.adv_handle, TX_POWER_LEVEL);
    APP_ERROR_CHECK(err_code);

[hmolesworth]

+8dB? That's a bug; setting +8dB doesn't work on the nRF52832, which only has a max of +4dB. Setting +8 actually sets a -ve dB value, look at the pulse currents:

   // 11.35mA NRF_RADIO->TXPOWER = 0x08
   // 23.17mA NRF_RADIO->TXPOWER = 0x04
   // 17.25mA NRF_RADIO->TXPOWER = 0x00

Just changing to +4dB alone might fix your disconnect issue :-)

[Tai]

I'm using nRF52833 actually which can be boosted to +8dBm.