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.

IWR1843BOOST: Data Structure for xyz coordinates and velocity

Part Number: IWR1843BOOST
Other Parts Discussed in Thread: IWR1843

Hello there, 

I am using IWR1843 and got some data captured from the Demo Visualizer. While trying to parse them, even though I used the demo python scripts for parsing the data, I get weird results in the x y z columns. 
I call them weird because even though in the oxygen it mentions that the values are in meters I get results like: 4.619.435.787.200.920 which is enormous. Same would go for velocity.

I would need some help to understand the structure of the data a bit better in order to properly parse the data.

  1. What is the detailed structure of the binary data file? Could you provide documentation that explains each field in the data file, its data type, and its length in bytes?

  2. Could you provide more information about the structure of each TLV in the data file? Specifically, how can I identify the number of detected objects in each TLV? Is this information included in the TLV header or elsewhere in the data file?

  3. Could you provide an example of parsed data? This would be very helpful to validate our parsing process.

  4. Could you provide any additional information or context that might be helpful in parsing and interpreting the data correctly?

Thank you so much in advance. 

  • Hello,

    I am actively answering the same question on the same device in this thread here: IWR1843BOOST: IWR1843BOOST

    I would recommend taking the same debug step as I mentioned there: place the device in debug mode and place a breakpoint within an if-statement that will trigger if the device is outputting some irrationally large number for one of the coordinates in the pointcloud TLV (the function you would be doing this in is MmwDemo_transmitProcessedOutput). 

    If you see that this breakpoint is never triggered, then we know that the sensor is not outputting such nonsense enormous values. This would tell us that the values are coming from a UART transmission error or a decoding error.

    Regards,
    Luke