Common disconnects using ble_app_interactive

[Lincoln]

Hello,

I am attempting to test slew of Rigado BMD-350 module BLE radios (uses nRF52832) using a Rigado BMD-301 series Eval Kit to act as the central.  The BMD-350 device is running the stock firmware from Rigado, BMDware v3.2.1.

Currently, I'm simply running the "ble_app_interactive" example application (pca10040) from the current nRF5 SDK 15.1.0 (a8c0c4d) and loading it on the Evaluation Kit to connect and query the peripheral GATT server.  I did modify this a bit to disable terminal colors, shorten the prompt, and output RSSI on advertisement packet events.

The SDK application works most of the time when I "connect <mac>", but I somewhat frequently get a "CENTRAL: Disconnect ... reason: 0x8" shortly after the connection.  The sequence looks like this:

---

> connect 94:54:93:2F:CA:9B
<info> app: CENTRAL: Connecting...
<info> app: CENTRAL: RSSI from Peripheral: -29 dBm
Connected to address: 94 54 93 2F CA 9B
<info> app: CENTRAL: Connected, handle: 0.
Current MTU: 247
MTU changed successfully
<info> app: Data length updated to 54 bytes.
> connected_devices
Connected devices:
0. 94:54:93:2F:CA:9B Security level: 1
Connection parameters update success
<info> app: Data length updated to 54 bytes.
>
<info> app: CENTRAL: Disconnected, handle: 0, reason: 0x8

---

Does anyone know how I might debug what's going on here?  I'm new to these soft devices and BLE in general, so I thought using a S132 SDK example application would be an easy way to design my test module, but it's not being reliable enough and I'm getting way more failures than I expect due to random disconnects.  It is possible it's the stock BMDware as well.

If anyone knows of any way I could work around this issue, or avoid it by adjusting some parameters, it would be greatly appreciated.  I'm still looking at all of the things the soft device in this particular application is doing...

[Lincoln]

I've been looking into this and I found this link regarding the NRF_SDH_CLOCK_LF_ACCURACY parameter: https://devzone.nordicsemi.com/f/nordic-q-a/29786/ble_hci_connection_timeout-and-nrf_clock_lf_xtal_accuracy_xx_ppm

Sure enough, if I update this parameter from +/- 20 ppm to +/- 250 ppm, I stop seeing the Disconnected events.

If the LF external crystal on the test module (BMD-350, which according to datasheet FreqTOL_LFXO_BLEmax = +/- 250 ppm), do both soft devices have to be configured to the least accurate module for the NRF_SDH_CLOCK_LF_ACCURACY?

[Sigurd]

Hi,

Disconnect reason 8 is the same as BLE_HCI_CONNECTION_TIMEOUT, and this can happen when the clock source is not configured correctly. If you do not have a LF crystal, you will need to use the LF RC oscillator and set the ppm and calibration interval accordingly.   

Lincoln said:

do both soft devices have to be configured to the least accurate module for the NRF_SDH_CLOCK_LF_ACCURACY?

No. When you configure the SoftDevice, you always set it according to the clock source and clock accuracy you have on your own device, you do not care about the accuracy of the device you are connecting to. The SoftDevice / BLE protocol handles this. (When the devices connect to each other, they exchange their clock accuracy, and this is taken into account when they calculate when to turn on the radio to send/receive data.)

[Lincoln]

Thank you Sigurd!  I'm using a Rigado BMD-300-EVAL board which, with respect to the crystals, match the Nordic DK design. (PCA10040, I assume they're talking about.  That's the SDK build I'm using anyways).  It has a +/- 20ppm LFXO, ABS07-32.768KHZ-7-T, with a 7pF Cl.  See here:

https://rigado.zendesk.com/hc/en-us/articles/223408667-How-does-the-Rigado-BMD-300-Series-Evaluation-Kit-differ-from-the-Nordic-nRF52-DK-

At this point, I think it means the device I'm testing maybe has an non-optimal setting?  It is a stock BMD-350, running BMDware 3.2.1.  I'll go poke Rigado a little more...

[Lincoln]

Ah actually, according to the BMDware source, it appears the internal RC oscillator is used by default.  See here

Considering this, do my periodic disconnects still not make sense?  I'm not attempting to run this in any difficult environment (high/low temperatures), so I can't imagine that both of these configurations wouldn't be good enough.

[Sigurd]

What SoftDevice version are you running on the peripheral and central?

Are both peripheral and central using the RC oscillator?

Note that starting from s132_nrf52_5.0.0-2.alpha, the application need to set the accuracy/ppm of the RC oscillator itself. From the s132_nrf52_5.0.0-2.alpha release notes:

The RC oscillator accuracy can now be set to any of the defined NRF_CLOCK_LF_ACCURACY values, and there is no default anymore. In other words, the nrf_clock_lf_cfg_t::accuracy parameter now has the same functionality when used with the RCOSC clock source as with the XTAL clock source

[Lincoln]

The soft device on the BMD-301-EVAL running as peripheral is the latest S132 v6.1.0.  In this I am running of the LFXO, NOT the RC oscillator.  This is equivalent PCA10040 (the 832-DK)

I did have to go look it up (i'm not modifying the stock Rigado code yet), but the peripheral device is apparently running S132 v3.1.0:

Perhaps the version difference could be an issue?

[Sigurd]

Lincoln said:

I did have to go look it up (i'm not modifying the stock Rigado code yet), but the peripheral device is apparently running S132 v3.1.0

Looking here, it could be S132 v3.0.0? Could you check the FWID of the SoftDevice to confirm this?

If you use nrfjprog to read 0x0000300C, it will give you the FWID:

nrfjprog --memrd 0x0000300C

If you get FFFF008C, it's S132 v.3.0.0, if you get FFFF0091 it's S132 v3.1.0

Lincoln said:

Perhaps the version difference could be an issue?

Since increasing the LFXO ppm for the BLE central resolves this issue, a hardware issue is more likely. 

Lincoln said:

CENTRAL: Disconnected, handle: 0, reason: 0x8

Do you get the same disconnect reason at the BLE peripheral ?