Disconnect for reason 8 after a couple of seconds if scanning while connected

[Krastanov]

Below are the symptoms, but it turns out the problem was quite simple: the device is not seem capable of scanning while at the same time being connected, unless you use a long timeout (no Empty PDU packets are sent while scanning).

5 to 10 seconds after connection (independently of whether any notifications are turned on) my peripheral device reports a disconnect for reason 8 (BLE_HCI_CONNECTION_TIMEOUT). This happens with test with three different central devices (Raspberry Pi W, a BLE dongle under linux, and an Android 7 device). All the centrals were verified to have connection intervals within the accepted interval for the peripheral (verified at the BLE_GAP_EVT_CONNECTED and BLE_GAP_EVT_CONN_PARAM_UPDATE).

I have the following configuration for my peripheral device (nrf52832, sdk 15.0.0, the Laird BL652 module):

#define MIN_CONN_INTERVAL               6   // in units of 1.25us
#define MAX_CONN_INTERVAL               100
#define SLAVE_LATENCY                   0  // changing this does not change the behavior described below
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)
#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(2000)
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(2000)
#define MAX_CONN_PARAMS_UPDATE_COUNT    0  // changing this did not matter - the central device always uses conn interval around 18 to 32, so no updates were called

I am using the synthesized clock (not a low frequency crystal and not the internal RC oscillator), which presumably is high precision, right? For the moment I do not have power constraints.

The power management logger, reports persistent CPU usage of 7%.

In the sniffer log under wireshark one can see that after connection the master and slave are exchanging "Empty PDU" packets for a few seconds up until packet 529 when only the master continues sending such packets. After half a second the master stops sending these unacknowledged packets as well. A few more seconds later I see that the slave resumes advertising, given that the connection has been lost. The log is attached (device d8:9a:ab:e5:5c:b5 is the slave of interest).

Any idea what would be causing the slave to stop responding? It does not seem like it is clock drift (the synth clock is precise) or an unacknowledged parameter update (no parameter updates happen because the initial connection parameters are fine).

Edit: the slave was not responding because separately the slave was also performing scans for packets from beacons. It was rather naive of me not to mention that first.

capture.pcapng

[Krastanov]

A particularly weird thing happens if I use the Nordic nRF Connect app, which might give a clue to what is happening:

The nRF Connect app connects successfully to the peripheral, just like the other apps or gatttools under linux or RaspberryPi. However, it does not disconnect after a couple of seconds unlike the other tools. Instead, if notifications are on, the notifications run (receiving a couple per second) until around the time when the other tools would have disconnected. At that point, instead of disconnecting, the nRF Connect just stops receiving notifications for a couple of seconds (without disconnecting). During that time I can see the peripheral reporting NRF_ERROR_RESOURCES (the peripheral retries when it gets that error and it has not been getting that error when using other connection tools on the master side). After a couple of seconds the peripheral stops reporting that error and the central (only under nRF Connect) continues getting new notifications as if nothing has happened.

By the way, all of this is done in an environment with very few on-air devices. There should be near zero interference from other BLE or WiFi devices.

[Krastanov]

The only reason nRF Connect does not disconnect is because it has **much** longer  supervision timeout. When I lengthen the timeout of the other tools, they also perform the same way. So the question is, why does the peripheral just hang for a couple of seconds and then restarts working as if nothing happened!? What could cause the hangs?

[Hung Bui]

Hi Krastanov, 

 

If you have a look at the S132 release note you will find this: 

Synthesized low frequency clock source is not tested or intended for use with the BLE stack.

 

Please try to test again with the RC clock instead. 

 

From the trace I can see a lot of missing packet and retransmission. Have you tuned your antenna ? Do you see the same problem if you test with our nRF52 DK ? 

 

[Krastanov]

Hello, Hung,

Thanks for the heads up about the SYNTH clock. I regrettably did not remember this while debugging, but I will keep it in mind in the future. The problem ended being annoyingly unrelated: the slave was not responding because the slave was also performing scans for packets from beacons.

It seem the softradio is incapable of sending acknowledgment Empty PDU packets while scanning (i.e. scanning for beacons while being connected to a master). I that right?

[Hung Bui]

Hi, 

You mean the connection was terminated because it was scanning ? I don't think it should be the case. Our scheduler should prioritize the connection if the connection is going to a timeout.

Could you change the clock to RC and test again ? Please send us a sniffer trace will multiple connection&disconnection so we can have enough data for our analysis.