No scan response using latest version of pc-ble-driver v6.1.1 on nrf52832

RE: No scan response using latest version of pc-ble-driver v6.1.1 on nrf52832

Edvin — Mon, 01 Feb 2021 13:08:16 GMT

Hello,

I am sorry, but I am not sure exactly how to fix this. It is not trivial to manipulate the connectivity firmware, and as I mentioned, it is not certain that this would work at all. Perhaps it messes up the internal state machine and message flow.

[quote user="fbttv"]We were good to go with pc-ble-driver v5, were we don't have to restart the scan after each event - but we are now running in to the fact that does not appear to cooperate with the DFU examples given in that version of the SDK. [/quote]

Perhaps it would be either to either fix this, or put the important data in the advertising packet instead of the scan response?

Why is the DFU not working? What observations do you see?

BR,
Edvin.

RE: No scan response using latest version of pc-ble-driver v6.1.1 on nrf52832

ttveldhuis — Fri, 29 Jan 2021 12:28:01 GMT

Sorry for the delayed reply, it took a while to get to this. Unfortunately without good results.

Depending on where I try to start the scan (tried with different calls) the result was either the scan not being resumed at all or the pc-ble-driver outputting the error:

Failed to decode event, error code is 14/0xe

Eventually I even tried to just add the application as an observer and start the scan from that callback by adding:

static uint8_t m_scan_buffer_data[31];
static ble_data_t m_scan_buffer = { m_scan_buffer_data, 31 };

void test_ble_event_handle(ble_evt_t const * p_ble_evt, void * p_context)
{
    sd_ble_gap_scan_start(nullptr, &m_scan_buffer);
}

int main(void)
{
    ....
    NRF_SDH_BLE_OBSERVER(m_ble_observer, 0, test_ble_event_handle, NULL);
    
    ....
}

But unfortunately that yielded the same "Failed to decode event" error.

Any (other) tips or suggestions?

Sidenote;

We were good to go with pc-ble-driver v5, were we don't have to restart the scan after each event - but we are now running in to the fact that does not appear to cooperate with the DFU examples given in that version of the SDK.

RE: No scan response using latest version of pc-ble-driver v6.1.1 on nrf52832

Edvin — Fri, 08 Jan 2021 12:41:20 GMT

Hello Thys,

To be fair, I don't know whether this will work or not at all. Officially, this is not supported, so I am not sure what scan buffer you can use. I am trying to see how the scan buffer is set up when the scanning is normally started.

It is usually started using conn_mw_ble_gap_scan_start() in conn_mw_ble_gap.c, so perhaps it would be possible to call that from the advertising report.

I believe that this is usually triggered from conn_mw_handler() in conn_mw.c -> conn_mw_handler_get(), which again is called from ser_conn_command_process() in ser_conn_cmd_decoder.c.

How about trying to call ser_conn_command_process(SD_BLE_GAP_SCAN_START, packet_len); from the adv report?

I can't tell what the packet_len is used for, other than being the length of the serial command itself. Try setting it to a random number and see what happens. It looks like the len needs to be > 0, so try with 1.

BR,

Edvin

RE: No scan response using latest version of pc-ble-driver v6.1.1 on nrf52832

ttveldhuis — Fri, 08 Jan 2021 11:12:09 GMT

Hi Edvin,

We'll give that a try.

The sd_ble_gap_scan_start call requires a buffer for the second argument, is there any easy place we can access the current scan buffer from for when calling it from the ser_conn_ble_event_encoder?

Kind regards,

Thys

RE: No scan response using latest version of pc-ble-driver v6.1.1 on nrf52832

Edvin — Wed, 06 Jan 2021 15:27:02 GMT

Hello Thys,

I have not tested this, but the events occur in ser_conn_ble_event_handle() in ser_conn_handlers.c.

The advertising reports will trigger the following chain:

ser_conn_ble_event_handle() -> app_sched_event_put() -> which will trigger:

ser_conn_ble_event_encoder() -> ble_event_enc() -> case BLE_GAP_EVT_ADV_REPORT: -> ble_gap_evt_adv_report_enc()

So the first thing I would check is whether adding the scan start call before ble_gap_evt_adv_report_enc() would be sufficient. You can check the return value of this softdevice call and see whether it ever returns anything other than NRF_SUCCESS;

Does it work without connecting to anything? Does any errors occur when you try to connect to anything? You can expect the scan_start() call in your application to return != NRF_SUCCESS, so try to ignore that for the time being. You can take note of what it returns.

I have not set up pc-ble-driver on my computer, so if you can give this a go, that would be great. If you are stuck somewhere, I can try to install it.

Best regards,

Edvin

RE: No scan response using latest version of pc-ble-driver v6.1.1 on nrf52832

ttveldhuis — Wed, 06 Jan 2021 13:37:58 GMT

Hi,

Thanks for the reply, the delay in the communication then is what I expected.

We are using the connectivity application that is compiled by the compile_connectivity target in the pc-ble-driver repository. Which from what I understand is the application from examples\connectivity\ble_connectivity.

There is no objection to modifying the connectivity application, I have tried to play around with it but couldn't find the proper things to change and where to add/change them.

We do also connect to devices (currently only one at a time), so we have to take that in to account.

If you could guide us to what to add/change and where that would be great.

Kind regards,

Thys

RE: No scan response using latest version of pc-ble-driver v6.1.1 on nrf52832

Edvin — Wed, 06 Jan 2021 13:25:54 GMT

Hello,

I had to ask around, as I see there have been some discussions on this topic, both here on DevZone, and internally.

What I see is that due to an API change in SD API v6 you need to restart the scanning after every advertising report. In serialization, this means that the advertising report needs to be sent (over serial), and then the application core/computer needs to decide whether or not to resume scanning, send the command back over serial, before it can be resumed. Since this takes time, the scan response has already been sent, and will not be picked up by the softdevice.

From the internal ticket:

"The scanning APIs were changed in SD API v6 so that the scanning needs to be restarted for every received advertising packet. Since ble-driver uses serialization, the event needs to travel from the connectivity firmware, over USB-UART, and up to the application on the pc-side. Then the application needs to send a command back to the connectivity to continue the scanning. This roundtrip time makes it a lot slower to receive advertising packets. "

I don't know where you found your serialization application (the one running on the nRF device that is plugged in the computer), but if you have compiled it yourself, you can look into restarting the scan directly in the nRF application in the BLE_GAP_EVT_ADV_REPORT event, so that this decision doesn't have to take the round trip.

Do you ever connect to anything? If so, you may need to take this into concideration. If you only support one connection, and start scanning, the softdevice will return an error to the start_scan call.

Let me know what you think about this, and whether you can try to change the connectivity firmware, found in SDK\examples\connectivity\ble_connectivity.

Best regards,

Edvin