Other Parts Discussed in Thread: IWR1443
Hi,
1. We are writing to inquire re. parsing and reading the incoming .bin file (DataOutput_XWR14xx.bin) from the IWR1443 radar. We noticed from a thread replied by Kyle (https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/732538/iwr1443boost-iwr1443-vital-signs-data), that one came make use of the main_readGuiSavedBinary.m file to parse the .bin. We did so for the 6843 radar, which worked ok.
Our main question is, for the IWR1443, we did utilize the same code, but we noticed that the LENGTH_DEBUG_DATA_OUT_BYTE is left at 128, whereas according to the ppt document, the output packet structure should be 88. If we change that variable to 88, then we’ll run into a reshape problem.
function [TOTAL_PAYLOAD_SIZE_BYTES, indexVitalSignsOutput] = calculate_PayLoadSize(ParamsStruct)
LENGTH_MAGIC_WORD_BYTES = 8; % Length of Magic Word appended to the UART packet from the EVM
LENGTH_DEBUG_DATA_OUT_BYTES = 128; %VitalSignsDemo_OutputStats size
LENGTH_HEADER_BYTES = 40; % Header + Magic Word
LENGTH_TLV_MESSAGE_HEADER_BYTES = 8;
MMWDEMO_OUTPUT_MSG_SEGMENT_LEN = 32;
Kindly inform us on whether this needs to be changed or not, and if so, what is the best course of action.
2. Additionally, and most importantly, if we leave this to 128, we observed a “distorted” timeAxis variable upon running this script. The problem is that the total time points is almost double the amount it should be. In a sense, that if we have started (and hand-noted) that the sensor started running at 17:00, the timepoints would suggest otherwise, that it the sensor started recording at around 16:55 to give you an example. We are also printing and saving a timestamp of when the actual user hits the stop button on the 1443, Matlab GUI, so we are getting the correct timestamp printed for when we have stopped the experiment. We then refer to the timeAxis array (after we parse the data via main_readGUISavedBinary.m) and subtract the maximum timepoint (which is in seconds) from the saved timestamp to get the start time of the sensor.
Having said that, upon dividing the timeAxis variable by 2 (an arbitrary value that we observed that the timeAxis was being saved to), the analysis was much better.
Any ideas or insights on why this is encountered?
