Consider a scenario where the master and slave negotiate a supervisor timeout of 20 seconds. The slave has code to explicitly disconnect if 5 seconds of link inactivity is detected (prior to the supervisor timeout) via observing the sequence of these events in rwble.c:
/*Last BLE event. Used for application's synchronisation with BLE activity */
typedef enum
{
BLE_EVT_SLP,
BLE_EVT_CSCNT,
BLE_EVT_RX,
BLE_EVT_TX,
BLE_EVT_FINETGTIM,
BLE_EVT_END,
}last_ble_evt;
The link is broken at t=0 and using a debugger breakpoint I observe that the slave code correctly initiates a disconnect at t=5 seconds elapsed via the kernel message GAPC_DISCONNECT.
However, what I'm also observing with the debugger is that the GAPC_DISCONNECT_IND, confirming the completion of the disconnection, does not occur until around t=10. With a packet sniffer I also see that advertising does not resume until after t=10. It appears as if the actual disconnection is delayed even though a GAPC_DISCONNECT is commanded at the proper time. In our case it is important that the disconnect happen immediately if the conditions mentioned above occur.
Thanks,
Hi JamesHiebert,
最可能的原因有这种行为is due to the connection interval. Which are you configurations for the connection interval? If the connection interval is too big and you are not using latency, I would suggest you to have smaller connection interval and increase the latency. Please check the attached screenshots. When the slave have nothing to send the connection interval is around at 2200ms (2000ms latency + 200ms conn interval). But when the slave have something to send, in your case the disconnection message, the device will wake up and the connection interval will be around t 200ms.
Thanks, PM_Dialog
Hello Dialog,
Thanks for the info. In our scenarios, the CI is very short, 11.25ms, and the slave latency is 0.
Have you tried the experiment during a long supervision timeout while the master is no longer transmitting idle packets to the slave?
Is it possible that the delay occurs because the slave can't transmit the disconnect command as the master and slave are no longer exchanging idles?
Hi JamesHiebert,
No, I have never tried this experiment. Could you please clarify it a little bit more? Which are the configurations that you are using?
Thanks, PM_Dialog
Try this:
1. Establish a connection with 11.25ms CI and 20s ST (master and slave).
2. Slave sets a timer for 5 (or more) seconds starting with the connection.
3. Before timer elapses, disconnect antenna from master
4. When timer expires, slave sends GAPC_DISCONNECT_CMD.
When is GAPC_DISCONNECTED_IND received by the slave app?
We would want this to occur immediately but it seems as if it is delayed significantly.
Hi JamesHiebert,
When you send a GAPC_DISCONNECT_CMD command the response is a GAPC_DISCONNECT_IND event which is triggered when the connection is finished and when the operation is completed, you will get a GAPC_CMP_EVT event. The GAPC_DISCONNECT_IND event will be sent to application task in order to inform that link has been disconnected. Receiving this message also means that task instances related to the link are cleaned-up and corresponding task instances cannot be used anymore until new connection is established. Do you mean that when you disconnect the master from the peer peripheral device, you don’t get the GAPC_DISCONNECT_IND?
Thanks, PM_Dialog
PM_Dialog,
We do get the GAPC_DISCONNECT_IND, but not immediately. It seems to take several seconds before the indication arrives. It's almost as if the system is trying to send the disconnect indication over the air back to the master but since the master's frames are not being received, it delays a bit before giving up and disconnecting anyway?
Dialog,
I corresponded with one of your engineering managers and his suggestion to send the following message instead of GAPC_DISCONNECT resolves the delay issue.
ke_msg_send_basic(LLC_LE_LINK_SUP_TO, KE_BUILD_ID(TASK_LLC, gapc_get_conhdl(conn_idx)), TASK_NONE);
Dialog,
I corresponded with one of your engineering managers and his suggestion to send the following message instead of GAPC_DISCONNECT resolves the delay issue.
ke_msg_send_basic(LLC_LE_LINK_SUP_TO, KE_BUILD_ID(TASK_LLC, gapc_get_conhdl(conn_idx)), TASK_NONE);
Hi JamesHiebert,
高兴你图d your issue out and thanks for the indication.
Thanks, PM_Dialog