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: Angle of Arrival measurement error

Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2640

Hello everyone,

i'm currently trying to develop a system for RTLS using the CC2640R2F and the BOOSTXL-AOA. As i just wanted to test its accuracy before buying more microcontrollers and arrays i tried the example from the 2.3 SDK version (works just with 2 x CC2640R2F and the antenna array). 

http://dev.ti.com/tirex/content/simplelink_academy_cc2640r2sdk_2_30_02_00/modules/blestack/ble_aoa/ble_aoa.html

The results that i get from it are really inacurate, i'm not even certain that it registers the rotation correctly at all. In this example supposedly one is able to advertise either normal or AoA packets. But from what i understand this example and even the examples in newer sdk versions (ble folder) are based on Bluetooth 4.x. I always thought that AoA packet advertisement is only supported by Bluetooth 5.1 (adding the CTE extension on the packet). How am i receiving an angle at all (is it maybe the reason for my bad measurements)?

Even the ToF example measurements are discouraging.

http://software-dl.ti.com/simplelink/esd/simplelink_cc2640r2_sdk/2.30.00.28_new/exports/examples/rtos/CC2640R2_LAUNCHXL/blestack/tof_initiator/README.html

Thanks in advance!

Greetings Dan

  • Hi Dan, 

    Assigning an expert to look into your issue. 

    Thanks, 
    Elin

  • Hi Dan,

    A couple of remarks regarding your issue:

    - you are using a one year-old SDK, you should consider moving to the latest

    - on CC2640, the RTLS is based on BLE 3. If you want RTLS based on BLE 5, then you need to migrate to CC2642 / CC2652

    - about the accuracy problems:

    * Have you moved the capacitor C51? (details are here in the section "Preparations")

    * Have you followed the appropriate labs/trainings? (the Simple Link Academy [SLA] is here)

    * Have you try to disable one of the two antennas arrays?

    * Are you running your tests in an appropriate environment?

    I hope this will help,

    Best regards,

  • Thank you for your response.

    As i explained, i'm just using this sdk because it doesn't require a third microcontroller.

    Why does the CC2640R2 doesn't support the BLE 5 if it is advertised on the official site, and is used for AoA in all examples. How would that work if they don't support the direction finding feature from Bluetooth 5.1?

    http://dev.ti.com/tirex/content/tirex-product-tree/cc26xx_devtools/.metadata/.tirex/project0_boostxl_aoa_bp/landing_page_index.html

    1.) Yes, i moved the capacitor C51 as indicated in the schematics.

    2.) Yes, i have done all the trainings regarding TI-RTOS and BLE

    3.) Yes, getting the same results with just one part of the array or even just 2 antennas.

    4.) Yes, i tried it first inside in a big open room and afterwards outside.

    Would appreciate any kind of help.

    Kind regards,

    Dan

  • danmbox said:
    As i explained, i'm just using this sdk because it doesn't require a third microcontroller.

    SDK 3.30 on CC2642 requires only two devices too...

    CC2640R2 does support BLE 5. I just wrote that the RTLS toolbox on CC2640R2 uses BLE 3.

    Regards,

  • Ok, so i'm still a little bit confused.

    So the BLE 5 Stack is not the same as Bluetooth 5.1 Standard?

    Because i couldn't understand how the example of the RTLS with BLE 3 could work without the feature of Bluetooth 5.1 (regarding the CTE extension).

    Regards,

    Dan

  • Hi Dan,

    For CC2640R2, the CTE feature is *NOT* implemented in the BLE 5 stack. Please note that the CTE feature is not required to be BLE 5.0 compliant.

    Now, still on CC2640R2, we have implemented the CTE feature on the BLE 3 stack. Here again, the CTE feature is not required to be BLE 3 compliant. However, there is nothing that prohibits us from supporting this feature.

    With that said, if you need to be BLE 5.1 compliant and require the direction finding features, you definitely need to use CC2642 / CC2652.

    I hope this is clearer,

  • Thank you very much, that helped me a lot!

    So that means that i could still use the CC2640R2 for the direction finding features (because you support this feature) if i don't need to be BLE 5.1 compliant?

    Would you still recommend to use the CC2652? What are the benefits being BLE 5.1 compliant?

    Kind regards,

    Dan

  • Hi Dan,

    danmbox said:
    So that means that i could still use the CC2640R2 for the direction finding features (because you support this feature) if i don't need to be BLE 5.1 compliant?

    Yes, exactly!

    danmbox said:
    Would you still recommend to use the CC2652?

    Tricky question: the two devices have differences regarding performance and price. This will depend on your project. If you are not trying to develop an ultra low-cost application, then CC2652 is a better pick because you will have more code space and computing power to handle the AoA data. If only the price matter, then CC2640R2 is better.

    danmbox said:
    What are the benefits being BLE 5.1 compliant?

    A stamp ;)  In a general basis, if you don't need to be BLE 5.1 compliant, then it is useless to spend time and money to do so. The reason that could push you to be BLE 5.1 compliant is mainly interoperability with existing BLE applications (and marketing of course).

    Regards,

  • Thank you very much! :-)

    For other community members regarding my measurement errors, i could solve them with this post (just look under the corresponding SDK):

    https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/770218

    Kind regards,

    Dan