Scan Response works only sporadic

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.

Parents
  • 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

  • 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.

Reply
  • 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.

Children
No Data
Related