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?

  • @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.

  • What function shall I have a look at to change the intervall after the link has been secured?

  • @muhkuhns: You should call sd_ble_gap_conn_param_update() with the parameter of your choice.

  • It basically works. Called it after the link secured. Everything is smooth and fine BUT strangely at least one of the 4 peripherals sends data that seems to be ~4-5 conection intervals old.. But looking at the code that makes no sense to me.. there is no queue.. it shouldn't be able to have a larger delay than one times the connection interval..

    Peripherals do measurements every 4seconds and then sd_hvx them.. Central outputs every 4seconds all 4measurements he received...

    So how can one value have like 20seconds delay?

    See also Edit in Question.

  • @muhkuhns: The thread getting long. I would suggest when you have new question to create a new case. If you queued too many notification (max 6 in the buffer), and if the central device doesn't support multiple packet per connection, they will be stack up and be transmitted in the next connection events. So you will have your notification comes pretty late compare to the time it's queued.

    Also if the RF link is not good, with lots of re-transmission, you will have larger latency.

Related