This information applies to any of the mmWave sensor BOOST EVMs
As described in the mmwave studio User's Guide Section "3 Using the DCA1000 EVM for capturing the raw ADC data", after 1GB of capture, a new file will be created to store the additional captured data. The EVM appends"Raw_n" to the file name given by the user.
C:\ti\mmwave_studio_02_00_00_02\docs\mmwave_studio_user_guide.pdf
Let's assume that the size of the captured data requires 3 files. The following files will be generated: myFile_Raw_0.bin, myFile_Raw_1.bin, myFile_Raw_2.bin. These files include the raw data from the sensor but also meta data generated by the transfer protocol. In these files the data is formatted in UDP packets.
These files may not include the received UDP packets in the correct order. So, the next step is to run the Packet reorder and zero fill utility for each "Raw_n" file.
The output of this process will be 3 new files: myFile-0.bin, myFile-1.bin, myFile-.bin. These files include raw data. The metadata has been removed.
An important piece of information for these files is that they do NOT include an integer number of frames. ONLY the first file "myFile-0.bin" is guranteed to start on a frame boundary.
This is the reason why the mmwave studio User's Guide includes the following NOTE:
NOTE: The matlab post processing utility in mmWaveStudio processes only the first captured raw ADC file successfully. For processing other files, user will have to develop his own processing.
Notice that it would be possible to write a utility that could compute the number of bytes of the partial frame at the end of the first file, then remove or add the rest of the partial frame from the beginning of the second file.
In this way, the second file will start on a frame boundary and can be processed with the matlab post processing utility integrated in mmwave studio.
Notice that this kind of parsing would have to be accomplished anyway to develop own processing. Indeed the processing must be aware of the frame boundary
