Large data transfer [nRF5 SDK v. 11, nRF52-DK, BLE]

[Pawel J]

Dear Forum Users,

I am trying to send the data in a burst. Thanks to this post I have managed to achieve ~2,5 kB/s. However this lasts only for few seconds. Then the stream is 4 packets long after which occurs a short break. This happens cyclically from then on and results in transfer drop to 80-160 B/s.

Could this be caused by the fact of using different SDK? Why is it so and how can it be improved?

The sending function heart_rate_meas_timeout_handler in nRF5 DK is a timer handler, so I stop the timer using app_timer_stop(). I have noticed that stopping battery_level_meas also causes the system working slowly.

Thank you for your help!

static void heart_rate_meas_timeout_handler(void )
{
    static uint32_t cnt = 0;
    uint32_t        err_code;
    uint16_t        heart_rate;

    err_code = app_timer_stop(m_heart_rate_timer_id);
    APP_ERROR_CHECK(err_code);

    heart_rate = (uint16_t)sensorsim_measure(&m_heart_rate_sim_state, &m_heart_rate_sim_cfg);

while(true)
{
    if (cnt < 300)
    {

    err_code = ble_hrs_heart_rate_measurement_send(&m_hrs, cnt);
    if (err_code == BLE_ERROR_NO_TX_PACKETS ||
        err_code == NRF_ERROR_INVALID_STATE ||
        err_code == BLE_ERROR_GATTS_SYS_ATTR_MISSING)
    {
        break;
    }
    else if (err_code != NRF_SUCCESS)
    {
        APP_ERROR_HANDLER(err_code);
    }

    cnt++;
}

in on_ble_evt():

 case BLE_EVT_TX_COMPLETE:
      heart_rate_meas_timeout_handler();
      break;

[Pawel J]

It seems you're intuition is right as there is parameters update event going on. This is what I have logged: BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST: min_conn_interval: 320 max_conn_interval: 520 conn_sup_timeout: 400 slave_latency: 0 Have you got an idea how could I avoid that? Thank you!

[Anders Strand]

Who is sending the parameter update request, the central or the peripheral?. Can you attach the sniffer log to your first post?

The connection intervals in the SDK examples are set on top of main.c

#define MIN_CONN_INTERVAL                MSEC_TO_UNITS(400, UNIT_1_25_MS)           /**< Minimum acceptable connection interval (0.4 seconds). */
#define MAX_CONN_INTERVAL                MSEC_TO_UNITS(650, UNIT_1_25_MS)           /**< Maximum acceptable connection interval (0.65 second). */
#define CONN_SUP_TIMEOUT                 MSEC_TO_UNITS(4000, UNIT_10_MS)            /**< Connection supervisory timeout (4 seconds). */
#define FIRST_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(5000, APP_TIMER_PRESCALER) /**< 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, APP_TIMER_PRESCALER)/**< 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. */

These values are from the ble_app_hrs example in SDK 11

The ble_conn_params.c module will negotiate connection parameters when gap_params_init() is called in main().

The FIRST_CONN_PARAMS_UPDATE_DELAY controls the time between connection and when the peripheral requests new connection parameters.