Avoid external devices disrupt a Bluetooth connection

[Tai]

Hi everyone! We're working on a device that is supposed to use in the operating room (OR). We're facing a serious problem with BLE connection as there are other wireless devices or sources of electromagnetic radiation in the OR. The system briefly describes as the following.

Our devices usually sit close to a mobile application (6-10 feet away). We're sending data from two BLE peripherals to the mobile app simultaneously. During the benchtop test, we never get any issues with data transmission. However, in the OR data were not successfully transmitted to the app. It jumped into the error either NRF_ERROR_RESOURCES or NRF_ERROR_BUSY, referring to the following portion of code. 

        err_code = sd_ble_gatts_hvx(p_cus->conn_handle, &hvx_params);
        if (err_code == NRF_ERROR_INVALID_STATE) {
            NRF_LOG_ERROR("ble gatts hvx error: %u", err_code)
            return err_code;
        }
        if (err_code == NRF_ERROR_RESOURCES || err_code == NRF_ERROR_BUSY) {
            // Wait for BLE_GATTS_EVT_HVN_TX_COMPLETE.
            // Drop data
            NRF_LOG_ERROR("ble gatts hvx out of resources")
            p_cus->busy = true;
        }

This issue doesn't happen frequently, we feel like those sources with wireless or electromagnetic radiation randomly disrupt the BLE connection. There are several options as mentioned the following we've implemented to mitigate this, but the issue still happens:

• Make a short connection interval (7.5 ms).
• Update DLE (up to 251 byte) and MTU (247) to increase the throughput.
• Queue implementation to reduce sample drops. 

Therefore, I greatly appreciate if there are any suggestions to avoid this issue. Thanks!

[Sigurd]

Hi!

You could try to increase the NRF_SDH_BLE_GAP_EVENT_LENGTH in sdk_config.h

[Tai]

Thanks for reply, Sigurd. I've read many posts regarding NRF_SDH_BLE_GAP_EVENT_LENGTH parameter.  I'm still confused how much should I increase this parameter? From what I understand, this parameter is linked with connection interval, deciding how many packets it can be transmitted during each connection interval. Since my connection interval is 7.5 ms, I've set NRF_SDH_BLE_GAP_EVENT_LENGTH to 6 (6 x 1.25ms = 7.5ms), covering 100% transmission bandwidth. 

I noticed its value is set to 400 (400 x 1.25ms = 500ms) with the following setup in the example of long-range demo. It seems this number is based on the max acceptable connection interval? Thanks!

#define CONN_INTERVAL_MIN               (uint16_t)(MSEC_TO_UNITS(7.5, UNIT_1_25_MS))    /**< Minimum acceptable connection interval, in 1.25 ms units. */
#define CONN_INTERVAL_MAX               (uint16_t)(MSEC_TO_UNITS(500, UNIT_1_25_MS))    /**< Maximum acceptable connection interval, in 1.25 ms units. */

[hmolesworth]

Some thoughts: Trace antenna/aerial behaves poorly; chip antenna/aerial has much better results. Height above ground can affect performance, eg on bench vs on floor (say heel of foot). FDA and other regulatory bodies (used to) frown on using BLE in the OR so clearance may be an issue.

[Sigurd]

If you think interference is an issue, you could confirm the packet loss, crc-error, etc with a sniffer trace: https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le

By increasing the queue buffer for notifications, then during interference, you could then be able to "buffer" up packets, and get them through once the interference is lower/gone.

If you are creating a custom PCB, we could help review the design. If so, please create a new private case for the PCB review.

[Tai]

hmolesworth said:

Some thoughts: Trace antenna/aerial behaves poorly; chip antenna/aerial has much better results. Height above ground can affect performance, eg on bench vs on floor (say sole of foot). FDA and other regulatory bodies (used to) frown on using BLE in the OR so clearance may be an issue.

Thanks for suggestions! We're using chip antenna, and we boosted Tx power to 8 dBm. With benchtop test, we barely get data drops unless we stress the device really hard (e.g., covering it with many isolated layers, moving it far away the phone app....).

In the OR setup, we currently put our phone app close to the floor and behind other medical equipment while the device is about 75 - 100cm height. Not sure if it affects the device performance.

FYI, as far as I know FDA does not have specific comments or regulations solely dedicated to devices using BLE technology in operating rooms. 

[Tai]

Sigurd said:

If you think interference is an issue, you could confirm the packet loss, crc-error, etc with a sniffer trace: https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le

It's really hard for us to trace it when testing it in the OR. We tried to reproduce it in the benchtop test by moving the device far away the phone app.

Sigurd said:

If you are creating a custom PCB, we could help review the design. If so, please create a new private case for the PCB review

We're using a third-party one with FCC granted for portable use (body worn).

[hmolesworth]

In my testing 75 - 100cm height would degrade performance; maybe test at 1-2m to see if it makes a difference ..

Edit: Worth reviewing this, although short-range OR is not quite the same near-ground can be an issue: testreport

[Tai]

Hi hmolesworth . Sorry for not replying this earlier. Thanks for this tip! We now accepted data loss as long as it's less than 2% of whole data.