SoftDeviceAPI v5 problems

[raffaeler]

I am using nRFConnect with nRF52840 Dongle. Since the last update to SoftDeviceAPI v5, nRFConnect cannot connect anymore to this specific devices (cheap JDY-10 BT/Serial adapters). Here there are more details and logs:
github.com/.../161

Sometimes the device cannot be even discovered, then I remove the USB dongle re-insert it and the scan finally find it, but still cannot connected.
As I wrote on GitHub, the device can be always found and connected if I use the Android App BLE Scanner.

I am not sure how can I help in diagnosing the issue.

[tesc]

Hi,

I am afraid this is a bit difficult to diagnose further if all you have is a single nRF52840 Dongle.

The best option is if in addition to the nRF52840 Dongle you have any of the nRF DKs or Dongle that are supported by the nRF Sniffer. Then you can trace what is going on over BLE, which in most cases gives a good indication of what might be the issue. Any other BLE sniffer would do the same job. As you are working on a community project I guess you do not have access to a dedicated BLE sniffer, and in that case the nRF Sniffer is a good low-cost alternative.

If you have a J-Link programmer it may be possible to debug the connectivity firmware running on the nRF52840 Dongle. This may require you to build the connectivity firmware yourself, but allows for log output, error code/line number on asserts, etc. All of our DKs comes with a J-Link programmer on-board, that can be used for development purposes, both for programming/debugging the on-board nRF SoC and for programming/debugging nRF SoCs on other boards (such as the nRF52840 Dongle, provided that you have the proper cable for connecting the two.)

Alternatively, if you can get a trace of the UART communication between the Dongle and the PC, then we might be able to get something useful out of that as well.

Regards,
Terje

[raffaeler]

Please let me know if I can be of further help.

[tesc]

Hi,

I am very sorry for the delay.

You are correct the traces doesn't reveal much.

However I see that the Samsung device (your smartphone I assume) sends scan requests to the device (SCAN_REQ), whereas the same does not seem to happen in the other traces, except maybe once. That might be a clue. What is the device address of the nRF device acting as connectivity device?

I also only see advertisements in the traces, and not connection setup.

• Have you filtered the traces so that only advertisements (and scan requests) are included?
• Have you previously bonded with the smartphone so that existing keys are used, and so the sniffer cannot MITM the connection?

Regards,
Terje

[raffaeler]

The Samsung device is a TV from the neighbothood I don't have access to. I have no idea why it scans continuously but that's it.
In the first trace (maybe in another one, but I can't remember now) I can see the mac address of my device. It is the one I wrote in my previous post.
I didn't filter at all, but I am not sure the Adafruit nRF51822 (v2, the black PCB) has the very latest firmware. I could not find a clear explanation on (and if it can) upgrading it.
Try to take a look at the trace including that mac address and see if, in your experience, there is some packet with strange content.

As I already told you, this is happening because of the SoftDevice API v5. Before that upgrade it always worked well.

[tesc]

Hi,

Again sorry for the delays, we are entering summer vacation season in Norway.

I am afraid I did not find anything wrong in the traces, apart from the fact that there is no packets indicating any attempt to set up a BLE connection (in any of them.)

If this worked well in an earlier version of pc-ble-driver, could you possibly get a trace from that as well, as that would make it easier to spot any changes?

Regards,
Terje