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

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

Tai — Thu, 28 Nov 2024 00:40:40 GMT

[quote userid="65515" url="~/f/nordic-q-a/116662/a-ble-disconnection-issue-occurred-randomly-after-the-device-had-been-functioning-without-any-problems-for-many-hours/512459"]Worth trying much bigger and less frequent packets, methinks[/quote]

Will definitely try this! I read some articles about this. Seems it could help improve BLE stability:

Frequent transmissions increase the likelihood of packet collisions in environments with many BLE devices or RF interference (e.g., Wi-Fi, microwave ovens).
Reducing the frequency of transmissions can lower the risk of collisions and reduce retransmissions, improving stability.

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

Tai — Thu, 28 Nov 2024 00:05:09 GMT

Oh interesting. Can you elaborate more on the Edit2 you just mentioned? From my understanding, due to the limit of receiving data from the tablet, it only can receive data from one device at a time while another one is buffering its data and then sending several packets to the tablet.

It seems you have another explanation of the above image in my previous reply. It's more about retransmitting data packets?

Edit: the BLE disconnect mostly happens at the device with 100 Hz sampling rate (10mSec). This device has 48 bytes/packet being transmitted to the tablet. Since you brought up the RSSI, although 4mSec device sends data more frequently, if it has a poor RSSI, will 10mSec device take over to transmit the data to the tablet?

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

hmolesworth — Wed, 27 Nov 2024 23:50:16 GMT

250Hz sounds suspiciously like ECG or similar; in a similar application I send 5 packets per second with 50 24-bit samples in each packet. The packets are bigger, of course, but the overall traffic is reduced. 5Hz display refresh rate allows smooth display scrolling of the waveforms. May not help, of course.

Edit: By this I mean fewer packets per second means less blocking/waiting time for each device

Edit2: I see there are in fact two RSSI; this means the 4mSec may be retransmitting frequently enough to hold off the 10mSec where the 4mSec has poor RSSI and the 10mSec RSSI is good, as perhaps in the original trace above. Worth trying much bigger and less frequent packets, methinks

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

Tai — Wed, 27 Nov 2024 23:32:19 GMT

Totally agree with the ATT payload explanation.

For the device sending 48 bytes/packet, I set the NRF_SDH_BLE_GAP_DATA_LENGTH of 58 while another one sending 10 bytes/packet, I set the NRF_SDH_BLE_GAP_DATA_LENGTH of 27. I think these values satisfied the requirement such that the MTU won't span multiple packets, causing the low throughput due to increasing the overhead.

[quote userid="72867" url="~/f/nordic-q-a/116662/a-ble-disconnection-issue-occurred-randomly-after-the-device-had-been-functioning-without-any-problems-for-many-hours/512440"]Say if it is receiving data from Device 01, while Device 02 keeps transmitting data to the phone app. Device 02's data will be queued on the air and arrived at the phone app as several ble packets as opposed to individual ble packet.[/quote]

In my app, data collection from both devices works as follows: the app listens for notifications from each device and uses a switch-case structure to handle the data accordingly when a notification is received. Since the two devices have different sampling rates—100 Hz for one device and 250 Hz for the other—the app receives notifications from each device at different intervals, corresponding to their respective sampling rates.

The following is what I captured from the app to illustrate what I mentioned above.

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

hmolesworth — Wed, 27 Nov 2024 19:44:42 GMT

Several BLE packets? Something not right there; are you not requesting increased data length? Some older tablets might restrict MTU to 23 byte packets. Lots of posts on this here, some notes:

// <i> The SoftDevice handler will configure the stack with these parameters when calling @ref nrf_sdh_ble_default_cfg_set.
// <i> Other libraries might depend on these values; keep them up-to-date even if you are not explicitely calling @ref nrf_sdh_ble_default_cfg_set.
//==========================================================
// <o> NRF_SDH_BLE_GAP_DATA_LENGTH   <27-251> 


// <i> Requested BLE GAP data length to be negotiated.

#ifndef NRF_SDH_BLE_GAP_DATA_LENGTH
#define NRF_SDH_BLE_GAP_DATA_LENGTH 251
#endif

ATT Payload up to 244 bytes 251-4=247 247-3=244
ATT MTU Determines the max amount of data that can be handled by the transmitter and receiver and which they can hold in their buffers.
The MTU value affects the amount of overhead data (specifically the ATT header which is 3 bytes). The minimum ATT MTU allowed is 27 bytes. This allows a max of 20 bytes of ATT payload (3 bytes are used for the ATT header, and 4 bytes for the L2CAP header).
There is no limit per the spec on how high the MTU value can be, but the specific stack in use may have its own limitations. For example, if you enable DLE then you can transfer up to 251 4 = 247 bytes (after deducting the L2CAP Header size). After taking into account the ATT header (3 bytes), we are left with 244 bytes for the actual ATT payload data. If the MTU is at least 247 bytes then the MTU will fit into one single packet. If the MTU is greater than 247 bytes, then the MTU will span multiple packets causing the throughput to go down (because of the packet overhead and timing in between the packets).

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

Tai — Wed, 27 Nov 2024 17:55:56 GMT

Thank you so much for following up on this, hmolesworth!. The following describes ble packets from each device being sent to the tablet's application. The device 01 is worn on the patient's foot.

I've read several posts regarding multiple peripheral devices sending data to the central device. However, they used another nRF52 device serving as a central device instead of the phone app. For connection parameters selection, I was able to config that for 2 peripheral devices as the following. On the phone app, seems it automatically negotiated and assigned the set of parameters by itself.

// DEVICE 01
#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). */

// DEVICE 02

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(15, UNIT_1_25_MS) /**< Minimum acceptable connection interval (0.1 seconds). */
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(30, 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). */

[quote userid="65515" url="~/f/nordic-q-a/116662/a-ble-disconnection-issue-occurred-randomly-after-the-device-had-been-functioning-without-any-problems-for-many-hours/512414"] What would be the worst-case delay in stream update that could be tolerated?[/quote]

Regarding the way I configure 2 devices to send data to the phone app, whenever data is available on each device, it notifies the phone app and sends data right away. The main limitation of the phone app when receiving data from 2 devices is that it only handles data from a device at a time. Say if it is receiving data from Device 01, while Device 02 keeps transmitting data to the phone app. Device 02's data will be queued on the air and arrived at the phone app as several ble packets as opposed to individual ble packet.

Edit: Fortunately, although we notice this limitation, we're able to retain most data without any packet loss happening in both devices.

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

hmolesworth — Wed, 27 Nov 2024 15:06:25 GMT

Moving back to main thread so easier to track replies. What are the sizes of the two device BLE packets sent to the tablet, and how often are they sent? What would be the worst-case delay in stream update that could be tolerated? These effectively dictate optimum settings.

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

Tai — Wed, 27 Nov 2024 05:26:20 GMT

This is my mistake 😅

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

hmolesworth — Wed, 27 Nov 2024 03:01:20 GMT

Good news; the original tag says nRF52832

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

Tai — Tue, 26 Nov 2024 22:53:38 GMT

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

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

hmolesworth — Tue, 26 Nov 2024 22:50:57 GMT

+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 :-)

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

Tai — Tue, 26 Nov 2024 22:36:56 GMT

#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);

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

hmolesworth — Tue, 26 Nov 2024 21:59:34 GMT

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;

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

Tai — Tue, 26 Nov 2024 21:38:01 GMT

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.

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

hmolesworth — Tue, 26 Nov 2024 20:04:08 GMT

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.

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

Tai — Tue, 26 Nov 2024 17:21:02 GMT

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?

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

hmolesworth — Mon, 25 Nov 2024 20:07:32 GMT

With that setup good quality antennas should work well, but for example a low-cost nRF52840 Dongle would not work well as that printed circuit antenna is not effective with personnel in close proximity. I prefer chip antennas. Here are a couple of discussions on maintaining connection stability; a lot depends on whether the streaming has to be live with no lag or you can accept some delay in updating (say) a scrolling live display. Also some tablets are better than others, and there are differences in what parameter ranges are allowed.

effect-of-connection-interval-on-connection-stability

throughput-and-long-range-demo

ble-connection-stability

There are lots on the devzone, these just happen to be a couple of links I have to hand

Edit: Orientation of the foot antenna matters; you might consider specifying a solid angle of best performance for the position of the tablet, or change the foot antenna alignment if that position happens to be inconvenient.

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

Tai — Mon, 25 Nov 2024 18:54:43 GMT

The following is the setting I have. A patient on the bed which is around 2.5 feet from the floor. Our device is worn in the patient's foot. The tablet location is a subject of change, meaning it can be held by someone or put on a table. Some people walked between the device and the tablet. Some other equipment was also in the room as well.

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

hmolesworth — Mon, 25 Nov 2024 18:18:40 GMT

Maybe post the settings you have; these can be tweaked to reduce disconnection likelihood by delaying as long as possible a disconnect due to loss of signal. Other options are coded PHY or increased Tx power, but the issue may also be with the tablet. Changing orientation or raising height of either device or tablet or both can help, a lot depends on multipath signals so room size and wall coatings.

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

Tai — Mon, 25 Nov 2024 17:47:56 GMT

Thanks for your suggestion, Susheel Nuguru ! We'll ask the module maker and try to test with the DK. Will keep you posted.

Similar question asked hmolesworth above, any suggestions to prevent the BLE device from being disrupted by human body or other sources of interference? Any help would greatly appreciate!

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

Tai — Mon, 25 Nov 2024 17:43:28 GMT

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!

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

Susheel Nuguru — Mon, 25 Nov 2024 11:04:49 GMT

It is a bit hard for us to say anything with the signal characteristics of the traffic outside the SoC as the module makers normally have different packaging on top and different antenna options to use. Please try to ask the module makers on this first unless you can show us that this issue is from the nRF chip and not the packaging or external components issue from the module.

Try running your app on the DK and see if you see the same. If not, then it is mostly module issue.

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

hmolesworth — Sat, 23 Nov 2024 01:49:27 GMT

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?