want to know how can i judge that the variation is caused in the connection interval, connection supervision timeout, slave latency once i have flashed ble_app_template code in nrf52832 s132.
want to know how can i judge that the variation is caused in the connection interval, connection supervision timeout, slave latency once i have flashed ble_app_template code in nrf52832 s132.
Hello again,
Ridhi said:as soon as click on connect button on nrf connect app on mobile it shows a CI of about 50ms and then when my timeout expires say 1second then the connection parameters are updated to what ever value i preffred.
Great - I am happy to hear that you are able to achieve the desired Connection Interval. If you would like this to happen faster you could reduce the timer used to send the request.
Ridhi said:Query: how initially this 50ms Connection Interval it is taking? i found the same in nordic bliky code also. Is that this duration is set by nrf connect and later that when peripheral sends request fro update of connection parametres it takes those values which i have set ie 500ms
Yes, as mentioned it is ultimately the central that decides the connection interval, which means that it does not matter what you configure on your peripheral device, or which peripheral example you are using - the central is still the one that decides.
However, the nRF Connect application is made to accept the connection parameter update requests from the peripherals.
The Connection Interval used before the first connection parameter update request is set in the central's code.
Best regards,
Karl
#define SLAVE_LATENCY 0 /**< Slave latency. */
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS) /**< Connection supervisory time-out (4 seconds). */
from definition i found
Slave latency: If the peripheral does not have any data to send, it can skip connection events, stay asleep, and save power.
Max set to 32 seconds: How to understand this i am not getting? pls tell how can visualize these
Slave latency is the number of times the peripheral might opt to not communicate during a connection event without breaking connection.
Normally, the a peer will terminate the connection if it no longer hears anything from its connected device. Slave latency lets the peripheral device decide whether it has any new data that needs transferring, or if it can skip the upcoming connection event.
Skipping a (or multiple) connection events saves power that otherwise would have gone to powering up the radio and sending an empty packet to the central just to maintain the connection. So, with a slave latency of 5 and a connection interval of 10 ms, the peripheral would only need to send an empty packet once per 50 ms instead of every 10 ms, to maintain the connection, if it has no data to transfer.
Connection supervision timeout is the time that a peer will wait before terminating the link. If you have a Connection supervision timeout of 4 seconds, a device will stay in the connection for 4 seconds after the peer stops replying, to see if the peer comes back. If it does not, the connection is terminated and the device may restart advertising or scanning again.
Best regards,
Karl
Yes Karl i understand these terminologies but i am failing to get that how this can be inferred?
Like when i say set connection supervision timeout as 4secs, does it mean that as i click on connect on nrf connect app after 4 secs then the devices get unconnected? however, nothing like that happened whenn i ran the code and checke don nrf connect app.
Also, say i have nordic blinky code which display led and button two services...in this how slave latency will work i dont get?
Ridhi said:Yes Karl i understand these terminologies but i am failing to get that how this can be inferred?
What do you mean by this - what are you having trouble inferring from the documentation?
Ridhi said:Like when i say set connection supervision timeout as 4secs, does it mean that as i click on connect on nrf connect app after 4 secs then the devices get unconnected? however, nothing like that happened whenn i ran the code and checke don nrf connect app.
No, the supervision timeout only comes into play when a peer stops responding.
If you would like to see how this looks you could set up the sniffer tool by having the sniffer follow into a connection, and then shut off one of the devices in the connection.
The other device will then continue to send packets to try and maintain the connection - in hopes that the peer will return before the supervision timeout occurs. When the supervision timeout occurs the other device will stop sending these packets, and terminate the link in its program.
This means that your program will not resume advertising / unconnected-behavior before the supervision timeout has occurred, in the case that a peer stops responding.
Ridhi said:Also, say i have nordic blinky code which display led and button two services...in this how slave latency will work i dont get?
Sure, this is a good example to demonstrate slave latency. Again, you could see this in practice by using the Sniffer tool to follow into the connection, and monitor the packets being transferred back and forth between the devices with and without slave latency.
In the case with 0 slave latency the BLE blinky devices will transfer a packet to each other each connection event, even though there is no new button state to communicate. This means that every 100 ms the two will exchange empty packets, just to maintain the connection.
If you add slave latency here, the peripheral device may then choose to not turn on its radio when a connection event is upcoming, because it sees that itself has no new information to send compared to the previous connection event. This will save the peripheral power, since it does not need to spend power to send and receive empty packets with the central.
However, in this case, the central will have no way of letting the peripheral know if a button is pressed on the central side, so you will then suddenly see a one-way delay between the central's LED lighting up, and the peripheral - since the peripheral is not turning on its radio to listen for the central's messages.
So, adding slave latency to the BLE Blinky application will actually degrade its performance, since the peripheral will not closely follow the central's led.
In the case that the peripheral was the only one sending data to the central (and the central never sending anything with a time-constraint back), slave latency would be fine to add.
Does this make things more clear?
Best regards,
Karl