• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 319 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: Delay of RTLS_CMD_CONN_PARAMS

Viki Shi
Expert 3130 points
Part Number: CC2640R2F


Hi,

A customer is testing AOA example,his enviroment is:  LAUNCHXL-CC2640R2+BOOSTXL-AOA ,SDK: simplelink_cc2640r2_sdk_3_40_00_10

During the test, the time of HOST received RTLS_CMD_CONN_PARAMS was T1, then it was forwarded to passive device, and the time of passive received it was T2. They found that if the time difference between T1&T2 was larger than 250ms, the passive device could not receive the AOA data in subsequent procedure. This test is under 4G network, so is this because of network delay?

Can you please shed some light on solving this problem? thanks.

BR,

Viki

  • 0
    TI__Guru** 101460 points

    Hi Viki,

    First of all let me remind you that TI has made the decision to discontinue further development and support of the TI-proprietary Angle of Arrival (AoA) on the CC2640R2. We recommend and welcome our customers using AoA on CC2640R2 to transition from the CC2640R2 to the new RTLS examples based on the Bluetooth 5.1 specification which can be used with the CC13x2R and CC26x2R devices. These software examples can be found in the SimpleLink™ CC13x2 and CC26x2 software development kit 3.40 or later which features a Bluetooth 5.1 qualified stack with support of Bluetooth 5.1 Angle of Arrival. To make this transition, here is a list of available resources you can reference: Simple Link Academy, AoA stack users guide, LaunchPad Tool Order Page

    For other readers, the same problem, with the same cause can happen on CC26X2R.

    In the RTLS example, the master device establishes a connection with the slave device.
    Once the connection established, the master shares the connection parameters (among other, the connection interval, the channel map, the next channel, the hop value, encryption keys...) with the passive.
    If the data takes too much time to arrive to the passive, then the information is outdated. In that case, the passive tries to listen on a channel that has already been used. So the passive cannot find the connection and cannot receive the CTEs. 

    In short, the passive is considering T1 next channel instead of T2 next channel.
    If you have a way to measure or estimate the time you need to receive the connection information on the passive (in other words, if you know how much how much connection events have been missed) then you should be able to successfully find the connection.
    For CC26X2R users, the CSA#2 (Channel Selection Algorithm) has to be deactivated (see here) - this is to prevent the use of an additional random value in the channel selection.
    For CC2640R2 (BLE4.1), you can consult the BLE spec (BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B], §4.5.8) to see  how to calculate the next channel.

    In summary, based on the number of connection events missed, the passive must calculate on which BLE channel he must expect the next connection event.

    I hope this will help,

    Kind regards,