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

Multilink Example - long time needed to establish connection and enable notifications

The m_client_count is like instantly increased when I power up another (or the first) peripheral.

But with increasing connection interval the time till the central finally enables notifications on the peripheral is dramatically increased - why is that?

peripheral - main.c - Connected and bonded with nRFMaster Panel and notifications enabled in no time -> Problem is the central?

RTT Output:

It seems like the time is indeed lost/needed for securing the link. As the first few lines come in pretty fast. Looking at the clock I would say

Scan gestartet // of course instant as always
GAP_EVT_ADV_REPORT // from here
EVT_DEVICE_CONTEXT_LOADED
EVT_CONNECTION
GAP_EVT_ADV_REPORT
EVT_DEVICE_CONTEXT_LOADED
EVT_CONNECTION
GAP_EVT_ADV_REPORT
EVT_DEVICE_CONTEXT_LOADED
EVT_CONNECTION
GAP_EVT_ADV_REPORT
EVT_DEVICE_CONTEXT_LOADED
EVT_CONNECTION // till here only a few seconds (3~4)
EVT_LINK_SECURED //but to reach this takes the biggest part
DM_EVT_LINK_SECURED
0;0;97962;22826;0;0;0;0
0;0;97965;22820;0;0;0;0
0;0;97964;22826;0;0;0;0
0;0;97963;22840;0;0;0;0
EVT_LINK_SECURED
DM_EVT_LINK_SECURED
0;0;97966;22843;0;0;0;0
0;0;97958;22850;0;0;0;0
0;0;97950;22843;0;0;0;0
0;0;97950;22850;98044;22856;0;0
0;0;97951;22856;98040;22846;0;0
0;0;97953;22863;98044;22860;0;0
EVT_LINK_SECURED
DM_EVT_LINK_SECURED
0;0;97952;22856;98046;22853;0;0
0;0;97945;22856;98042;22860;0;0
0;0;97946;22856;98041;22863;0;0
0;0;97945;22863;98028;22860;97952;22713
0;0;97946;22863;98033;22870;97951;22706
0;0;97952;22866;98032;22870;97954;22706
EVT_LINK_SECURED
DM_EVT_LINK_SECURED
0;0;97944;22860;98031;22876;97956;22716
0;0;97949;22866;98025;22870;97955;22713
0;0;97947;22870;98024;22883;97955;22716
98015;22686;97941;22870;98023;22876;97944;22726
98017;22696;97945;22873;98021;22886;97940;22726

Above with 4seconds conn_int => >2,5minutes till 4th peripheral send first measurement.

With 50ms it is quite fast. (Same time for the evt_conn but like no time for link_secured for all 4 peripherals vs. ~40seconds each with 4second interval.)

30seconds till last peripheral is link_secured with 500ms interval.

So what is the easiest way to change connection intervall after all inks are secured?

central - main.c

central - client_handling.c

//Edit:

image description

The measurements on the left come in fine.. the 1*interval delay (2nd from top) can happen..

But on the right the 4times connection interval doesn't make sense to me. at least I can't explain it..

4s timer on peripherals does: Measurement + sd_ble_gatts_hvx();

4s timer on central ouputs the values received by

	case BLE_GATTC_EVT_HVX:
	for (int i=0; i<8; i++) {
	empf_buffer[i] = p_ble_evt->evt.gattc_evt.params.hvx.data[i];
	}
	modul_nr = empf_buffer[7];
	zaehler[modul_nr] = 0;
	druck[modul_nr] = empf_buffer[0]<<16 | empf_buffer[1]<<8 | empf_buffer[2];
	temperatur[modul_nr] = empf_buffer[3]<<16 | empf_buffer[4]<<8 | empf_buffer[5];
	spannung[modul_nr] = empf_buffer[6];

so no buffering of data.. or does sd_ble_gatts_hvx(); a sort of buffering?

  • @muhkuhns: Could you elaborate a little bit more on the relation between the m_client_count and the question. I don't quite understand it.

    Regarding your observation on "increasing connection interval the time till the central finally enables notifications on the peripheral is dramatically increased". I think it's pretty straight forward.

    We only enable notification after we did a service discovery to find the handle of the CCCD to be written (to enable notification). If we have longer connection interval, it will take longer time to finish service discovery and then after that to write to CCCD.

    So there are 2 option here, one is to keep the connection interval short at the beginning and increase it afte we finish enabling notification.

    Second is to bond with the device and store bond information, so that next time we will be able to restore the CCCDs value automatically without doing service discovery again and again.

  • For the m_client_count thing: I just thought in the beginning that the time to connect increased as a whole.. forget about that part.

    What of your two suggestions should I try out first? As in the end there are 1 master and 4peripherals I guess the bonding would be a good idea. But I was thinking this were already implemented in the multilink example?

    I will have a look at how to increase connection interval after initial setup.

  • @muhkuhns: I'm not sure how much we have implemented, but it seems from the code that the bonding handling and restore system attribute is already there in the device manager peripheral, you just need to call from the application.

    Increasing connection interval would be pretty simple.

  • Could you maybe hint out some specific functions I should look up in the dic for this purpose?

  • @muhkhuns: it's actually implemented in our ble_app_hrs_c example. In this example, we trigger pairing after finish with service discovery. Please have a look at BLE_HRS_C_EVT_DISCOVERY_COMPLETE event in hrs_c_evt_handler.

    The rest is already implemented in the device_manager_central.c event the CCCD re-enabling (m_service_context_load)

Related