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.

IWR6843AOP: Crashes in OOTB demo code with large number of detected objects, NOT just serial bandwidth problems

Part Number: IWR6843AOP

I am working to modify the out of the box demo software for the mmwave AOP radar.

When I reduce CFAR gain and ungroup peaks so that I can do on-host processing, I get a lot of contacts (e.g. 150). But still less than the max number in the API.

Sometimes the sensor simply crashes and stops responding and needs to be power cycled.

This happens _less_ if I reduce frame rate to e.g. 10fps, but doesn't go away. Likewise, I disabled the UART sending in the code and only report number of contacts. It still crashes at around 150. So it's clearly some processing that's taking too long and not just the slow UART.

Does anyone have a hint on what timings I'm likely failing? 

  • Hi,

    Your processing time is probably exceeding the time you're allotting between chirps. Why do you want to detect lots of points? Would it be more efficient to run the CFAR off-chip and just stream off the detection matrix?

    Best,

    Nate

  • Okay, that makes sense. Thank you! I see that the ISK demo handles a lot more points by offloading CFAR to the DSP, so I may pursue that avenue.

    For the second part, I am just ignorant. I am completely new to radar, and at present I'm completely just experimenting with it to see what it can do. In particular, I'm overlaying the demo output using augmented reality, and I'm finding that the denser the point clouds, the more "sense" the radar data makes when visualized like that. It is kind of the opposite of machine tracking applications, where you really wish you just had center of mass or skeleton points for each contact so that you can logic abstractly about it. But when visualized in AR, having the denser clouds helps your brain identify objects.

    I had not considered streaming the detection matrix. I suppose I had thought that was identical to the "radar cube", which has a 768KiB memory allocated for it and is obviously too big to stream. I assumed that the CFAR was the algorithm which reduced that data to a manageable size. I think I want the rawest spatialized data available. I will expand my knowledge and investigate streaming the detection matrix.

    Thank you!