nrf52 observer scanning intervals erratic in nrf connect 2.7 when connected as peripheral

[edmcnicholas]

I have a device that acts as a peripheral with a connecting interval of 100-150mS and  also as an observer listening for beacons.  When I get a beacon I update the scan interval from an interval of 100mS with a window of 20mS to an interval of 500mS with a window of 250mS.  Up until 2.7 this worked correctly and I had no issue sending indicate events during this window. 

In a effort to keep on the latest code base we have updated to 2.7 and this no longer works and it hangs on indicate events seemingly locking up the devices Bluetooth as I do not get an indicate failed for 30s.  Even if I am only connected without indicates enabled i see the same erratic scanning and do not get anywhere near either interval and the scan seems to be random.  When I disconnect i see the expected scanning.

Please let me know if something has changed in 2.7 as this is a show stopper.  Any help would be appreciated.

Observer low and high speed scan

static struct bt_le_scan_param scan_param_slow = {

    .type     = BT_LE_SCAN_TYPE_ACTIVE,

    .interval = 160,        //n*.625 = 100ms  

    .window   = 32,         //n*.625 = 20ms

    .options  = BT_LE_SCAN_OPT_CODED | BT_LE_SCAN_OPT_NO_1M

};

static struct bt_le_scan_param scan_param_fast = {

    .type     = BT_LE_SCAN_TYPE_ACTIVE,

    .interval = 800,            //n*.625 = 500ms  

    .window   = 400,            //n*.625 = 250ms

    .options  = BT_LE_SCAN_OPT_CODED | BT_LE_SCAN_OPT_NO_1M

};

 

peripheral interval

#define BT_LE_CONN_PARAM_HFR BT_LE_CONN_PARAM(  \

                          80, \    

                          120, \

                          0, 600)

2.6.2

2.7 peripheral connected

2.7 peripheral not connected

[edmcnicholas]

I can confirm that this is not the code porting to more device tree oriented code as I just used the same project with the old board files and child image build system.  This is definitely an issue with the soft device.

[Elfving]

Hello Edward,

So yeah, you are not building using the new "sysbuild" then? And you are not building this directly from the SDK folder (maybe by modifying a sample or something), as that might also make it build using sysbuild?

I should also mention that the VSC extensions functionality is also a bit limited in 2.7, but if this is an older project that you've just copy-pasted a few files to I guess you haven't modifed any of these files in the VSC GUI either?

You are using NRF52, so I guess this isn't relevant either. I am not really seeing anything here either, but let me know something catches your eye. What nRF52 Soc is it?

Regards,

Elfving

[edmcnicholas]

Here is the dis peripheral sample with a scanner running with a delayable kwork that switches the interval.

2.7 one interval at 500/250 all others 500/50 or shorter.

2.6.2 500/250ms windows

peripheral_dis_scan.zip

[Hung Bui]

Hi Edward, 

I'm taking over the ticket from Håkon. 
I have reproduced the issue here. It seems that there is some change in the scheduler algorithm from v2.7. 
I am checking internally with the team to see why that happen and if there is anyway you can have the scanner having more priority over the advertiser. 

[edmcnicholas]

It's actually the connection causing the issue it is fine while advertising 

[Hung Bui]

Hi Edward, 
If you look at the documentation here: https://docs.nordicsemi.com/bundle/ncs-2.7.99-cs2/page/nrfxlib/softdevice_controller/doc/scheduling.html

You can find that the scanner (which windows is not equal to interval) can get 4th priority which is lower than advertising/connection. This is not listed in the documentation in v2.6.0
This may explain why the scheduling looks different between v2.6.0 and v2.7.0. 

Back to your issue, you mentioned "it hangs on indicate events seemingly locking up the devices Bluetooth" could you explain ?

One suggestion to avoid this issue is to do scan interval = scan windows. This will utilize the timeslot better (any available free timeslot will be used for scanning)

Could you give some more info about your application ? 

[edmcnicholas]

The indicate is sent out when we receive a broadcast message to the central takes a long time to fail with error -12 it looks like it is locking up for a good 30s and this was also not the case in 2.6 is there a buffer that needs to be increased? a lot of these messages get received.

int rc = bt_gatt_indicate(NULL, &g_armed_char_ind_params);
    if (rc)
    {
        LOG_WRN("Armed Indicate failed: %d", rc);
    }

[00:02:36.018,371] <wrn> hfrCentral: Armed MSG Filters matched. Address: EC:C0:85:69:36:93 (random) RSSI: -63 dRSSI 2818
[00:03:05.906,463] <wrn> bt_det: Armed Indicate failed: -12

[edmcnicholas]

It looks like the indicate function if very different in 2.7 as well

[Hung Bui]

Hi Edward, 

Could you reproduce the issue with a sample ? 
Can you capture a sniffer trace ? 
You may have error -12 with indication when there is a ongoing indication not confirmed yet. I suspect that it was because there were packet drop due to bad scheduling. A sniffer trace would be able to tell that. 
How often do you send the indication ? 

[edmcnicholas]

If i were to switch this to a notify would that work better and not hang as it does not require a response or can I look and see if there is a pending indicate.  These can be sent at very high rate but don't need to be.

[edmcnicholas]

Also if I do the same scan interval and window it looks to stay in RX the entire time.

[Hung Bui]

Hi again, 
I'm not 100% sure about switching to notification can solve the issue. Because I'm not 100% sure if error -12 was caused by an ongoing indication or something else. Please try to test with the notification to see if you get the same error. 
If you can reproduce the issue with indication on a sample, it would be great. 

Please try to test with scan window = scan period to see if it improves.