BLE multilink inherent 1 second scheduling?

[pcalleme]

Hello,

I have been testing the BLE multilink examples for the s120 softdevice. More specifically, I have tested the ble_app_hrs_c example in the experimental s120 folder. All is working fine, I am able to connect multiple peripherals and connect them to the central.

The peripherals have a notification rate of 100ms, i.e. 10 readings are notified every second. I verified this using the dongle and a BLE app.

The problem that I have is that the central only displays the readings exactly every second. It seems like some scheduling is going on (in the softdevice?) that delays the discovery of a notification. In my UART terminal (connected to the central), I get the readings from my central exactly at 1 second every time.

It must have something to do with a BLE evt that is discovered as a BLE_GATTC_EVT_HVX evt. Although the event is triggered early and 10 times per second, I only get an output exactly every second.

Next to that, I do notice some buffering behaviour as well. Size seems to be 6. So if my input changes, it takes 6 seconds for the central to display the changed input while displaying old data on second 1,2,3,4 and 5.

Can somebody help me and tell me what is going on here? Very much appreciated!

[pcalleme]

After hours of digging into this problem, finally solved the issue. The answer is not a difficult one and lies in altering the minimum and maximum connection times in ble_gap_conn_params in the connection manager code as follows:

/**
 *  Scan parameters requested for connection. 
 */
static const ble_gap_conn_params_t m_cnxn_param = 
{
    MSEC_TO_UNITS(50, UNIT_1_25_MS),                               // Minimum connection 
    MSEC_TO_UNITS(200, UNIT_1_25_MS),                              // Maximum connection     
    0,                                                              // Slave latency 
    MSEC_TO_UNITS(CONN_MNGR_SUPERVISION_TIMEOUT, UNIT_10_MS)        // Supervision time-out
};

I was confusing these values with the scan parameters. Problem solved.