Connection Interval

[Filya]

Hi everyone,

I'm new to working with Bluetooth/

My problem is that the connection interval time sent by the central device does not converge with the time I see using an oscilloscope or a configured timer for 1 ms.
The principle of operation of my program is that the peripheral device sleeps for a certain time and wakes up at a specified interval. The central device at this time is trying to connect to it. Using the timer, I count the time from when the device woke up to the time of the BLE_GAP_EVT_CONNECTED event and to the time of the BLE_GAP_EVT_CONN_PARAM_UPDATE event. The time difference between these events is about 600 ms. I can not understand why such a difference in time. Maybe I did not correctly understand the meaning of the parameters MIN_CONN_INTERVAL and MAX_CONN_INTERVAL? If so, then how can you reduce the time for a full connection, so that the BLE_GAP_EVT_CONN_PARAM_UPDATE event occurs as soon as possible.

To check what the actual value is transmitted by the central device, you can make a breakpoint during the execution of the program at the time of the BLE_GAP_EVT_CONN_PARAM_UPDATE event, which I actually did.

According to the received data, the central device set the value of the maximum and minimum interval of 7.5 ms.In the peripheral device, I have the following parameters:

MIN_CONN_INTERVAL    MSEC_TO_UNITS (7.5, UNIT_1_25_MS)

MAX_CONN_INTERVAL   MSEC_TO_UNITS (30, UNIT_1_25_MS)

SLAVE_LATENCY            1

CONN_SUP_TIMEOUT   MSEC_TO_UNITS (250, UNIT_10_MS)

I also read that the connection interval can vary from 7.5 ms to 4 s, maybe this value is the connection interval for my central device?

Chip: BT840F (analog nRF52840);

SDK: nRF5_SDK_15.2.0;

Softdevice: s132_nrf52_6.1.0_softdevice;

Phone: Xiaomi Redmi 5+.

Thanks in advance for your help.

[Simonr]

Hi

I see that you stated in your original question that you are using the s132 SoftDevice. This is not a compatible SoftDevice for the 840 products, I am sorry I didn't catch this before now, but you should switch to the s140 SoftDevice. This is probably the reason you are experiencing delays of this degree. I am surprised it is working at all.

Best regards,

Simon

[Filya]

I am using s140 SoftDevice, in this respect everything is correct. I just have another nRF52832 DK board, and for it I used s132 SoftDevice

[Simonr]

Very well, it was worth a shot.

Filya said:

If the MAX_CONN_PARAMS_UPDATE_COUNT parameter is set to 0, then there will be no re-entry, but the client will also not receive the data. I suppose that this is related to the necessary, central device, connection interval. At the first entry, it always sets 7.5 ms (read with p_ble_evt-> evt.gap_evt.params.conn_param_update.conn_params.max_conn_interval). When re-entering exposes 11 ms and apparently this time is satisfactory for the transfer of the data packet.

 I am having trouble understanding what exactly you mean here, could you try rephrasing? 

Next, are you saying that the PARAM_UPDATE event is running twice in a row before sending any packets? That seems very strange, and do you really mean 800ms? Wasn't the initial delay of 49ms? 

As I stated earlier the reason your central device (The Xiaomi phone right?) is not obligated to use the connection parameters your peripheral wants to use, which is why it doesn't happen.

Best regards,

Simon 

[awneil]

Simonr said:

are you saying that the PARAM_UPDATE event is running twice in a row

ISTR that Android does not like receiving multiple Parameter Update requests - certainly not in quick succession ... ?

[Filya]

I mean that the central and peripheral devices need to spend 2 attempts, in order for the central device to accept the data packet.

If I understand correctly, with the help of p_ble_evt-> evt.gap_evt.params.conn_param_update.conn_params.max_conn_interval in the BLE_GAP_EVT_CONN_PARAM_UPDATE event we see what value of the connection interval was sent by the central device. If this is the case, then the central device initially sets 7.5 ms and this time is not enough for the central device to receive the packet. At the second attempt it exposes 11.25 ms and then the central device receives the packet.

I do not understand why 7.5 ms was initially set. I set the values ​​MIN_CONN_INTERVAL = 7.5 ms, MAX_CONN_INTERVAL = 12 ms. That is, the second value is in the range of the connection interval time that I set.

About 800 ms. After the BLE_GAP_EVT_CONNECTED event and before the BLE_GAP_EVT_CONN_PARAM_UPDATE event, about 500 ms pass on the first hit, and about 300 ms on the next hit. In total, this gives 800 ms.
About 49 ms. I saw this number with p_ble_evt-> evt.gap_evt.params.conn_param_update.conn_params.max_conn_interval in the BLE_GAP_EVT_CONN_PARAM_UPDATE event, but now I managed to reduce it to the values described above.