Common disconnects using ble_app_interactive

RE: Common disconnects using ble_app_interactive

Sigurd — Wed, 12 Sep 2018 09:09:34 GMT

[quote userid="72698" url="~/f/nordic-q-a/38330/common-disconnects-using-ble_app_interactive/148265"]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[/quote]

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

[quote userid="72698" url="~/f/nordic-q-a/38330/common-disconnects-using-ble_app_interactive/148265"]Perhaps the version difference could be an issue?[/quote]

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

[quote userid="72698" url="~/f/nordic-q-a/38330/common-disconnects-using-ble_app_interactive/148265"]CENTRAL: Disconnected, handle: 0, reason: 0x8[/quote]

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

RE: Common disconnects using ble_app_interactive

Lincoln — Tue, 11 Sep 2018 15:35:33 GMT

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?

RE: Common disconnects using ble_app_interactive

Sigurd — Tue, 11 Sep 2018 08:48:45 GMT

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

RE: Common disconnects using ble_app_interactive

Lincoln — Mon, 10 Sep 2018 20:29:56 GMT

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.

RE: Common disconnects using ble_app_interactive

Lincoln — Mon, 10 Sep 2018 19:07:13 GMT

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...

RE: Common disconnects using ble_app_interactive

Sigurd — Mon, 10 Sep 2018 14:43:12 GMT

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.

[quote user="Lincoln"]do both soft devices have to be configured to the least accurate module for the NRF_SDH_CLOCK_LF_ACCURACY?[/quote]

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.)

RE: Common disconnects using ble_app_interactive

Lincoln — Sat, 08 Sep 2018 20:48:07 GMT

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?