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.
a. 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 ).
b. After 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.
所以在您的应用程序,我建议你尝试另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.
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.
My observations are
a. Master and slave both agreed to send empty_pdu at the conn_interval of 1000 ms. I have verified it via BLE sniffer.
b. 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. 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;
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;
Hi 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;
一个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.
一个dditional attentions need to be paid when tweaking these parameters.
That is understood. Let us talk about "If slave has data to be transmitted in between, it sends out data at next connection event."
So, if slave wants to send some data, can it be possible to send immediately without waiting for 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.
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.
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.
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.
Refer attached pdf page 1.
a. connection interval update to 1000msec request sent from slave to master.
b. request accepted by the master.
c. after acceptance of request, 22 empty_pdus are sent at older connection conn_interval ( 10ms ). You can verify timings from logs.
So, here 1000msec conn_interval is applicable after 22 * 10ms = 220ms. This delay can be acceptable.
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.
a. connection interval update to 10msec request sent from slave to master.
b. 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.
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?
Hi 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.