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.

TDA3: Vision SDK Radar Use Case 3: multi_radar_capture_fft_display

Part Number: TDA3

I have a question about this use case. The output metadata and the output of second FFT data don't seem to correlate. I captured a frame of data using the Network_Rx tool on an external PC. I got:

[DSP1  ]     43.283017 s: AlgorithmFxn_RadarFftProcess: numChunks 1, numHorzPoints 16, numVertPoints 1024, offsetBwAntennas 64, pitch 256, numAntennas 4

However, the captured Range/Doppler Map frame size was 1,048,576 bytes. We are trying to parse this RDM data using the above metadata. There is a factor of 4 missing based on the parsing information given in the EVE_Applets_UserGuide.pdf Appendix D Figure 5. Can you please show me hoe this data can be parsed on the external host?

Thanks,

--Khai

  • Hi Khai,

    Can you please check the data type that is being used for the Network Transmit from the TDA?
    You can place a break point on the code in the function NetworkTxLink_drvSendData in the IPU1_1 to see the data type that is getting used and the cmdHeader.dataSize getting set. This would help us understand if the transmit from TDA has an issue or the reception in your environment has an issue.

    Thanks and Regards,
    Piyali
  • Hi Piyali,

    I did some extensive debugging and I know why the RDM data is 4x the amount of that described in its MetadataDescriptor. It's all because of the number of chirp Profile used. When 2 Profile is used, the RDM buffer size is 1048576 bytes. When 1 Profile is used, then this number reduces by a factor of 4 to 262144 bytes. What I don't know is why 2 Profile ups that by 4x and not 2x. Do you have a reason for that?

    Please see attached pics and you will know what I mean.rdmDataAtNetworkTx.zip

    Thanks,

    --Khai

  • Also, if 2 profiles is used, how then does the data format look like for parsing?
  • Khai,

    Thanks for the analysis!

    Are you running this independently? SRR and LRR or this is something you are switching at run time using advanced frame?

    The meta data does not seem correct for the LRR case. The numVertPoints should have been higher. Can you set the first profile to the LRR config to check if this is something wrong in the fact that the LRR is in the 2nd profile versus first?

    Thanks and Regards,
    Piyali
  • Hi Piyali,

    Thanks for all the responses at once. They really help my understand of the software much better. As for this case, we only use 1 chirp Profile which is configured for LRR. We haven't even gotten to play with Advanced Frame config. We are still sticking with Normal Frame for now. So, I thought with that LRR metadata number for single Profile makes perfect sense as the buffer size matches that of the metadata description. Now I am puzzle since you said it's low.

    Thanks,

    --Khai

  • HI Piyali,

    So once we got LRR case config and work correctly, we want to be able to detect at short range as well. Does that mean we have to have a short range Profile and exercise Advanced Frame mode?

    If so, please describe a bit how this works and what kind of setup is required? Also, how do we interpret the data coming out of Ethernet to make sense of it?

    Thanks,
    --Khai
  • Khai,

    I say this because, I see that the width is 2048 (1024 samples) and the height is 128 in the 2nd profile. versus 512 (256 samples) and height of 128 in the first profile. However, the meta data for both look the same. 16 (numHorz), 1024 vertpoints.

    The second profile 1024 should have been larger as the range dimension is higher.

    Thanks and Regards,
    Piyali
  • Now I understand what you are talking about. You were looking at the zip file I attached. Let me answer your question and you can make sense of what I am doing here so you can answer me question correctly. The pics in the zip file was taken using the SRR use case built in to Vision SDK. I simply run and captured that for debugging. The SRR use case has 2 chirp profiles defined. I tested it with 2 profiles and then 1 profile by simply commenting out 1 profile and rerun. All this are done using Normal Frame config. The results of the RDm and metadata are captured in the zip file I provided. As I asked before, why there is a 4x in buffer size when 1 profile is used versus 2 profile is used. You haven't yet answer me on this maybe because you don't know how I tested here. If you can, please do what I did on your side and you will see the results I captured.

    Now, let's move to the LRR case.
    You asked "Are you running this independently? SRR and LRR or this is something you are switching at run time using advanced frame?"

    Yes, we are running this independently. We don't yet employed dynamic switch from SRR to LRR at the moment. Right now we only have LRR Profile config. When I say we use 1 Profile, I meant in the code I only have 1 Profile defined and populated the rlProfileCfg_t data structure.

    Thanks,
    --Khai
  • Khai,

    As discussed yesterday, when 2 profiles are used the full buffer allocation in DDR is based on max parameters. This is what is used by the framework to allocate DDR memory. You need to use the EVE calculated metadata to understand the arrangement within this buffer.

    Thanks and Regards,
    Piyali