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

Configuration for central and multi peripheral devices with DLE and Event Connection Extension Enabled

Hi,

The final design we are working on is composed of 8 peripherals notifying (every 80ms or 160ms) to 1 central.

Packet data size is 141 bytes and depending on rate configured by application these packets are output at 80 or 160 ms.

Often, we compare information from sniffer nRF v2.01 wireshark file and from output of Central device, and some packets are lost from several peripherals.

We supposed, the configuration values are not properly tuned to these requirements, mainly connection interval and event length for both rates.

Below are listed current configuration we have applied to devices.

All devices are NRF52832 with S132 v5.0 SDK14.2 (based on mBed v5.12.4).


Central Connection parameters for final design
===================================
Data Packet Length Extension enabled
Connection Event Extension enabled

PHY 2M
ATT MTU = 144 bytes
NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 0
NRF_SDH_BLE_CENTRAL_LINK_COUNT       8    // n
NRF_SDH_BLE_GAP_EVENT_LENGTH          6    // 7.5ms
scan interval = 140 ms 
scan window = 90 ms
scan timeout = 3000 ms

After connection, update conn parameters to:
min Connection Interval = 80 ms or 160 ms  // 10 * n + scan window  or 20 * n + scan window; 
max Connection Interval = 80 ms or 160 ms //  scan window = 0, no scan after all devices connected
slave latency = 0ms
supervision timeout = 6000 ms
Central enable notification at once for all peripherals simultaneously.
Central only receive packets from peripherals, not sending (almost) any data to them

Central LL_LENGTH_REQ (from sniffer, confirmed 2M PHY and MTU size is 148 bytes)
=====================
Max Tx/Rx octets : 148
Max Tx/Rx time : 1296us (at 2M PHY should be 648us, it isn't ?!)

Peripheral Connection parameters (same for all) for final design
================================================
Data Packet Length Extension enabled
Connection Event Extension enabled
ATT MTU = 144 bytes
NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 1
NRF_SDH_BLE_CENTRAL_LINK_COUNT       0
NRF_SDH_BLE_GAP_EVENT_LENGTH          6 // 7.5ms

PPCP (0x2A04)
min Connection Interval = 100 ms
max Connection Interval = 100 ms
slave latency = 0ms
supervision timeout = 6000 ms

For this request, we changed configuration to work with only 2 peripherals and 1 central although the results are very similar to the final design.

For 2 peripherals and 1 central, see files attached.

Configuration has been changed following parameters:

Central Connection parameters
========================
Data Packet Length Extension enabled
Connection Event Extension enabled

PHY 2M
ATT MTU = 42 bytes
NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 0
NRF_SDH_BLE_CENTRAL_LINK_COUNT       2    // n
NRF_SDH_BLE_GAP_EVENT_LENGTH          2    // 2.5ms
scan interval = 140 ms 
scan window = 90 ms
scan timeout = 3000 ms

After connection, update conn parameters to:
min Connection Interval = 10 ms or 20 ms  // 10 * n + scan window  or 20 * n + scan window; 
max Connection Interval = 10 ms or 20 ms //  scan window = 0, no scan after all devices connected
slave latency = 0ms
supervision timeout = 6000 ms
Central enable notification at once for all peripherals simultaneously.
Central only receive packets from peripherals, not sending (almost) any data to them

Central LL_LENGTH_REQ (from sniffer, confirmed 2M PHY and MTU size is 46 bytes)
=====================
Max Tx/Rx octets : 46
Max Tx/Rx time : 480us (at 2M PHY should be 240us, it isn't ?!)

Peripheral Connection parameters (same for both) 
======================================
Data Packet Length Extension enabled
Connection Event Extension enabled
ATT MTU = 46 bytes
NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 1
NRF_SDH_BLE_CENTRAL_LINK_COUNT       0
NRF_SDH_BLE_GAP_EVENT_LENGTH          2 // 2.5ms

Looking at wireshark files, we see sometimes that master send several empty packets and there is a lack of data from peripherals.

Any help with this issue will be very appreciated.

Thank you very much for your time.

capture_88.pcapngcapture_36.pcapngcapture.txt

Parents
  • Hi,

    Regarding scan and connection parameters, note that with the scan window and connection interval you have chosen, the SoftDevice of the central is not able to schedule connections and scanning without collisions between the two. Note also in the top-most scenario that when central has min/max of 80/160, and peripheral has min/max of 100/100, the negotiated connection interval will be 100. For timing and connection/scan parameters, I refer to Connection timing as a Central and Suggested intervals and windows, from the SoftDevice Specification.

    Regarding periods of no packets from the peripheral, I see that for instance in capture_36.pcapng, at No. 8502, which is the last notification before no packets for a while, the packet is malformed (wrong CRC) and for the series of Empty PDU from master the sequence number is the same (repeated packet). It looks to me like the packet from the slave is either not received because of interference / noise, or it pauses RX for a while. Can you tell a bit more about the test setup with regards to where the boards (including sniffer) are placed in relation to each other?

    Note also that the nRF Sniffer can only follow one link. That means you will get packets between the central and one of the peripherals, and so other peripherals and connections between those and the master will not be part of the sniffer trace.

    Regards,
    Terje

  • Hi Terje,

    For easy, consider following scenario as we changed configuration to run with only 2 peripherals to reproduce issue.
    We are considering this design similar to multilink scheduling with two connections as a Central and minimum interval, as described on S132 spec.

    Each Peripheral output (S) 39 bytes packet data at every 2t, where t is sensor rate at 10ms, see below picture.

    Connection Event Length Extension enabled
    Data Length Extension enabled
    Gap event length = 16 (20ms) for both peripherals
    Gap event length = 4 (5ms) for central
    TX/RX MTU = 42 bytes
    TX/RX time = 480us

    After connection and before notifications, we update conn parameters to sensor rate at 10ms:
    min Connection Interval = 32 (40 ms) // 10 * n*n + scan window, n=2 (common factor in ms)
    max Connection Interval = 32 (40 ms) // scan window = 0, no scan after all devices connected
    slave latency = 0ms
    supervision timeout = 6000 ms
    Central enable notification at once for all peripherals simultaneously.
    Central only receive packets from peripherals, not sending (almost) any data to them

    But this timing setup is not working properly as packet data are being lost from each peripheral.
    After reading many times, S132 spec and specially the chapter 15.10 Suggested intervals and windows, which is not much clear we have tried lots of combinations of these parameters but none of them eliminates this problem.
    New log files were attached showing how this configuration performed.
    Devices are placed on the table and are away 30 cm from each other forming a triangle and sniffer boards placed in the middle of it. Central tx power is +4dbm and 0dbm for peripherals.
    Thanks.

    4760.capture_36_new.pcapng3286.capture_88_new.pcapng5661.capture_new.txt

  • Hi,

    Three suggestions:

    1. It might be an LF clock issue. What is your setting for NRF_SDH_CLOCK_LF_ACCURACY? Try set it to 500 ppm (NRF_CLOCK_LF_ACCURACY_500_PPM). This goes for both peripherals and central.

    2. Use slave latency. Note that unit is not ms, it is number of connection events the peripheral can skip. (Note also that unit for supervision timeout is ms, not 1.25 ms units.)

    3. In order to reduce the effect of scanning on active links, you can set equal, low values for scan window and scan interval (e.g. 5.)

    Regards,
    Terje

  • Hi,

    I give a try to each of your suggestions but no one has a positive effect to solve missed packets.

    1- At First, NRF_CLOCK_LF_ACCURACY for master/slaves were the same as 20ppm.

    Before reading BLUETOOTH SPECIFICATION Version 5.0 | Vol 2, Part E chapter 7.7.65.10 LE Enhanced Connection Complete Event, in the last paragraph is stated "The Master_Clock_Accuracy parameter is only valid for a slave. On a master, this parameter shall be set to 0x00." I changed both as suggested to 500ppm without success.

    So, considering it changed master to 500ppm and keep slaves in 20ppm although this has not solved the question.

    2- Slave latency has been tried but it makes master missed lot of packets

    3- Changed scan window and scan interval for 10ms.

    Any other suggestion ? I'm still working full time to solve this issue and keep trying but no success to the end.

Reply
  • Hi,

    I give a try to each of your suggestions but no one has a positive effect to solve missed packets.

    1- At First, NRF_CLOCK_LF_ACCURACY for master/slaves were the same as 20ppm.

    Before reading BLUETOOTH SPECIFICATION Version 5.0 | Vol 2, Part E chapter 7.7.65.10 LE Enhanced Connection Complete Event, in the last paragraph is stated "The Master_Clock_Accuracy parameter is only valid for a slave. On a master, this parameter shall be set to 0x00." I changed both as suggested to 500ppm without success.

    So, considering it changed master to 500ppm and keep slaves in 20ppm although this has not solved the question.

    2- Slave latency has been tried but it makes master missed lot of packets

    3- Changed scan window and scan interval for 10ms.

    Any other suggestion ? I'm still working full time to solve this issue and keep trying but no success to the end.

Children
  • Hi,

    The LF accuracy setting affects timing windows in the BLE protocol, for accounting for clock drift. It will not change the accuracy of the clock, rather it accounts for drift up to the selected value. The NRF_CLOCK_LF_ACCURACY setting is used by the BLE stack in both ends of the connection, in the places appropriate.

    What boards are you using? Does nRF52 Development Kits show the same behavior Would it be possible for me to reproduce this using nRF52 DKs?

    Regards,
    Terje

  • Hi,

    I managed to solve the main issue as I changed the way I was handling TX_COMPLETE event when transmitting data and now every packet is sent without any packet loss.

    Thank you very much for your time and support.

    Regards.

Related