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.
1. What should I do to make the slave disconnecting automatically in a minute?
SDK version: 16.0.0. Softdevice version:7.0.1
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…
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.
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.
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
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?
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
Do you have some solutions to handle this issue?
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