Home
ANT Forum

ANT Forum

Username		Password		Remember Me?	forgot password?

You are here: Forum Home → ANT Developer’s Forums → ANT General Questions → Thread

25 May 2020 02:32 AM

Total Posts: 2

Joined 2019-12-04

Hello everybody.

I want to quickly scan for available HR monitors. For this, I figured going into continuous scan mode should give fastest acquisition times. Since HR monitors broadcast at 4.06Hz, scanning for a couple of seconds should give me plenty of packets of every monitor around me.
However, what I see is that I'm not nearly receiving the number of packets expected from a 4.06Hz broadcast - I tried continuous scanning and high-duty background search. see details below.

hardware
MCU: nRF52840
nRF SDK: 15.3.0
Softdevice: S340 v6.1.1
Sensor (master): Heart rate monitor - broadcast @4.06 Hz

configurations
high-duty (~ from ant_hd_search_and_bs)

sd_ant_lib_config_set(ANT_LIB_CONFIG_MESG_OUT_INC_RSSI | ANT_LIB_CONFIG_MESG_OUT_INC_DEVICE_ID);
const ant_channel_config_t bs_channel_config = {
    .channel_number = 0,
    .channel_type = CHANNEL_TYPE_SLAVE_RX_ONLY,
    .ext_assign = EXT_PARAM_ALWAYS_SEARCH,
    .rf_freq = 57,
    .transmission_type = 0,  // Wild card
    .device_type = 0x78,
    .device_number = 0x00,   // Wild card
    .channel_period = 0x00,  // This is not taken into account.
    .network_number = 0,
};
const ant_search_config_t bs_search_config = {
    .channel_number = 0,
    .low_priority_timeout = ANT_LOW_PRIORITY_TIMEOUT_DISABLE,
    .high_priority_timeout = ANT_HIGH_PRIORITY_SEARCH_DISABLE,
    .search_sharing_cycles = ANT_SEARCH_SHARING_CYCLES_DISABLE,
    .search_priority = ANT_SEARCH_PRIORITY_DEFAULT,
    .waveform = ANT_WAVEFORM_DEFAULT,  // must be set to the default for high duty search
};
const ANT_HIGH_DUTY_SEARCH_CONFIG hconfig = {HIGH_DUTY_SEARCH_ENABLE, HIGH_DUTY_SEARCH_SUPPRESSION_NONE,
                                             HIGH_DUTY_SEARCH_RESTART_INTERVAL_DEFAULT};
sd_ant_high_duty_search_config_set(&hconfig;);
ant_channel_init(&bs;_channel_config);
ant_search_init(&bs;_search_config);
sd_ant_channel_open(0); 

cont.scan (~ from ant_continuous_scanning_controller)

sd_ant_lib_config_set(ANT_LIB_CONFIG_MESG_OUT_INC_RSSI | ANT_LIB_CONFIG_MESG_OUT_INC_DEVICE_ID);
ant_channel_config_t channel_config = {
    .channel_number = 0,
    .channel_type = CHANNEL_TYPE_SLAVE_RX_ONLY,
    .ext_assign = 0x00,
    .rf_freq = 57,
    .transmission_type = 0,  // wildcard
    .device_type = 0x78,     // 0x78 = heart rate monitor
    .device_number = 0x00,   // wildcard
    .channel_period = 0x00,  // Not used, since this is going to be scanning
    .network_number = 0,
};
ant_channel_init(&channel;_config);
sd_ant_rx_scan_mode_start(0); 

event handler

static uint8_t cnt = 0;
static void ant_evt_handler(ant_evt_t *p_ant_evt, void *p_context) {
    if (p_ant_evt->channel == 0) {
        switch (p_ant_evt->event) {
        case EVENT_RX:
            cnt++;
            break;
        default:
            break;
        }
    }
}
NRF_SDH_ANT_OBSERVER(m_ant_observer, APP_ANT_OBSERVER_PRIO, ant_evt_handler, NULL); 

The event handler simply counts RX events during the scan/search period.

Results
Counts during 5-second scan/search
high-duty: 9, 4, 13, 2, 12, 3, 9, 11 (avg: 7)
continuous: 3, 4, 3, 2, 3, 5, 2, 5 (avg: 3)
high-duty (+2nd HRM): 17, 11, 14, 9, 22, 20 (avg: 15)
continuous (+2nd HRM): 7, 6, 5, 8, 6, 8 (avg. 6)
continuous (via USB dongle/ANTware, 'open in scan mode'): ~20 (all), reliably

While doing the tests, there is an active BLE connection (hence no BLE advertising), but only little communication on the BLE channel.

What I take from these tests is that on application-side I should, in principle, be able to handle each event of a single sensor (5sec@4Hz=20 events), but I only reach this number if I let 2 HRM sensors broadcast at the same time. With a single HRM sensor I miss >50% in high-duty mode, and even >80% in continuous scan mode.

The scan mode with a USB dongle and ANTware works as expected and lists RX events at the expected broadcast rate of ~4Hz.

My questions are:
- why is the continuous scan missing so many packets compared to high-duty (no suppression)? and both are still missing a lot of packets compared to the actual number emitted by the sensor
- why is there such a big variation in counts between runs? I have max. 2 ANT devices present at the same time, so radio is definitely not crowded.
- is this the right way to scan for all available HR monitors as fast as possible (I don't need to care about keeping any other ANT communication alive in the background)?

Thanks for any ideas.

25 May 2020 12:01 PM #1

jcfriesen_ant Administrator

Total Posts: 3

Joined 2013-03-03

Hi,

Have a couple of questions regarding the setup:

1. What connection interval is being used for the BLE connection?

2. What does the performance look like if BLE is disabled on the device?

26 May 2020 01:19 AM #2

Chris Blomfield-Brown Newbie

Total Posts: 2

Joined 2019-12-04

Thanks, that was a nudge in the right direction!
When I terminate the active BLE connection prior to ANT scanning, there were essentially no packets lost anymore with both (high-duty & continuous scan) methods - even when leaving the BLE advertising active.

Looking around further there might be a possibility to temporarily shift radio priority between ANT and BLE using sd_ant_coex_config_get / sd_ant_coex_config_set.

I have read out the current coex_config for the scan channel:
config = 02 C7 03 04 00 3A 00 3A 14 3C
advanced_config = 00 02 00 20 54 C7 00 20

Do you have a recommendation for which settings to use to give highest priority to ANT for the duration of the scan?
Unfortunately I could not find more documentation than this

*          Configuration structure is as follows:
 *          Byte0 = Configuration enable bitfield
 *                  bit0 - enable/disable tx/rx channel keep alive config (Byte4/5 & Byte6/7)
 *                  bit1 - enable/disable tx/rx channel fixed interval priority config (Byte1)
 *                  bit2 - enable/disable transfer keep alive config (Byte2)
 *                  bit3 - enable/disable search channel fixed interval priority config (Byte3)
 *                  else - reserved
 *          Byte1 = tx/rx channel fixed interval priority configuration
 *          Byte2 = transfer keep alive configuration
 *          Byte3 = search channel fixed interval priority configuration
 *          Byte4(LSB)/Byte5(MSB) = tx channel keep alive configuration
 *          Byte6(LSB)/Byte7(MSB) = rx channel keep alive configuration
 *          Byte8 = ANT counts/16 spent in high priority mode during search scan.
 *          Byte9 = ANT counts/16 spent in low priority mode during search scan.
 *
 *          Advanced configuration structure is as follows:
 *          Byte0 = Configuration enable bitfield
 *                  bit0 - enable/disable priority override config (Byte1)
 *                  bit1-7 - reserved
 *          Byte1 = ANT priority override. 0 = low, 1 = normal(default), 2 = high, 3 = critical
 *          Byte2 = Reserved
 *          Byte3 = Reserved
 *          Byte4 = Reserved
 *          Byte5 = Reserved
 *          Byte6 = Reserved
 *          Byte7 = Reserved 

Ideally I would like to use the continuous scan mode, so some configs, e.g. "search channel fixed interval", seem to not apply to continuous scanning.

Or should I rather change the BLE connection parameters (e.g. increase the connection interval if possible?) to reduce temporarily the impact of BLE communication on the ANT scan?
My current BLE connection intervals are
min: 6 * 1.25ms
max: 80 * 1.25ms

26 May 2020 05:24 PM #3

jcfriesen_ant Administrator

Total Posts: 3

Joined 2013-03-03

If possible, I would check what rate is actually being established with your connection interval. One of the issues with changing coexistence on a scanning channel is that it can adversely affect your BLE connection, potentially causing connection loss. I would suggest trying a higher minimum interval for BLE and seeing if that meets your needs.

1 of 1 Pages

ANT Forum

Missed packets in continuous scan mode