• State Not Answered
  • +3 person also asked this people also asked this
  • Replies 25 replies
  • Subscribers 74 subscribers
  • Views 6985 views
  • Users 0 members are here
Attachments (5) Download All
Nordic Case Info
  • Case ID: 233016
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    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?

  • 0 in reply to Torsten Robitzki

    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?

  • 0 in reply to Jørgen Holmefjord

    Ok, would be great if you could provide this firmware. You have not seen this issue with other devices/firmwares? Could you for instance test one of the stock examples from the SDK? The ble_app_uart example should for instance use scan response.

  • 0 in reply to Jørgen Holmefjord

    Hi Jørgen,

    I tried to reproduce this with the ble_app_uart example and the results are quite compareable. I've modified the attached nordic_reproducer.cpp to count the number of scan reports received for every address ending in 0xf3 (which is just my device) and to stop execution once, a scan reponse was received. This small tables shows the number of received advertisments and the time it took to receive a first scan response:

    470 0m44.629s
    549 >0m51.572s
    488 0m46.725s
    403 0m38.277s
    350 0m33.204s
    444 0m41.694s
    175 0m17.192s
    324 0m31.005s
    302 0m28.396s

    For the second measurement, during the entire runtime of the program, no scan response was received. The attached no_scan_response_II.log shows the program output during a measurement (182 advertisings received until after 18s, a first scan response was received). no_scan_response_II.pcapng contains a wireshark sniff during this 18s.

    I don't expect the pc-ble-library to report every scan response, but if the library would report just every 10th, it would be just a matter of a second to get a valid scan response.

    Unfortunatelly, my current product design relies on receiving the scan responses, which works fine for native Windows10 and OS/X. I would like to support pc-ble-driver to be able to use BLE 5.0 features without the need to have OS support on the client side.

    no_scan_response_II.pcapngno_scan_response_II.log

  • 0 in reply to Jørgen Holmefjord

    Hi Jørgen,

    where you able to reproduce my measurements with the ble_app_uart example?

    best regards,

    Torsten

  • 0 in reply to Torsten Robitzki

    Hi,

    I have reproduced the behavior here. I have not fully verified it yet, but I currently think the amount of delay between the BLE_GAP_EVT_ADV_REPORT events until scanning is resumed again with sd_ble_gap_scan_start() might be to root cause of this issue.

  • 0 in reply to Sigurd

    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?

Reply
  • 0 in reply to Sigurd

    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?

Children
Related