• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 36 subscribers
  • Views 372 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.

Original question:

AWR6843AOP: Please help to provide an example which ONLY outputs Range FFT results

AWR6843AOP: AWR6843AOP: Please help to provide an example which ONLY outputs Range FFT results

Jyun-Yu Chen
Prodigy 10 points
Part Number: AWR6843AOP

Tool/software:

Hi Expert,

By the reply from E2E, we have conducted the range FFT results output for verification.

Nevertheless, we find a major problem that when a hand put in front of radar, the hand disappears in the range FFT results, as shown in the following figure:

The two signals are captured from the same pointer “rangeProcHWAObj->radarCubebuf” but in different code, i.e., in rangeprochwa.c and in mss_main.c, respectively, both in small_obstacle_detection_6843_can_mss

Again, since we had developed our own algorithms, the TI’s original algorithm may not suitable for us.

Additionally, building small_obstacle_detection_6843_can_mss, the RAM allocation shows that the PROG_RAM and DATA_RAM have used most RAM, i.e., PROG_RAM~80% and DATA_RAM~45%, as the following figure.

It seems that usage of RAM may be redundant for us.

Thus it is very appreciate that TI can assist us to remove the corresponding codes/variables/hardware which do not related to range FFT results.

Thanks

  • 0
    TI__Expert 3810 points

    Hi Jyun-Yu Chen,

    I have assigned this thread to one of our software engineers. Please expect a response within the next business day.

    Thanks,
    Kundan

  • 0
    TI__Mastermind 40685 points

    HI, there:

    I would recommend you to access the range FFT output through radarCube instead of any other temporary buffer.  Because it could be overwriting in different timing.  

    While on the other hand, radarCube data will be hold before next frame start. 

    Best,

    Zigang

  • 0 in reply to zigang Yang
    Prodigy 10 points

    Hi Zigang,

    Sure, I know that. But I do not know where the raw range FFT results in radarCube can be correctly accessed. Also, combined with the second problem of codes/variables/hardware resource, they are our bottlenecks to develop our automotive products.

    So again, would it be possible to help us to provide an example which ONLY outputs range FFT results?

  • 0 in reply to Jyun-Yu Chen
    TI__Mastermind 40685 points

    As I know, we do not have a demo just output range FFT results.  I will reassign your ticket to an expert for small_obstacle_detection_6843_can_mss.  

    Best,

    Zigang

  • 0 in reply to zigang Yang
    TI__Mastermind 23357 points

    Hello,

    If your only interest is in the range FFT, you can simply use Out of Box demo that outputs the Range Profile as a TLV that can be visualizer as seen below. There should be no issue with seeing a hand. This would be the simplest way to get range FFT with no external algorithms such as CFAR removing unwanted points at this level.

    Best Regards,

    Pedrhom

  • 0 in reply to Pedrhom Nafisi
    Prodigy 10 points

    Hi,

    Thanks for the reply. We do not want to see the range profile in computer. We would like to have raw range FFT results (including real parts and imaginary parts) to develop our own algorithms in TI's radar chip. 

  • 0 in reply to Jyun-Yu Chen
    TI__Mastermind 21211 points

    Hello, 

    I will try to help you here since Pedrhom is currently out of office. As Zigang mentioned before we do not have any examples which only do the Range FFT and no additional processing. Since you are using small obstacle detection the range processing is done in by the HWA in the MSS. The doppler, angle, and CFAR processing is done in the DSP, you can remove/replace this with your own custom algorithms. Please see DPC_ObjectDetection_execute() in objectdetection.c and DPU_radarProcess_process() in radarProcess.c (in dss project). The input parameter, pDataIn, contains a pointer to the range fft output (radar cube). 

    Best regards,

    Josh

  • 0 in reply to Josh Dye
    Prodigy 10 points

    Hi,

    Thanks for the help.

    Yes, we know the corresponding pointers and files in the mss and dss. Additionally, We also turn off the TI's MTI algorithm by setting "processInst->aoaInput->clutterRemovalFlag = 0;" to see the raw range FFT results. But we still do not know how to remove/replace the codes in dss or in mss even do not know how to start to do it because those are made by TI's experts. Moreover, if we really remove some codes we do not need, we still do not guarantee such removals may lead to some side effects or not in the TI's sdk. Therefore, we sincerely hope that we could have an example which only conducts the Range FFT and no additional processing.

    Thanks.

  • 0 in reply to Jyun-Yu Chen
    TI__Mastermind 23357 points

    Hello,

    Enabling clutter removal is not raw range FFT, it only includes points that have 0 doppler. There is some processing done to combine the data across antennas, as well as CFAR algorithms at play.  The only way to get the real/imaginary unfiltered unprocessed raw ADC values, which you will then need to do an FFT offline yourself, is by using a DCA1000 Please see the post attached below for more details on the DCA1000. I will note that the DCA1000 is a recording tool, not a live playback tool. There is no method to process raw data live in real time as it comes in with TI mmWave sensors.

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1441304/faq-dca1000evm-support-tools-debugging-and-more

    Best Regards,

    Pedrhom