TDA3: Range FFT processing

Khai Trinh

Part Number: TDA3

Hi,

I am trying to figure out in the Vision SDK code when Range FFT begins processing the incoming chirp data. Does it process the moment it gets the first returned chirp or does it wait until the entire chirp sequence finishes before it start processing Range FFT?

I saw a plot in the ProcessorSDK_UserGuide.pdf in Section 3.9.1.2 that has angle information. How do you achieve Angular information? Do you perform a third FFT on the chirp data assuming second FFT result in Doppler information?

Thanks,

--Khai

over 5 years ago

0 Piyali Goswami over 5 years ago

TI__Mastermind 30235 points

Khai,

The FFT waits for the full frame to be recieved before staring the FFT operations.

We perform digital beam forming (multiplication with a steering matrix) for getting the angle information.

Thanks and Regards,
Piyali

0 Khai Trinh over 5 years ago in reply to Piyali Goswami

Genius 4140 points

Hi Piyali,

Thank you.

Would you please point out to me where in the source code (which files) perform range FFT and angle calculation in the SDK. I am using AWR1243 + RVP from D3 Engineering.

One other question about D3. Does TI work with D3 and merge source code to the overall Vision SDK? Is that how it works?

Thanks,

--Khai

0 Piyali Goswami over 5 years ago in reply to Khai Trinh

TI__Mastermind 30235 points

Hi Khai,

The Range FFT and the Angle calculation happens in EVE as part of the EVE library, PROCESSOR_SDK_RADAR_03_05_00_00\ti_components\algorithms\eve_sw_01_19_00_00\apps\fft
PROCESSOR_SDK_RADAR_03_05_00_00\ti_components\algorithms\eve_sw_01_19_00_00\apps\beam_forming

There are wrappers over these library APIs in vision_sdk\apps\src\rtos\radar\src\alg_plugins\alg_fxns

Regarding the D3 source code merge, the D3 team shares the changes with the support and that is merged with the Processor SDK Vision package.

Thanks and Regards,
Piyali

0 Khai Trinh over 5 years ago in reply to Piyali Goswami

Genius 4140 points

Hi Piyali,

Thanks for the pointers to the signal processing code. It's hard for me to follow the code and figure out what it actually does. I then bumped into a paper from TI (attached) discussing how Range, Doppler and Angle are calculated. My question is was the information in this paper actually implemented in the code in Vision SDK.

Thank you,
--Khai

0 Khai Trinh over 5 years ago in reply to Khai Trinh

Genius 4140 points

Sorry, file attachedMIMO Radar.pdf

0 Piyali Goswami over 5 years ago in reply to Khai Trinh

TI__Mastermind 30235 points

Hi Khai,

In addition to the paper mentioned which covers the basics of the radar processing, to understand the processing chain, I would also request you to have a look at ti_components\algorithms\eve_sw_01_19_00_00\apps\docs\EVE_Applets_UserGuide.pdf Section: Appendix D: Radar Processing Data Flow

Thanks and Regards,

Piyali

0 Khai Trinh over 5 years ago in reply to Piyali Goswami

Genius 4140 points

Hi Piyali,

How should I go about constructing the steering angle matrix knowing that it's a matrix of size Num. Antennas x Num of Angle bins? Say if I have 1 TX and 4 RX with angles from -3 to 3 degrees and a bin angle of 0.5 degrees, I will have a steering matrix of 4 x 13. How do you come up with the matrix complex elements within the matrix?

My questions are:

1. Does the steering matrix have to do with the actual physical placements of the RX antennas on the AWR1243 that are separated by d = lambda/2?

2. We are customizing the AWR1243 with our own and attaches it with 4 RX antennas that are separated by N * lambda apart where N is a constant to be defined (maybe 3, 4, etc...), Will this change how the steering matrix need to be to work for our antenna placements? How do we go about coming up with the steering matrix for our case?

Thanks,

--Khai

0 Piyali Goswami over 5 years ago in reply to Khai Trinh

TI__Mastermind 30235 points

Hi Khai,

You can use the Chains_RadarCalculateSteeringMatrix function in vision_sdk\apps\src\rtos\radar\src\common\chains_common_radar.c to calculate the steering matrix. The logic is explained in the function. Kindly have a look at this function.

This takes care of antenna separations which is N*lambda as well.

Thanks and Regards,
Piyali

0 Khai Trinh over 5 years ago in reply to Piyali Goswami

Genius 4140 points

HI Piyali,

Thanks for pointing the processing flow of the radar use case in the EVE_Applets_UserGuide Appendix D. It's quite helpful to understand what the processing looks like as well as the input output format at each processing stage. The output of Range/Doppler FFT is what I have a little trouble at. I understand all the parameters that play into the output buffer format except q. What is q here? The doc said it can be 8, 16 or 32. How and when will it change? At the present time when I run the use case, q is set to 16 when I print out numHorzPoints.

Thanks,

--Khai

0 Piyali Goswami over 5 years ago in reply to Khai Trinh

TI__Mastermind 30235 points

Khai,

The numHorzPoints is something which is internally calculated by the EVE to balance the EDMA pitch and the total availble EVE internal memory.
The number of range points influences the calculation of numHorzPoints.

Thanks and Regards,
Piyali

0 Khai Trinh over 5 years ago in reply to Piyali Goswami

Genius 4140 points

Hi Piyali,

We experience quite a bit of sidelobes in the Range and Doppler FFT in the RDM display. We are wondering what types of FFT window(s) is it currently used? I saw the source file chains_common_radar.c that contains FFT window of all sizes. What type of windowing are they?

Thanks,
--Khai

0 Khai Trinh over 5 years ago in reply to Piyali Goswami

Genius 4140 points

Hi Piyali,

Back to the question on calculating the steering matrix for beam forming alg. The function takes:

Chains_RadarCalculateSteeringMatrix((Int16*)pBeamFormParams->steeringBuf[i],
horzAngleRes, pAr12xxCfg->radarParams[0].numRxAntenna[i],
CHAINS_RADAR_VERT_RES, pAr12xxCfg->radarParams[0].numTxAntenna[i],
antSeparation, maxHorzAngle, CHAINS_RADAR_MAX_VERT_ANGLE);

In our specific Long Range Radar use case, our parameters to this function is different. The existing Short Range Use case in the SDK has:

maxHorzAngle = 60;
horzAngleRes = 2;
antSeparation= 0.5;

My question is that why and how maxHorzAngle and horAngleRes are selected. What factors are considered to determine their values. I am actually more interested in how the horzAngleRes is picked.

in our LRR case, we have these parameters as as we know our antenna beam width is 6 degrees so maxHorzAngle = 6 as bellow:

maxHorzAngle = 6;
horzAngleRes = .2;
antSeparation= 20;

But horzAngleRes was picked out of the blue. I am not sure what value should this be?

Also, in chains_common_radar.c, ChainsCommon_ar12xxSetBeamFormParams() prepares parameters for beam forming Alg, it has the following two lines:

pBeamFormParams->beamFormingScaling = 15; // Khai: does beamFormingScaling need to be different for LRR?
pBeamFormParams->energyScaling = 15; // Khai: does beamFormingScaling need to be different for LRR?

These two parameters are selected for the short range radar use case with +-30 degrees @ horzAngleRes = 2. Again, would these parameters need to be changed for our LRR use case?

Thanks,
--Khai

0 Piyali Goswami over 5 years ago in reply to Khai Trinh

TI__Mastermind 30235 points

Khai,

This is a hanning window for example. You can update this based on the windowing function of your choice.

Thanks and Regards,
Piyali

0 Piyali Goswami over 5 years ago in reply to Khai Trinh

TI__Mastermind 30235 points

Khai,

There are 2 things regarding the angle resolution. One is the number of antennas which will determine the true resolution with which you can distinguish 2 objects. The second is at what resolution you would like to find the peak. This is given by horzAngleRes. The horzAngleRes is more of a software thing where after beam forming you can detect a peak at 0 deg or 0.2 deg and so on. This does not make sure that if two objects are 0.2 degree apart then the objects are distinguishable. This is based on the physical antenna configuration.

The choice of 0.2 versus something else is determined by what you would like to report as the output.

Beam forming scaling and energy scaling are factors you can use to make sure you are able to detect the peaks clearly. They make sure the data is not saturating the 16 bit containers when performing the matrix multiplication and peak detection. You can take a look at the kind of data you are generating in the LRR case and see if the data is going beyond 16 bit adjust the scaling accordingly. This can be kept the same as SRR if there is no saturation due to underscaling or loss of data due to over scaling.

Thanks and Regards,
Piyali

0 Khai Trinh over 5 years ago in reply to Piyali Goswami

Genius 4140 points

Hi Piyali,

How can I debug into BeamForm data when it's done at the low level. Is it debuggable? All i have access to at this point is the detection descriptor.
Thanks,
--Khai

0 Piyali Goswami over 5 years ago in reply to Khai Trinh

TI__Mastermind 30235 points

Khai,

As discussed yesterday during the call, the beam form code is availble in the EVE algorithms foder under ti_components for single stepping and debugging.

Thanks and Regards,
Piyali

0 Khai Trinh over 5 years ago in reply to Piyali Goswami

Genius 4140 points

typedef struct
{
UInt32 winCoefficients[RADAR_FFT_MAX_NUM_STAGES];
/**< winCoefficients */
UInt32 enableWindowing;
/**< Enable Windowing */
UInt32 enableDcoffset;
/**< Enable Dcoffset */
UInt32 enableInterferenceZeroOut;
/**< Enable InterferenceZeroOut */
UInt32 enableDopplerCorrection;
/**< Enable DopplerCorrection */
UInt32 windowingScaleFactor;
/**< Enable Windowing */
UInt32 scaleFactors[RADAR_FFT_MAX_NUM_STAGES];
/**< Enable Windowing */
UInt32 interferenceThreshold;
/**< Enable Windowing */
UInt8 enableOverFlowDetection;
/**< Set it to 1 to enable overflow detection else set it to zero.
* If enabled the applet will return the scale factors to be applied
* at each stage as part of outArgs. if scale factors are zero for
* each stage then there is no overflow detected.
*/
UInt32 windowCoeffAddr[RADAR_FFT_NUM_POINTS_MAX];
/**< Window coefficient buffer addresses supported */
}AlgorithmFxn_RadarFftAlgCreateParams;

Above is the FFT Input Param data structure. Please provide the meaning of the parameters. More specifically we are interested in windowingScaleFactor, interferenceThreshold, enableOverFlowDetection & scaleFactors[RADAR_FFT_MAX_NUM_STAGES]. What do they do and how they play in the FFT processing.

Thanks,
--Khai

0 Khai Trinh over 5 years ago in reply to Khai Trinh

Genius 4140 points

It looks like the Range and Doppler Map data are being threshold. Why it said that is that the noise floor data seems to have been replaced with 0s. Is there a way to get the RDM data without thresholding applied?
Thanks,
--Khai

0 Khai Trinh over 5 years ago in reply to Khai Trinh

Genius 4140 points

Another question we have is the parameters to CA-CFAR Peak Detection. The formula for detecting CUT > NoiseFloor * C1/2^C2. Our question is What is NoiseFloor and how is NoiseFloor calculated and where is it done so?

Thanks,
--Khai

0 Piyali Goswami over 5 years ago in reply to Khai Trinh

TI__Mastermind 30235 points

Khai,

You can refer to section 4.1.1.10 FFT_TI_InArgs of the eve_sw_XX_XX_00_00\apps\docs\EVE_Applets_UserGuide.pdf for details regarding the different parameters. For quick reference I am pasting them below:

windowingScaleFactor: Scale factor to be used at windowing operation. This factor is internally used to right shift ( along with rounding ) the output after multiplication by windowing coefficient. Mathematically if x is the output and n is the scaling factor then the output would be (x + 1 << ( n - 1)) >> n. This is only required if windowing is enabled by setting enableWindowing = 1

interferenceThreshold: This corresponds to interferenceZeroOutThreshold
Threshold to be used for interference zero out. This is the maximum absolute value of the input data above which that sample would be set to zero. This is only required if enableInterferenceZeroOut is set to 1.

enableOverFlowDetection : Set it to 1 to enable overflow detection else set it to zero. If enabled the applet will return the scale factors to be applied at each stage as part of outArgs. if scale factors are zero for each stage then there is no overflow detected

scaleFactors: Scale Factor to be used for each stage of FFT. This factor is internally used to right shift ( along with rounding ) the output after multiplication by twiddle factor (in Q15). Mathematically if x is the output and n is the scaling factor then the output would be (x + 1 << ( n + 15 - 1)) >> (n + 15). Each stage of FFT grows by certain amount ( 1 bit or 2 bit for radix 2 or radix-4 respectively). Hence to avoid overflow each stage scale factor should be chosen such that input data is within 15 bit. It is important to note that in our implementation twiddle factors are stored in Q15 format and hence if a particular stage scale factos is n then its effective scaling applied at output would be (15 + n). Note that if enable32bitsIntermResults=1, in order to maintain the maximum dynamic range of 32-bits for the intermediary stages, no scaling is performed at these intermediate stages. Only when output is 16-bits, to prevent overflow in the last stage, scaling is applied. Note that the user can still specify scale factors for the intermediary stages. The applet will simply sum them up, add them to the last stage's scale factor.

Thanks and Regards,
Piyali

0 Piyali Goswami over 5 years ago in reply to Khai Trinh

TI__Mastermind 30235 points

Khai,

The range doppler heat map sets the noise floor data to 0 based on the binRange[0] value. if you keep this really low then the noise floor would not be removed from the range doppler heat map.

Code references:
PROCESSOR_SDK_RADAR_03_XX_00_00\vision_sdk\apps\src\rtos\radar\src\alg_plugins\alg_fxns\radardrawfftheatmap\radarDrawFFTHeatMap_priv.c
Function: RadarDrawFFTHeatMap_processData
Code snippet to search for: if (energy > pCreateArgs->binRange[0])

What you should change is in the function: ChainsCommon_ar12xxSetFFTHeatMapParams, file: PROCESSOR_SDK_RADAR_03_XX_00_00\vision_sdk\apps\src\rtos\radar\src\common\chains_common_radar.c

Change the range array to set the appropriate thresholds to allow drawing all energy bins.

Thanks and Regards,
Piyali

0 Khai Trinh over 5 years ago in reply to Piyali Goswami

Genius 4140 points

Hi Piyali,

Welcome back and thanks for responding to my inquiries again.

Is there any one of the FFT control parameters above instruct the FFT processing in the EVE to remove the noise floor in the RDM data?

Thanks,

--Khai

0 Piyali Goswami over 5 years ago in reply to Khai Trinh

TI__Mastermind 30235 points

Khai,

FFT does not remove the noise floor.

Thanks and Regards,
Piyali

0 Piyali Goswami over 5 years ago in reply to Khai Trinh

TI__Mastermind 30235 points

Khai,

The CFAR-CA noise floor calculation is described in the eve_sw_XX_XX_00_00\apps\docs\EVE_Applets_UserGuide.pdf Appendix D 2. Peak detection section. Kindly go through this and let us know if you have further questions.

Thanks and Regards,
Piyali

0 Khai Trinh over 5 years ago in reply to Piyali Goswami

Genius 4140 points

Hi Piyali,

I am not talking about how the RDM data is being mapped to HeatMap plot. I am concerning about the output and Range/Doppler FFT data which we call it RDM data. This data should have both noise and targets info in the 2-D array. There is one RDM for each RX with memory structure defined in the EVE Appendix D Figure 5. This is the data we have it output over Ethernet to our AI engine. We need the RDM data without noise floor removed.

Our initial analysis seem to be that the RDM noise floor has been removed from the data. That's why I have a series of questions about FFT input parameters that potentially can alter /remove the noise floor from the data.

Based on your answers, FFT input parameters doe not remove noise floor. Am i reading that correctly?
Thanks,
--Khai

0 Khai Trinh over 5 years ago in reply to Khai Trinh

Genius 4140 points

Hi Piyali,

There is this param in the FFT input structure that has no description in the EVE Doc
pFFTParams->algCreatePrm[0].interferenceThreshold = 1500;

What is this and could this remove the noise floor?
Thanks,
--Khai

0 Khai Trinh over 5 years ago in reply to Khai Trinh

Genius 4140 points

Hi Piyali,

I think the above param is called interferenceZeroOutThreshold in the EVE Doc. This value is set to 1500 and then set again to 0 in the code. So it's effectively 0.

But there still another param pFFTParams->algCreatePrm[0].enableDcoffset = 1; Base on the EVE doc description below:

Set it to 1 to enable DC offset calculation else set it to zero. DC offset will find the average in both real and imaginary direction and subtract it from each input sample.

Can this potentially also remove noise floor?
Thanks,
--Khai

0 Piyali Goswami over 5 years ago in reply to Khai Trinh

TI__Mastermind 30235 points

Khai,

Yes the FFT does not remove the noise floor as a dedicated operation. One thing that may be removing the noise floor is the choice of scale factor. if the scale factors are high then the noise floor would be scaled down to 0.

Thanks and Regards,
Piyali

0 Khai Trinh over 5 years ago in reply to Piyali Goswami

Genius 4140 points

Hi Piyali,

Would you please be specific about which scale factor exactly that can put the noise floor to 0 if not the list of FFT input parameters?

Thanks,

--Khai

0 Piyali Goswami over 5 years ago in reply to Khai Trinh

TI__Mastermind 30235 points

Khai,

We have discussed this during our call, that the scale factors that need to be modified are:
UInt32 rangeScaleFactors[FFT_TI_MAX_NUM_STAGES] = {2, 2, 2, 2, 2};
UInt32 dopplerScaleFactors[FFT_TI_MAX_NUM_STAGES] = {2, 2, 2, 2, 2};

pFFTParams->algCreatePrm[0 or 1].windowingScaleFactor = 15;

Thanks and Regards,
Piyali

Processors

Processors forum

TDA3: Range FFT processing