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.

Linux/AWR1443: how to slice the raw data into bytevec from /dev/ttyACM1 data steam?

Part Number: AWR1443

Tool/software: Linux

Hi TI

Goal: On Linux, write a python/C++ program to capture and display the azimuth heat map from mmWave Demo Visualizer

Current process:

1. Send config from demo visualizer to module, including sensorStart.
(So I can see the heat map is on. The config is attached for your reference)

2. cat /dev/ttyACM1 > Data.log for several seconds

3. Look at mmwave.js to find some ideas about parsing the raw data from cat.

Questions:

1. the raw data from cat is not starting from the beginning, since I'm catting after I'm sure the heat map is generated
    on the webpage. So I'm thinking about how to slice the data into bytevec. I saw in the mmwave.js the magic word
    is 21436587 so if I try to parse to raw data with the magic word, it will be sliced into the bytevec used in the javascript file?

2. Is the start_record button in the webpage logging the bytevec? I can see the saveStreamData(data); on line:143
    of mmwave.js yet the data is the same as bytevec that later used in process1 function?
    (the process1 function is where the bytevec being processed for drawing plots, just a reminder)

    Just wanna know if there's a way that we can store the bytevec data for later processing or like I want to get the
    point cloud of azimuth heat map and display somewhere or do some analysis.

3. Can you explain a bit about the algorithm of the function processAzimuthHeatMap in mmwave.js?
     It's a bit confusing since the variable names are not very clear.

4. Or is there another demo that I can look into if I want to get the azimuth heat map?

Thanks!

WCC

Config:

/cfs-file/__key/communityserver-discussions-components-files/1023/2642.profile.cfg

  • Hi,

    In order to correctly display the data sent by the target code you need to be clear about the format the sent data.

    In order to understand this format you need to review

    • mmWave SDK demo documentation
    • review code used in one of our demos (all demos use same protocol to send data to the host)

    Once you understand this format, you need to understand how a host reads this data. The process is the same in the mmWave Visualizer or in a Matlab GUi.

    You can take a look for example at the GUI file provided for the occupancy detection lab

    mmwave_automotive_toolbox_2_4_7\labs\lab0003_occupancy_detection\gui\od_demo.m

    Then you can implement the same in any other programming language

    thank you

    Cesar

  • Hi Cesar,

    Thanks for the reply.

    Yeah after playing with the code and the return packet, I think I finally understand the format of the TLV items, matching what doxygen said.

    But my question will still be the actual process of the data. I don't see some documents about which algorithm you've implemented for mmWave Demo.
    I mean I know after this function, the raw data will be processes and then we can get the point cloud.
    (specifically about the processAzimuthHeatMap() in mmwave.js, which I get the higher level concept about doing 2D FFT on frames across antenna)

    Do you know where it's documented?

    Thanks!

    WCC

  • Hi,

    1. If you capturing directly from COM port then look for Magic word to sync with starting of object result message.

    2. Start_button at the visualizer captures the processed data which goes for the plotting. You can capture any data to a file, refer the code logic being used for capture buttom.

    3. I need to check with the team about this.

    4. TI-Rex application may have heat map feature, please look into those applications.

    Regards,

    Jitendra

  • Hi Jitendra,

    Thanks for the advice. But I think syncing with magic word is risky since I couldn't expect there's no coincidence in the payload.

    But I just figure out that simply monitoring the byte streams from /dev/ttyACM1 is incorrect since there'll be undocumented rubbish between packets. I'm not sure what's the messages sending between packets. To capture the packets, using the "start record" button on Demo Visualizer is the right place that I can get byte streams of only packets. 

    BTW I'm using SDK v1.0.2, which is v1.2, since I found some demos could compile with latest SDK, like water vs ground.

    Thanks!

    WCC

  • Hi,

    Note that the magic word is defined in the target code.

    You can change it as you wish and use a pattern that you think will not be coincidence in the payload.

    Note that this is the method used in all the GUIs we provide and we did not have a problem

    I will close this thread now

    Thank you

    Cesar