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?
Ok Karl i got to understand about the above discussion about connection interval.
I tried to understand your comment and discussion about supervision timeout but i am not able to understand. Eg: say i have nordic blinky code and i set the supervision timeout as 4 secs. i am not getting what and how this we can see its effect on nrf connect app.
i have slave latency of 0 say, in nordic blinky code there are two services: button and led. how will pheripheral know that it has no data to send so it sets the slave latency.
i am very much confused inunderstanding
Ridhi said:i have slave latency of 0 say, in nordic blinky code there are two services: button and led. how will pheripheral know that it has no data to send so it sets the slave latency.
I am sorry to hear that, RIDHIMA. Please do not hesitate to ask if any part of my answer should be unclear, so that I may elaborate.
Ridhi said:say i have nordic blinky code and i set the supervision timeout as 4 secs. i am not getting what and how this we can see its effect on nrf connect app.
The simplest explanation of the connection supervision timeout is: "It is how long will the device attempt to contact a peer that has stopped responding"
So, if you have 4 s supervision timeout on your peripheral, and you are in connection with a nRF Connect central. If the central stops responding to the peripheral (they both expect to exchange a packet at least for once every connection interval) such as if it leaves the area, or goes into an elevator or similar, they will both still try to communicate with each other for each passing connection interval - in hopes that they will hear from each other again, and continue the connection. The connection supervision timeout tells them how long they should keep trying to reach the peer that is no longer responding.
When a connection is terminated the devices will usually go back into either scanning or advertising so that they can find a new connection. This will not happen until the connection supervision timeout has expired., because both devices still consider the connection as working so long as it has not expired (even though they do not hear anything from their peer).
Ridhi said:how will pheripheral know that it has no data to send so it sets the slave latency.
The peripheral can know this by checking the contents of the packet it intends to send in the upcoming connection event.
If the packet is empty and the slave latency is > 0 it can skip the upcomming connection event. If the packet is non-empty (contains data) it should transmit during the event.
Best regards,
Karl
Hello Karl
I have a ble nrf52832 dev kit. I have interfaced flash and temp sensor STTS with it. I am using it for temp data logging. I have intially set the connection parameters as:
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(7.5, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(100, UNIT_1_25_MS)
#define SLAVE_LATENCY 0
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(9000, UNIT_10_MS) /
#define FIRST_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(5000)
#define NEXT_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(3000) /
#define MAX_CONN_PARAMS_UPDATE_COUNT 3
I press a button my device advertsises
then i connect using nrf connect app
.Created a custom service ,
press button deevice goes to logging mode and gives abot 20 logs for 10 mins say.
then i again press button to put device in sleep mode
then again press button to re advertise and connect on app
then enable notification of the created service and then read the temp logs.
with above connection parameters i am able to get the logs but when i set the values for power optimization as:
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS)
#define SLAVE_LATENCY 0
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(9000, UNIT_10_MS) /
#define FIRST_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(5000)
#define NEXT_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(3000) /
#define MAX_CONN_PARAMS_UPDATE_COUNT 3
i am only able to get 4 logs just for 1 min and then my system is going to sleep state instead of giving logs
It is hard for me to say anything about what might be going on here, from your description alone. Is there any errors occurring when you use the 1000 ms connection interval? Does the device reset unexpectedly?
I would think that you might get buffer overflows etc when increasing the connection interval by this much, if you have not also made changes to your sensor-data buffer sizes.
Have you verified that the connection interval being used is actually 1000 ms?
Best regards,
Karl
yes i have verified this infact i also did with
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(4000, UNIT_1_25_MS) /**< Minimum acceptable connection interval (0.5 seconds). */
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(4000, UNIT_1_25_MS) /**< Maximum acceptable connection interval (1 second). */
#define SLAVE_LATENCY 1 /**< Slave latency. */
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(16010, UNIT_10_MS) /**< Connection supervisory time-out
as told by you. still it is giving same issue
but with values as 7.5-100 ms it works fine
yes i have verified this infact i also did with
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(4000, UNIT_1_25_MS) /**< Minimum acceptable connection interval (0.5 seconds). */
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(4000, UNIT_1_25_MS) /**< Maximum acceptable connection interval (1 second). */
#define SLAVE_LATENCY 1 /**< Slave latency. */
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(16010, UNIT_10_MS) /**< Connection supervisory time-out
as told by you. still it is giving same issue
but with values as 7.5-100 ms it works fine
Please be specific - which issue do you refer to when you say 'same issue'?
Is it the issue you described in your previous comment, where the buttonpress does not produce the expected logs, or is it the issue you had before with being unable to set the desired connection parameters? The former sounds like an application logic issue, and the latter sounds like a configuration issue.
Could you also elaborate how you verified that the connection interval was actually 1000 and 4000 ms?
Best regards,
Karl
1). 'same issue' : is the issue i described in my previous comment, where the button press does not produce the expected logs when connection interval was 1000.
2). when i had set to 7.5-100ms the current between logs was
556.76 µA
but when connection interval was 1000ms it increased to
685.85 µA
why is the current between logs increasing?
3). i didnt get what is the overflow you meant bcz with 7.5-100ms i am able to get many logs but not with changing interval to 1000ms
Ridhi said:1). 'same issue' : is the issue i described in my previous comment, where the button press does not produce the expected logs when connection interval was 1000.
Thank you for specifying.
Ridhi said:2). when i had set to 7.5-100ms the current between logs was
556.76 µA
but when connection interval was 1000ms it increased to
685.85 µA
why is the current between logs increasing?
It is hard for me to speculate about this without seeing the current code.
However, this might be another symptom of the issue you are seeing with the missing / less-than-expected logging. I suggest that we focus on resolving this issue first, so that we potentially does not spend time debugging a symptom that may go away when we resolve the root issue.
Ridhi said:3). i didnt get what is the overflow you meant bcz with 7.5-100ms i am able to get many logs but not with changing interval to 1000ms
What I meant is that there might be an overflow in your buffers if you change the connection interval from 7.5 ms to 1000 ms unless you have taken specific actions to accommodate for the increase in time between transfers.
For example, if you have a sensor you are reading from every 15 ms, that would mean 1 buffered packet between every other connection event. If you then change to 1000 ms connection interval, you will suddenly buffer 67 packets between each connection event. If the connection interval is the only thing that you have changed, there might be issues with the buffers overflowing when you make this change.
Again, this is just speculations on my part, since I have not actually seen the code in its current state.
Please also see my other previous questions:
Karl Ylvisaker said:Could you also elaborate how you verified that the connection interval was actually 1000 and 4000 ms?
Karl Ylvisaker said:Is there any errors occurring when you use the 1000 ms connection interval? Does the device reset unexpectedly?
Best regards,
Karl
Could you also elaborate how you verified that the connection interval was actually 1000 and 4000 ms?
ans: as suggested by you i had set :
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS)
and next time as:
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(4000, UNIT_1_25_MS) /**< Minimum acceptable connection interval (0.5 seconds). */
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(4000, UNIT_1_25_MS) /**< Maximum acceptable connection interval (1 second). */
#define SLAVE_LATENCY 1 /**< Slave latency. */
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(16010, UNIT_10_MS) /**< Connection supervisory time-out (4 seconds). */
then i got only 16 logs which rendered sleep afterwards.
However with Connection Interval as:
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(7.5, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(100, UNIT_1_25_MS)
device did not fall to sleep and gave logs continuously
Ridhi said:ans: as suggested by you i had set :
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS)and next time as:
Setting the peripheral's preference is not equal to verifying what connection interval that is actually being used. As mentioned the peripheral may only request an update of the parameters. It does not have any decision making powers over the central.
To verify which connection parameters are used you will either have to have the logger of the peripheral or central output the used connection parameters and updates or use the nRF Sniffer tool to see which interval is actually being used.
Ridhi said:and next time as:
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(4000, UNIT_1_25_MS) /**< Minimum acceptable connection interval (0.5 seconds). */
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(4000, UNIT_1_25_MS) /**< Maximum acceptable connection interval (1 second). */
#define SLAVE_LATENCY 1 /**< Slave latency. */
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(16010, UNIT_10_MS) /**< Connection supervisory time-out (4 seconds). */then i got only 16 logs which rendered sleep afterwards.
Is there anything else unexpected that happens?
Does the device reset? Does anything unexpected appear in the logs you are seeing? Does the central device log anything unexpected?
Saying that you suddenly only see 16 logs does not provide me with any information to debug with.
I am not sure we will be getting anywhere with this until we see a sniffer trace. Could you capture a sniffer trace of these two scenarios, and upload the traces along with the peripheral's logs?
It is hard for me to suggest anything at all from your current description of the issue.
Best regards,
Karl