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

Nrf52832 periphral disconnects timeout when BLE/ANT+ scan

Dear Nordic:
My use scenario may be a little complex. I try to describe it clearly.
A device developed on NRF52832/S332/SDK13, acts as a combination of Bluetooth central, peripheral, ANT+ display.
What i expect is: when it starts up, it tries to connect a target Ble sensor with known peer address, it also starts Ble scan and ant+ search, and sends the realtime results to PC by Nordic Nus notification.
Without connection behavior, it works well. But when I added the connection operation today, the peripheral role (nus) quickly disconnects. The reason shows 0x08 BLE_HCI_CONNECTION_TIMEOUT.
By the way, i use extended packet in nus service which support MTU 247. I checked all the parameters configured for BLE initialization, and found nothing to solve my problem.
Does the environment i am using support my scenario? It's a prototype of a bike computer. Please give me some advise to check my issue or how to accomplish the scenario with better solution.
Thanks very much.
Parents
  • Hi,

    Check out this application note on ANT channel search:
    https://www.thisisant.com/resources/an11-ant-channel-search-and-background-scanning-channel/

    Likely you need to disable high priority search, in addition the BLE link should use slave latency (for instance >10) to allow some blocking by the ANT channels.

    Best regards,
    Kenneth

  • Hi Kenneth:

    I printed the connection parameters when peripheral receives BLE_GAP_EVT_CONNECTED. And it shows superversion timeout is 500 with Android and 75 with IOS. I think it's the key that causes disconnection when i use IPhone. Is there any way wo update the superversion timeout to a bigger value?It's expected to be MSEC_TO_UNITS(4000, UNIT_10_MS) that i defined.

  • Typically it is the conn_params_init() that can initiate and handle this for you. For instance in ble_conn_params_init() you specify a FIRST_CONN_PARAMS_UPDATE_DELAY delay, which is the delay from connection event until it will try to negotiate new connection parameters (MIN_CONN_INTERVAL, MAX_CONN_INTERVAL, SLAVE_LATENCY and CONN_SUP_TIMEOUT). A supervisor timeout of only 75ms sounds very short yes. 

    My suggestion may be that you stop ANT channel search when you receive the BLE_GAP_EVT_CONNECTED event, and wait until BLE_GAP_EVT_CONN_PARAM_UPDATE event to check the updated connection parameters in &p_ble_evt->evt.gap_evt.params.conn_param_update.conn_params, for instance that the parameters use slave latency and that supervisor timeout is more than for instance 500ms before you start ANT channel search again.

    Best regards,
    Kenneth

Reply
  • Typically it is the conn_params_init() that can initiate and handle this for you. For instance in ble_conn_params_init() you specify a FIRST_CONN_PARAMS_UPDATE_DELAY delay, which is the delay from connection event until it will try to negotiate new connection parameters (MIN_CONN_INTERVAL, MAX_CONN_INTERVAL, SLAVE_LATENCY and CONN_SUP_TIMEOUT). A supervisor timeout of only 75ms sounds very short yes. 

    My suggestion may be that you stop ANT channel search when you receive the BLE_GAP_EVT_CONNECTED event, and wait until BLE_GAP_EVT_CONN_PARAM_UPDATE event to check the updated connection parameters in &p_ble_evt->evt.gap_evt.params.conn_param_update.conn_params, for instance that the parameters use slave latency and that supervisor timeout is more than for instance 500ms before you start ANT channel search again.

    Best regards,
    Kenneth

Children
Related