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

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