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.