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?

Parents
  • @muhkhuns: 37 seconds needed when the connection interval is 4 second is quite reasonable.

    It's only 9 connection events. Doing a service discovery process often take longer than 9 connection events.

    But 5 seconds when the connection interval is 50ms is pretty strange. Because this meant it take 100 connection events before the notification is sent.

    Anyway, 4 seconds connection interval is pretty long one.

    My suggestion is you stick with 50ms connection interval at the begining. Then after you have the first notification, you can try to update the connection interval to the longer one, e.g 4 seconds. Make sure you also set the connection timeout accordingly, suggesting at least 3 times the connection interval.

Reply
  • @muhkhuns: 37 seconds needed when the connection interval is 4 second is quite reasonable.

    It's only 9 connection events. Doing a service discovery process often take longer than 9 connection events.

    But 5 seconds when the connection interval is 50ms is pretty strange. Because this meant it take 100 connection events before the notification is sent.

    Anyway, 4 seconds connection interval is pretty long one.

    My suggestion is you stick with 50ms connection interval at the begining. Then after you have the first notification, you can try to update the connection interval to the longer one, e.g 4 seconds. Make sure you also set the connection timeout accordingly, suggesting at least 3 times the connection interval.

Children
No Data
Related