Improve distance

[jhc]

Hi,

I got some troubles on the communication distance between the two units which one acts as central and one acts as peripheral, I tried to adjust the BLE parameters the same as ble_app_uart example, but distance was not good compared to the units running ble_app_uart_c and ble_app_uart examples respectively.

Here is my configurations:
SDK: nRF5_SDK_15.2.0_9412b96
IDE: SEGGER Embedded Studio for ARM Release 4.30c Build 2019120200.40763 Windows x64

BOARDS: PCA10056.
Source code is base on ble_app_multirole_lesc example, and is ported to working on freeRTOS.

And we mesure the communication distance just according to the BLE_GAP_EVT_CONNECTED & BLE_GAP_EVT_DISCONNECTED event.

Could you have some comments for me to improve the communication distance?

BLE parameters:

#define LESC_DEBUG_MODE                    (0)                                              /**< Set to 1 to use the LESC debug keys. The debug mode allows you to use a sniffer to inspect traffic. */
#define LESC_MITM_NC                       (0)                                              /**< Use MITM (Numeric Comparison). */


#define APP_BLE_CONN_CFG_TAG                (1)                                             /**< Tag that identifies the SoftDevice BLE configuration. */


#define ADV_INTERVAL                        MSEC_TO_UNITS(40, UNIT_0_625_MS)

#define SCAN_DURATION                       (0x0000)                                        /**< Duration of the scanning in units of 10 milliseconds. If set to 0x0000, scanning continues until it is explicitly disabled. */
#define APP_ADV_DURATION                    MSEC_TO_UNITS(1000, UNIT_10_MS)         /**< The advertising duration in units of 10 milliseconds. */

#define MIN_CONN_INTERVAL                   MSEC_TO_UNITS(20, UNIT_1_25_MS)                 /**< Minimum acceptable connection interval. */
#define MAX_CONN_INTERVAL                   MSEC_TO_UNITS(75, UNIT_1_25_MS)                 /**< Maximum acceptable connection interval. */
#define SLAVE_LATENCY                       (0)                                              /**< Slave latency. */
#define CONN_SUP_TIMEOUT                    MSEC_TO_UNITS(4000, UNIT_10_MS)                  /**< Connection supervisory time-out (4 seconds). */


#define SEC_PARAMS_BOND                     (1)                                             /**< Perform bonding. */
#if LESC_MITM_NC
#define SEC_PARAMS_MITM                     (1)                                             /**< Man In The Middle protection required. */
#define SEC_PARAMS_IO_CAPABILITIES          BLE_GAP_IO_CAPS_DISPLAY_YESNO                   /**< Display Yes/No to force Numeric Comparison. */
#else
#define SEC_PARAMS_MITM                     (0)                                             /**< Man In The Middle protection required. */
#define SEC_PARAMS_IO_CAPABILITIES          BLE_GAP_IO_CAPS_NONE                            /**< No I/O caps. */
#endif
#define SEC_PARAMS_LESC                     (0)                                             /**< LE Secure Connections pairing required. */
#define SEC_PARAMS_KEYPRESS                 (0)                                             /**< Keypress notifications not required. */
#define SEC_PARAMS_OOB                      (0)                                             /**< Out Of Band data not available. */
#define SEC_PARAMS_MIN_KEY_SIZE             (7)                                             /**< Minimum encryption key size in octets. */
#define SEC_PARAMS_MAX_KEY_SIZE             (16)                                            /**< Maximum encryption key size in octets. */

#define FIRST_CONN_PARAMS_UPDATE_DELAY      APP_TIMER_TICKS(5000)                           /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (5 seconds). */
#define NEXT_CONN_PARAMS_UPDATE_DELAY       APP_TIMER_TICKS(30000)                          /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */
#define MAX_CONN_PARAMS_UPDATE_COUNT        (3)                                             /**< Number of attempts before giving up the connection parameter negotiation. */

parameters in SDK_config.h:

// <o> NRF_SDH_BLE_PERIPHERAL_LINK_COUNT - Maximum number of peripheral links. 
#ifndef NRF_SDH_BLE_PERIPHERAL_LINK_COUNT
#define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 1
#endif

// <o> NRF_SDH_BLE_CENTRAL_LINK_COUNT - Maximum number of central links. 
#ifndef NRF_SDH_BLE_CENTRAL_LINK_COUNT
#define NRF_SDH_BLE_CENTRAL_LINK_COUNT 19
#endif

// <o> NRF_SDH_BLE_TOTAL_LINK_COUNT - Total link count. 
// <i> Maximum number of total concurrent connections using the default configuration.

#ifndef NRF_SDH_BLE_TOTAL_LINK_COUNT
#define NRF_SDH_BLE_TOTAL_LINK_COUNT 20
#endif

[bjorn-spockeli]

Hi jhc, 

I got some troubles on the communication distance between the two units which one acts as central and one acts as peripheral, I tried to adjust the BLE parameters the same as ble_app_uart example, but distance was not good compared to the units running ble_app_uart_c and ble_app_uart examples respectively.

If the hardware you're running is identical and the parameters you have listed are identical then you should not see any difference in range. Is the test setup completely identical to the one with ble_app_uart examples?

The only thing that maters from a programmaticpoint of view is what the TX output power is set to. This is done with sd_ble_gap_tx_power_set. So if you want to increase the range I would suggest increasing the TX Output power. note, this comes at the cost of a higher current consumption. 

Best regards

Bjørn

[jhc]

Thanks for your reply!

Therefore, you mean the communication range is only depend on the parameters I list and the tx power? But actually, the parameters is exactly the same with the unit running ble_app_uart example, and all the test units are set to the same tx power, too, but the result is that the range of the units running ble_app_multirole_lesc example is less than the ones running ble_app_uart example.

Is there any other parameters need to be set to identical?

And another phenomenon, the units running ble_app_multirole_lesc example disconnected from each other very quickly once out of range, seem the CONN_SUP_TIMEOUT is not take affect.

#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)             /**< Connection supervisory timeout (4 seconds), Supervision Timeout uses 10 ms units. */

[bjorn-spockeli]

jhc said:

Therefore, you mean the communication range is only depend on the parameters I list and the tx power?

 The range is really only dependent on the TX output power, the PHY layer used( 1Mbps, 2Mbps or Coded)  and how well the RF frontend is tuned and laied out on the PCBs. So if you are using the same devices for testing, i.e. that you reflash the device that ran the ble_app_uart code with the ble_app_multirole_lesc code, then you should see identical performance in terms of range if both examples use the same TX output power  and the same PHY, e.g. 1Mbps. 

 

jhc said:

And another phenomenon, the units running ble_app_multirole_lesc example disconnected from each other very quickly once out of range, seem the CONN_SUP_TIMEOUT is not take affect.

#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)             /**< Connection supervisory timeout (4 seconds), Supervision Timeout uses 10 ms units. */

 The connection supervision timer will start "counting" when packets are lost, so the device was likely dropping packets before you determined that you were out of range. 

Best regards

Bjørn

[jhc]

Thanks for replying.

For the CONN_SUP_TIMEOUT, I did a simulation, steps as follows : first of all, the two units are very close to each other, and then after connected completely ( logs showed that the pairing is finished), LED lights on. then we simply shutdown one unit, the LED will go out within 1 second(far from 4 seconds ) after the shutdown.

[bjorn-spockeli]

Please verify that BLE_HCI_CONNECTION_TIMEOUT(0x08)  is passed as the disconnect reason when you get the BLE_GAP_EVT_DISCONNECTED event in ble_evt_handler, i.e. check if p_ble_evt->evt.gap_evt.disconnected.reason is equal to 0x08.

[jhc]

Yes!

Log as below:

<info> app: PERIPHERAL: Disconnected, handle 1, reason 0x8.