This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AWR1642BOOST: dat file from mmwave demo visualizer reading

Part Number: AWR1642BOOST

As suggested by TI, I run the demo of AWR1642BOOST through mmWave Demo Visualizer, and download the .dat file for offline analysis through record function in the visualizer. However, when I try to extract the information from .dat file, something wrong happens. Specifically, I write a Matlab program to read the data. When the program parses header, detected objects, range profile, and noise profile, everything is fine. But when I parse to range doppler heatmap, I find the type field of the TLV is wrong (i.e., 4.2939e+9, I think this value should be 5). So I went back to see if there is any problem in parsing the range azimuth heatmap. But I find the type is exactly (i.e., 4), and the length may be also right. Hence, I think the problem happens in parsing the payload of range azimuth heatmap TLV. According to mmw Demo Data Structure v0.1, the length of the heatmap would be #RangeBins * #VirtualAntennas * 4 bytes, and my config is 

channelCfg 15 1 0

profileCfg 0 77 916 7 57.14 0 0 70 1 256 5209 0 0 30

So I think the #VirtualAntennas=4 and #RangeBins=256. And I use this length to parse the heatmap. Is this correct?

And I also try to use another python program parseTLV.py to parse the dat file, but it seems only the header, detected objects, and stats can be extracted.

Would someone like to answer this question? Thank you very much.

  • Hi,

    Can you let us know which version of the mmWave SDK you are using?

    Would it be possible to post a sample of the .data file here so that we can take a quick look?

    Best Regards,
    Anand
  • Hi Anand,

    Thanks for your reply. The version of mmWave SDK is 2.0. And the .dat file xwr16xx_stream2.datis attached. Thank you very much.

    Best regards,

    Li

  • Hi,

    The .dat file that you shared appears to parse correctly. From the SDK documentation (C:/ti/mmwave_sdk_02_00_00_04/packages/ti/demo/xwr16xx/mmw/docs/doxygen/html/index.html), the Length of the Azimuth static heatmap is "(Range FFT size) * (Number of virtual antennas) * (size of cmplx16ImRe_t_)" which is 4096 bytes (== 256 * 4 * 4), and the Length of the Range/Doppler heatmap is "(Range FFT size) * (Doppler FFT size) * (size of uint16_t)" which is 8192 bytes (== 256 * 16 *2).

    Could you refer to this documentation and double check your parser code?

    Best Regards,
    Anand
  • Hi Anand,

    Thank you very much! Now my code can successfully parse the dat file.

    But I have another question. When I parse to range profile and noise profile, the length seems to be contradictory with mmw Demo Data Structure v0.1. From mmw Demo Data Structure v0.1, the length of the profile is #RangeBins * 4 bytes (#RangeBins=256?). But in fact, when I use 128 * 4 bytes, the parse result can be correct. Does #RangeBins equal to Range FFT size? Or maybe the data structure in mmw Demo Data Structure v0.1 is different from that in mmwave SDK 2.0? Thank you very much.

    Best regards,
    Li
  • Hi Li,

    Can you point me to where you got the mmw Demo Data Structure v0.1 document?

    The SDK document is correct. The noise profile TLV should have a length of (RangeFFTSize) * 2 bytes. Looking at your configuration, you have 256 range bins, so the length should be (256 *2) which is also what you have in the .bin file that you shared.

    Note that RangeBins is the same as Range FFT size.

    Best Regards,
    Anand
  • Hi Anand,

    Thanks for your reply. The link of the document is https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/1023/mmw-Demo-Data-Structure_5F00_8_5F00_16.pdf, and you can refer it for details.

    If the length of noise profile is (RangeFFTSize) * 2 bytes, it would be correct for my parsing code. The document mentioned the lengths of noise and range profile are both (RangeFFTSize) * 4 bytes and (RangeFFTSize) * 4 bytes respectively, which makes me confused.

    Also, I find the length of descriptor in detected objects TLV would be 4 bytes, which can be divided into a 2 bytes #Detected objects, and 2 bytes XYZ-Q-format (in the document, the length of these two are defined as 4 bytes).

    Thank you again for your kind help.

    Best regards,

    Li

  • Hi Li,

    Thanks. That pdf document is incorrect.
    The SDK documentation is correct.

    By the way, every TLV has a length parameter at the beginning - you can use that to parse generically.

    Best Regards,
    Anand
  • Hi Anand,

    Thank you very much. This answer solves my problem.
    Would you please point which documentation in the SDK I can refer for parsing the data? I only find a high level data structure document, in which the length of payload in each TLV is not explained in detail.

    Best regards,
    Li
  • Hi Li,

    A TLV is a standard structure with the payload size passed at the start of each section (en.wikipedia.org/.../Type-length-value). So if you look at the start of each TLV, the length for each segment is available there - even if the segment payload is not decoded correctly, it would always be possible to reach the subsequent segments correctly.

    The interpretation of each payload however depends on the demo code or configuration. For the Out-of-box demos included with the SDK, I think the best documentation is the section "Output information sent to host" in the SDK demo documenation ("file:///C:/ti/mmwave_sdk_02_00_00_04/packages/ti/demo/xwr16xx/mmw/docs/doxygen/html/index.html" in your installation).

    This is always updated for each SDK release, so it will be the most current information.

    Best Regards,
    Anand
  • Hi Anand,

    Thank you very much. This answer solves my question.

    Best regards,
    Li