AWR1642BOOST: detected object amplitude and frequency extraction

Hi Gareth,

Please give me 2 days' time to go through the paper you have shared and let you know the feasibility for an application using our device.

Regards,

Kaushik

Hi Kaushik, have you had time to look into the above? Kind Regards

Hi Gareth,

I am still in the process of going through your paper. Please expect a delay as this would take some time. In the meanwhile, any information you can provide me with of your requirements based on your understanding would speed up the process.

Gareth Cooper said:

I want to understand if I can get the information from the AWR1642BOOST UART without the DCA1000. I don't have access to a DCA1000 so am hoping the data will be available in the slow data path.

Additionally, based on your question above, the DCA1000 is used to capture the ADC data streamed over LVDS and send it via ethernet for further processing. UART on the device is only meant to stream out smaller data packets such as detected point cloud and streaming out the entire ADC data would not be possible. UART has a max baud rate of 921600 as we use in our demo.

Regards,

Kaushik

Thank you Kaushik.

My question around the DCA1000 vs. UART was more about what could be achieved - I understand the constraints mentioned. I was hopeful that only a subset (of useful information) could be sent to the UART port. I'm not sure is CAN or SPI would also be an option in this case.

Requirement wise initially, is pretty much as per the paper. I want to emulate the experiment for tag identification. I believe this has some similarities to other methods such as chipless RFIDs and Van-Atta arrays. This approach has various benefits for my target end-state.

Thanks,

Gareth

Hi Gareth,

Can you briefly explain what kind of data rates or sizes you are looking at?

Regards,

Kaushik

Hello,

I can only go on some sort of estimation from the paper - happy to be corrected. Given there are multiple objects to be detected (say 100 over a reasonably small area) and latency isn't the biggest issue (i.e. non-real time), then I see feature and location extraction to be the main data elements. So, 25 features, plus XYZ data - around 30 variables per object. 300 variables (per frame?) @  (approx float size of 4bytes) ~ 1200 bytes per frame, not including header/transmission overheads of course.

Does that help at all, I'm not very familiar with calculating data rates for this type of application.

Thanks,

Gareth

Hi Gareth,

I see that mmWave SDK user guide mentions different UART baud rate options for application to stream object data.

So you need to calculate data rate and size requirement by yourself if your requirement can meet at max UART baud rate possible. Else you can opt other interface available SPI, CAN or stream over DCA1000 (LVDS->Ethernet).

Here is application refer to send object data over CAN https://dev.ti.com/tirex/explore/node?node=A__AOYjo76-dpIyrvo9ogbz3g__radar_toolbox__1AslXXD__LATEST

OOB/mmw demo in SDK 3.5 have an option to stream object data over LVDS (and capture using DCA1000EVM): mmwave_sdk_03_06_00_00-LTS/packages/ti/demo/xwr16xx/mmw/mss/mss_main.c: 

Thank you, yes that might help with the UART communications. The main question was around the ferrotag paper though.

Best Regards,

Gareth

Hi Gareth,

Going by your calculations, a rate of ~(1200 Bytes + Header/Extras) per frame for your application is supported by UART (with default dataport baud rate config).

Regards,

Kaushik

Thanks again.

The original question was centered around the derivation of Amplitude and frequency for each detected object. 

What approach is suggested for this activity - should I be intercepting the data directly in CCS somehow, or are there other options?

Thanks,

Gareth

Hi Gareth,

CCS is an IDE for development on our EVMs. Derivation of amplitude and frequency (or implementation of any algorithm for that matter) should ideally be performed on the device itself. Your outputs can then be sent out via any peripheral such as UART.

Regards,

Kaushik

Hi Kaushik, I was thinking more along the lines that the application could be debugged etc through CCS and therefore would be able to view the data coming directly from the device at that point in time.