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.

[Kenneth]

I recommend you always do a scan first (sd_ble_gap_scan_start()), followed by a connect (sd_ble_gap_connect()), independent of use case 1 or 2. Using sd_ble_gap_connect() should only be called once you have received an advertisement packet first using sd_ble_gap_scan_start(). Using sd_ble_gap_connect() should only be used after you know the peer is in range and actively wanting to connect.

[mlyonupdesigns]

The approach I describe works so I'm not sure why I would need to scan first. What does the sd_ble_gap_connect() function use the scan parameter argument for if not to locate the specific device? Are you suggesting that "scanning while in the gap connect functionality" will be less likely to allow the peripheral work to get done?

[Kenneth]

Feel free to do this as you like.

The "benefit" by scanning first is for instance if you have more than one peer that you may want to connect to, then by scanning first you will get an advertisement packet from any peer, and then you can connect with that one since you know it's in range and powered. While if you go straight to connect, then you will not know if there are other peers that you have a relationship with that is in range and powered up.

[mlyonupdesigns]

Can you point me to an example of how to connect using sd_ble_gap_connect() and a whitelist? Is it possible that will improve the behavior? If the BLE central his priority over all BLE peripheral connections why does scanning using 10 msec/20 msec scan parameters while the BLE peripheral is connected seem to improve behavior?