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.

BOOSTXL-AOA: angle calculation issues using SDK functions

Part Number: BOOSTXL-AOA

Hello,

Currently, we have BOOSTXL-AOA and several CC26X2R1 DKs, simplelink_cc13x2_26x2_sdk_5_10_00_48 SDK. We obtained a patched RTLS UI software that does not crash with UI errors. The software with default settings can connect to the master/CTE receiver. It can synchronise with periodic advertisements from CTE transmitters, and it can receive CT. However, the results (i.e. angles) are a bit unpredictable not only for connection-less mode but also for the connection-oriented mode. This behaviour does not correspond with our expectations and demo presented here: https://training.ti.com/tida-01632-automotive-bluetooth-low-energy-receiver-reference-design
In connection-oriented mode, the angle rarely goes below 0 degrees, it is unstable and it seems that it does not reflect the relative position between transmitter and receiver.

We analysed the RAW data, and it seems that the sampling works correctly. There is a considerable drop in received signal strength when using a different antenna from the array, but this corresponds with a note provided in TI's documentation.


The questions are
a) Is our goal achievable with the TI solution? I.e. a quite reliable angle calculation for direction finding using two CTE devices in connection-less mode with two antennas? Our scenario should match exactly TIDA-01632.
b) Is the provided algorithm (either in RTLS UI or SDK) able to calculate the angle correctly given the setup mentioned above?
c) Is the connection-less mode fully supported in RTLS UI?
d) Is the connection-less mode fully supported in SDK?
e) If we let manufacture TIDA-01632 PCB, will this demo be working with already available SDK? Is it possible to obtain the sources presented in the video for TIDA-01632?

Example of RAW data when 0 degree angle should be reported:

waveforms_sampled

Our goal is to get to state, where BOOSTXL-AOA kit will use 2 antennas for angle detection, similar to TIDA-01632
Pleas can you look at measurement and consider if this is sufficient quality data for SDK algorithm? Or can you just give us general feedback to results? We are able to measure more cases etc.
This test was carried out in laboratory and distance between nodes was around 1.5m.
Best regards Zdenek & Jan
  • Hi Zdenek & Jan,

    The IQ data collected look great to me - at least I don't think you could get better IQ data in a non-controlled environment (i.e. in a non-conductive transmission). In a real environment, undesired signals (multipath and concurrent transmissions) interfere with the signal of interest. Embedded or system-level algorithms are required to mitigate these and achieve desired localization performance/angular accuracy.

    These algorithms should be adapted and fine-tuned to your specific use case. The antenna design should be taken into account when developing these algorithms.

    As of today, in the SDK, we provide algorithms that should NOT be considered as able to mitigate multipath effects. These algorithms are only examples and are written for arrays of 3 antennas.

    My answers:

    a) Your goal will require to develop embedded or system-level algorithms to mitigate undesired signals.

    b) No, the algorithms are only written for 3 antennas and do not mitigate multipath effects

    c) No. In connectionless mode, the RTLS UI only allows to collect the IQ data. No actual angle calculation is run for connectionless mode.

    d) Yes. The SDK does support CTE transmission and IQ data sampling that can be used for the development of localization algorithms that will need to be specific to your product implementation. These are supported both fr connection and connectionless modes. 

    e) We do not share these on a public forum.

    Best regards,

  • Thank you very much for your reply.

    We are investigating the suitability of Bluetooth CTE for a long-range scenario. According to the Bluetooth specification, there is no CTE on the LE Coded PHY, and we are trying to understand how to handle that.

    The connectionless direction finding is dependent on periodic sync, which relies on the transmission of ADV_EXT_IND and AUX_ADV_IND packets. It means three packets need to be successfully delivered to receive CTE. This requirement decreases the chance of successful receipt with increasing distance. It would help if at least the auxiliary packets were transmitted using the coded PHY. It looks, however, that the transmission of AUX_ADV_IND using LE coded PHY implies also coded PHY for AUX_SYNC_IND, which means that there will be no CTE. We concluded that all three (or the last two in the best case) packets need to be transmitted using 1M PHY.

    Q1) Does TI permit transmission of CTE over coded PHY? If not, is there a possibility of establishing a more reliable channel for a long-range mode implying higher packet loss?
     
    Q2) Is the reception of periodic advertisements immune to packet loss? The specification is a bit vague, and it is hard to deduce whether the scanner can recover from a single (multiple) loss of AUX_SYNC_IND packets.
     
    Q3) Is there a possibility to obtain I/Q samples when we use the proprietary Wireless TI mode? We do not need to stay with Bluetooth.

    Zdenek

  • Hi Zdenek,

    1) No, we do not provide CTE for coded PHY. The Bluetooth LE connection handles re-transmission in case of packet loss.

    2) When a periodic advertisement is "lost", it is NOT re-transmitted - actually the advertiser has no way to know if someone has receive the advertisement. With that said, a synchronized device (scanner) will keep the synchronization even if some packets are lost. Actually the scanner will consider the sync as lost if no packets are received during a configurable timeout.

    3) TI does not offer proprietary AoA

    Best regards,

  • Hi,

    If your question is answered, please make sure to mark the thread as resolved. This will help other users to find this conversation.

    Appreciate your help,

    Kind regards,