Missed scan response with S132 6.x connectivity

[Adrian Eggenberger]

Hi

I've just modified our platform that uses a connectivity based environment to the latest S132 6.1.0/SDK15 combination. Since the migration I seem to miss a lot of scan responses event if they are configured on start scan.

My assumtion is that the new added pause in scanning after a advertisement report has been received is causing this problem. The pause between the advertisement reception and the continue call with start scan function is naturally longer than if no connectivity is used. This longer pause may cause that no scan response is received.

Is this a known behavior? What can I do to get the scan working witch scan responses over connectivity?

Regards Adrian

[Balaji Srinivasan]

Hello Adrian,

Are you turning on extended scanning? In other words, what is the value of ble_gap_scan_params_t::extended when you call the sd_ble_gap_scan_start API? 

Is the peer advertiser also on s132 v6.1? Or is it a non-Nordic device? 

Can you confirm that the radio environment you are in when you test the 6.1 SoftDevice is similar to that when you had tested the 6.0 SoftDevice? (eg. number of advertisers and scanners around, wifi etc) I ask this because I suspect that the radio environment you are in when testing the 6.1 SoftDevice is a more noisier. In that case, it is likely that the scan responses are not received by the scanner. 

@ What can I do to get the scan working witch scan responses over connectivity?

I do not understand this statement fully, Especially the 'connectivity' part. 

Cheers,

Balaji

[Adrian Eggenberger]

Hi

The extended scanning is not enabled (= 0). The advertiser is also a Nordic device based on S132 6.x, but there are other non Nordic devices around also advertising. The issue is not directly related to S132 6.1, it is an issue with both version of the 6.x softdevice.

I don't think it has something to do with the environment, because with the S132 5.x the scan responses can be received without a problem. 

The problem only occurs if the connectivity firmware is used. With standard firmware (application and softdevice on the same nRF52 chip) everything seems to work as expected.

Regards Adrian

[FormerMember]

Hi Adrian,

Could you elaborate a little on this paragraph: My assumtion is that the new added pause in scanning after a advertisement report has been received is causing this problem. The pause between the advertisement reception and the continue call with start scan function is naturally longer than if no connectivity is used. This longer pause may cause that no scan response is received.

Which settings do you use when scanning?

Regards,

Kristin

[Adrian Eggenberger]

Hi Kirstin

In the description for the event "ble_gap_evt_adv_report_t" the following statement can be found:
When ble_gap_adv_report_type_t::status is not set to BLE_GAP_ADV_DATA_STATUS_INCOMPLETE_MORE_DATA, scanning will be paused. To continue scanning, call sd_ble_gap_scan_start.

In my understanding this causes that any advertisings (or scan responses) received between the call of sd_ble_gap_scan_start with parameters set to NULL is ignored.

When the application and the BLE-stack are not running on the same CPU (=> connectivity (Link))  the time until the scan can be continued by the sd_ble_gap_scan_start call is increased because the communication over UART between the two CPU's.

My assumption is now that with the increased time the scanning is "paused" the scan response is mostly ignored as the scan response always comes shortly after the advertising packet.

The settings used for the scan are:
extended = 0
report_incomplete_evts = 0
active = 1
filter_policy = BLE_GAP_SCAN_FP_ACCEPT_ALL
scan_phys = BLE_GAP_PHY_AUTO
interval = 0xA0
window = 0x50
timeout = 0
channel_mask = {0,0,0,0,0}

Regards Adrian

[Balaji Srinivasan]

Adrian Eggenberger said:

My assumption is now that with the increased time the scanning is "paused" the scan response is mostly ignored as the scan response always comes shortly after the advertising packet.

This assumption is correct. But this was the case with 6.0 SoftDevice as well. So I am still unsure why you were not seeing the same behavior when testing with 6.0 SoftDevice.

Anyways, one solution for you is to modify the connectivity firmware (function ble_event_enc() in ble_event_enc.c) to call sd_ble_gap_scan_start() when it processes the BLE_GAP_EVT_ADV_REPORT. This, of course, would mean that you are adding some intelligence to the connectivity firmware. 

[Adrian Eggenberger]

Balaji Srinivasan said:

This assumption is correct. But this was the case with 6.0 SoftDevice as well. So I am still unsure why you were not seeing the same behavior when testing with 6.0 SoftDevice.

Maybe I've written this not correctly. The effect is the same on 6.0 and 6.1. It is different in Softdevice version 5.x.

I did a quick test of you proposed solution with the added scan start in the function ble_event_enc. It didn't change anything. In my connectivity firmware the event from the softdevice is synced in the context of our OS. This surely causes some delay. I have to run the test with the original connectivity firmware.

Anyway if the sync in our OS takes already too long for receiving the scan response we would also have a problem in the normal firmware. I didn't test this so far. Can you give a rough estimation how fast the sd_ble_scan_start needs to be called to be able to catch the scan response?

. 

[Balaji Srinivasan]

Adrian Eggenberger said:

The effect is the same on 6.0 and 6.1. It is different in Softdevice version 5.x.

Thanks for clarifying that. 

Adrian Eggenberger said:

Can you give a rough estimation how fast the sd_ble_scan_start needs to be called to be able to catch the scan response?

Yes. The time between the end of a scannable adv_ind (on air) and the end of the shortest possible scan response (on air) is about 607 micro seconds. The gap between the ADV_IND and SCAN_REQ is 150 micro seconds. The stack raises its the first adv report after it has sent the SCAN_REQ on air. So I would say that the sd_ble_gap_scan_start should be called within about (607 - 150) = 457 micro seconds. I have verified this using a quick test.

[Adrian Eggenberger]

Thank you for the estimation and the quick test. I think that absolutly explains the behavior I see.

Sadly with this API the handling of the softdevice events in the OS context becomes really hard as the sync in an OS domain always costs time. Till now the handling of softdevice events could be a few milliseconds after the softdevice triggers the event. With the newest API we probably need to find a solution to handle the advertisings in the ISR. In my opinion this is a big downside of the new API in the v6 softdevices. Additionally using this API over the connectiviy is also not possible without workarounds.

I‘m still searching for a way to fix this problem. I‘ll report here if I find a way to handle this.

Regards Adrian

[Balaji Srinivasan]

Adrian Eggenberger said:

I did a quick test of you proposed solution with the added scan start in the function ble_event_enc. It didn't change anything.

I am a bit curious as to why this did not work. Can you confirm that you call the scan_start after the encoding of the event is complete? And can you also confirm that you have removed the call to scan_start in your application side (so that there are not two calls to scan_start sent to the SoftDevice) Do you also ensure the scan_start API returns NRF_SUCCESS?

[Adrian Eggenberger]

As far as I remember the scanning successfully was reactivated by the sd_ble_gap_scan_start that has been added in the connectivity firmware, but no scan responses have been received. I would expect that this is caused by our handling of the softdevice IRQ in our connectivity firmware (we are not using exactly the Nordic implementation there). We are probably too slow in handling the IRQ? I‘ll try to do a measurement tomorrow as today I‘m out of office.

Did you test this with the Nordic connectivity firmware? As far as I remember ther is also a synchronization to the sheduler contex. Is this fast enough?