Scan Response works only sporadic

[BleHf]

I'm using the the pc_ble_driver and want to scan BLE devices with legacy and extended pdu.

My problem is that scan responses only reached sporadic my callback.

Init:

sd_ble_gap_scan_start(m_adapter, &m_scan_param, &m_adv_report_buffer);

in Callback

static void on_adv_report(const ble_gap_evt_t *const p_ble_gap_evt)
{
....
sd_ble_gap_scan_start(m_adapter, NULL, &m_adv_report_buffer); //continue scanning
}

Sometimes i get a timeout:

static void on_timeout(const ble_gap_evt_t * const p_ble_gap_evt)
{
....
sd_ble_gap_scan_start(m_adapter, &m_scan_param, &m_adv_report_buffer); //restart scanning in case of timeout => but why?
}

Is something wrong with my scanning process? As i understand, i need to restart scanning after EACH report. (only after BLE_GAP_ADV_DATA_STATUS_INCOMPLETE_MORE_DATA, but this is here not the case)

See Sequence for Scanning:

Different View:

Sniffing with Wireshark looks ok. Scanning Requests and Responses are there. So it seems some kind of receiving issues.

[Edvin]

Hello,

What SD_API version are you using in your pc-ble-driver app (and on the connectivity device)? If you are using the latest version, there was a change in the softdevice that made it difficult to be able to pick up scan responses, because of the delay from the advertising event -> serial -> decide to continue scanning -> serial -> actually resume scanning. The time it takes for this round trip to complete takes a bit of time, and in many cases, the scan response is done by the time you resume scanning. 

If possible, try to stick to the older version of the pc-ble-driver if you are dependent on scan responses. SD API 5 and earlier will not have this issue.

Best regards,

Edvin

[BleHf]

Hi Edvin,

thanks for your feedback.

I'm using SD API 6, because SD API5 does not support extended advertising. So the only way to go is with API 6. 

My setup is:

connectivity is 4.1.4

with s140  6.1.1.

I understand the roundtrip latency in the communication path. For that reason i found it really interesting, so run the ble stack mainly on the embedded device.

Also having an oversized report buffer, some caching of 2-3 scan reports should be no problem.

[BleHf]

Is there a chance to get an improved behavior?

[Edvin]

Hello,

From our side, there will be no new releases on the pc-ble-driver side. This is a deprecated tool (because it builds on the softdevice from the nRF5 SDK, which is in maintenance mode). So no new releases from our side, unfortunately.

You can see a discussion that I had with another user a couple of years ago, here.

I am not sure whether he attempted, and whether that succeeded, but my idea back then was to modify the application running on the nRF to always resume scanning directly from the nRF. This will probably require some modifications both on the application running on the nRF, and the application running on the host side.

Alternatively, as my colleague mentioned in one of your other tickets, you can look into the Bluetooth Shell.

BR,
Edvin