Connection Interval

RE: Connection Interval

Simonr — Mon, 01 Apr 2019 13:15:19 GMT

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

[quote user="Filya"]After the characteristics have been updated for the second time (14: 54: 53: 482), it is possible to read / write from / to the characteristics.[/quote]

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:

Connect to the device.
Start service discovery from the phone.
When this is completed, enable notifications on the characteristic you want to use.
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

RE: Connection Interval

Filya — Mon, 01 Apr 2019 12:35:47 GMT

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).

RE: Connection Interval

Simonr — Mon, 01 Apr 2019 10:53:30 GMT

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

RE: Connection Interval

Filya — Mon, 01 Apr 2019 08:49:47 GMT

The principle of the project, which I do this: on the peripheral side are sensors. The device itself sleeps and wakes up at a certain interval, connects to the central device to transmit the values received from the sensor, and then falls asleep again. The central device is a smartphone (with Android OS).

Since the peripheral device is battery powered, it is necessary to reduce power consumption and time of reception / transmission. When I began to look more closely at the time of connecting and transferring data, I saw the situation that I described earlier.

Since the connection takes from 800 ms to 1300 ms, which was shown earlier, depending on the Bluetooth module (or something else depends on), I need to know whether this time can be reduced or not.

The code changes in the example ble_app_cscs were not. The situation with the time spent on the connection is the same in this example, and in my main project.

RE: Connection Interval

Simonr — Fri, 29 Mar 2019 09:00:02 GMT

I think I have lost track on what exactly you are trying to achieve here. Sorry about this, but could you explain to me once more, where you are in your project now, and what it is exactly you want to achieve. If you have done any changes to your code since the last one you sent me, please attach an updated version of your code as well.

Best regards,

Simon

RE: Connection Interval

Filya — Thu, 28 Mar 2019 14:57:42 GMT

I'm not sure if this is due to when notifications are enabled. After talking with his colleague, he says that he sends a request for notification as soon as the connection is established. In this case, I see the same delay (~ 800 ms) as your example, where I do not even send a request for notification.

I also noticed this feature. I also used Xiaomi Redmi Note 6 Pro phones (with Bluetooth module 5.0) and Huawei P Smart (with Bluetooth module 4.2). The delay in applying Huawei is ~ 800 ms. Delay when using Xiaomi (with Bluetooth module 5.0) - ~ 1400 ms. Since the phone with Bluetooth module 5.0 I only have this model and other models don't have, then perhaps this is an isolated case. But if not, then module 5.0 has even more delay, with the fact that data transfer is faster.

In my project it is very critical that so much time is spent on the connection, since Frequent falling asleep is expected. With such a time there will be a great expenditure of energy. The future device will be battery powered.

Xiaomi Redmi 5+; project: ble_app_cscs; application on Android: nrf Connect.

Xiaomi Redmi Note 6 Pro; project: ble_app_cscs; application on Android: nrf Connect.

RE: Connection Interval

Simonr — Wed, 27 Mar 2019 09:01:04 GMT

Is seems like you are missing the point here. If you want to reduce the time it takes from connection until you have transferred your data, you will need to enable notifications from the phone as soon as you connect. This has nothing to do with the connection parameters update. You should leave the connection parameter readings be, as this is not the reason you are seeing the delay in data transfer.

Best regards,

Simon

RE: Connection Interval

Filya — Tue, 26 Mar 2019 15:20:03 GMT

I used the mentioned function to disconnect after 2 switches. This was done to display the total time spent on establishing a normal connection.

I removed this function and set the times of the connection connection, as you said. But the number of connections and elapsed time remained the same.

I slightly changed the connection time measurement for each connection and now it shows how long it takes for each switch.

I'll post the main.c file so that we can see what has been changed.

devzone.nordicsemi.com/.../6076.main.c

Below is the result with the above changes. The time is in ms.

RE: Connection Interval

Simonr — Tue, 26 Mar 2019 09:32:19 GMT

Sorry for the late reply, but I have finally had time to look at your project. First of all, the reason for the disconnects are because you set your application to disconnect if the connection parameters are above 7.5 ms with this line of code:

if (max_int_upd > 6) 
    {
      err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gattc_evt.conn_handle,
                                       BLE_HCI_REMOTE_DEV_TERMINATION_DUE_TO_LOW_RESOURCES);
      APP_ERROR_CHECK(err_code);

And I am sorry for confusing you earlier, as I neglected the fact that Android devices have a minimum connection time of at least 15ms (iPhones at 30ms). So you should get rid of this function all together, unless you want it to disconnect every 5 seconds after starting reading.

It is not the connection event itself that takes time, it seems to be on the central application side. You said your colleague had made an application right. The delay you are experiencing is from the time you connect to the central, until it starts the CSC event. I am guessing that doesn't happen immideately as you connect.

You should also tune the min_conn_interval and max_conn_interval, as the project you sent me defined these as 500 and 1000, which means that your peripheral wants to use between 500 and 1000 ms to connect. I suggest you set them to the following:

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(7.5, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(30, UNIT_1_25_MS)

to make it work on both iPhones and Android, as well as removing the function mentioned above that causes disconnects. I hope this was helpful, and if you have any further questions, just ask!

Best regards,

Simon

RE: Connection Interval

Filya — Fri, 22 Mar 2019 14:03:38 GMT

I am sending you a project, the results of which were demonstrated in my last message. The situation shown in the last post is the same for both my main project and the example.

devzone.nordicsemi.com/.../1121.ble_5F00_app_5F00_cscs.rar

RE: Connection Interval

Simonr — Fri, 22 Mar 2019 08:48:06 GMT

I think for me to help you, you will have to send me your project, so I can see exactly how your project is set up. If you don't want to share it on the forum I can set this case to private, so only you and Nordic engineers can see it. Just say the word and I'll do it before you upload the project.

Best regards,

Simon

RE: Connection Interval

Filya — Thu, 21 Mar 2019 12:54:46 GMT

Specifically, the disconnection in the BLE_GAP_EVT_CONN_PARAM_UPDATE event does not occur, since the sd_ble_gap_disconnect function is not called anywhere. Perhaps there is a restart function or some similar, perhaps it is called.

I checked the reason of the shutdown in the BLE_GAP_EVT_CONN_PARAM_UPDATE and BLE_GAP_EVT_DISCONNECTED events. In the first option, disconnection occurs when I click the "Disconnect" button in the nRF Connect application. In the second option, the disconnection occurs when the second reconnection occurs.

1 option:

Reasons:

0x06 - BLE_HCI_STATUS_CODE_PIN_OR_KEY_MISSING

0x27 - Requested QoS Not Supported (in file ble_hci.h this definitions commented out)

0x1E - BLE_HCI_STATUS_CODE_INVALID_LMP_PARAMETERS

0x13 - BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION

2 option:

Reasons:

0x06 - BLE_HCI_STATUS_CODE_PIN_OR_KEY_MISSING

0x27 - Requested QoS Not Supported (in file ble_hci.h this definitions commented out)

0x16 - BLE_HCI_LOCAL_HOST_TERMINATED_CONNECTION

RE: Connection Interval

Simonr — Thu, 21 Mar 2019 11:39:02 GMT

Seeing as you have multiple connection events, there will have to be some disconnect event as well somewhere. Could you try to write the disconnect reason by using p_ble_evt->evt.gap_evt.disconnected.reason so we can see why your application disconnects the first time around. This function uses the definitions stated in ble_hci.h

Best regards,

Simon

RE: Connection Interval

Filya — Thu, 21 Mar 2019 08:17:23 GMT

Yes, I tried using the ble_app_cscs example. It works correctly. The modification consisted only in adding code to find out the number of reconnections and their parameters.

About the address. The type of address I have is BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE, therefore the address does not correspond to the central device and changes periodically.

Regarding the number of reconnections and changes in the value of the connection interval. As stated in the comments here, in the current versions of the android, the connection algorithm is laid, first with a connection interval of 7.5 ms, and after that, the connection is already with parameters supported by both devices.

RE: Connection Interval

Simonr — Wed, 20 Mar 2019 08:38:29 GMT

So did you at any point try with an unmodified ble_app_cscs example, the nRF52832DK board, and the nRFConnect application?

It seems very strange that multiple connection events occur. Are you sure you are connecting to the intended device? Can you look at the connection event and find which address you are connecting to? This should be possible by using p_ble_evt -> evt.params.connected.peer_addr.addr[i].

Best regards,

Simon

RE: Connection Interval

Filya — Tue, 19 Mar 2019 11:36:33 GMT

Did you check the return values from sending the notifications (or start sending data function).

I checked the return value and the result was NRF_SUCCESS.
I also want to clarify that the transfer of useful data itself does not lead to this error. As I showed in the ble_app_cscs example, several connections occur during the establishment of a connection between two devices. After that, you can already freely send and receive data.

It is the central that decides the connection interval on connection, not the peripheral, so it will be 7.5ms when first connecting

From my point of view, it seems a bit strange that the central device gives out 7.5 ms by the first attempt, whereas everywhere it is described that android applications need at least 15-20 ms.

I think the reason of your delay might be that you haven't enabled notifications correctly. You will have to do this from your central (phone). How and when do you do this?

Indeed, I use a third-party application that my colleagues write. Perhaps they need to make some more adjustments.
But I want to note that the last example I gave in the last message (screenshot from the terminal) was made on the nRF52832 DK board with a modified ble_app_cscs example, which I also posted. And I checked the operation of the peripheral application using the nRF Connect application.

Thank you in advance

RE: Connection Interval

Simonr — Tue, 19 Mar 2019 10:10:43 GMT

[quote user="Filya"]If I understand you correctly, you are proposing to start sending data right away when I get into the BLE_GAP_EVT_CONNECTED event. I tried to do this and the result did not change.[/quote]

Did you check the return values from sending the notifications (or start sending data function).

[quote user="Filya"]Tell me, is this possible? I just have no more options, why I always see the connection interval = 7.5 ms when I first try to connect.[/quote]

It is the central that decides the connection interval on connection, not the peripheral, so it will be 7.5ms when first connecting.

I think the reason of your delay might be that you haven't enabled notifications correctly. You will have to do this from your central (phone). How and when do you do this?

Also what app are you using on your phone? I suggest using the nRFConnect app if you aren't already.

Best regards,

Simon

RE: Connection Interval

Filya — Mon, 18 Mar 2019 16:09:48 GMT

If I understand you correctly, you are proposing to start sending data right away when I get into the BLE_GAP_EVT_CONNECTED event. I tried to do this and the result did not change.

I have an assumption that the first connection interval is always set to 7.5 ms. Perhaps during the first attempt, the peripheral device substitutes the ideal value of the connection interval to check if it is possible or not. After that, the central device rejects this value and sends back its values for the connection interval at which a stable connection of two devices already occurs.
Tell me, is this possible? I just have no more options, why I always see the connection interval = 7.5 ms when I first try to connect.

Concerning the timer and in general the way of counting time. I'll post the main file from the cscs example, where the timer is set up and everything else to display this problem.

devzone.nordicsemi.com/.../05355.main.c
I want to clarify about the part of the code that is described in the BLE_GAP_EVT_CONN_PARAM_UPDATE event.

    if (max_int_upd > 6) 
    {
      err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gattc_evt.conn_handle,
                                       BLE_HCI_REMOTE_DEV_TERMINATION_DUE_TO_LOW_RESOURCES);
      APP_ERROR_CHECK(err_code);
    }

I make the disconnection in this way, because it is during the second connection that a stable connection occurs and you can already begin to transfer data. Just during the shutdown, I clearly observe how much time it takes to complete the connection.
If disconnection is not done, then another 3 reconnections occur with the parameters of the connection interval equal to 997.5 ms.

The time obtained using the timer, I also observe with an oscilloscope, so the time display is correct.

I experimented with chips BT840F (analog nRF52840) and nRF52832 (on nRF52832 DK) and an example of ble_app_cscs. The results were getting exactly the same.

Below is the result that I did on nRF52832:

Thank you in advance

RE: Connection Interval

Simonr — Fri, 15 Mar 2019 11:42:50 GMT

Can you try to start sending data immediately after ble_evt_connected? You will likely get NRF_ERROR_INVALID_STATE in the beginning, but just keep trying until you get NRF_SUCCESS. This means that notifications aren't enabled, or that ATT_MTU exchange is running. It should not be necessary to wait until conns_params_update to send data.

[quote user="Filya"]Only with the following parameters data is received.[/quote]

What following parameters are you referring to?
Yes, the time_conn are timers, but where in your code have you defined them/their values?

Best regards,

Simon

RE: Connection Interval

Filya — Thu, 14 Mar 2019 11:24:41 GMT

About the logs. If I understand you correctly, on the side of the smartphone I am not getting at the moment. Only in the manner described above, I get a report.

"Also, why are you waiting to transfer data until you get the last conn_params_update event? That shouldn't be necessary."

The last event I do not expect. As soon as I get to the BLE_GAP_EVT_CONN_PARAM_UPDATE event, I immediately start the data transfer. Due to the fact that for the first time the time interval parameters are set to 7.5 ms, the data does not come to the phone. Only with the following parameters data is received.

About time_conn [0-3]. I set up a timer at 1 ms intervals and start it when the peripheral device wakes up.

RE: Connection Interval

Simonr — Thu, 14 Mar 2019 09:50:24 GMT

Having some trouble recreating this. Are these logs when connecting to your phone or to the other nRF chip you have? Also, why are you waiting to transfer data until you get the last conn_params_update event? That shouldn't be necessary.

I also have a question about your code snippet. Where does the time_conn [0-3] come from?

Best regards,

Simon

RE: Connection Interval

Filya — Wed, 13 Mar 2019 13:28:03 GMT

I use the example - ble_app_cscs

SDK: nRF5_SDK_15.2.0

RE: Connection Interval

Simonr — Wed, 13 Mar 2019 13:18:09 GMT

What source code did you use? Was it one of the SDK example projects, in that case which one? This way I can try to recreate the problem.

Best regards,

Simon

RE: Connection Interval

Filya — Wed, 13 Mar 2019 10:09:16 GMT

Updated 1 image

RE: Connection Interval

Filya — Wed, 13 Mar 2019 09:59:13 GMT

I set MIN_CONN_INTERVAL = 11.25 ms and it did not give results. Also, the first time it hits the BLE_GAP_EVT_CONN_PARAM_UPDATE event, it shows 7.5 ms.

As for the demonstration, the following is the event handler code:

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
  ret_code_t err_code = NRF_SUCCESS;
  
  gap_evt_1 = p_ble_evt->header.evt_id;
  
  switch (p_ble_evt->header.evt_id)
  {
  case BLE_GAP_EVT_DISCONNECTED:
    {
      NRF_LOG_INFO("Disconnected.");
      app_timer_stop(m_our_char_timer_id);
      time_conn[3] = time_conn[0] - (time_conn[1]+time_conn[2]);
      time_conn[0] = 0;
      NRF_LOG_INFO("CONNECTED = %d, CONN_PARAM_UPDATE = %d, DISCONNECTED = %d", time_conn[1], time_conn[2], time_conn[3]);
    } break;
    
  case BLE_GAP_EVT_CONNECTED:
    {
      NRF_LOG_INFO("Connected.");
      err_code = bsp_indication_set(BSP_INDICATE_CONNECTED);
      APP_ERROR_CHECK(err_code);
      
      min_int = p_ble_evt->evt.gap_evt.params.connected.conn_params.min_conn_interval;
      max_int = p_ble_evt->evt.gap_evt.params.connected.conn_params.max_conn_interval;
      NRF_LOG_INFO("Min int = %d, Max int = %d", min_int, max_int);     
      
      m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
      err_code = nrf_ble_qwr_conn_handle_assign(&m_qwr, m_conn_handle);
      APP_ERROR_CHECK(err_code);
      
      time_conn[1] = time_conn[0];
    } break;
    
  case BLE_GAP_EVT_CONN_PARAM_UPDATE:
    {  
      
      min_int_upd = p_ble_evt->evt.gap_evt.params.conn_param_update.conn_params.min_conn_interval;
      max_int_upd = p_ble_evt->evt.gap_evt.params.conn_param_update.conn_params.max_conn_interval;
      slave_conn_upd = p_ble_evt->evt.gap_evt.params.conn_param_update.conn_params.slave_latency;
      conn_sup_upd = p_ble_evt->evt.gap_evt.params.conn_param_update.conn_params.conn_sup_timeout;
      
      NRF_LOG_INFO("Min int upd = %d, Max int upd = %d, Slave latency = %d, Conn sup time = %d", min_int_upd, max_int_upd, slave_conn_upd, conn_sup_upd);
      app_timer_start(m_our_char_timer_id, OUR_CHAR_TIMER_INTERVAL, NULL);
      if (disc_evt == 0)
      {
        NRF_LOG_INFO("start conn"); 
        time_conn[2] = time_conn[0] - time_conn[1];
      }
    } break;
    
  case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
    {
      NRF_LOG_DEBUG("PHY update request.");
      ble_gap_phys_t const phys =
      {
        .rx_phys = BLE_GAP_PHY_AUTO,
        .tx_phys = BLE_GAP_PHY_AUTO,
      };
      err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
      APP_ERROR_CHECK(err_code);
    } break;
    
  case BLE_GATTC_EVT_TIMEOUT:
    {
      // Disconnect on GATT Client timeout event.
      NRF_LOG_DEBUG("GATT Client Timeout.");
      err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gattc_evt.conn_handle,
                                       BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
      APP_ERROR_CHECK(err_code);
      break;
      
    case BLE_GATTS_EVT_TIMEOUT:
      // Disconnect on GATT Server timeout event.
      NRF_LOG_DEBUG("GATT Server Timeout.");
      err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gatts_evt.conn_handle,
                                       BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
      APP_ERROR_CHECK(err_code);
    } break;
    
  default:
    // No implementation needed.
    break;
  }
}

And a screenshot from the terminal:

1) The parameters of the minimum and maximum interval of the connection event recorded at the time of contact with the event BLE_GAP_EVT_CONNECTED.
2) The parameters of the minimum and maximum interval of the connection event recorded at the time of contact with the event BLE_GAP_EVT_CONN_PARAM_UPDATE. Here it is clear that there were 2 hits in this event with different parameters.
3) Here are the times in ms. The time is shown from the moment the device woke up and hit every event (BLE_GAP_EVT_CONNECTED, BLE_GAP_EVT_CONN_PARAM_UPDATE, BLE_GAP_EVT_DISCONNECTED).

The parameters of the minimum and maximum interval, which I set:

#define MIN_CONN_INTERVAL   MSEC_TO_UNITS(11.25, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL   MSEC_TO_UNITS(12, UNIT_1_25_MS)
#define SLAVE_LATENCY       1
#define CONN_SUP_TIMEOUT    MSEC_TO_UNITS(350, UNIT_10_MS)

I also decided to check on the source code of the example, which I took as a basis. The results are similar, just a few occurrences.

1 option:

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(500, UNIT_1_25_MS)  
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(1000, UNIT_1_25_MS)           
#define SLAVE_LATENCY                   0                                          
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)

2 option:

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(48.75, UNIT_1_25_MS)           
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(1000, UNIT_1_25_MS)           
#define SLAVE_LATENCY                   0                                          
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)