Bluetooth connection parameters

RE: Bluetooth connection parameters

Joakim Jakobsen — Fri, 10 Nov 2017 08:39:22 GMT

Yes, sometimes that happens.
The reason I linked to the duplicate is to let other people searching the forum for similar issues easily find the information in both cases. That is also the reason we want to avoid duplicate threads.
Best regards.

RE: Bluetooth connection parameters

jon — Wed, 08 Nov 2017 17:25:56 GMT

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!

RE: Bluetooth connection parameters

Joakim Jakobsen — Mon, 06 Nov 2017 12:52:50 GMT

This question has a duplicate.

RE: Bluetooth connection parameters

endnode — Sun, 05 Nov 2017 11:43:58 GMT

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.

RE: Bluetooth connection parameters

endnode — Sun, 05 Nov 2017 11:38:07 GMT

(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:

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.

RE: Bluetooth connection parameters

endnode — Sun, 05 Nov 2017 11:32:38 GMT

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)

RE: Bluetooth connection parameters

jon — Sun, 05 Nov 2017 00:55:18 GMT

I am curious, are the min and max conn intervals how often the central will send a keep alive signal?

RE: Bluetooth connection parameters

jon — Sun, 05 Nov 2017 00:54:47 GMT

oh, i was thinking that those parameters were told to the central at first connection. Could you help me understand the peripheral connection parameters update procedure? This is where I would use FIRST_CONN_PARAMS_UPDATE_DELAY and NEXT_CONN_PARAMS_UPDATE_DELAY, correct?

I would like to try and force the master to accept the parameters so that I can play around and see what parameters will help me experience bluetooth disconnects less often. As it stands I have a central that communicates with two peripherals that tend to move around a bit in the room. I transmit and expect data back every 300 ms or so. Bandwidth is not an issue as I am not sending/receiving a lot of data. I was thinking that I could lower the MIN_CONN_INTERVAL and MAX_CONN_INTERVAL settings and increase the CONN_SUP_TIMEOUT (so that i get less bluetooth disconnects from the windows bluetooth stack).

RE: Bluetooth connection parameters

endnode — Sun, 05 Nov 2017 00:28:56 GMT

No, they are not used when the connection starts because there is simply no way how would Master (Central) know these. They are not broadcasted (no space). However Master can (and should) read them is Peripheral Preferred Parameters Characteristic and Peripheral also can use Peripheral Connection Parameters Update procedure.

I'm afraid the problem here is the perception which leads you to wrong questions. I guess it's safe to say that these parameters are used but that's not saying that you can automatically achieve what you want. Which brigs us to the right question (from my point of view;): what do you want exactly to achieve? Do you want to force Master (Central) to certain connection parameters? Do you want to increase bandwidth? To lower latency? Do you want to achieve that with every peer (another nRFx board, phones, PCs...)? Maybe you fiddle with the thing which won't help you.

RE: Bluetooth connection parameters

jon — Sat, 04 Nov 2017 23:57:42 GMT

The project that was used can be found in the SDK under, examples\ble_peripheral\ble_app_uart. So if I were to modify those parameters, do they get sent to the central and used when the connection is first made? What do you suggest is the best way to figure out whether or not the parameters I am setting are actually being used?

RE: Bluetooth connection parameters

endnode — Sat, 04 Nov 2017 08:27:45 GMT

What project you use? There are like hundred main.c files in SDK;) Normally these constants are indeed used in the code when you recompile and load it to the board so they should be used. The question is what you expect to happen;) Normally there is no debugging on Link Layer on systems like smart phones or Windows boxes so the usual way is to get RF analyzer/sniffer and see what is happening in the air.