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?
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
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
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
with above configuration i get many log values and logging continues:
but with 
after 16 logs nothing happens and logs stop without any error but in power profiler i saw that logging stopped after 16 values
no value after 16 logs
Karl pls look into at earliest
Please share logs using the Insert -> Code -> Text option rather than sharing screenshots of the logs. Proper formatting drastically increases readability and thus makes debugging easier.
Please also show me the log for the scenario in which the application seemingly stops after 16 logs.
Have you run a debugging session and checked out if the program counter gets stuck anywhere following the 16'th logging?
Please see my previous comment about the sniffer.
Could you capture a sniffer trace of these two scenarios in addition to the logs?
Best regards,
Karl