你好，
我的设备是电池供电设备，它始终处于连接模式。因此，为了节省电池电量，我有Conn_Interval增加。我有以下观察结果。
一种。当我的设备连接时，默认conn_interval是10ms。因此，exten_pdu正在从两侧（主设备和从站）每10ms传输。
湾检测到没有活动后，我的设备将conn_interval更改为1sec。收到新Conn_Param_update_Request后，新Conn_Interval在24个数据包之后生效。（从从站到掌握和从主站到从机12中的12。因此，新的Conn_Interval（1秒）在24 *旧Conn_Interval（10 ms）= 240ms后完全有效。
到目前为止一切都很好。
C。现在，如果主设备或从属想要进行任何活动，它们会在延迟1秒后收到数据包。到过来，我一旦我检测到任何活动，我就会设置旧Conn_Interval（10ms）。但传输24个空_Packets后，它会生效，然后他们开始在10ms时发送空_pdu。
所以，我的问题是有没有办法我可以在我发送conn_param_update_request后立即获得更新的conn_interval有效？
Device:
嗨ankit，
在连接参数更新手抖动期间，主站告诉从站，或者说哪个连接事件，以应用新的连接参数。这简要解释了你所观察到的东西。
所以在您的应用程序,我建议你尝试另ther connection parameter, slave latency. Slave can choose not to answer connection events up to the slave latency number of times. However, if slave has data to send, it can choose to send data at any time. In this way, you'll have responsiveness and battery life.
只需您的信息，Master具有连接参数的最终决定，这意味着您想要应用的参数可能不是实际应用的参数。它真的取决于它如何在主侧实施。
My observations are
一种。Master和Slave都同意在1000 ms的Conn_Interval处发送Expter_pdu。我通过BLE Sniffer验证了它。
湾Now if master or slave want to send data, it is observed that the data packet is being sent after the interval of 1000ms. To avoid that I am decreasing the conn_interval to 10 ms, Whenever there is an activity.
C。但这种新的conn_interval在传输12个空_pdus后是有效的。此12个空_pdus以旧CONN_INTERVAL传输到1000毫秒。这意味着新的conn_interval 10 ms在12000毫秒后有效。
我想减少这12秒的延迟。那么，对于那将是延迟的工作？
空闲模式conn_param
params.intv_min = ms_to_doubleslots（980）;
params.intv_max = ms_to_doubleslots（1000）;
params.time_out = ms_to_timerUnits（3100）;
params.latency = 0;
normal mode conn_params
params.intv_min = ms_to_doubleslots（10）;
params.intv_max = MS_TO_DOUBLESLOTS（30）;
params.time_out = ms_to_timerUnits（1250）;
params.latency = 0;
嗨ankit，
Said the conn_params is set once like this
params.intv_min = ms_to_doubleslots（10）;。params.intv_max = MS_TO_DOUBLESLOTS（30）;
params.time_out = ms_to_timerUnits（1250）;
params.latency = 4;
和主设备和从站之间的商定的连接间隔和延迟是10ms和4.然后允许从站跳过4个连接事件。所以您可能发现的最佳案例是从Allave答案每50毫秒alymet_pdus。如果从站之间有数据，它会在下次连接事件中发送数据。
Additional attentions need to be paid when tweaking these parameters.
据了解。让我们谈谈“如果从属从而在介于中传输数据，则会在下一个连接事件中发送数据。”
So, if slave wants to send some data, can it be possible to send immediately without waiting for next connection event.
要做到我正在减少connection_interval时间。但它后很有效。
嗨ankit，
并不真地。设备必须等待连接事件进行通信。这是如何设计的。
Connection event(or called connection instant) is numbered in an increasing manner, n, n+1, n+2 and so on. In the command LL_CONNECTION_UPDATE_REQ master sends to slave to update connection parameter, there's one field named 'Instant' which specifies a connection event number. This informs slave the new connection parameter will be applied after this specific connection event number.
对于conn_intv == 10ms和slave_latency == 4的示例。Slave在Connevent n下回答empty_pdu。如果在COPEVENT N之后没有数据需要通过从站传输，则最佳案例是在COPEVENT N + 5处的EXPLAVE答案。如果在Connevent N + 1之前有准备要传输的数据，则从站将在Connevent N + 1上传输它。因此，大致响应延迟，从准备到数据的数据被传输，大约小于10ms。
嗨，我通过BLE Sniffer捕获了日志，我在这里解释了我的问题。使用iOS应用程序执行操作。
Default connection interval is 10ms. So, when the device gets connected it communicates with conn_interval of 10ms. Once device detects that now the connection is idle and there is no more data to send either from the master or from slave side, it updated connection parameter by changing conn_interval of 1000ms.
请参阅附加PDF第1页。
一种。connection interval update to 1000msec request sent from slave to master.
湾请求主人接受。
C。after acceptance of request, 22 empty_pdus are sent at older connection conn_interval ( 10ms ). You can verify timings from logs.
因此，在22 * 10ms = 220ms后，这里可以适用1000msec Conn_Interval。这种延迟可以是可接受的。
But, when master or slave want to do communication, slave again sends connection parameter update request with conn_interval of 10ms. So, that communication can be made fast.
Refer attached pdf page 2.
一种。连接间隔更新到从从站发送到master的10msec请求。
湾请求主人接受。
C。在接受请求之后，在旧连接CONN_INTERVAL（1000ms）上发送22个空_pdus。您可以从日志中验证时间。
That means new conn_interval ( 10msec ) is applicable after 22 * 1000ms = 22000 ms ( 22 seconds ). Till that 22 seconds, if master or slave perform any operation, that is delayed by 1seconds.
So, I want to know is there any way we can reduce those 22 empty_pdu packets to make updated conn_inerval effective immediately?
嗨ankit，
There's nothing can be done on the slave side. It's decided by master. In the sniffer log, LL_CONNECTION_UPDATE_REQ is the command which master tells slave what new parameters to apply and when to apply.