This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

What are the limitations when using the S132 central with 20 peripherals connected?

Are there any limitations when the central is connected to 20 peripherals at the same time?  Is there a minimum connection interval (ie, can I set them all to 7.5ms?).

Parents
  • Hi,

    Shortest possible connection interval for n connections mainly depends on the event lengths of those connections, which is configurable in 1.25 ms units. For s132 v5 the minimum event length setting is 2.5 ms (2 units) and the default setting is 3.75 ms (3 units). (See sd_ble_cfg_set(), and the setting structure ble_cfg_t --> ble_conn_cfg_t --> ble_gap_conn_cfg_t for setting the event length.)

    How connections are scheduled is described at length in the Scheduling chapter of the SoftDevice specification. Sections "Suggested intervals and windows" and "Connection timing as a Central" should be of particular interest.

    In short, for the minimum event length of 2.5 ms the theoretical minimum connection interval is 20 * 2.5 ms = 50 ms. (Provided that there has been large enough timing windows for setting up the connections prior to that.)

    Regards
    Terje

  • Thanks, this was very helpful.

    I read through the documentation and still have some questions.  I changed the event length on the central to 2 (2.5ms).  I also see that there is a setting for min/max connection intervals in the central side.  In the multi-link example, they are set to 9.375 and 37.5ms.  That project uses a max of 8 connections.  Since my project has a max of 20, should I set these both to 50ms on the central side?  Same on the peripheral side?

    Also, let's say the system connects to only 19 peripherals and continues to scan for the 20th.  Does that scanning process interfere with the timing of the already established connections to the other 19 peripherals?  It it does, would increasing the connection interval help with this?  I would assume it would based on the documentation, but not sure how to set this up.

  • I now see the section on the Scanner timing as well in the documentation.  It's still a bit unclear to me how this would work.  I see that the scan window occurs after all the connections.  So if my interval is 50ms, that would only leave 2.5ms at the end for scanning when 19 peripherals are connected.  I think it makes sense to increase the interval.  Is this correct?

  • It depends a little on your peripherals, as the connection interval chosen on the central side should be a connection interval that the peripheral will "accept". (I write "accept" in quotes because the only way for the peripheral to not accept is to disconnect, which is what peripherals do if they are given an incompatible connection interval.) If you are in control of the peripheral firmware then you may of course choose connection interval freely.

    All SoftDevice timing events, such as a connection event, a connection establishment, a scan event, etc. are scheduled by the SoftDevice scheduler. A timing event is either scheduled in its entirety or not scheduled at all. When several events are overlapping, there is a priority ordering deciding which event "wins". See SoftDevice timing-activities and priorities for details.

  • So these are my settings.  Does this make sense?

    On Central:


    NRF_SDH_BLE_CENTRAL_LINK_COUNT 20
    NRF_SDH_BLE_TOTAL_LINK_COUNT 20

    NRF_SDH_BLE_GAP_EVENT_LENGTH 2 // 2.5ms

    SCAN_INTERVAL 32 // 20ms
    SCAN_WINDOW 32 // 20ms

    MIN_CONNECTION_INTERVAL 56 // 70ms
    MAX_CONNECTION_INTERVAL 56 // 70ms

    On Peripheral:

    APP_ADV_INTERVAL 64 // 40ms

    MIN_CONNECTION_INTERVAL 56 // 70ms
    MAX_CONNECTION_INTERVAL 56 // 70ms

    So for each 70ms interval, I have 20 * 2.5ms = 50ms for the connections and 20ms for the scan window.

Reply
  • So these are my settings.  Does this make sense?

    On Central:


    NRF_SDH_BLE_CENTRAL_LINK_COUNT 20
    NRF_SDH_BLE_TOTAL_LINK_COUNT 20

    NRF_SDH_BLE_GAP_EVENT_LENGTH 2 // 2.5ms

    SCAN_INTERVAL 32 // 20ms
    SCAN_WINDOW 32 // 20ms

    MIN_CONNECTION_INTERVAL 56 // 70ms
    MAX_CONNECTION_INTERVAL 56 // 70ms

    On Peripheral:

    APP_ADV_INTERVAL 64 // 40ms

    MIN_CONNECTION_INTERVAL 56 // 70ms
    MAX_CONNECTION_INTERVAL 56 // 70ms

    So for each 70ms interval, I have 20 * 2.5ms = 50ms for the connections and 20ms for the scan window.

Children
  • I would reduce the scan interval (and window), and/or give more headroom for scanning. The way this is scheduled is that after the first scan event the full "series" of consecutive scan events will follow regularly, back to back, fixed in the frequency given by the scan interval. Any of them colliding with active connections gets discarded. By using shorter intervals+windows more of that "free time" left after all the connection events will be utilized.

    In the end you should do some testing on a full 20 peripheral setup, in order to verify that it works as intended. Most likely you will have to do some tweaking of the settings based on the real world testing.

  • I may have found a bug in the stack.  When I increase NRF_SDH_BLE_CENTRAL_LINK_COUNT above 15, I start getting errors.  The error I am seeing is:


    implicit declaration of function 'MACRO_REPEAT_FOR_16'

    I found that the macro list stops at 15.  Is this a bug or am I doing something wrong?

  • Even after fixing all the macros, I now get an error NRF_ERROR_INTERNAL when calling nrf_sdh_ble_enable.  Has Nordic verified that 20 central connections works with the latest stack?  It's pretty easy to test by just adjusting the sdk_config in the ble central multilink example.

  • I take that back, looks like the error is actually NRF_ERROR_NO_MEM.  I still question if 20 centrals have been tested.

  • I increased the memory for the softdevice and added all the macros to get the system to build with 20 peripherals connected to a central.  It sometimes works, but usually what happens is the system connects to the 20 peripherals, but constantly tries a connection request to the same mac instead of cycling between all of them.  If I back the system down to 8 peripherals, everything seems ok.  Has anyone tried using more than 8 peripherals connected to a central?

Related