nRF52810 S112 background reconnect issue

[dr9]

Hi,

I'm working through a number of the PCA10040e examples (SDK16 | S112 | nRF52810 - mouse and keyboard to be specific) and have noticed some irregular behavior when waking the peripheral from sleep.  After bonding, if you put the peripheral to sleep, and let the central go to sleep as well (screen locked/off, no audio playing, etc.) and then wake the peripheral, the connection is not reestablished.  To restore the connection, you have to restart the peripheral with the central awake (i.e. being moved, screen on, audio playing, etc.)  However, if the central is "awake" when the peripheral is woken up, the connection is restored as expected.

I tried this with a nRF52832 (same examples in PCA10040 with S132) and the issue does not present itself.  The connection is able to be reestablished with the central sleeping.  Is this something to do with the Soft Device?  I plan on running a set of sniffer traces this afternoon and will post the results.

Thanks

p.s. central is an iOS device at this time.

[dr9]

Not sure if it helps, but I did find that if I make a call to advertising_start() sometime after the peripheral is running, with the central still sleeping, it does connect. 

[Kenneth]

You can find in chapter 35 in the Apple Bluetooth guidelines some recommendations to parameters that should be used: https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf

For instance I believe the advertising_start() may start by doing directed advertisement, this is not recommended by apple, see chapter 35.3. So you may need to init advertisement module without directed advertisement enabled.

Apple also have some suggestions for advertisement intervals.

[dr9]

Hey Kenneth,

Thanks for taking a look.

Kenneth said:

For instance I believe the advertising_start() may start by doing directed advertisement, this is not recommended by apple, see chapter 35.3. So you may need to init advertisement module without directed advertisement enabled.

The advertising_start() function calls ble_advertising_start(&m_advertising, BLE_ADV_MODE_FAST) as written in the SDK.  The advertising_init() function in main.c has directed advertising off:

/**@brief Function for initializing the Advertising functionality.
 */
static void advertising_init(void)
{
    uint32_t               err_code;
    uint8_t                adv_flags;
    ble_advertising_init_t init;

    memset(&init, 0, sizeof(init));

    adv_flags                            = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;
    init.advdata.name_type               = BLE_ADVDATA_FULL_NAME;
    init.advdata.include_appearance      = true;
    init.advdata.flags                   = adv_flags;
    init.advdata.uuids_complete.uuid_cnt = sizeof(m_adv_uuids) / sizeof(m_adv_uuids[0]);
    init.advdata.uuids_complete.p_uuids  = m_adv_uuids;

    init.config.ble_adv_whitelist_enabled          = true;
    init.config.ble_adv_directed_high_duty_enabled = false;  
    init.config.ble_adv_directed_enabled           = false;
    init.config.ble_adv_directed_interval          = 0;
    init.config.ble_adv_directed_timeout           = 0;
    init.config.ble_adv_fast_enabled               = true;
    init.config.ble_adv_fast_interval              = APP_ADV_FAST_INTERVAL;
    init.config.ble_adv_fast_timeout               = APP_ADV_FAST_DURATION;
    init.config.ble_adv_slow_enabled               = true;
    init.config.ble_adv_slow_interval              = APP_ADV_SLOW_INTERVAL;
    init.config.ble_adv_slow_timeout               = APP_ADV_SLOW_DURATION;

    init.evt_handler   = on_adv_evt;
    init.error_handler = ble_advertising_error_handler;

    err_code = ble_advertising_init(&m_advertising, &init);
    APP_ERROR_CHECK(err_code);

    ble_advertising_conn_cfg_tag_set(&m_advertising, APP_BLE_CONN_CFG_TAG);
}

Also confirmed that set_adv_mode_fast() is setting adv_params.properties.type = BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED, which is constant with what is being recommended in chapter 35.3.

I manipulated the advertisement intervals per Apple's guidelines, and per a variety of recommendations in the DevZone, and observed no changes.

[Kenneth]

Then I think a sniffer trace is the next step. It may be iOS that impose some limitations here while it is in sleep. Very strange that there seems be a difference between S112 and S132. 

Do you see any difference between phones or ios versions?

Kenneth

[dr9]

Getting the sniffer running shortly.

Initial test phone was an 8 running iOS13.3.1.  I just tested it on an iPad Pro running 13.7 and it works fine! 

Might be something with the older iOS.  I'm updating that phone now, too.

[dr9]

dr9 said:

Might be something with the older iOS.  I'm updating that phone now, too.

Updated to iOS 14 - no change in behavior observed.

Sniffer traces are attached. 

The trace titled "...sniffer_connects" represents what happens when the peripheral wakes up while the central is awake.  The trace titled "...sniffer_doesn't_connect" represents what happens when the peripheral wakes up while the central is asleep.  

3681.20200923 - sniffer_connects.pcapng

6327.20200923 - sniffer_doesnt_connect.pcapng

[dr9]

adding a second set of traces in case you want to see multiple samples.20200923 - sniffer_connects - 2.pcapng20200923 - sniffer_doesnt_connect - 2.pcapng