• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 195 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

IWR6843AOPEVM: 2D-FFT data in OOB demo

Tosin Babarinde
Intellectual 435 points
Part Number: IWR6843AOPEVM
Other Parts Discussed in Thread: IWR6843AOP

hello,

I am looking to have 1D/2D FFT data out of my sensor as they are of better use for my study.

To get 2D-FFT data (Doppler-Range heatmap) I started by increasing the baudrate of the dataPort to 3125000, and set guiMonitor to -1 0 0 0 0 1 0

Doing this, I was able to increase the frame rate up to 18-20 fps (i.e. frame periodicity of 55.556 to 50 ms).

Using the mmwave demo visualizer also, I could use the record data button to capture some data.  My questions as follows:

1. Is it OK to increase the baudrate?

2. Is there any other way to get 2D-FFT data from the sensor, preferably over UART?

3. How can I have access to 1D-FFT data?

4. Is there any scripts (MATLAB/Python) that can be used to load/read the captured .dat data from demo visualizer?

regards,

Tosin

  • 0
    TI__Guru 50240 points

    Thanks Tosin

    We'll need a few days to look into this but will have an update for you next week.

    Regards,

    AG

  • 0
    TI__Expert 7510 points

    Hello,

    1. Is it OK to increase the baudrate?

    [CD] >> The IWR6843AOP datasheet only specifies a typical baud rate of 921600. Feel free to increase the baud rate up to 3125000 as you have, as this is what the driver specifies as the max baud rate. Going right up to these max performance specs though can lead to bit errors which could effect your end application. "OK" in this context is what ever performance that you feel is acceptable. We do not guarantee that it can run at any baud rate higher with no issue.

    2. Is there any other way to get 2D-FFT data from the sensor, preferably over UART?

    [CD] >> The following TLVs that our processing chain exposes by default is specified in the resource specified below. The source code for our SDK is available for you to explore, so if you want to make a modification then you are free to, but we only output what is specified below.

    OOB Documentation for 68xx:
    <MMWAVE_SDK_INSTALL_PATH>\packages\ti\demo\xwr68xx\mmw\docs\doxygen\html\index.html

    3. How can I have access to 1D-FFT data?

    [CD] >> Same answer as in (2)

    4. Is there any scripts (MATLAB/Python) that can be used to load/read the captured .dat data from demo visualizer?

    [CD] >> For our OOB demo offering your best bet is to leverage the script that is linked below. This script takes .dat produced by demo visualizer and creates .csv file.

    mmWave Demo Scripts
    C:\ti\mmwave_sdk_03_05_00_04\packages\ti\demo\parser_scripts

    Best regards,

    Connor Desmond

  • 0 in reply to Connor Desmond
    Intellectual 435 points

    Thanks for detailed responses Connor.

    On another note, is the radar designed to transfer other data types over the LVDS other than raw data? I am looking at using LVDS to transfer the radar cubes and/or doppler matrices...Was this ever considered?

    Additionally, is it possible to create my own data type and corresponding TLV? For example I can convert the Range/Doppler matrices into vectors, and transfer these vectors in small chunks/packets over the UART....Is this a possibility?

    regards,

    Tosin

  • 0 in reply to Tosin Babarinde
    TI__Expert 7510 points

    Hello,

    These kind of modifications are what I would consider advanced, so you will need to have a firm grasp of how the system is implemented currently and make modifications within our SDK architecture. At a high level if you have access to the peripheral's driver and you can store the data you are interested in a structure and provide that data to the driver then it could work. The major constraint is going to be making sure that you get all this work done before the end of the next frame. Additionally, synchronization, inner core communication (if you are using a DSP), managing different tasks etc all have to taken into account. If I were you I would start with the 64xx OOB demo source code and understand that because it does not use the DSP thus it is simpler to digest.

    Yes. You can add/modify/remove anything from what we provide. This comes with the caveat that if you make any modifications that the support on the forums will be limited because you have made modifications. I would suggest making sure you know exactly how something works both at a functional/modular level as well as at a system level before you make modifications. Familiarity with CCS and debugging within that framework will be a must for anyone who wants to make modifications as well as pin down bugs as they appear.

    Best regards,

    Connor Desmond