This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Connection Interval

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.

Parents
  • Thanks!

    I still don't see why you do the connection parameter update (CONN_PARAM_UPDATE), as that is what takes time in your screenshots. This is not a connection event. There are no screenshots in this thread that shows how much time the initial connection takes. They are all just parameter updates. If you comment this out of your code, are you able to show me that the actual connection takes 800ms, because on my end this never takes more than 30 ms or so with another device, and approx. 200ms with my phone (iPhone 6), which seems to be as fast as this example gets with a mobile device.

    My log in nRFConnect when connecting to another DK:

    12:45:44.835	Connecting to device
    12:45:44.857	Connected to device CD:3D:F1:F2:0C:E0 //The connection event takes 22ms
    Best regards,
    Simon
Reply
  • Thanks!

    I still don't see why you do the connection parameter update (CONN_PARAM_UPDATE), as that is what takes time in your screenshots. This is not a connection event. There are no screenshots in this thread that shows how much time the initial connection takes. They are all just parameter updates. If you comment this out of your code, are you able to show me that the actual connection takes 800ms, because on my end this never takes more than 30 ms or so with another device, and approx. 200ms with my phone (iPhone 6), which seems to be as fast as this example gets with a mobile device.

    My log in nRFConnect when connecting to another DK:

    12:45:44.835	Connecting to device
    12:45:44.857	Connected to device CD:3D:F1:F2:0C:E0 //The connection event takes 22ms
    Best regards,
    Simon
Children
  • Here I provide my screenshots from nRF Connect.

    It turns out that the connection itself took 308 ms (14: 54: 52: 408 - 14: 54: 52: 710). After this, the connection parameters are updated several times in a row. When the announcement of updating connection parameters appears for the first time (14: 54: 53: 047), the characteristics window is not active, reading, recording, etc. is impossible.
    After the characteristics have been updated for the second time (14: 54: 53: 482), it is possible to read / write from / to the characteristics.
    It turns out that all the time, from the beginning of the connection to the ability to read the characteristics, is 1074 ms (14: 54: 52: 408 - 14: 54: 53: 482).

  • Hi

    This is more like it, some data to work with!

    Filya said:
    After the characteristics have been updated for the second time (14: 54: 53: 482), it is possible to read / write from / to the characteristics.

    How do you want to read/write? Do you want to use notifications? This is possible after you have enabled notifications from the nRF to the phone, and here is the simplest way to do that:

    1. Connect to the device.
    2. Start service discovery from the phone.
    3. When this is completed, enable notifications on the characteristic you want to use.
    4. Send notifications from the nRF to the phone.

    Again, this has nothing to do with the connection parameter updates, which just uses time in your application and are disruptive when you want to minimize current consumption.

    Best regards,

    Simon

Related