• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 166 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

IWR6843AOPEVM: Connection to device is lost when increasing number of detected points within demo visualizer

Nicolaj Malle
Prodigy 50 points
Part Number: IWR6843AOPEVM

Hi,

I am trying to configure the IWR6843AOPEVM board to output more detected points. More points result in greater CPU load on the device, and at some number of points the device becomes unresponse until it is reset.

Currently, I use the out-of-box firmware and the demo visualizer to do real-time tuning. As the number of points increases (e.g. by turning of peak grouping), the CPU load also increases. At some point the load is too much and I assume the device crashes. 

From my short investigations it seems to be more resilient to these crashes when the selected Frame Rate (fps) in the Scene Selection is lower.

Are the crashes expected behavior? Is there something that can be changed in the visualizer or firmware to get around this behavior?

Thanks, 
Nicolaj

  • 0
    TI__Expert 7510 points

    Hello,

    The probable cause of this behavior is that you have not sent out all of the data for a given frame before the next frame starts. As you have mentioned lowering the frame rate or increasing the frame period leads to fixing the issue. This would be the parameter to start with.

    The other approach is to minimize the amount of data you send into the processing chain or lower the amount of processing that is done in the chain. The latter is probably not the best way to go since you are just using the default OOB processing chain. The former would most likely the way to go if you want to take the hit on performance. To reduce the amount of data that is fed into the processing chain you might what to play around with number of chirps that you send ( effects velocity resolution), change the number of samples per chirp (effects range resolution), or you can change the number of TX antennas that you have configured (effects angular resolution) etc. Additionally, you can lower the CFAR threshold which may not work for you because it will result in less detected points, but some low SNR reflections might be due to multi path, or environment noise; it really depends on the material of the object of interest. In conclusion, more points isn't always better.

    You will have to find the balance between performance and frame rate which works best for your application and see what middle ground applies best.

    Best regards,

    Connor Desmond

  • 0 in reply to Connor Desmond
    Prodigy 50 points

    Hi Connor,

    Thanks for the reply.

    Is there not some way to safeguard the device from the mentioned behavior? If it is due to not having sent out all data before the next frame, maybe it is possible to ignore points past some threshold such that the frame to be sent cannot exceed a certain size?

    Also, I would imagine turning off some of the TLVs in the frame would lower the amount of data needed to be sent.

    My main issue is that I can configure the board to get many points from few objects in a clutter free scene, which is great, but when I then turn the device to a scene with more clutter, it crashes. 

    Thanks, 
    Nicolaj

  • +1 in reply to Nicolaj Malle
    TI__Expert 7510 points

    Hello,

    Correct. I was assuming that you were sending just the detected objects TLV. If you are sending more than I would suggest try not sending those as that will increase the amount of data send over UART per frame. The other option you could try is to increase the UART baud rate from 921600 bps to something higher. Note that the GUI visualizer only supports 921600 bps, so you would need to make your own visualization tool for that. The only threshold that you can change that will effect the number of detected points is CFAR; see cfarCfg CLI command. All that being said if you want to put some safeguard in the application you are free to do so. We do provide all of the source code for the demo, so you are free to modify it to suit your needs.

    Best regards,

    Connor Desmond