CC2640R2F: Advertise stops after connecting 2 Bluegiga BLED112 dongle

Hello Niranjan,

Thanks for all the details. I'm going to assign someone to help you.

-Luis

Hi Niranjan,

Thank you for the thorough description! In regards to the multi_role project, there is a predefined symbol MAX_NUM_BLE_CONNS which determines the maximum amount of connections allowed. I'm unsure of if this is still the same within your modified GAP_LINK_ESTABLISHED_EVENT, but in the OOB multi_role within the GAP_LINK_ESTABLISHED_EVENT there is this following piece of code:

        //turn off advertising if no available links
        if (linkDB_NumActive() >= maxNumBleConns)
        {
          uint8_t advertEnabled = FALSE;
          GAPRole_SetParameter(GAPROLE_ADVERT_ENABLED, sizeof(uint8_t), &advertEnabled, NULL);
          Display_print0(dispHandle, MR_ROW_ADV, 0, "Can't adv: no links");
        }

This will check the max number of BLE connections allowed everytime a link is established. If the amount of links reaches the max number of BLE connections, advertising will automatically stop. Your observation of disconnecting a BLED112 and advertising starts again also supports this explanation as disconnecting will free a link allowing for advertising to turn on again.

To verify this is what's occurring, I would search for this piece of code within the application and check the predefined symbol MAX_NUM_BLE_CONNS to see if it's set to 2.

Best Regards,

Jenny

Hi Jenny,

Thanks for the reply. Looks like the MAX_NUM_BLE_CONNS is set to 3 yet the advertisement stops.

Regards,

Mohini

Hi Mohini,

Thank you for this information. I had some additional clarification questions.

- When the multi_role device stops advertising, does it still maintain a connection with the previous devices?

- What is the connection interval with the other devices?

- What role (peripheral or central) does your multi_role serve and what role does your BLED112s serve?

- I saw this observation "We have used mobile phones (BLE 4.1 and above) and other CC2640R2F devices for connection. In these cases everything is working fine." In these cases, were the tests run with 2 mobile phones or 2 CC2640R2F and advertising still persists?

- Do you notice any heap issues occur when you have more than 2 BLED112s connected? Utilizing the HEAPMGR_METRICS predefine symbol can shed more light on this.

- When you have the 2 BLED112s connected, can you look at the connHandleMap variable within multi_role.c and verify the only two connections are the 2 BLED112s?

Best Regards,

Jenny

Hello Jenny,

I am working on the same project, Please find the required info below,

- When the multi_role device stops advertising, does it still maintain a connection with the previous devices?

Yes, it maintains the connection with the previous devices, only the adverstisement gets disabled.

- What is the connection interval with the other devices?
We will get back on this

- What role (peripheral or central) does your multi_role serve and what role does your BLED112s serve?

Multi-role serves the BLE Peripheral role and the BLED112s does the scanning and connection, there by doing the BLE central role

- I saw this observation "We have used mobile phones (BLE 4.1 and above) and other CC2640R2F devices for connection. In these cases everything is working fine." In these cases, were the tests run with 2 mobile phones or 2 CC2640R2F and advertising still persists?
- Combination doesn't matter, all the combinations works fine. i.e. Mobile (M) + CC2640R2F(C) (Cental Role) , M +M, C+C. 

- Do you notice any heap issues occur when you have more than 2 BLED112s connected? Utilizing the HEAPMGR_METRICS predefine symbol can shed more light on this.

This is one of the first tests that we have performed, when we obeserved this issue and observed no heap issues, confirmed the same using the  HEAPMGR_METRICS

- When you have the 2 BLED112s connected, can you look at the connHandleMap variable within multi_role.c and verify the only two connections are the 2 BLED112s

Yes we have confirmed the same.

Please let us know if any additional info is required.

We will get back with the information of the connection intervals used. But I assume this should not have influence, as when using Android Mobile applications where the connection inteval is 7.5ms (the max possible), it works fine and the same is expected to work with the dongles.

Best Regards,
Abhi

Update:

- What is the connection interval with the other devices?

Connection interval in BLE dongle (BLED112)  is 8ms.

But as described, we can maintain stable connection with 3 android/iPhone devices. Android devices have the connection inteval of 7.5 ms and we have faced no issue with them.

Hope it provides all the necessary clarifications to probe the issue, if any additional information is required, we would be glad to share the same.

Best Regards,

Abhi

Hi Abhi,

Thank you for the clarification. I will take a further look at this issue and get back to you as soon as possible. I will also create an internal ticket for the software team to review too to see if they have any input on this issue at hand.

Best Regards,

Jenny

Hi Abhi,

Is there a requirement for that specific connection interval for the BLED112? Just to verify, can you modify the connection interval for the BLED112 to be 30ms to see if this issue still occurs? Thanks!

Best Regards,

Jenny

Hi Jenny,

We have tested with the 30ms connection interval. And the advertisement continues after the two BLED112 connections.

Below observation for the minimal connection interval.

Hi Niranjan,

Thank you for performing these extensive tests and sharing the results. I'm glad to hear that this issue is resolved by increasing the connection interval!

Yes, the smaller the connection interval, the peripheral will have a more difficult time connecting to multiple centrals reliably. As connections take priority over the advertisements, it appears that having a smaller connection interval for both devices is causing the advertisements to stop. The reason why it works for the Android device is because for Android, it will have a connection interval of 7.5s, but then cycles up to 48.75ms which is why it appears that the Android device doesn't cause any issues.

Best Regards,

Jenny

Hi Jenny,

Thanks for the explanations.

But we have done some more exercises, we set the connection interval from the multirole and connected to device under test. And we have seen the advertisements even after the 3 connections (Non connectable after 3 connections is our requirement and expected). Results are tabulated.

Could it be possible to confirm the behavior from your side?

And I have some more questions,

* Can peripheral negotiate the min and max connection interval?

* Can peripheral reject the connections if connection interval is not with in the specified range?

Thanks

Niranjan Hegde

Hello Jenny,

It would be great, if you can answer Niranjan's question.

As we cannot have control over the BLE central's that tries to connect with our device, would it be possible to negotiate the connection interval with the connected client device?

Best Regards,

Abhi

Hi Niranjan,

Thanks for performing this extensive test. I wanted to get some clarification on the results you are seeing. Are you observing:

- After analyzing the table, is it saying that the multi_role is no longer connectable after 3 launchpads connect to multi_role? Since this is expected behavior, I wanted to verify that this is what your tests are displaying and that this isn't the issue.

- Is the issue you're seeing different from the original question? Where advertisements still continue after 3 launchpads have connected when it should've stopped.

I will also attempt to run these tests too to confirm the behavior.

In regards to your questions:

Can peripheral negotiate the min and max connection interval?

The peripheral can send a request, but the central side mandates the connection interval. If the request is rejected, the peripheral can re-send the request again. Both sides should have a range of connection interval values (min and max) though to have a successful negotiation.

Can peripheral reject the connections if connection interval is not with in the specified range?

If the peripheral can't agree on a connection interval, it can terminate the connection.

Best Regards,

Jenny

Hi Jenny,

Thanks for your answers.

We have tested with the multi_role (with our custom application) to see the behavior at the higher connection intervals. As you can see, results are different than the BLED112 connections.  Even with 10-15ms connection interval, device under test could able to connect to 3 devices without issue. Advertisement has not been stopped.

Our application can have maximum 3 connections. And after 3 connections we are enabling non-connectable advertisements. From the table you can see that we are getting non-connectable advertisements. But 10-17.5ms connection interval the advertisement interval is inconsistent.

Your previous answer for the connection interval and advertisement may not completely good with this new tests. So could you please check and confirm?

Also could you please share the more information on connection interval negotiation or link which has these information will also be good.

We will also check on the peripheral negotiation part.

Thanks

Niranjan Hegde

Hi Niranjan,

Thank you for clarifying this. I will perform the tests you have detailed in your previous post and share the test results and any additional information with you as soon as possible.

Best Regards,

Jenny

Hello Jenny,

Thanks a lot for the prompt support here.

Can peripheral negotiate the min and max connection interval?

Can peripheral reject the connections if connection interval is not with in the specified range?

Do we have an example available, which we can take as reference to implement the above functionality?, As we would like to ensure we are not  held by the whims of a BLE central device, which likes to set some unreasonable conneciton interval.

Best Regards,

Abhi

Hi Abhimanyu and Niranja,

I wanted to give an intermediate update on testing. I am currently waiting on launchpads I have ordered as I only had 2 CC2640R2s on hand. I'm waiting for the additional 3 to complete the interval testing as stated by Niranja. I am also currently modifying the connection interval parameters with our current examples to to demonstrate the two functionalities in question: peripheral negotiation and rejection. Once doing so, I will provide you with the specific setup to reproduce these two functionalities to test on. I will try to get these examples to you by mid week and the testing will occur after I receive the launchpads which will be later this week or early next week, thank you for your patience.

Best Regards,

Jenny

Hi Jenny,

Thanks for the update. We will wait for your input.

Hi Niranjan,

When testing the OOTB simple peripheral and simple central together, the default connection parameter update setting for peripheral is GAPROLE_LINK_PARAM_UPDATE_WAIT_REMOVE_PARAMS which will allow for the peripheral to wait for a parameter update request and respond with the remote's (central) requested parameters. Due to this, even if the minimum and maximum connection interval range do not align with the central, the connection is still formed. This supports your suspicion that the answer may not entirely be accurate based on the test results.

There are, however, modifications that can be made to allow for the application to handle when a GAP_UPDATE_LINK_PARAM_REQ_EVENT is received. To enable the application to handle these requests, the update enable param (gapRole_updateConnParams.paramUpdateEnable located within PROFILES/multi.c) should be set to GAPROLE_LINK_PARAM_UPDATE_APP_DECIDES. More information about the API can be found here: https://dev.ti.com/tirex/explore/content/simplelink_cc2640r2_sdk_4_30_00_08/docs/ble5stack/ble_user_guide/doxygen/ble/html/group___g_a_p.html#gaed1b6299bfe3b0469e2baf53cba04fe1 . If a parameter request is sent from the central, additional logic can be implemented within the GAP_UPDATE_LINK_PARAM_REQ_EVENT case to compare the min and max connection intervals with the ones set in the multi_role project. A GAPRole_TerminateConnection(connHandle) can be called to immediately terminate the link once determining if the connection intervals do not align.

In addition, I verified that I will receive the launchpads tomorrow. I will perform the connection interval tests you have detailed and provide the results by COB tomorrow.

Please let me know if any clarification is needed. Thanks!

Best Regards,

Jenny

Hi Niranjan and Abhimanyu,

I have performed the connection interval tests as described by Niranjan and I have produced similar results to the results Niranjan has shared.  Connection intervals of 10ms-17.5ms are connectable, however, inconsistent. This supports the fact that having a tighter connection interval will cause the device to potentially switch context between connections to launchpad 1 and 2 and not have enough time to schedule advertising. The reason why you view advertising inconsistently while having this smaller connection interval is possibly due to the jitter introduced to the advertising event period (for more reference this information can be located within the Bluetooth Core Specification V4.2 https://www.bluetooth.com/specifications/archived-specifications/ under section 4.4.2.2 Advertising Interval).

The period of an advertisement event is a combination of the set advertising interval and an advertising delay. This advertising interval is defined as a set value within the code, however, the advertising delay is a pseudo-random value generated to prevent interference and collision. This pseudo-random value can range from 0ms-10ms. Since this value varies, it could be the reason why you are seeing the inconsistent advertising within a 10ms-17.5ms range.

Best Regards,

Jenny

Hello Jenny,

Thanks a lot for the detailed explanation. It is quite clear now the observed behaviour. As discussed, It would be nice, if you could share an example on how to deal with the centrals  that sets low intervals.

The reason we have to consider it is, our project uses 3 parallel connections and we donot want the user have the problem of not able to make a new connection due to this limitation.

Best Regards,

Abhi

Hi Abhi,

I apologize for the delayed response. In regards to the example, please refer to the response made on October 19 on how to handle connection parameter updates. To provide some more information on what modifications need to be made:

- Within multi.c you can configure the application to handle link parameter updates as shown in the code below:

// Connection parameter update parameters.
static gapRole_updateConnParams_t gapRole_updateConnParams =
{
  .paramUpdateEnable = GAPROLE_LINK_PARAM_UPDATE_APP_DECIDES,
  .connHandle = INVALID_CONNHANDLE,
  .minConnInterval = DEFAULT_MIN_CONN_INTERVAL,
  .maxConnInterval = DEFAULT_MAX_CONN_INTERVAL,
  .slaveLatency = MIN_SLAVE_LATENCY,
  .timeoutMultiplier = DEFAULT_TIMEOUT_MULTIPLIER
};

The possible parameter options located in multi.h are shown below:

/** @defgroup Multi_Param_Update_Options Parameter Update Options
 * @{
 *  Possible actions the device may take when it receives a
 *  Connection Parameter Update Request.
 */
#define GAPROLE_LINK_PARAM_UPDATE_ACCEPT       0 //!< Accept all parameter update requests
#define GAPROLE_LINK_PARAM_UPDATE_REJECT       1 //!< Reject all parameter update requests
#define GAPROLE_LINK_PARAM_UPDATE_APP_DECIDES  2 //!< Notify app for it to decide
#define GAPROLE_LINK_PARAM_UPDATE_NUM_OPTIONS  3 //!< Number of options. Used for parameter checking.
/** @} End Multi_Param_Update_Options */

Please let me know if there are any confusions with the previous post (made on October 19th) or if additional clarifications are needed. Thank you for your patience!

Best Regards,

Jenny

Hello Jenny,

Thanks for the info regarding how to configure and control the connection behaviour. I hope using the above info we can control the connection behaviour in  BLE Central and Peripheral roles of the TI chip.

This info is crucial for our devlopment in the coming months. We will get back to you, if we need your further support..

Thank you,

Best Regards,

Abhi

Hi Abhi,

Thank you for the follow-up. Please let me know if there are any issues when implementing this or if more support is needed.

Best Regards,

Jenny