Softdevice / Whitelist Issues

[SteveHx]

We are attempting to deploy a system consisting of one nRF52840 devkit running the multi-NUS example app, and over a dozen custom boards based on the nRF52832. It all works fine at my facility, which is very much RF-quiet. When attempting to bring up the system at the customer site, we appear to be getting the custom units captured by other BLE central devices. Attempting to track those down, but only partially successful. The custom board is using the 112 softdevice. What is the difference between 112 and 132? I have a vague recollection that with 132 we could be connected by multiple devices whereas 112 was restricted to a single connection at a time. If that is the case, I want to try to change to the 132 device. Surely there is a straightforward way within SES to do that?

I am also looking for a way to have our device only allow connections from our central device. I remember seeing something like that, though I really don't want to go the full Bonding route (but may have to).

Suggestions very welcome! The customer is in a bit of a panic because we're setting up for a big demonstration to customer's customer this Friday.

Steve Hendrix

[SteveHx]

I am now at the client site (long day so far). Still having problems maintaining reliable connections between multi-NUS on the 52840 DK board, and about 15-20 user application devices running 52832 with a custom application derived from the UART sample app. I have discovered that the 52840 multi-NUS randomly throws an error and reboots:

ASSERTION FAIL [conn] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/gatt.c:4437

                       invalid parameters

The multi-NUS then reboots, but of course takes time to reestablish all the connections.

We also need a way, either by modifying the source code, or thru the USB link, to cause multi-NUS to periodically rescan for units that may have been missed.

Any suggestions?

Steve Hendrix

[Einar Thorsrud]

Hi Steve,

I see now that you have references to Zephyr (so nRF Connect SDK), but earlier in this thread you have made references to SoftDevice and nRF5 SDK Code. Do you use the nRF5 SDK for the peripherals and the nRF Connect SDK for the central? That in itself is no problem, I just want to get a better understanding. With "Multi NUS", are you referring to this project from this blog post? Is this your central?

SteveHx said:

I have discovered that the 52840 multi-NUS randomly throws an error and reboots:

ASSERTION FAIL [conn] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/gatt.c:4437

                       invalid parameters

Which nRF Connect SDK version are you using? based on the assert line number I am guessing 1.6.x, so I will assume that for now.

The assert in zephyr/subsys/bluetooth/host/gatt.c:4437 is checking that the first parameter (struct bt_conn *conn) is not NULL, so as you get this assert it means you passed NULL / 0 to the call to bt_gatt_subscribe() for some reason. You need to review and/or debug your application to se how this can happen.

There is clearly a bug you see here, but there could also be other issues. As you use as may as 15-20 peripheral connected to a single central, that means it must handle and find time to a lot of concurrent connections (in addition to scanning). Which connection parameters do you use? That is essential here with so many devices. You typically need long connection intervals and short event lengths to get this working. You probably also want a long supervision timeout.

SteveHx said:

We also need a way, either by modifying the source code, or thru the USB link, to cause multi-NUS to periodically rescan for units that may have been missed.

Looking at the multi NUS code from the blog, I see that it generally always scans except for during service discovery, so you should not need to explicitly start it. If you want to, you can add code for that, but there is no code in the example I am looking at that lets you control this from USB or UART, so you must add that (and decide how you want it to work).

Einar