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.

IWR1443: Extract point cloud data from SPI_read buffer

Part Number: IWR1443
Other Parts Discussed in Thread: TIDEP-0091

I've done data transfer between 2 TI radar EVMs via SPI. In Master side, I send data the same way as UART_write_polling().

Slave read data, then I need to put those data into UART_write(), but I don't know how to extract data from receive buffer of SPI_read to make UART_write can send out correct point cloud data to GUI. Someone told me to refer to TIDEP-0091 document, but that case only transfer number and text, so it's easier than sending point cloud data. Please tell me fundamental of point cloud data transfer through buffer received from another communication protocol (it's different from getting point cloud data by device itself, in this case it gets data from another radar). I'd be grateful if you can give me example for this task.

  • Hector,

    This has been addressed here: (your thread)

    https://e2e.ti.com/support/sensors/f/1023/t/897434

    The format of the output data is described here:

    file:///C:/ti/mmwave_sdk_03_03_00_03/packages/ti/demo/xwr68xx/mmw/docs/doxygen/html/index.html

    But the code itself is your best resource. In the original OOB code, you have the example of how the point cloud data is written to UART.  In the code I provided in the above thread, you have the example of how it is written to SPI.  You must be able to follow the code, understand what is being written and much in each write, look up and understand the data structures, or even step through it with the debugger in order to understand what it is doing.  It's all there.

    > (it's different from getting point cloud data by device itself, in this case it gets data from another radar)

    It's only different if what is being written is different.  That's why you need to understand the code.  For example, all SPI writes are 128 bytes.  If the demo code writes the packet header in a single write, you should immediately ask yourself "is it writing more of the packet than just the header?".  Then examine the code - what does the next write do?  How many bytes are in the header? Perhaps the receiving processor understands that the first packet is only the header with padding.

  • Dave,

    1. Do u mean after SPI_read on Master, I shouldn't write data from SPI buffer to UART in mss code, but need to modify oob_parser.py code? I thought that I only need to modify mss code by performing SPI_read and UART_wrtite in sequence. Originally, UART_write send data to GUI such as head, tlv array... 

    UART_write_polling(uartHandle,(uint8_t*)&header, sizeof(MmwDemo_output_message_header)

    Now we can add SPI_read in MmwDemo_transmitProcessedOutput(). Firstly, SPI_read(rxbuf), then push data from rxbuf into UART_write(), isn't it? Why do we need to modify oob_parser.py code? Is it easier and more efficient than my method above? If so, please tell me more details about OOB. Anyways, I think modify OOB python code only works when we use Rapsberry Pi. If we use a device to receive SPI data and connect to PC via USB, oob code must be UART data reading. So I need to make UART_write get data from SPI_read buffer in mss program.

    2. I see original mss demo code has UART_write with inputs are header, array of tlv data, detmatrix...

    TLV header size is 8 bytes, but SPI transfer data size is 128 bytes. If so, after SPI_read, GUI may receive TLV header & point cloud data at once (8 bytes header + 120 bytes point cloud data) even though we only want to receive header first, the data will be incorrect. How can we avoid it in SPI transfer function?