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,
The best way to see exactly how your connection parameter configuration affects the connection would be to use the nRF Sniffer tool to see exactly what is happening on-air.
Alternatively, if you just would like to play around with different connection parameters to see how each of them affects your connection you could take a look at the experimental ATT MTU throughput example from the SDK.
If you would like to visualize different connection parameter configurations you could take a look at the Online Power Profiler, which will let you see the effects of each configuration on the packet exchanges (as well as estimated power consumption).
Best regards,
Karl
Karl i am finding a difficulty in normal understanding the connection interval thing. Actually, by definition of CI i found it is the time btw two consecutive events for which the radio is turned ON. how can i judge this in nrf connect app?
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
when changed the Connection Interval for 3000ms the device doesnot discover?
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(3000, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(3000, UNIT_1_25_MS)
Is this still you, RIDHIMA?
Please elaborate on what you are asking. The more specific you are, the easier it will be for us to help you.
Do you mean to say that the device does not show up when you scan for it, if you change the peripheral's MIN_CONN_INTERVAL and MAX_CONN_INTERVAL values? These values does not matter to the advertisement or discoverability of the device, so I think that something else might have gone wrong then.
Best regards,
Karl
Yes Karl,
I happened to change :
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(3000, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(3000, UNIT_1_25_MS) in ble_App_template code
but thw the device doesnot show any adevrtising?
Karl, kindly assist
I happened to change :
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(3000, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(3000, UNIT_1_25_MS) in ble_App_template code
but the the device doesnot show any adevrtising?
I wanted to set the Connection interval as either 100/1000/2000/4000ms, how cn this be achieved?
Karl, kindly assist
I happened to change :
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(3000, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(3000, UNIT_1_25_MS) in ble_App_template code
but the the device doesnot show any adevrtising?
I wanted to set the Connection interval as either 100/1000/2000/4000ms, how cn this be achieved?