This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

gap_params_init and connection parameter issue

Hello,

I'm working on a firmware for a device that is created using ble proximity example. It is power constrain device and required a connection interval of 30 sec between a master (Android phone only) and slave nRF52810.

I’m using the following version and device.

  1. SDK v17.0.2
  2. 2. s112_nrf52_7.2.0_softdevice
  3. Basically I’m using Android phones as my central or master device and nRF52810 as peripheral or slave.

Basic feature of the firmware

                The architecture is based on Application Timer Event callbacks.

                The firmware was prepared using the BLE Peripheral Proximity example.

In order to minimize power consumption the device runs a minimum of active GATT services listed below:

  1. TX Power
  2. Instant Alert Service (IAS)
  3. Instant Alert Service Client (IAS-C)
  4. Connection is BLE_PERIPHERAL

To get the desire interval I'm changing the following parameters. I have used different values for these parameters without violating the following two constrain but seem I'm not able to go beyond 15 sec interval ( 30 sec is desired). Is there anything I'm not doing correct. 

                   //constrains

    1. conn_sup_timeout * 4 > (1 + slave_latency) * max_conn_interval
    2. (1 + Conn_Latency) * Conn_Interval_Max * 2 < conn_sup_timeout

                   // Parameters

    1. MIN_CONN_INTERVAL               MSEC_TO_UNITS(800, UNIT_1_25_MS)
    2. MAX_CONN_INTERVAL               MSEC_TO_UNITS(830, UNIT_1_25_MS)
    3. SLAVE_LATENCY                   18
    4. CONN_SUP_TIMEOUT                MSEC_TO_UNITS(32000, UNIT_10_MS)

I'm getting the following error whenever I try to increase slave latency.

  • gap_params_init();
    • APP_ERROR_CHECK(err_code);
      • I think It might help you “void app_error_handler_bare(ret_code_t error_code)” here error_code = 0x00000007.
Parents
  • err_code = 7 means NRF_ERROR_INVALID_PARAM (look at nrf_error.h). 

    You have set your conn_sup_timeout to 32 000 units of 10ms = 32 seconds, which is the maximum allowed supervision timeout. 

    From the Bluetooth specification, Vol6, part B, section 4.5.2:

    The connSupervisionTimeout shall be a multiple of 10ms in the range 100ms to 32.0s and shall be larger than

    (1 + connSlaveLatency) * connInterval * 2

    which is considered in your b. constraint. 

    When conn_latency = 18:

    (1+18) * 800*1.25 *  2 = 38 000, which is already larger than your supervision timeout, so it should probably have returned NRF_ERROR_INVALID_PARAMS.  

    You can't have 30ms connection interval. You can have maximum 4 seconds (you can find the limits in ble_gap.h. Search for BLE_GAP_CP_LIMITS).

    The reason that this requirement exists is that the devices should have at least two attempts to send a packet before they disconnect. Otherwise, you will get a disconnect every time a packet is lost due to noise on air. 

    BR,

    Edvin

Reply
  • err_code = 7 means NRF_ERROR_INVALID_PARAM (look at nrf_error.h). 

    You have set your conn_sup_timeout to 32 000 units of 10ms = 32 seconds, which is the maximum allowed supervision timeout. 

    From the Bluetooth specification, Vol6, part B, section 4.5.2:

    The connSupervisionTimeout shall be a multiple of 10ms in the range 100ms to 32.0s and shall be larger than

    (1 + connSlaveLatency) * connInterval * 2

    which is considered in your b. constraint. 

    When conn_latency = 18:

    (1+18) * 800*1.25 *  2 = 38 000, which is already larger than your supervision timeout, so it should probably have returned NRF_ERROR_INVALID_PARAMS.  

    You can't have 30ms connection interval. You can have maximum 4 seconds (you can find the limits in ble_gap.h. Search for BLE_GAP_CP_LIMITS).

    The reason that this requirement exists is that the devices should have at least two attempts to send a packet before they disconnect. Otherwise, you will get a disconnect every time a packet is lost due to noise on air. 

    BR,

    Edvin

Children
No Data
Related