pc-ble-driver no scan response

[Torsten Robitzki]

I want to incoorperate the pc-ble-driver into a product, using the PCA10059 USB-dongle. My design requires me to receive advertising scan responses. I successfully receive advertising events and I see both, scan resquests and scan responses with a sniffer, but I never receive any scan responses. According to the debug messages, printed by the pc-ble-driver I suspect that scan responses are never send from the PCA10059 to the connected PC.

I expect the `type.scan_response` field in the received `ble_gap_evt_adv_report_t` event to be set once in a while.

Any idea, why I do not receive any scan responses? Do I have to configure the reception? A'm I'm using the wrong connectivity firmware?

I'm using the connectivity_4.1.1_usb_with_s140_6.1.1 with an PCA10059 1.0.0 on OS/X 10.14.5.

See attached, the sniff and the logfile.

best regards,

Torsten

no_scan_response.pcapngno_scan_response.log

[Torsten Robitzki]

While further investigating this, I build the connectivity firmware (debug build) and deployed it onto a PCA10056 (to be able to debug it). With this setup, I receive scan responses once in a while. I made some measurements and found that in most times (5 out of 9), it takes 40 to 50 seconds to receive a first scan response from a specific address, while in all other times (4 out of 9) it takes 2 to 4.3 seconds to receive a first scan response.

The specific address I'm looking at, advertises with an interval of ~110ms (according to the sniffer). The time it takes to receive a first scan response devided by the number of received advertising PDUs (ADV_IND) is roughly 2 times 110ms for all measurements. I would expect ~110ms / 3, as the scanned device advertises on all three advertising channels. And of cause during all periods, there are plenty of scan requests made by the connectivity firmware and scan responses by the device.

In my setup, I had to configure the pc-ble-driver client with a baudrate of 100,000 (not 1,000,000 as in the examples). Could this be some kind of congestion on the USB part? If so, why are advertings priorizes over scan responses?

[Jørgen Holmefjord]

Sorry for the slow reply, I have been very busy during the summer. I'm checking with the developer if we have any testing or known issues with this.

Torsten Robitzki said:

I made some measurements and found that in most times (5 out of 9), it takes 40 to 50 seconds to receive a first scan response from a specific address, while in all other times (4 out of 9) it takes 2 to 4.3 seconds to receive a first scan response.

Are you testing this against a specific device, or are the 9 tests with different devices? Which kind of devices are you testing with?

[Torsten Robitzki]

Hi Sigurd,

thank you very much for reproducing the behavior. I think your first interpretation sounds resonable. Which on the other hand meens, that this issue is not solvable with the current state of the pc-ble-driver.

Adding some kind of automatic-rescan-switch, which would instruct the connectivity firmware to automatically issue the sd_ble_gap_scan_start() would solve the problem. What do you think? Can you think of other methods to at least mitigate the problem?

[Sigurd]

That sounds like a good idea. Unfortunately, I can’t think of any other ways to mitigate or solve this.

[Torsten Robitzki]

By accident, I've used the nRF Connect "Bluetooth Low Energy" modul, which installed the connectivity firmware version 4.1.1 SoftDevice API version 3. nRF Connect was able to show me the advertising response data very quickly, reproducable.

How is nRF Connect using the connectivity differently than the pc-ble-driver? What could I do to get the same behaviour.

[Sigurd]

Torsten Robitzki said:

How is nRF Connect using the connectivity differently than the pc-ble-driver

pc-ble-driver has support for SoftDevice API version 2, 3, 5 and 6. nRF Connect for Desktop still uses SoftDevice (API) v3, also for nRF52840. The scanning APIs were changed in SoftDevice v6 so that the scanning needs to be restarted for every received advertising packet. That's the reason why you don't have this issue on API v3.

(Edit: nRF52840 products that are going to be listed with Bluetooth SIG need to use use SD v6 and above, ref this QDID list.)

[Torsten Robitzki]

Well, that makes sense. Unfortunatelly, this doesn't solve my problem, as I need advertising response and BLE 5.0 features :-(