IWRL6432BOOST: rangeproc_test - file length and header parameters misunderstanding

Alexander Mruga

Part Number: IWRL6432BOOST
Other Parts Discussed in Thread: IWRL6432AOPEVM

Tool/software:

I am currently preparing for R&D of sensors and doing various experiments with IWRL6432BOOST/IWRL6432AOPEVM boards and have reached the Range DPU test. This is the test ..\MMWAVE_L_SDK_05_05_03_00\examples\datapath\rangeproc\xwrL64xx-evm\m4fss0-0_freertos

While studying the test, I encountered a discrepancy between the size of the data file and the data specified in the header of this file. When loading the radar ADC source/configuration as "..\BinData\major_motion\adc_data_0001_CtestAdc6Ant.bin" with a size of 5898256 bytes, I see the following data in the header (first 4 int32_t values):
numTxAntennas = 2
numRangeBins = 64
numChirpsPerFrame = 64
numFrames 60

Running the test and inspecting rangeproc_test_main.c in the debugger shows that a single frame of radar data is read from the file as a sequence of fragments of 384 samples of 3 receive antennas for all 64 chirps.

For the case of numRxAntennas = 3, which is hardcoded in the test, we have 60*64*3*128=1,474,560 samples, or 2,949,120 bytes. However, the file is 5,898,256 bytes in size. The header is 4*4=16 bytes, the rest is the data block: 5,898,256 - 16 = 5,898,240 bytes, which is twice as much.

It looks like either numChirpsPerFrame should be 128, or the numFrames should be 120. I am not considering the option that the calculation should take into account the number of transmitting antennas that double the number of samples in the frame, because I am analyzing the code.

Please clarify where I am wrong?

Thank you.

2 months ago

0 Alexander Mruga 2 months ago

Prodigy 210 points

Sorry for wrong copy-paste of the header. The header is:

header (first 4 int32_t values):
numAdcSamples = 128
numVirtualAntennas = 6
numChirpsPerFrame = 64
numFrames 60

0 Nathan Block 2 months ago in reply to Alexander Mruga

TI__Mastermind 37805 points

Hi,

If you have 64 range bins, you have 128 ADC samples.

6 virtual antennas/chirp * 128 ADC samples / chirp * 64 chirps/frame * 60 frames should be the correct calculation here because you have 3RX and 2 TX antennas.

Best,

Nate

0 Alexander Mruga 2 months ago in reply to Nathan Block

Prodigy 210 points

Hi,
I completely agree with your calculation. But I saw something different studying the code and the test in the debugger. Look, the test reads one frame of ADC data in a loop:
```

/* Read chirps from the file */
for(i = 0; i < testConfig.numChirpsPerFrame; i++)
{
if (!endOfFile)
{
/* Read one chirp of ADC samples and to put data in ADC test buffer */
numReadSamples = fread(gAdcTestBuff, sizeof(uint16_t), numAdcSamplesPerEvt, fileId);
if (numReadSamples != numAdcSamplesPerEvt)
{
endOfFile = true;
}
}

/* Manual trigger to simulate chirp avail irq */
errorCode = EDMAEnableTransferRegion(
baseAddr, regionId, EDMA_APPSS_TPCC_B_EVT_CHIRP_AVAIL_IRQ, EDMA_TRIG_MODE_MANUAL); //EDMA_TRIG_MODE_EVENT
if (errorCode != 1)
{
DebugP_log("Error: EDMA start Transfer returned %d\n",errorCode);
return;
}

ClockP_usleep(1000); //1s sleep

} /* end of chirp loop */

```
Preliminarily, numAdcSamplesPerEvt is calculated as:
```
numAdcSamplesPerEvt = (testConfig.numAdcSamples * testConfig.numRxAntennas);

```

So it turns out that only half of the ADC data is read from the `adc_data_0001_CtestAdc6Ant.bin` file! Same problem when testing the Radar Cube with a reference to the ground-truth Cube from the `adc_data_0001_CtestAdc6Ant_demo_RadarCube.bin` file!

Everywhere you use 'testConfig.numRxAntennas', not 'testConfig.numVirtualAntennas'!?

Please take a look at these arguments and my first post with calculations.

Thanks.

0 Nathan Block 2 months ago in reply to Alexander Mruga

TI__Mastermind 37805 points

Hi,

Is it possible that the number of chirps/frame handles this? It can be somewhat ambiguous when you use two TX's whether the # of chirps/frame is the number of chirps per transmitter per frame, or whether it's the number of chirps per frame for all transmitters. If you look at the rangeProc documentation, it does the range FFT on each chirp. If you use two TX antennas, it computes the range FFT once for each TX antenna. If there is a bug here like you're describing, then you should be able to double testConfig.numChirpsPerFrame without the code breaking. Is that accurate?

Best,

Nate

0 Alexander Mruga 1 month ago in reply to Nathan Block

Prodigy 210 points

Hi,

Thanks for the good advice to look at the test more simply. Indeed, the number of chirps per frame is often interpreted ambiguously in TI documents and other sources. Even in the same sources, sometimes this number in one place corresponds to the number of transmissions to the antenna, sometimes to a set of virtual antennas. It is sometimes difficult to correctly build the entire processing up to the generation of heatmaps because this confusion does not provide clarity, and the code often contains magical divisions by 2 or 3 to get the number of Doppler chirps and confuse things even more. So I am studying all the tests contained in the SDK to thoroughly understand this. Thank you very much to the TI company for this opportunity.

I took your advice and doubled the number of numChirpsPerFrame. After that, I had to make many more edits to make the test work correctly. So actual test which is in the SDK now, it examines only half of the radar cube. By the way, the file `adc_data_0001_CtestAdc6Ant_demo_RadarCube.bin` which is used as a ground truth has the second half filled with zeros, so I replaced it too. Now everything works correctly for me and there is clarity in working with the radar.

Thank you very much,

Regards

Sensors

Sensors forum

IWRL6432BOOST: rangeproc_test - file length and header parameters misunderstanding