Fail to change connection timeout.

[Yoole]

Hi,

   I want to make the slave disconnect with the master in a minute automatically.

   However, It's failure when I have motified the codes like below:

   

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(20, UNIT_1_25_MS)             /**< Minimum acceptable connection interval (20 ms), Connection interval uses 1.25 ms units. */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(75, UNIT_1_25_MS)             /**< Maximum acceptable connection interval (75 ms), Connection interval uses 1.25 ms units. */
#define SLAVE_LATENCY                   0                                           /**< Slave latency. */
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)             /**< Connection supervisory timeout (4 seconds), Supervision Timeout uses 10 ms units. */
#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(5000)                       /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (5 seconds). */
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(30000)                      /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */
#define MAX_CONN_PARAMS_UPDATE_COUNT    3                                           /**< Number of attempts before giving up the connection parameter negotiation. */

   Whatever I change NEXT_CONN_PARAMS_UPDATE_DELAY to xxx value, it doesn't work.

   Q:

   1. What should I do to make the slave disconnecting automatically in a minute?

   SDK version: 16.0.0. Softdevice version:7.0.1

BR,

   Yoole

[Karl Ylvisaker]

Hello Yoole,

There might be a mismatch in what you want to achieve and what you are changing here.
First of all, I see no mention of which setting you have changed to a minute in the code.

NEXT_CONN_PARAMS_UPDATE_DELAY

This is the delay before the peripheral requests to update the parameters of the connection, to suit the peripherals requirements. This is not how you initiate a disconnection of the link.
The timeout supervision is used to set how long the device will keep the connection live when it does not hear anything from its peer. So, for example, the central will not report the link as broken even though it has not heard anything until the supervision times out.

Q:

   1. What should I do to make the slave disconnecting automatically in a minute?

If you would like the connection to be terminated after a given time, you can use the sd_ble_gap_disconnect function, in connection to a timer ( such as the app_timer ).
So, to disconnect after 60 seconds, you should set up a timer which is started on the CONNECTED event, and have the disconnect function called in the timer's expiration handler.

Please do not hesitate to ask if anything should be unclear, or if you should encounter any other issues or questions.

Best regards,
Karl

[Yoole]

Hi Karl，

   Thanks for your reply.

   Here is a strange performance, I connect the module(slave) with iPhone11(master) and the connection will be disconnected automatically in about 30 seconds. When I debug to check disconnected event,  I cannot find that "p_ble_evt->header.evt_id" was called in "ble_evt_handler".

   On account of the auto-disconnection, I have no means to use app_timer to revise that timeout.

   Can I have your analysis?

BR,

Yoole

[Karl Ylvisaker]

Hello again Yoole,

Yoole said:

Thanks for your reply.

It is not problem at all, I am happy to help!

Yoole said:

Here is a strange performance, I connect the module(slave) with iPhone11(master) and the connection will be disconnected automatically in about 30 seconds.

That does sound strange. Is it exactly 30 seconds?
Does the phone provide you with any information about the disconnection? Are you connecting to the your device using the OS Bluetooth settings, or are you using an application on the phone?

Yoole said:

When I debug to check disconnected event,  I cannot find that "p_ble_evt->header.evt_id" was called in "ble_evt_handler".

I am not sure I understand what you mean here - are you saying that no disconnected event is received by the application?
Are you attempting to see this by placing a breakpoint on the switch statement itself? You should rather place it within the case you would like to check.

The "sure-fire" way to find out what is happening here is to use the nRF Sniffer tool. Are you familiar with the nRF Sniffer?
It is a very powerful tool when developing with BLE, since it lets you monitor all the on-air BLE traffic. Seeing this, we could verify whether the disconnection is caused by a deliberate termination by one of the devices, or if the connection times out, etc.

Looking forward to resolving this issue together!

Best regards,
Karl

[Yoole]

Hi Karl,

   Happy weekend.
   Not so exactly. I take a simple test by second chronograph. Android(nRF connect app) and IOS(nRF connect app) has diffent numbers, the former is about 40 seconds and the latter is about 30 seconds.

• I am not sure I understand what you mean here - are you saying that no disconnected event is received by the application?
  Are you attempting to see this by placing a breakpoint on the switch statement itself? You should rather place it within the case you would like to check.

   Yes, I have placed a breakpoint on the switch statement. But BLE_GAP_EVT_DISCONNECTED was not triggered when disconnection happened.

   After the packets capturing, I noticed that the connection state has been something wrong. There's no services and characteristics responded. Is this the causes of abnormal disconnection?

• 

   Do you have some solutions to handle this issue?

BR,

   Yoole

[Karl Ylvisaker]

Hello Yoole,

Yoole said:

Happy weekend.

Thank you, I hope your weekend was great as well!

Yoole said:

Android(nRF connect app) and IOS(nRF connect app) has diffent numbers, the former is about 40 seconds and the latter is about 30 seconds.

This could indicate that the connection is closed by the central after some time, and that the two different centrals have different timeout intervals / requirements for closing the connection. We will have to take a look at the sniffer trace to see what the case is here, exactly.

Yoole said:

Yes, I have placed a breakpoint on the switch statement. But BLE_GAP_EVT_DISCONNECTED was not triggered when disconnection happened.

Debugging with breakpoints is not straight-forward when the SoftDevice is enabled and in a connection, because the constant haling of the CPU will break the connection every time.
Take a look at the answer by my colleague Susheel in this ticket.
To avoid having to make these changes to be able to debug ( when you are just looking to see if the code enters a certain code block ) I would recommend adding a logging output instead, for convenience.

Yoole said:

After the packets capturing, I noticed that the connection state has been something wrong. There's no services and characteristics responded. Is this the causes of abnormal disconnection?

It is very hard to say from looking at this small sniffer exempt, but there are no disconnect initiated here, as far as I can see.
Please upload the entire sniffer trace, and write out what you are doing when the different exchanges happen: "The behavior can be seen in the exchange starting at packet 140, with a sudden disconnet / termination of the link at packet 200", for example.
This enables me to see what is really going on in the link, while at the same time not having to weed through potentially thousands of packets.

Looking forward to resolving this issue together!

Best regards,
Karl

[Yoole]

Hi Karl,

   Sth has come up, and time has been delayed.

   Following were two entire sniffer traces. 

   0216.std_beacon_connection_detail-1.pcapng5383.std_beacon_connection_detail-2.pcapng
   In std_beacon_connection_detail-1 and xxx-2 trace, I just use Android app, NRF CONNECT, to connect the module and wait for the disconnection happened.

   The behavior can be seen  in std_beacon_connection_detail-1 in the exchange starting at packet 20, with a sudden disconnect/termination of the link at packet 50.

   The similarity with std_beacon_connection_detail-1, xxx-2 begins at packet 12 and stops at packet 16.

   

BR,

   Yoole

[Karl Ylvisaker]

Hello Yoole,

Yoole said:

Sth has come up, and time has been delayed.

I am sorry, but I do no understand what you mean by this.

Yoole said:

Following were two entire sniffer traces. 

Thank you for providing these traces.
In one of the traces, it seems that you do not follow into the connection ( you have not selected your device from the device menu, as shown in the included picture ).
So, this trace did unfortunately did not provide so much information.

In the other trace it seems that there is an abrupt end to the packet tranfers.
Is this trace taken while pairing / bonding with an iOS device?
It might be that the iOS devices wants to do the pairing procedure on 2 Mbps PHY, if possible.
What device are you using to do the sniffing, does it support 2 Mbps PHY?
Furthermore, what security are you using for your connection?

I suspect that the connection might be terminated by either device, possibly because of a mismatch in either security or connection parameters.

Best regards,
Karl