AWR2544LOPEVM: awr2544 instrumentation LVDS based streaming - bin file has less data than expected

A quick update, I have also tried with studio_cli from radar_toolbox_3_00_00_05, but the same observation.

Hello QHLam,

Can you verify if the last data present on the ADC buffer is present in the bin file which is present in the DCA?
I want to understand whether the DCA capture is wrong, or the ADC data is not getting populated.

Regards,
Saswat Kumar

Hello Saswat, 

I did the test with different configs (changed in no of ADC samples), and observed that I was able to get correct bin file size whenever no of ADC sample is less than 512 e.g. 256, 384,  the last data present on ADC buffer also present in UDP packet from wireshark and saved properly into bin file. 

However, only half size saved into bin file whenever no of ADC samples was greater than 512 (e.g. 640, 768). More details please refer to the attached snapshot.

I also extended the frame period, but it didn't help. Perhaps it was the firmware issue, cbuff settings or adcbuf_config  may need to change? Please let me know if you have any ideas? Thanks. 

lvds_test.pdf

attach pdf file for more details. 

1423.lvds_test.pdf

Hello QHLam,

That is why I am asking, on the device ADC buffer memory can you check whether the last ADC data value is actually present in the DCA capture tool.
This will help us identify whether lesser data is being generated or lesser data is being captured.
If you compare the UDP and the bin file it will be same as the UDP packet is what is captured via DCA1000EVM

Regards,
Saswat Kumar

Hello Saswat, 

I'm not sure what you mean the DCA capture tool. I don't exactly know if there's a way to check if DCA1000EVM FPGA has received the last ADC data via LVDS. I did check the UDP data sent by DCA hardware and data saved into bin file by Studio CLI. 

Here's the data flow: 

[ADC buffer] --> [CBUFF] --> LVDS Interface --> [DCA1000EVM FGPA] --> Ethernet (UDP) --> [Studio CLI] --> [bin file]

Can you please let me know a bit details of your suggestion about DCA capture tool? 

Thanks. 

Hello QH Lam,

The DCA capture tool is what is integrated along with the studio cli.
What I am asking is when the application has ran, can you connect to the ADC memory and check what is the data and compare with the last packet that you received?

Also it will be a long weekend holiday right now, so please expect reply next week.

Regards,
Saswat Kumar

Hello Saswat, 

Yes, that's what I did and shared with you the test results. 

I had JTAG connected on awr2544 to view the ADC memory. And from studio cli side, I had wireshark to monitor UDP packet sent by DCA1000EVM hardware, as well as looked into the bin file to view the data saved after application run completed. 

And here's the summary: 

• Data collection with config #1: 1 frame, 200ms frame period, 4 Tx, 4 Rx, TDM mode, 256 ADC samples, 128 chirps.

--> Checked the last ADC data value presented in the last UDP packet and saved into bin file correctly. [Passed]

--> Bin file size, after application has ran, was as expected. [Passed]

• Data collection with config #2: 1 frame, 200ms frame period, 4 Tx, 4 Rx, TDM mode, 512 ADC samples, 128 chirps. (same as cfg #1, just change number of adc sample to 512 for better range resolution)

--> Checked the last ADC data value didn't present in the last UDP packet and didn't save into bin file. [Failed]

--> Bin file size, after application has ran, was only a half of the expected size. [Failed]

• Data collection with config #3: 1 frame, 200ms frame period, 4 Tx, 4 Rx, TDM mode, 768 ADC samples, 128 chirps. (same as cfg #1, just change number of adc sample to 768)

--> Checked the last ADC data value presented in the last UDP packet and saved into bin file. [Passed]

--> However, bin file size, after application has ran, was only a half of the expected size. [Failed]

Hope the test results are helpful for you to identify the possible causes. 

Thanks, 

QHLam

Hello Saswat, 

I think I figured out the root cause. It was because the waveform profile config I used, the chirp time was shorter than the required time for the generated ADC data to be transferred. I extended the chirp idle time, then I got the ADC data transferred and captured properly by DCA capture tool. 

profileCfg 0 77 3.5 3.5 23 0 0 160 0 512 40000 0 0 36

The limitation regarding ADC data transfer rate already mentioned in mmwave_plus_sdk_release_note. (Point #6)

However, it's still a bit unclear to me that the profile config needs to ensure the generated data per chip can be transfer within chirp idle time. 

ADC data transfer rate is limited by HSI Clock configured in SDK (1000MHz which is
500 Mbps); ensure the generated data per chirp can be transferred within chirp idle
time.
==> Ensure that Chirp idle time > ADC data per chirp / 500 Mbps where ADC
data per chirp = Number of ADC samples * Number of Rx * 16 bits.

Per my understanding, ADC buffer is a ping/pong buffer, so just need to ensure that the generated data per chirp can be transferred with chirp cycle time (idle + ramp end time). 

Please let me know if my understanding is incorrect. 

Thanks, 

QHLam