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. */

[Sigurd]

Hi!

Tai said:

From what I understand, this parameter is linked with connection interval, deciding how many packets it can be transmitted during each connection interval.

Correct, it also indirectly increase the queue buffer for notifications.

Alternatively, you can try set the buffer size directly.

    ble_cfg_t ble_cfg;
    memset(&ble_cfg, 0, sizeof ble_cfg);
    ble_cfg.conn_cfg.conn_cfg_tag           = APP_BLE_CONN_CFG_TAG;
    ble_cfg.conn_cfg.params.gatts_conn_cfg.hvn_tx_queue_size = 50;
    err_code = sd_ble_cfg_set(BLE_CONN_CFG_GATTS, &ble_cfg, ram_start);
    APP_ERROR_CHECK(err_code);

(should be added to ble_stack_init() in main.c )

[Tai]

Hmm, we're developing an IOS application to receive data, and IOS limits number of packets (about 4-6 data packets) being sent for each connection interval. Thus, playing around with those you mentioned won't be much effective.

Any suggestions on grounding/shielding the device to prevent it from interference of other devices?Thanks!

[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.