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 really need to explore all the info you gave me on whitelisting more thoroughly, but at the moment I'm shifting to panic mode as I am to fly to NJ tomorrow morning with my equipment and able to set up the demo for my client. We are still having a problem with peripherals disappearing from multi-NUS, and struggling to find any commonality to the disappearances. At this time the evidence is starting to suggest that the problem is not the Peripheral being grabbed by a different Central, so whitelisting isn't going to help that. But I've been poking around and trying to better understand the BLE stack, and came up with a number of questions:

1) You indicated that S112 should be able to handle 4 simultaneous connections. Looking at these two lines from sdk_config.h

#define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 1

#define NRF_SDH_BLE_TOTAL_LINK_COUNT 1

I presumed I could changed those numbers to 2 to allow two simultaneous connections. That leads to another of those mysterious breakpoints with no information as to what happened. Based on past experience, I tried increasing the RAM available to the softdevice by 512 bytes. No joy; those two parameters must be set to 1. How are those to be used?

2) In main.c, cp_init.disconnect_on_fail is set to false in the provided example. At some time in the past, I experimentally changed it to true and left it that way. Could that be a cause of failures to connect or reconnect?

3) Near the top of main.c are several parameters defined that I don't understand, that may or may not be relevant to my immediate problem.

MIN_CONN_INTERVAL

MAX_CONN_INTERVAL

SLAVE_LATENCY

CONN_SUP_TIMEOUT

I can't find any concise explanation of these and how they may or may not be relevant to my immediate problem.

4) My application has a basic "heartbeat" at 5 seconds, at which interval it checks for incoming commands from the multi-NUS, and sends out a status report of a couple dozen ASCII characters. Could this interval interact in bad ways with anything in the BLE stack?

5) Any other suggestions for more reliable connections / reconnections?

Help! I'm going to see my client in the morning.

Steve Hendrix

[Einar Thorsrud]

Hi Steve,

SteveHx said:

We are still having a problem with peripherals disappearing from multi-NUS, and struggling to find any commonality to the disappearances. At this time the evidence is starting to suggest that the problem is not the Peripheral being grabbed by a different Central

I see. What data do you have of what is actually happening? Do you have logging on the peripheral side? If you for instance log whenever a connection is established including the address of the peer and when connections are closed, that should be quite useful. Perhaps something completely different is happening, and if so adding a bit of logging here and there might show some unexpected things.

SteveHx said:

I presumed I could changed those numbers to 2 to allow two simultaneous connections. That leads to another of those mysterious breakpoints with no information as to what happened. Based on past experience, I tried increasing the RAM available to the softdevice by 512 bytes. No joy; those two parameters must be set to 1. How are those to be used?

You need to increase the RAM reserved for the SoftDevice (so use a higher application RAM start address and lower size). But there is nothing in the description of your application that indicate that you need to support more concurrent connections on the peripherals? Also, for this to be useful (if it was relevant), you would have to adjust your application to actually handle multiple connections.

SteveHx said:

2) In main.c, cp_init.disconnect_on_fail is set to false in the provided example. At some time in the past, I experimentally changed it to true and left it that way. Could that be a cause of failures to connect or reconnect?

That could be. I suggest you add logging to see what the disconnect reason is. If the connection parameter module disconnects because of this you should get the BLE_HCI_CONN_INTERVAL_UNACCEPTABLE (0x3B) disconnect reason.

SteveHx said:

3) Near the top of main.c are several parameters defined that I don't understand, that may or may not be relevant to my immediate problem.

MIN_CONN_INTERVAL

MAX_CONN_INTERVAL

SLAVE_LATENCY

CONN_SUP_TIMEOUT

I can't find any concise explanation of these and how they may or may not be relevant to my immediate problem.

These are the connection parameters, which are the most essential parameters of a Bluetooth connection. See this old post. As you control both the central and peripheral side here, you should simply configure the same connection parameters on both sides and this will just work. What connection parameters you should use are application specific (which latency, throughput, timeout fits your specific application?). As you have multiple connections on the central side you should not be too aggressive here, as the central needs to be able to schedule and fit all it's connections.

SteveHx said:

5) Any other suggestions for more reliable connections / reconnections?

I understand you are short on time, but I would say that you need to first debug and analyze to understand what actually happens. Once that is clear, fixing the problem should be much easier.