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

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
  • Now I added some LED toggles into the connectivity firmware. In `ble_gap_evt_adv_report_t_enc()` I toggled different LEDs. One LED is toggled for every call to the function, one LED for every event with the MAC address of my device. And finaly, one LED for every scan response. The toggle schema of the LED is comparable to what I receive on the PC side. So nearly no scan responses are reportet to `ble_gap_evt_adv_report_t_enc()`.

    On the calling side of `ble_gap_evt_adv_report_t_enc()`, I made sure, that in `ser_conn_ble_event_encoder()` allocating memory is not causing a problem. `ser_hal_transport_tx_pkt_alloc()` never fails.

    So I traveled up the call stack and found that in `ser_conn_ble_event_handle()` events are scheduled onto an application queue (`app_sched_event_put()`). So I moved my LED blinking test code infront of the scheduling. Same pattern here, so no events get lost, due to this scheduling.

    Further up the call stack, there is just `nrf_sdh_ble_evts_poll()` which calls `sd_ble_evt_get()` and just calls `ser_conn_ble_event_handle()` indirectly. Moveing the LED blinking test code there, reveals the same results.

    So it seems, the Softdevice is sending scan requests, the device is responding with scan responses, but the SD is not reporting the responses. Why is that?

Reply
  • Now I added some LED toggles into the connectivity firmware. In `ble_gap_evt_adv_report_t_enc()` I toggled different LEDs. One LED is toggled for every call to the function, one LED for every event with the MAC address of my device. And finaly, one LED for every scan response. The toggle schema of the LED is comparable to what I receive on the PC side. So nearly no scan responses are reportet to `ble_gap_evt_adv_report_t_enc()`.

    On the calling side of `ble_gap_evt_adv_report_t_enc()`, I made sure, that in `ser_conn_ble_event_encoder()` allocating memory is not causing a problem. `ser_hal_transport_tx_pkt_alloc()` never fails.

    So I traveled up the call stack and found that in `ser_conn_ble_event_handle()` events are scheduled onto an application queue (`app_sched_event_put()`). So I moved my LED blinking test code infront of the scheduling. Same pattern here, so no events get lost, due to this scheduling.

    Further up the call stack, there is just `nrf_sdh_ble_evts_poll()` which calls `sd_ble_evt_get()` and just calls `ser_conn_ble_event_handle()` indirectly. Moveing the LED blinking test code there, reveals the same results.

    So it seems, the Softdevice is sending scan requests, the device is responding with scan responses, but the SD is not reporting the responses. Why is that?

Children
No Data
Related