• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 3 answers
  • Subscribers 51 subscribers
  • Views 343 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: In the communication of one master and multiple slaves, how to make the connection time difference of the slaves as equal as possible?

Nick Sun
Intellectual 2265 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2642R

Hi team,

Here's the request from the customer:

In the communication of one master and multiple slaves, how to make the connection time difference of the slaves as equal as possible? For example, the connection interval is set to 25ms and customer expects the connection interval of 2 slaves to be 12.5ms. If it cannot be divided equally, whether it can also ensure the stability of each connection interval is also acceptable, such as 10ms.

At present, through the radio frequency mapping observation test and found that the connection time difference between two slaves may be only 5ms or less, and sometimes 12ms.

Could you help check this case? Thanks.

Best Regards,                                                       

Nick    

  • +1
    TI__Guru** 101460 points

    Hi Nick,

    The Bluetooth LE does not offer the possibility to control the anchor point of the connections. A guard time of 5 ms is kept between connections, which should ensure the stability of the connections.

    I hope this will help,

    Best regards,

  • 0 in reply to Clément
    TI__Intellectual 2265 points

    Hi Clément,

    The main problem at present is that if the interval between the two slave connections is small, it will be easier to lose packets. It may be due to the retransmission mechanism that there will be multiple data transmissions and receptions on a connection event, which may cause the system to be unable to handle it, resulting in packet loss.

    Best Regards,                                                       

    Nick    

  • 0 in reply to Nick Sun
    TI__Guru** 101460 points

    Hi Nick,

    I am afraid your analysis is not correct.

    Shorter interval between the anchor points limits the number of chained packets transmitted and may increase the risk of collisions (leading to some packet losses). However, as retransmissions occur in the following connection interval (and not in the same connection interval), the anchor point interval does not play any role here.

    For information, the CC2642R is tested to maintain 32 connections with 5 ms of interval between anchor points (see here).

    Best regards,

  • 0 in reply to Clément
    TI__Intellectual 2265 points

    Hi Clément,

    Is it possible to have multiple retransmissions in one connection event? 

    By observing the radio frequency mapping LNA, it is found that on a connection event, there are sometimes multiple LNA pulses (1-4) with an interval of about 260us. These 4 LNAs mean that there are 4 data packets sent in this connection event? They set the connection interval to 25ms, the data is 90 bytes, and the MTU is set to a maximum of 255. What's more, it may not be enough for data copying with an interval of about 260us.

    The LNA picture is shown in the following figure:

    Best Regards,                                                       

    Nick    

  • 0 in reply to Nick Sun
    TI__Guru** 101460 points

    Hi Nick,

    Again, there is no way to have several re-transmission in the same connection event as the connection event is considered as terminated as soon as one  packet is not acknowledged.
    Here, the screenshot shows the transmission of chained packets (i.e. several different packets, NOT the same packet being re-transmitted).

    Nick Sun said:
    These 4 LNAs mean that there are 4 data packets sent in this connection event?

    Correct.

    Nick Sun said:
    What's more, it may not be enough for data copying with an interval of about 260us

    The packets received are stored in the radio RAM and pushed back to the application core when it is ready. Having such short delay between the reception of Bluetooth LE packet is expected and fully supported by the device.

    Best regards,

  • 0 in reply to Clément
    TI__Intellectual 2265 points

    Hi Clément,

    Customer can understand what you are saying. However he sends new data every 25ms and his problem is that if the master fails to receive successfully for many times in a row, the slave will resend the data. This may cause several packets on one connection event. And the interval between these data packets is very small. Is there a way to increase the interval of these data packets?

    Best Regards,                                                       

    Nick   

  • 0 in reply to Nick Sun
    TI__Guru** 101460 points

    Hi Nick,

    Nick Sun said:
    Is there a way to increase the interval of these data packets?

    No there is not.

    However, the case you are describing should often rarely, and the number of packets sent should not exceed MAX_NUM_PDU (https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_30_00_03/docs/blestack/ble_user_guide/html/ble-stack-3.x/stack-configuration.html?highlight=max_num_pdu#id4).

    The solution is then to

    - either limit MAX_NUM_PDUS  to a value guaranteeing that the data transfer is short enough in all circumstances. 

    - or accept that sometimes a collision may occur and lead to a restransmission

    I hope this will help,

    Best regards,