• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 793 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:

AWR1243: enabling all 12 transmit antennas for 4 chip cascade radar system

AWR1243: enabling all 12 transmit antennas for 4 chip cascade radar system

coolguy
Prodigy 180 points
Part Number: AWR1243

Hi respectful TI Experts,

Regarding our previous question (http://e2e.ti.com/support/sensors/f/1023/p/742670/2750494#2750494), we thought that we fixed the problem completely. The problem still exists and we have some clues.

That's the reason I submit this question again. Sorry for duplicated question.

When we modified your software packages for TDA2xx to enable all 12 transmitter with TDM manner for our cascade board, there are some errors. Sometimes, in range profile shown in matlab, it looks like some portion of rangle profile is removed. And sometimes, in Putty console, we can see some error message and MCU runs error callback function. It happens when we run the software which is bulit with release mode.

When we build a binary with debug mode, by any chance, we get to know that above symtoms do not exist. I think maybe it is important clue. Because the software in debug mode runs slowly, it might have enough time to process each function so there might be no timing conflict between cores.

we are currently using PROCESSOR_SDK_RADAR_03_04_00_00.

I hope you can find some cause of the problem with our observation

  • 0
    TI__Mastermind 30245 points
    Hi,

    Would you be able to share a patch with all the changes you have made in the code? That would help us narrow down the issue.

    Thanks and Regards,
    Piyali
  • 0 in reply to Piyali Goswami
    Prodigy 180 points

    Hi,

    Yes, we can send the source files which are related to our modifications.

    I don't think it is godd idea to attach our source files here. Therefore, how about sending them to your email?

    Or we can send them to "Dham, Vivek <vivek.dham@ti.com" so he can forward them to you .

    BR

    Donghan

  • 0 in reply to coolguy
    TI__Mastermind 30245 points

    Hi Donghan,

    yes, you can share with Vivek.

    Thanks and Regards,

    Piyali

  • 0 in reply to Piyali Goswami
    TI__Mastermind 30245 points
    Keeping this thread updated. With the changes shared and modified for TI board the issue is not observed at TI. Next steps is to see the customer antenna configuration and check why they see an issue.

    Kindly note as the antennas are physically different on the TI and customer board the final result of angle and range would not match on the TI board.
  • 0 in reply to Piyali Goswami
    TI__Mastermind 30245 points
    Hi Donghan,

    There was one bug discovered in the SDK code related to angle estimation. Can you please incorporate the below change and check if your angle estimation improves?

    diff --git a/apps/src/rtos/radar/src/usecases/cascade_radar_object_detect/chains_cascadeRadarOd.c b/apps/src/rtos/radar/src/usecases/cascade_radar_object_detect/chains_cascadeRadarOd.c
    index 27ef846..4d3b13c 100755
    --- a/apps/src/rtos/radar/src/usecases/cascade_radar_object_detect/chains_cascadeRadarOd.c
    +++ b/apps/src/rtos/radar/src/usecases/cascade_radar_object_detect/chains_cascadeRadarOd.c
    @@ -702,10 +702,10 @@ Void chains_cascadeRadarOd_SetAppPrms(chains_cascadeRadarOdObj *pUcObj, Void *ap
    Chains_cascadeRadarOdAppObj *pObj
    = (Chains_cascadeRadarOdAppObj*)appObj;
    UInt32 portId[SYSTEM_CAPTURE_VIP_INST_MAX] = {
    - VPS_CAPT_VIP_MAKE_INST_ID(VPS_VIP1, VPS_VIP_S1, VPS_VIP_PORTA), /* Master - VIN2A */
    - VPS_CAPT_VIP_MAKE_INST_ID(VPS_VIP2, VPS_VIP_S0, VPS_VIP_PORTA),
    - VPS_CAPT_VIP_MAKE_INST_ID(VPS_VIP2, VPS_VIP_S1, VPS_VIP_PORTA),
    VPS_CAPT_VIP_MAKE_INST_ID(VPS_VIP1, VPS_VIP_S0, VPS_VIP_PORTA),
    + VPS_CAPT_VIP_MAKE_INST_ID(VPS_VIP1, VPS_VIP_S1, VPS_VIP_PORTA),
    + VPS_CAPT_VIP_MAKE_INST_ID(VPS_VIP2, VPS_VIP_S0, VPS_VIP_PORTA),
    + VPS_CAPT_VIP_MAKE_INST_ID(VPS_VIP2, VPS_VIP_S1, VPS_VIP_PORTA)
    };

    /* Fill params for cascade, params are used in cascade Algo */

    Thanks and Regards,
    Piyali
  • 0 in reply to Piyali Goswami
    Prodigy 180 points

    Hi Piyali

    Thanks for sharing the bug information with us.

    Just for my clarification, I am just wondering if the bug is a general problem in the SDK regardless of the board type and the number of antennas or it is a specific problem to us.

    We tried to apply the bug for our radar system, but it seems that it doesn’t make any difference in the system in a large sense (maybe detailed performance would be better, but I didn’t check it). But, after the bunch of tests (builds and runs), I can narrow down the symptom more specifically.

    1. Even with the multiplication of azimuth and elevation tx antennas for our array, we can see a nice (normal) range profile at this moment. In this case, there is no DSP exception happening. In addition to that, when ALGORITHMFXN_RADAR_DSP_PROCESS_MAX_AZIMUTH_FFT in radarDspProcess_if.h = 4U and aoaCreateParams->numAzimuthFFTs       = 4 in chains_cascadeRadarOd.c, both range profile and cloud point results seem to be normal. But, it is not enough to us because we have 6 virtual antennas in elevation axis as you may know and we want to fully utilize them.

    2. Therefore, we should increase ALGORITHMFXN_RADAR_DSP_PROCESS_MAX_AZIMUTH_FFT to 6 or 8(in case it should be power of 2), aoaCreateParams->numAzimuthFFTs       = 6. But when we applied them in the codes there is no DSP exception happening (I speculate that the abnormal range profile would happen due to these parameter setting.

    3. In case ALGORITHMFXN_RADAR_DSP_PROCESS_MAX_AZIMUTH_FFT = 4, aoaCreateParams->numAzimuthFFTs       = 6, there is no DSP exception during the operations. But it shows wrong cloud point results and sometimes it seems that detection is impossible, because it used wrong data in elevation axis.

    This observations are a little bit different from the observations I shared in the previous email. (sorry for that if you are confused with them). please ignore the previous email and refer to this observation. I think at this moment the final solution for our radar is how to increase both aoaCreateParams->numAzimuthFFTs and ALGORITHMFXN_RADAR_DSP_PROCESS_MAX_AZIMUTH_FFT to more than 6, so we can have a higher angular resolution in elevation axis corresponding to 6 virtual antennas.

  • 0 in reply to coolguy
    Prodigy 180 points

    Dear Piyali,

    We found out that ALG_FXN_RADAR_DSP_PROCESS_AOA_MAX_AZIMUTH_FFT in radarDspProcessAoa_priv.h also shuld be larger than 4 to enable 6 virtual elevation antennas.

    With this modification, we cannot see DSP exception anymore. The remaining issue is we cannot still get point cloud results because the number of CFAR detections is zero, in this case.

    I think the remaining would be another story, so if you agree with my thought I will take this posting as resolved and I will post new article after finding more symptoms.

    Before that, please make sure that we should apply the bug you reported us for our radar board system.

  • 0 in reply to coolguy
    TI__Mastermind 30245 points
    Hi Donghan,

    Yes, you should apply the patch.

    Thanks and Regards,
    Piyali