Hi,
My device is battery operated device and it is always in connected mode. So, to save battery power, I have increased conn_interval. I have following observations.
一种。When my device gets connected, default conn_interval is 10ms. So, empty_pdu are being transmitted on every 10ms from both the sides( master and slave ).
湾一个fter detecting no activity, my device changes conn_interval to 1sec. After receiving acceptance of new conn_param_update_request, new conn_interval is effective after 24 packets.( 12 from slave to master and 12 from master to slave ). So new conn_interval(1 sec) is exactly effective after 24 * old conn_interval( 10 ms ) = 240ms.
Till now everything is fine.
C。Now if master or slave want to do any activity, they receive packets after the delay of 1 second. to over come this, I am setting old conn_interval ( 10ms ) as soon as I detect any activity. But it gets effective after transmitting 24 empty_packets and then they start sending empty_pdu at 10ms.
So, my question is there any way I can get updated conn_interval effective, as soon as I send conn_param_update_request?
Hi Ankit,
During the connection parameter update hand shaking, master tells slave at which point, or said which connection event, to apply the new connection parameter. This briefly explains what you've observed.
So in your application, I might suggest trying another 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.
Just for your information, master has the final decision of connection parameters, meaning that the parameters you'd like to apply might not be the one actually applied. It really depends on how it is implemented at master side.
我的观察是
一种。Master and slave both agreed to send empty_pdu at the conn_interval of 1000 ms. I have verified it via BLE sniffer.
湾现在，如果主站或从站想要发送数据，则观察到数据包在1000ms的间隔之后正在发送。避免我在存在活动时将Conn_Interval降低到10毫秒。
C。But this new conn_interval is effective after transmission of 12 empty_pdus. This 12 empty_pdus are transmitted at old conn_interval to 1000 ms. That means new conn_interval 10 ms is effective after 12000 ms.
I want to reduce this 12 seconds delay. So, for that will latency work?
idle mode conn_params
params.intv_min = MS_TO_DOUBLESLOTS(980);
params.intv_max = MS_TO_DOUBLESLOTS(1000);
params.time_out = MS_TO_TIMERUNITS(3100);
params.latency = 0;
正常模式conn_param
params.intv_min = MS_TO_DOUBLESLOTS(10);
params.intv_max = MS_TO_DOUBLESLOTS (30);
params.time_out = MS_TO_TIMERUNITS(1250);
params.latency = 0;
Hi Ankit,
说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 = 4;
一个nd the agreed connection interval and latency between master and slave is 10ms and 4. Then slave is allowed to skip up to 4 connection events. So the best case you might discover is that slave answers empty_pdus every 50ms. If slave has data to be transmitted in between, it sends out data at next connection event.
在调整这些参数时需要支付额外的注意。
据了解。让我们talk about "If slave has data to be transmitted in between, it sends out data at next connection event."
因此，如果奴隶想要发送一些数据，则可以立即发送，而无需等待下一个连接事件。
To do that I am reducing connection_interval time. But it is effective after long time.
Hi Ankit,
Not really. Devices have to wait for connection events to communicate. This is how BLE is designed.
连接事件（或调用连接即时）以越来越多的方式编号，n，n + 1，n + 2等。在命令LL_CONNECTION_UPDATE_REQ MASTER发送到从站以更新连接参数，有一个名为“Instant”的字段指定连接事件编号。这通知从站，在此特定连接事件编号之后将应用新的连接参数。
For the example of conn_intv == 10ms and slave_latency == 4. Said slave answers the empty_pdu at ConnEvent n. If no data needs transmission by slave after ConnEvent n, the best case is slave answers empty_pdu at ConnEvent n+5. If there's data ready to be transmitted before ConnEvent n+1 occurs, then slave will transmit it at ConnEvent n+1. So roughly the response latency, from data ready to data be transmitted, is approximately less than 10ms.
Hi, I have captured logs via BLE sniffer and here I am explaining my problem in details. Operations are performed with ios application.
默认连接间隔为10ms。因此，当设备连接时，它与10ms的Conn_Interval通信。一旦设备检测到现在连接空闲并且没有更多的数据从主站或从从属侧发送，它通过更改1000ms的conn_interval更新了连接参数。
Refer attached pdf page 1.
一种。连接间隔更新到从从站发送到master的1000msec请求。
湾request accepted by the master.
C。接受请求后，将在旧连接CONN_INTERVAL（10ms）处发送22个empty_pdus。您可以从日志中验证时间。
So, here 1000msec conn_interval is applicable after 22 * 10ms = 220ms. This delay can be acceptable.
但是，当主设备或从站想要进行通信时，从站再次发送10ms的Conn_Interval的连接参数更新请求。因此，可以快速地进行这种通信。
请参阅附加PDF Page 2。
一种。connection interval update to 10msec request sent from slave to master.
湾request accepted by the master.
C。after acceptance of request, 22 empty_pdus are sent at older connection conn_interval ( 1000ms ). You can verify timings from logs.
这意味着新的Conn_Interval（10MSEC）在22 * 1000ms = 22000毫秒（22秒）之后适用。直到22秒，如果主站或从站执行任何操作，那么延迟1秒。
所以，我想知道有没有办法，我们可以减少那些22个空的_pdu数据包，立即使更新的conn_inerval生效？
Hi Ankit,
从奴隶一侧没有任何东西可以完成。它由掌握决定。在嗅探器日志中，LL_CONNECTION_UPDATE_REQ是MASTER告诉从站应用程序和何时应用的新参数的命令。