• State Not Answered
  • Replies 7 replies
  • Subscribers 76 subscribers
  • Views 3890 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 213599
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents Reply Children
  • 0 in reply to Lincoln

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

  • 0 in reply to Sigurd

    Thank you !  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...

  • 0 in reply to Sigurd

    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.

  • 0 in reply to Lincoln

    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
  • 0 in reply to Sigurd

    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?

Related
Terms of service