pca10059 / pca10056 + pc-ble-driver-py + HRCollector Example

[Franz]

Dear people,

I use a pca10056 (alternatively the pca10059 dongle) and have compiled the connectivity firmware as described on the github page (release 4.1.1).

The only changes I did in the connectivity source files were:

• increasing the LINK_COUNT in sdk_config and adjusting the APP_RAM_BASE accordingly
• adding the line  err_code = nrf_sdh_ble_default_cfg_set(1, &app_ram_base); SER_ASSERT(err_code == NRF_SUCCESS, err_code);  after line 325 in conn_mw_ble.c of the segger SES project ble_connectivity_132v5_usb_hci_pca10056.
  
  • it seems this line is necessary so that the sdk_config.h defines for the LINK_COUNT  have an effect.

Now, I use the HRS_Collector sample provided by the python bindings of the pc-ble-driver-py and get measurement values from my device(s) by receiving notifications. This works so far, however I have the problem, that after some time (minutes, sometimes seconds), it seems that the connection to the peripheral is lost (i notice that by a led blinking on my peripheral) while the python driver/script does not report any loss of connection or error.

The peripheral itself is based on a custom nRF52832 board and the "link loss problem" doe snot occur when the peripheral is used with another BLE dondle/software so this seems to be related to the nordic python driver and/or connectivity firmware. Behaviour is the same for pca10056 and pca10059.

Can you please provide a hint of what could be wrong here and how to start useful debugging from here? (it seems a bit daunting to debug the connectivity firmware...)

[EDIT]: If I use the precompiled connectivity hex file delivered with the 4.1.1. version of the pc driver (connectivity_4.1.1_usb_with_s132_5.1.0.hex) I have(only one device possible with precompiled firmware) the following error after some time: Disconnected: 0 BLEHci.conn_interval_unacceptable

Thanks a lot and best regards!

[Sigurd]

Hi,

Franz said:

Disconnected: 0 BLEHci.conn_interval_unacceptable

Try to adjust MIN_CONNECTION_INTERVAL and MAX_CONNECTION_INTERVAL. See this link. Try e.g. MIN = 50ms , and max = 100ms. If that does not work, try MIN = 400ms and MAX=650ms

[Franz]

Thanks for the hint, I am currently running a test with modified connection intervals - it seem to work so far. Could you tell me the big idea about why the central (connectivity FW) tries to negotiate different settings than at the initial connection establishment? I see the call of conn_params_negotiation() in on_connect() but I don´t get the big picture of the logic and the purpose of changing the parameters over time.

[Sigurd]

It's likely the other way around, the ble_app_hrs will try to negotiate the connection interval to be within it's own defined max/min limit. The ble_app_hrs will disconnect if this negotiation fails.

Snippet from ble_app_hrs:

/**@brief Function for handling the Connection Parameters Module.
 *
 * @details This function will be called for all events in the Connection Parameters Module which
 *          are passed to the application.
 *          @note All this function does is to disconnect. This could have been done by simply
 *                setting the disconnect_on_fail config parameter, but instead we use the event
 *                handler mechanism to demonstrate its use.
 *
 * @param[in] p_evt  Event received from the Connection Parameters Module.
 */
static void on_conn_params_evt(ble_conn_params_evt_t * p_evt)
{
    ret_code_t err_code;

    if (p_evt->evt_type == BLE_CONN_PARAMS_EVT_FAILED)
    {
        err_code = sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_CONN_INTERVAL_UNACCEPTABLE);
        APP_ERROR_CHECK(err_code);
    }
}

[Franz]

Not sure why those specific settings help, but it worked out...