This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2652R: Regarding Client side connection interval

Part Number: CC2652R

Hi,

Is it necessary to keep client side connection interval of equal to or greater than 32.5ms to successfully connecting 4 devices.

as per below information

When at least one connection is already formed, in order to allow enough processing time to scan for a new connection, the minimum possible connection interval (in milliseconds) that can be used is:

12.5 + 5*n

where n is the amount of current connections.

For example, if there are currently four connections, all four connections must use a minimum connection interval of 12*5 + 5*4 = 32.5 ms in order to allow scanning to occur to establish a new connection.

I want to connect 4 devices with Connection interval of 10ms at client side but I am not able to connect 4 device successfully,

Need help in doing this Let me know how to do this ?

With TI Hardware or BLE stack is it possible to connect 4 device using simple central(Rx) and receive 1 data packet in each connection event from each peripheral in every 10ms ?  i.e all 4 peripheral should send 1 data packet in every 10ms and client must receive 4 Data packet in every 10ms.

Regards,

Vidit

  • Hey Vidit,

    With TI Hardware or BLE stack is it possible to connect 4 device using simple central(Rx) and receive 1 data packet in each connection event from each peripheral in every 10ms ?  i.e all 4 peripheral should send 1 data packet in every 10ms and client must receive 4 Data packet in every 10ms.

    As we discussed in your original post, achieving this is not possible. simple_central randomly schedules anchor points for every connection. As the spacing here is random, you cannot guarantee your 10ms timing in this case. simple_central also has the option to enable an "Extended Guard time", which allows for each connection anchor point to be scheduled 5ms apart from each other. This means there is not enough time for the central to receive 4 data packets (if they are spaced out by 5ms, 4x5ms = 20ms at least). This doesn't even account for missed connection events, so you will have difficulty achieving this use case while maintaining a connection. There is simply not enough bandwidth to do this. We have a new feature in the v5.10 SDK that may help improve this called Connection Fairness. Read more about it here in our User's Guide. That being said, I still think this is not possible.

    Is there a reason you must maintain a connection with your devices? Can you send this data in advertisements? You should be able to achieve this by just using advertisements in the simple_observer/broadcaster configuration.

    Is it necessary to keep client side connection interval of equal to or greater than 32.5ms to successfully connecting 4 devices.

    This is our recommendation, it is not necessary to keep this.

    I want to connect 4 devices with Connection interval of 10ms at client side but I am not able to connect 4 device successfully,

    You are seeing this because there is not enough time to allow for a long enough scan to discover/connect with new devices.

  • Hi Ammar,

    Thanks for the reply.

    Yes, you have already mentioned in your previous post regarding anchor point and I asked you regarding editing of guard time and you told we can not perform these changes without making modifications to the source libraries.

    After seeing the result I think to achieve our use case we will have to modify libraries.

    1. Like I want to check reducing Anchor point to less than 5ms or to increase to 10ms as per my use case.

    (As, our expectation is to achieve data in every 10ms interval from all four sensor so, I think if we can able to modify the anchor point then we check the results).

    2. I also want to check reducing connection interval below 7.5ms i.e 3ms or 2ms or 5ms 

    (As, reducing connection interval will provide us enough spacing for all 4 connection to stay connected and transmit data, along with if we can reduce anchor point to further below 5ms to some thing about 2.5 or 2ms than we can check if we can achieve expected result).

    So, all this changes require a library level or stack level changes.

    Therefore I want know how to edit library or stack level change on TI platform.

    Also, I want to let you know that we are in the product manufacturing phase using TI platform.

    Need TI help in knowing how to start writing Driver level code on TI platform ?

    So, Need TI support in resolving this issue.

    Regards,

    Vidit 

  • Hey Vidit,

    1. Like I want to check reducing Anchor point to less than 5ms or to increase to 10ms as per my use case.

    Unfortunately this is not possible as the source code is not made available for public use. Additionally, the guard time is set at 5ms intentionally, to allow time for the stack to process a connection event. Even if you were able to modify the source, we do not recommend reducing this value as you may encounter other issues.

    2. I also want to check reducing connection interval below 7.5ms i.e 3ms or 2ms or 5ms 

    This is not possible either, as it is against the Bluetooth spec (7.5ms is the defined minimum connection interval).

    What is your end application? I'm having trouble understanding the need for this requirement. If you can send this data over advertisement payload, this can also be a valid option to look into. Unfortunately I can't advise you further without some more context.

  • Hi Ammar,

    I was just having one small query regarding guard Time.
    This guard Time Parameter used is added by TI or it is part of BLE specification.

    Because when I was going through BLE specification I came across one guard time 

    Specification of the Bluetooth System, v5.1 (vtsociety.org)

    Is this guard time same as that of given Advanced BLE stack as the range for this is quite low and in BLE stack we can have guard time as fix value and that is 5ms.

    Thank You

  • Hey Vidit,

    This guard time is associated with EDR packet payloads which is not supported as it refers to Bluetooth Classic and not Bluetooth Low Energy.

    The guard time setting in the SDK is added by TI to allow central devices to manage multiple connections, and allows time for the radio/MCU to process any TX events it needs to execute for a particular connection.

  • Hi Ammar,

    Does this guard time (5ms) parameter varies with manufacture to manufacture ?

    or Is it given in BLE specs to keep guard time of 5ms ? (if present can you share document in which is given as I could not found that).

    Thank you

  • Vidit,

    The guard time is specified by TI in this case in order to provide our device time to transmit data and prep for the next connection if connected to multiple devices. All BLE traffic regardless of vendor will take the same amount of time to transmit, and multiple packets per connection interval can be sent on a connection, so the guard time was selected to ensure our device has enough time to be ready, but also to actually allow the device to send and receive data. Also, please note that you would have zero time to scan basically when you have 2 or even 3 devices connected and you would likely see very, very long times to actually connect to all 4 devices. You do have the option to set the guard time off (i believe it's off by default in the latest SDK), and then the central device will schedule the anchor points randomly in time, but you will still have almost zero time to scan. You can find more about the guard time here:dev.ti.com/.../link-layer-cc13x2_26x2.html

    What application are you building that requires you to have so many connections within 10ms? 

    I think it would be helpful if you could give us the context of your application to maybe think of alternative thoughts. 

  • Hi Vidit,

    I saw your email. I think the best way you can potentially implement this is by not using the guard time option but setting it such that the central randomly schedules the anchor points in time. I do think you will have to perform some testing on whether you believe this will suffice for your application though as you may have scenarios where you do not get data for all your devices within a BLE connection. As we stated in the past, the minimum connection interval is 7.5ms and the device will always need some time to prepare for the next connection which includes radio resync to a new channel, etc. All of this will potentially contribute to some instances where a connection event may not be handled because of closely overlapping connection events with other connections. In addition, this leaves you with very little time for scanning, but you can look into using the scanning priority feature we introduced in SDK 5.10 as well. You can find more info in our docs under Link Layer on this. I can't say for certain your application will work, but would recommend you consider a proprietary RF technology in addition to my suggestion above. 

  • Hi Evan,

    I am having one doubt regarding LE secure connection.

    Our Transmitter data size is 10 bytes.

    1. Can I use PDU size below 69 i.e 27 and still have LE secure connection (As in Note it is given that if we are using LE secure than PDU size of min 69).

    Can you explain If I am using PDU size of 27 is my transmission still secured similar to when it is greater than PDU greater than or equal to 69 ?

    2. In BLE stack PDU size below 27 is not allowed and we know that max 20bytes on Notification data can be sent in one PDU

    Then, if my data is 10 bytes, so 10 bytes are still empty so why can't I reduce my PDU size to 17bytes ?

    Generic Attribute Profile (GATT) — SimpleLinkTm CC13x2 / CC26x2 SDK BLE5-Stack User's Guide 2.01.02.00 documentation

    Thank you.

  • Hi Vidit,

    Please post a new thread for questions unrelated to previous threads. This thread with regards to the original topic is considered resolved.