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.

CC2640R2F: Packets are lost when transferring from the periphery to the multi-role

Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2640, , BLE-STACK

Good day!
I have a problem with CC2640
I am using a multi-role and two peripherals. My peripheral settings TGAP_CONN_EST_INT_MIN = 20 and TGAP_CONN_EST_INT_ MAX = 20

I count the number of sent packets from the periphery to the multi-role (GATT_Notification returns SUCCESS). And the number of received packets in muti-role.
Some packages don't get through. I tried increasing TGAP_CONN_EST_INT_ MAX but packets are still lost, but in smaller numbers. This happens when multi-role is actively exchanged with other peripherals.
What could be the problem?

P.S. Both connections use MTU_Exchange

  • Hi,

    Could you please specify how you are counting the number of packets exchanged between the devices? Do you have some BLE traces that could help us to identify the problem? Do you see the problem when the connection interval is longer? Is the problem worst when the connection interval is smaller?

    In addition, could you please specify which SDK version you are using? Which stack (ble or ble5)? And confirm you are using CC2640R2F?

    Thanks and regards,

  • Thank You for the quick response

    I don't have a trace yet

    I use GATT_Notification to count the packets sent. Every time the GATT_Notification function returns SUCCESS I increase the counter of sent packets

    In multi-role, I count the number of received packets and there are fewer of them

    >>Do you see the problem when the connection interval is longer?

    Sometimes

    >>Is the problem worst when the connection interval is smaller?

    Yes it is.

    simplelink_cc2640r2_sdk_1_50_00_58 , ble-stack, СС2640R2F

    Thanks and regards

  • Hey Alex,

    Here are a few things you can try:

    In a very general sense, the performance you see sounds in line with expectations. Although, I cannot confirm this without any PER numbers from your tests. You mention a "small amount" of packets are still lost. Do you have a percentage? Depending on the size of the packets you are sending, and the amount of simultaneous active connections, it is possible that there is not enough time to handle such fast connection intervals. Again, this depends heavily on your application; this is just my general thoughts initially.

  • Hi Ammar,

    Thank you for these links. They are very useful.

    But I don't understand something. Please tell me

    1. GATT_MTU_Exchange automatically calls HCI_LE_SetDataLenCmd? If so, how is Max_TX_Time set ?

    2. How is priority allocated for Connection Event, Advertising Event, Scanning? Can scanning or advertising interfere with data reception?

    3 Is the entire Payload GATT_Notification always located in one PDU?

    Perhaps you can advise a detailed document or a picture where the format and timings of packets are presented in detail, indicating the connection parameters?

    Thank you very much in advance

  • Hey Alex,

    Alex Selyutin said:
    1. GATT_MTU_Exchange automatically calls HCI_LE_SetDataLenCmd? If so, how is Max_TX_Time set ?

    I'm not sure what you mean by this, but the data length can be set using that API. It is also set upon initialization using HCI_LE_WriteSuggestedDefaultDataLenCmd. The max TX time is also set in the initialization using the APP_SUGGESTED_TX_TIME define.

    Alex Selyutin said:
    2. How is priority allocated for Connection Event, Advertising Event, Scanning? Can scanning or advertising interfere with data reception?

    Put short, connection events will always take priority over advertising and scanning. They should not interfere with data reception during a connection event.

    See https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/734530 , https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/863971?CC2642R-CC2642-scan-issue 

    Alex Selyutin said:
    3 Is the entire Payload GATT_Notification always located in one PDU?

    You can verify this using a sniffer, but it depends on the amount of data you transfer as well as if you've enabled data length extensions or not.

    Alex Selyutin said:
    Perhaps you can advise a detailed document or a picture where the format and timings of packets are presented in detail, indicating the connection parameters?

    I don't think we have such a document, but I would read over the BLE specification for these details. You can also refer to our SDK User's Guide for some higher-level detail on how the data exchange works during connections. Here's the link for BLE3 Stack, or BLE5 Stack if you are using a BLE5 project.

    Hey Alex,

    Alex Selyutin said:
    1. GATT_MTU_Exchange automatically calls HCI_LE_SetDataLenCmd? If so, how is Max_TX_Time set ?

    I'm not sure what you mean by this, but the data length can be set using that API. It is also set upon initialization using HCI_LE_WriteSuggestedDefaultDataLenCmd. The max TX time is also set in the initialization using the APP_SUGGESTED_TX_TIME define.

    Alex Selyutin said:
    2. How is priority allocated for Connection Event, Advertising Event, Scanning? Can scanning or advertising interfere with data reception?

  • Hey Ammar!

    Thank You a lot for answers to my problem! 

    But I want to clarify something

    In ours BT-system we used one multi-role, two peripherals and one central. All devices connected to multi-role. All devices use СС2640R2F

    All devices have minConnInterval = maxConnInterval = 20

    When multi-role holds connect to peripheral, the central can try connected to it. Central set anchor point for connect intervals.

    To avoid collisions of connect with the periphery, the multi-role must do Update Parameters Connect for remove anchor point of periphery.
    As I understand it must does automatically. But I can call CONNECTION_UPDATE_REQ
    But some number of packets from periphery to multi-role is lost.
    In my opinion the reason this is collision in connections multi-role-central and multirole-periphery.

    Could this be?
    How can this be fixed?

    Best Regards

    Alex.

  • Hey Alex,

    The scheduling of connection events on the central side happens at the link layer. There are two options to set this "guard time", which is the time between consecutive connection event processing on the central. The first is this time is randomly selected, and the other option guarantee's a 5ms delay between each scheduled event. See our User's Guide, specifically the link layer section here. The scheduler should not collide internally with other scheduled connection events. To verify you can set the 5 ms guard time and this will ensure there is enough spacing.

    Additionally, you have a fairly tight connection interval. Does the issue occur if you increase the connection interval? The example readme recommends the following connection interval based on n number of nodes:

    "

    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

    "

  • Hey Ammar,
    Thank you for the ideas.
    I have tried increasing the connection interval, but the problem with packet loss did not go away and transfer speed dropped.
    I tried using only three devices - multi-role, peripheral and central. And I have two connections.
    All projects used SDK 1.50.00.58
    MAX_PDU_SIZE=148
    MAX_NUM_PDU=4
    Connection interval  = 20    (20 *1.25ms=25 ms  >  12.5 + 5*2 = 22.5ms)
    But I see packet loss from peripherals to multi-role (img 1)
    The oscilloscope shows the following (img 2) Here, multi-role transfers packets to central and tries to receive packets from the periphery
    In my opinion it, there are connection collisions
    I don't understand why the multi-role does not update the connection with the periphery after establishing a connection with the central?
    And why the multi-role don't move anchor point for connection event for periphery?
    I try for this Update Parameters Connect for Peripheral. But it has no effect.
    Does it make sense to update the connection parameters from the multi-role for the Central?
    Does SDK 4.30 solve similar problems?
    SDK 4.30 used defines
    #define BLE_MASTER_CONNECTION_RANDOM 0
    #define BLE_MASTER_CONNECTION_ALIGNED 1
    Maybe something similar exists in SDK 1.50 ?
    Or are there other solutions?

    Best Regards,

    Alex

  • Hey Alex,

    Here are some comments I have:

    • There were a number of bug fixes made to the stack since the 1.50 release, some in the scheduler. They may not directly be related to this issue (as we're not exactly sure what the issue is yet). Regardless, I'd strongly advise you update to the latest SDK if possible. 
    • A sniffer capture showing OTA ble packets would help here
    • Updating the connection parameters on the central will free up radio bandwidth from the central->multirole device and it should enable more airtime for the peripheral. Do you see packet loss if you disconnect the central device and only connect the multi-role to the peripheral?

    Some potential workarounds to investigate may be to incorporate application level retries if the data is critical. You can also use indications instead of notifications, which means the data will send sequentially and wait for an ack until sending the next packet.

    Hope this helps! I will look into the defines you mentioned and try to report back after Thanksgiving holiday.

  • Hi, Ammar!

    I will try to update SDK for all my projects, but for it need some time.

    >>Do you see packet loss if you disconnect the central device and only connect the multi-role to the peripheral?

    If I power off the central device then packets don't loss between the multi-role and the peripheral.

    When I power on the central device - packets lose

    Best Regards

    Alex

  • Thanks for clarifying. I would recommend starting with the multi-role project and then retesting the peripheral/central connections.

    One rather quick way to verify your theory of connection collisions is to expose the TX/RX pins on each device and look at all 6 signals with a logic analyzer. Checkout the Debugging RF Output section of our User's Guide.