Sending lots of data using notifications in a loop, data rate slows down after few seconds? (FreeRTOS based app)

RE: Sending lots of data using notifications in a loop, data rate slows down after few seconds? (FreeRTOS based app)

TylerD — Fri, 29 Nov 2019 12:58:43 GMT

I agree that there could be some use for this like you said, to speed up the service discovery for example and then switch to slower interval to save power.

However, in my experience it is typically the central that should be responsible for this. For example, when testing with an Android phone (OnePlus 5) I've noticed that when I connect to a peripheral, the phone (i.e. the central) is toggling the connection parameters in the beginning. Having toggling on the peripheral side seems a bit odd for me, and in worst case both the central and the peripheral can be requesting connection parameter updates which would result in a mess.

Now that I found the hidden feature in the example it is easy to fix, but it cost me 1-2 hours of extra debugging time.

RE: Sending lots of data using notifications in a loop, data rate slows down after few seconds? (FreeRTOS based app)

mrono — Fri, 29 Nov 2019 12:51:09 GMT

[quote userid="78353" url="~/f/nordic-q-a/55019/sending-lots-of-data-using-notifications-in-a-loop-data-rate-slows-down-after-few-seconds-freertos-based-app/222774"] what is the point[/quote]

I think the point is that often you'd like to connect using a fairly short interval, so that the initial data exchange, potentially including a lengthy service discovery, happens fast. Then switch to the interval you actually want to use.

But I do agree that the way it is done in many examples is pretty 'hidden'.

RE: Sending lots of data using notifications in a loop, data rate slows down after few seconds? (FreeRTOS based app)

TylerD — Fri, 29 Nov 2019 11:38:06 GMT

Argh... after some hair pulling I found out that the FreeRTOS example is changing connection parameters on the fly. And the first change occurs at 5 seconds mark. I don't get it, what is the point of adding this kind of hidden features in the examples. For me, it just complicates things and causes unnecessary confusion.

This is the relevant piece of code of the FreeRTOS HRS main.c ->

/**@brief Function for initializing the Connection Parameters module. */
static void conn_params_init(void)
{
    ret_code_t             err_code;
    ble_conn_params_init_t cp_init;

    memset(&cp_init, 0, sizeof(cp_init));

    cp_init.p_conn_params                  = NULL;
    cp_init.first_conn_params_update_delay = FIRST_CONN_PARAMS_UPDATE_DELAY;
    cp_init.next_conn_params_update_delay  = NEXT_CONN_PARAMS_UPDATE_DELAY;
    cp_init.max_conn_params_update_count   = MAX_CONN_PARAMS_UPDATE_COUNT;
    cp_init.start_on_notify_cccd_handle    = m_hrs.hrm_handles.cccd_handle;
    cp_init.disconnect_on_fail             = false;
    cp_init.evt_handler                    = on_conn_params_evt;
    cp_init.error_handler                  = conn_params_error_handler;

    err_code = ble_conn_params_init(&cp_init);
    APP_ERROR_CHECK(err_code);
}

Value of FIRST_CONN_PARAMS_UPDATE_DELAY is set to 5000ms.

I think I'll try to strip the entire "connection parameters" module from the code, I don't see any use for this kind of clutter.