Bluetooth connection parameters

[jon]

I am working with nRFx modules and have a few questions about updating parameters. I started my project with an example and modified what I needed. However, I am not sure if the parameters are getting set when I change them. Currently I go into main.c and change the following parameters:

#define MIN_CONN_INTERVAL                          MSEC_TO_UNITS(20, UNIT_1_25_MS)           
#define MAX_CONN_INTERVAL                         MSEC_TO_UNITS(75, UNIT_1_25_MS)           
#define SLAVE_LATENCY                                  0                                         
#define CONN_SUP_TIMEOUT               
#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(5000, APP_TIMER_PRESCALER)  
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(30000, APP_TIMER_PRESCALER) 
#define MAX_CONN_PARAMS_UPDATE_COUNT    3                                
#define TX_POWER_LEVEL                                4      

If I change these parameters, specifically the first three (connection interval, slave latency, and connection supervision timeout), will they automatically be set on with the central? I am currently connecting to a windows 10 device and trying to figure out if the parameters are being updated and if not, why? How would I check to see if they are getting updated?

[endnode]

There is only one interval in BLE link and that's connection interval. Even if no communication happens there are two "empty" PDUs exchanged every interval (unless there is master or slave latency allowed and device takes the opportunity to miss certain interval and follow up later). The main factor for connection loss (if your device stack is implemented correctly!!!) is supervision time-out which cannot be lower then slave latency and simply once any side of the link doesn't receive any PDU ack in that time it should terminate connection immediately (and because there is no one to signal it over the radio it's rather internal process inside the stack and signalling to upper layers if applicable).

Your strategy of lowering connection interval makes sense because it should mean more chances to exchange valid PDU pair which will reset supervision timer. Also lower interval... (1/2)

[endnode]

(2/2) ... should prevent clock drift (even that shouldn't happen for certified HW and stack) so again higher chance that if there is disconnection because of link loss then it's because devices went too far and signals are too weak rather then some technical/SW issue while devices operate in standard range.

When it comes to connection parameters update procedure all I can tell you is on Infocenter:

• From GAP Central side
• From GAP Peripheral side

Unfortunately I'm not familiar with the example you use and FIRST/NEXT CONN_PARAMS_UPDATE_DELAY constants and mechanisms so I cannot advise on these.

[endnode]

Finally I would say that still the truth lives only in the radio so using BLE sniffer or some more expensive radio analyzer would tell you exactly what are connection parameters at the beginning and how different Masters (GAP Central devices) react on simple read of PPCP values from GATT Server or explicit Peripheral Connection Parameters Change procedure. Don't be surprised that if you target mobile phones and similar devices you can see very different behavior starting from proper rejecting to accepting but with several seconds of delay or accepting but not acting accordingly or simply ignoring... so in the end it's quite difficult to fine-tune the application logic to really improve your situation. And basically impossible if you want to have 100% compatibility with all possible centrals. If you target one or few specific devices then it's probably good way.

[Joakim Jakobsen]

This question has a duplicate.

[jon]

yes, joakim, this is an accidental duplicate. However, I am getting helpful information on both copies of the question.

Endnode, thank you so much for all the help. You have set me on a good path!