AWR2944EVM: How to change the data in Vector multiplication Cofficient RAM?

Hi,

Just a quick update:

The customer has been able to assign a value to the memory space pointed to by the HWA_RAM_type_VECTORMULTIPLY_RAM and has also converted the number to be written to RAM through the function mathUtils_asymQuantInt().

Now the data written is [0,10,1,...] ], but the results are still not correct. The resulting VA plot is as follows:

Thanks and regards,

Cherry

Hi,

The result after modifying the HWA_RAM_type_VECTORMULTIPLY_RAM is shown in the following figure:

But the side lobe of the 2944 is a little high. Are the above results correct?

The customer does not have the configuration window function and should output after the FFT after ABS and log2 have been completed.

According to the TRM, the output should be 16 bits of data, with the upper 8 bits being 0 and the lower 8 bits being the output data.

But the actual data read out is typically not 0 in the upper 8 bits. Why?

The processing block diagram is shown in the second figure (from the TRM).

Thanks and regards,

Cherry

Hi Cherry,

Cherry Zhou said:

A total of 43 bits of data after zeroing between 16 virtual channels are 3DFFT, all 16 virtual channels are horizontal antenna virtual channels.

1)  I'm unable to understand this line, can you please rephrase or explain the same little differently?

2) Is this just an observation or a question?

3) cmultScaleEn is applicable only in CMULT mode 0101b. vecMultiMOde1RamAddrOffset indicates the address from where your vector with which your input samples are multiplied starts with. "The customer sets cmultScaleEn to disable because each iteration reads 43 bits of data into the Hwa memory" -> What does this mean? 

You can directly load data into the vector coeff RAM using memcopy or EDMA before triggering the HWA by setting CMULT_MODE is set to 0b0000. If not, the access to the RAM will be locked.

What value is required to change if you want to keep the sample read unchanged? -> CMULT mode 0110b resets the start address of the vector coeff RAM by default for each iteration if that is what you meant by this question.

Mainly, there is some ambiguity concerning the "43 bits". What are they trying to achieve and how are they trying to do so?

In your latest reply, the sidelobes seem to be a result of not applying windowing for your input samples. Can you confirm if the effect is minimized with the application of windows?

Also, have the confirmed the output of FFT ABS?

Regards,
Kaushik

Hi Kaushik,

Thanks for your response.

1. The reason for reading 43 points into HWA is that the front end of the newly designed antenna is not a uniform linear array, and it is necessary to perform lamda/2 interpolation in the middle of the 16 virtual channels.The final result is 43 bits.

2. The problem with cmultScaleEn is now fixed. If cmultScaleEn is set to Enable, the input data will be complex multiplied with the values of 12 I,Q channels. But now the input number exceeds 12 in each iteration, so set cmultScaleEn to Disable, and let the input number be multiplied by the number in coeff RAM.

3. Coeff RAM can be written in dopplerHWA_config. After the number [0,1,0,1....] saved in the coeff RAM is converted by the function mathUtils_asymQuantInt, each input number can be multiplied with the number in the coeff RAM and remains unchanged.

4. After inverting the output 3DFFT result according to the output formatter in 2944TRM, it can be the same as the 3DFFT done by matlab with the 2DFFT result.

5. After verifying the 3DFFT, a new problem appeared, about Local Maximum detection and os-cfar. Tested in the dark room, used the serial port to print out the output results, and found that 64-point 3DFFT was performed. When the detected peak appears in the last angle channel (63), the signal amplitude on the angle channel (0) which is increased by 1 will be higher than that on the (63) channel. This part uses the SDK's own configuration. The customer only modified the points of the angle FFT from 48 points to 64 points. May I ask what is the reason for this? The customer checked the information of all points detected by CFAR through the serial port, and found that the value of channel 0 was detected by os-cfar.

Thanks,

Annie

Hi Annie,

Glad to hear the customer has been able to progress!

In your first point, I understand the customer's use case but, can you confirm if the result is 43 bits or 43 bytes? In the earlier case, I would like to know how the 43 bits are fed into the HWA using the input formatter if possible.

For the concern in 5) It seems like there is a bin mismatch for angle FFT. Is my understanding correct? With higher FFT size, your energy would be more appropriately distributed across the bins which is why you can see a small shift. This delta can change the bin that the CFAR picks. If possible, can you share the plots that you are referring to?

Regards,

Kaushik

Hi Kaushik,

1.

Kaushik Gowda said:

can you confirm if the result is 43 bits or 43 bytes?

43 refers to 43 8-byte complex numbers, i.e. the result of 2DFFT. 

2.

Kaushik Gowda said:

For the concern in 5) It seems like there is a bin mismatch for angle FFT. Is my understanding correct? With higher FFT size, your energy would be more appropriately distributed across the bins which is why you can see a small shift. This delta can change the bin that the CFAR picks. If possible, can you share the plots that you are referring to?

a) Measurements in the darkroom found that the local maximum test did not detect the channel with the highest amplitude of the 64 angle channels in the current dopplerBin in the beam(angle)-doppler plot. Only the maximum value is currently observed on the 0 th angle channel, but local max detects the peak of the 63 th angle channel. The result is not plausible whether a loop or a non-circular local max is used for detection. May I ask what caused it?

b) The customer outputs all of the results of OS-cfar detection on the serial port and detects the peak of the 0 th angle channel in OS-cfar. However, after combining the results of CFAR and BitMask detected by local max in function DPU_DopplerProcHWA_extractObjectList, the peak value of channel 0 can no longer be detected. And the peak of the 63 th angle channel still exists.

Is it possible to assume that the highest peak is not detected by local max? Of course, there is a correct case where the 63rd angle channel is higher than the 0th angle channel and the 62nd angle channel.

3. The customer tried to print the result of the local maximum test on the serial port and the result was bitmask, the peak detected was 1, otherwise 0. See page 5844 and page 5845 of the 2944TRM for the format of the output.
The customer's 3DFFT is 64 points, and should be stored in 2 32-bit spaces, and there is no high bit of zeroing, but the serial output is 0 for all the upper two bytes of 32-bit data.

In the function DPU_DopplerProcHWA_extractObjectList, use the pointer feed to store the local maximum bitmask in rangeBin units of 32 dopplerBin. So a rangeBin requires a total of 64 UINT32_t spaces, and local_bitmax is of type UINT32_t*. 

 for(local_max_pri=0;local_max_pri<64;local_max_pri+=2)

        {

            CLI_write("%x %x\r\n",*(result->local_bitmax+result->objOut[energy_max_index].rangeBin*64+local_max_pri),*(result->local_bitmax+result->objOut[energy_max_index].rangeBin*64+local_max_pri+1));

        }

 

Does the bitmask reside in memory in the following order:

DopplerBin0[ant0,ant1...ant63],dopplerBin1[ant0,ant1 ... Ant63],..., dopplerBin31

Thanks and regards,

Cherry