Scanning for ANT+ Heart Rate Monitor Noticeably Impacts Existing BLE Peripheral Connection Performance

[mlyonupdesigns]

I am configuring the ANT+ scan on two separate channels with the following parameters:

ROMDATA_T ant_search_config_t aprfant_dynastream_search_config =
{
.channel_number = APRFANT_HRM_DYNASTREAM_SCAN_CHANNEL_NUMBER,
.low_priority_timeout = ANT_LOW_PRIORITY_TIMEOUT_DISABLE,
.high_priority_timeout = ANT_HIGH_PRIORITY_SEARCH_DISABLE,
.search_sharing_cycles = 64, //ANT_SEARCH_SHARING_CYCLES_DISABLE,
.search_priority = ANT_SEARCH_PRIORITY_DEFAULT,
.waveform = ANT_WAVEFORM_DEFAULT,
};

ROMDATA_T ant_search_config_t aprfant_suunto_search_config =
{
.channel_number = APRFANT_HRM_SUUNTO_SCAN_CHANNEL_NUMBER,
.low_priority_timeout = ANT_LOW_PRIORITY_TIMEOUT_DISABLE,
.high_priority_timeout = ANT_HIGH_PRIORITY_SEARCH_DISABLE,
.search_sharing_cycles = 64, //ANT_SEARCH_SHARING_CYCLES_DISABLE,
.search_priority = ANT_SEARCH_PRIORITY_DEFAULT,
.waveform = ANT_WAVEFORM_DEFAULT,
};

While the scan is active, an existing BLE peripheral connection (with notifications being sent every 250msec) is substantially impacted resulting in "bursty" delivery of notifications. Additionally, trying to establish a BLE peripheral connection while the scan is active works sometimes and not other times (this depends on the central device behavior).

I see other posts on the forum talking about BLE heart monitor scanning strategy related to reducing the scan window/interval to minimize the impact on an existing connection. I also see the same impact when scanning for a BLE heart rate monitor with an existing BLE peripheral connection.  I am currently using a 50 msec window and a 100 msec interval. I assume I should reduce both the lessen the impact on the BLE peripheral connection.

Could someone please suggest reasonable parameters for ANT+ and BLE scanning that will reduce the impact on the BLE peripheral connection while still giving good performance?

[Kenneth]

My recommendations to minimize impact on a BLE peripheral link is to:

- For BLE scanning set scan window to 5ms (or less) and adjust scan interval to fit your power consumption requirements (5ms or more).

- For ANT search check out this thread: 
https://devzone.nordicsemi.com/f/nordic-q-a/60158/how-to-arrange-ble-and-ant-event/244652#244652 

[mlyonupdesigns]

The BLE peripheral connection is impacted by either ANT+ or BLE heart rate belt searching. Based on the ANT settings listed above, I feel like I've set the scan parameters to be "friendly" to the BLE peripheral operation. I have not used the ANT coexistence functions to alter the behavior that way. Is that likely to make a big difference?

I also ran experiments with the BLE by setting the scan window to 10 msec and the scan interval to 20 msec. There didn't appear to be any improvement, but I will recheck. My understanding was that by using a 20msec interval, the 250 msec BLE peripheral schedule would be allowed to happen generally unimpeded.

[Kenneth]

I assume this is the S332 softdevice, so you may find some information in the scheduling chapter 16 in the S332 softdevice specification:
https://www.thisisant.com/developer/components/nrf52832/#tab_tech_resources_tab

The ANT coexistence api can have a big impact, it will ensure BLE have higher priority always.

mlyonupdesigns said:

My understanding was that by using a 20msec interval, the 250 msec BLE peripheral schedule would be allowed to happen generally unimpeded.

 I agree.

[mlyonupdesigns]

I'll assume using the ANT coexistence functionality will solve my issue when scanning for ANT heart rate belts.

I reviewed section 16 of the SDS, and feel like it's sufficiently confusing about explicitly calculating "optimal" scan interval and scan window. My application uses a connection interval between 90 and 100 msec depending on the mobile device being used. For that connection interval range, it seems to me that a 10 msec scan window and a 20 msec scan interval should provide sufficient selectively to allow the peripheral to operate unimpeded. As you agree with that, what else could be happening to explain why the peripheral is impacted so obviously?

[mlyonupdesigns]

Further, it does appear that changing the scanning parameters improves BLE peripheral performance when explicitly starting a scan using sd_ble_gap_scan_start. But when attempting to connect to a known peer using sd_ble_gap_connect without having previously scanned, which should be using the same scan parameters, the BLE performance is impacted.

[Kenneth]

I do not see how using sd_ble_gap_scan_start() before sd_ble_gap_connect() should have any influence, however if you look at the table 16-1 scheduling priorities in the S332 softdevice specification you can find that central connection setup have higher priority than serving BLE in a connection. I do not see any good workaround to that, maybe establish new connection with a very slow interval (>250ms) may help and/or prior to this period reduce the connection interval of the already established BLE link to 125ms for a short period of time (thereby indirectly every other BLE interval can be interrupted without any problems).

Best regards,
Kenneth

[mlyonupdesigns]

Perhaps I wasn't clear. My application has two use cases: 1. Scanning and discovering unknown heart rate belts, followed by selecting one and establishing a connection. 2. Establishing a connection to a previously connected (but no longer connected) heart rate belts using device number (peer address).

In use case 1, sd_ble_gap_scan_start() is used to discover and sd_ble_gap_connect() is used to connect. In use case 2, sd_ble_gap_connect() is used to connect which much use scan (?) to locate the specific peer address device.