MMWCAS-DSP-EVM: cascade capture only demo question

Any advice on this? It's been nearly a week with no response.

Hi,

Please refer to ~\ti_components\networking\nsp_gmacsw_4_16_01_01\docs\NSP_TFDTP_Design_UserGuide.pdf for details.

Regards,
Stanley

Hi, Stanley. Thank you for responding. Your reference does not answer my question, however.

My question was: How does one identify the start and end of a frame of radar data in the incoming TFDTP packets? And how does one find the ADC sample corresponding to a given receiver, transmitter, chirp and sample index This is not explained in the TFDTP design guide.

Through sheer experimentation I've determined one frame of radar data is sent distributed over 4 tfdtp frames (one for each chip, presumably). But I'm still unable to determine how to find the samples corresponding to a particular transmit-receive antenna pair, or how the antenna indices map to antenna locations on the PCB. Please advise.

You can refer to ch4 in ~/vision_sdk/docs/Radar/ProcessorSDKRadar_DataSheet.pdf.

Hi again. Thanks for your quick reply. I have actually been through the processor sdk radar datasheet before and, while the diagrams on page 18 are helpful they leave some questions unanswered.

Is each VIP buffer is simply dumped into a TFDTP frame and sent out over network tx? If so, how do I know which TFDTP frame corresponds to which VIP buffer? Also, how is the data organized within each VIP buffer? Is it in column-major or row-major order? And how can I tell which physical antenna on the PCB corresponds to a particular RX or TX antenna,?

Thanks again for your help. I've been though the processor sdk documentation quite thoroughly and I just need more detail than the documentation provides.

Could someone please address the questions in my last message? It's been nearly two weeks with no reply.

Each TFDTP frame is corresponding to one radar frame from one VIP port.

You should use ~\vision_sdk\apps\tools\network_tools\bin\network_rx.exe to retrieve the data.

Please refer to ~\vision_sdk\docs\FeatureSpecificUserGuides\VisionSDK_UserGuide_NetworkTools.pdf for instructions how to use the tool.

The tool will save radar frames into 4 different files representing the data from each VIP port.

First file will be radar data from Master device, the second file from Slave1, the third from Slave2, and the forth from Slave3.

Please note that, due to high throughput required to transfer raw ADC data, the frame can be dropped if network throughput can't keep up with incoming radar data. We don't recommend to use this method for capturing raw data.

We typically use this only for object data capture since the network throughput requirement is much lower.

For raw data capture, we recommend the data capture solution based Linux SDK storing data to on board PCIe SSD.

Regards,
Stanley

Thanks so much for replying! This still doesn't quite address my issue, however.

First, I'm not having any problem receiving the TFDTP data from the MMWCAS-DSP-EVM. I've already built a ROS node that does this quite reliably. My problem is with interpreting the received data.

I think I can infer from your answer though that the network_tx process running on the DSP-EVM sends TFDTP frames containing the data from each VIP buffer sequentially, with the order being Master, Slave 1, Slave 2, Slave 3, Master, Slave 1, Slave 2, Slave 3, and soforth. Is this correct? PLEASE confirm if this is correct or not.

Second, you still haven't answered my question about how the data within the VIP buffers is organized. By analyzing the example matlab scripts included with mmwave studio 3.08, I think the bytes in the VIP buffers are organized as follows:

• vip_idx = 4 * (rx_idx + num_rx_per_chip * (adc_sample_idx + num_adc_samples_per_chirp * (chirp_idx + num_chirps_per_loop * loop_idx)))
• the bytes at vip_idx and vip_idx+1 represent the 16 bit I value for the given sample
• the bytes at vip_idx+2 and vip_idx+3 represent the 16 bit Q value

Please confirm if the above indexing is correct and, if not, PLEASE let me know how to correct it.

Each VIP frame has a channel id and Network Rx tool is based on that to save the frame to different files.

Each radar operate independently so there is no guaranteed order. However, since we send start commend to master -> slave1/2/3 so the data tend to arrive in that order.

For the data format in each radar frame, it is explained on page 17 with diagram in ProcessorSDKRadar_DataSheet.pdf as shown below. Not sure why this is not clear.

===============

Once the raw ADC data is captured, the data in the DDR is as shown below. Note the chirps are captured in non-interleaved format. So every row TxnRxm shown below has 16 bit I and 16 bit Q data for all the ADC samples in a given frame. The width of the frame is given by the 4 Bytes x Range Dimension x Num Rx Antenna per sensor. The height of the frame is Num of TDMA Tx antenna x Doppler Dimension.

Regards,

Stanley

If the order of arrival of frames from network_tx is not guaranteed, then could you explain how network_rx.exe identifies which tfdtp frames correspond to which AWR device? In your earlier message you indicated the first file saved by network_rx.exe corresponds to master, the second corresponds to slave 1, and soforth. If there is a way to identify the device to which a given frame corresponds without relying on the order that would be very helpful.

With regard to the frame data format, I understand the data in each frame represents a 2-dimensional matrix of adc samples where each row corresponds to the adc samples for a complete frame for a single rx-tx pair. However, when a multidimensional data structure (like a matrix) is stored in memory it needs to be flattened and there are a number of different ways to do this. I provided an example for how it might be done in my previous message. Is that example correct?

Sorry, I missed your comment about the tfdtp channel ID in your previous response. That resolves my first question. Second question still stands though.

Yes, you can refer to the script in mmwave studio. It is the same format.

Hi, Stanley. Thanks for the reference. In regard to your earlier statement that the network_rx node uses the tfdtp frame channel number to identify which VIP buffer the frame came from: I checked the incoming TFDTP frames and they all have the same channel number: 55. So I'm not sure how the network_rx node identifies which VIP buffer each frame corresponds to. Could you look into this further?

Also, for anyone who comes across this in the future, I'm in the process of determining the ordering through brute-force experimentation:

• vip_idx = 4 * (sample_idx + num_samples_per_chirp * (rx_idx + num_rx_per_chip * (tx_idx + num_tx * chirp_idx)))
• the bytes at vip_idx and vip_idx+1 represent the 16 bit I value and vip_idx+2 and vip_idx+3 represent the 16 bit Q value for the given sample
• Also note this indexing is not the same as the I posted earlier.
• This is not fully tested but I've verified it works well for the range doppler fft, and occluding a single rx antenna results in a signal dropout from all antenna pairs with that RX antenna. Still need to test it with angle FFTs.