Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

Missed packets in continuous scan mode

Rank

Total Posts: 2

Joined 2019-12-04

PM

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_ENABLEHIGH_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_evtvoid *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_observerAPP_ANT_OBSERVER_PRIOant_evt_handlerNULL); 

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 ([email protected]=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.      
Rank

Total Posts: 2

Joined 2013-03-03

PM

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?
     
Rank

Total Posts: 2

Joined 2019-12-04

PM

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/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-reserved
 
*          Byte1 ANT priority overridelownormal(default), highcritical
 
*          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      
Rank

Total Posts: 2

Joined 2013-03-03

PM

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.