IWR1843BOOST: Serial data stops after a while

Hi Carlos,

You mention using /dev/ttyACM so this tells me that you are using a linux based machine. If you are not using the GUI, could you please explain how you are starting the demo? Also what method are you using to save the serial port information? Please be as detailed as possible.

Just noting quickly, the GUI has a recording feature, is that not suitable for your development?

Finally, I highly recommend to use the latest version of the industrial toolbox (v 4.7.0).

Hi Sabeeh,

Thanks for your reply. Yes I will provide more details here.

I have a custom setup where I am tracking road vehicles in real time using a custom python application running on Ubuntu. I used the IWR1642BOOST kit with industrial  toolbox V3.6.2 for 12 months very successfully. A couple of months ago, I decided to upgrade to a 3D environment and bought the IWR1843BOOST using the industrial toolbox 4.5.1. And now I am having trouble as described in the previous message. I start the demo by sending all the commands inside the default 18xx_traffic_monitoring_70m_MIMO_3D.cfg file contained within the default 4.5.1 toolbox to port /dev/ttyACM0. After the command sensorStart, the /dev/ttyACM1 port starts sending point cloud and tracking data normally, but it simply stops after a while (typically less than 1 minute). I tried to use a terminal command like Cutecom to read data directly from /dev/ttyACM1, but the problem is the same. I could not yet establish a pattern of when it stops, for example, not after a specific TLV, it seems random at this stage.

I just double checked and the traffic monitoring lab has no changes between v4.5.1 and v4.7.0.

For the sake of providing more information, I ran the demo using the matlab gui from a Windows PC. The demo stops after a few seconds as usual. However, there are other warning messages about problems with the frames structure. I did 2 runs and collected the log files of both runs and attached here.

1411.runs.zip

Thank you for testing and providing this information. Out of curiosity, what is the scene of this test scenario? Do you believe there are many hundreds of points? This could possibly be causing a buffer overflow somewhere along the processing chain.

Furthermore, I have tested this on my own IWR1843BOOST using Toolbox 4.5.1 and have not been able to replicate this issue. Can you confirm that your power supply is rated for 5V and able to supply 3A?

Hi Sabeeh, I can confirm the power supply is an industrial power supply and can supply 3A. 

From the files I sent you, can you work if there is a buffer overflow? If yes, how do I solve the problem?

What do you suggest I do to solve the frame structure problems as well? 

Thanks.

The frame structure problems are solved by editing the 18xx_traffic_monitoring_70m_MIMO_3D.cfg file.

I'm unable to use your data. The overflow issue is more complicated, here is another e2e thread addressing the problem: https://e2e.ti.com/support/sensors/f/sensors-forum/993392/iwr6843isk-stop-the-sensor-when-detection-exceeds-max-num-of-trackingcfg-in-long-range-people-detection-demo

Could you please describe your test scene and scenario?

Hi Sabeeh,

Thanks for that. The image below matches the FOV of the radar. 

You mentioned the frame structure problems are solved by editing the 18xx_traffic_monitoring_70m_MIMO_3D.cfg file. Can you please elaborate what I need to edit to fix the frame structure problem? The frame structure problems are detailed in the logs I sent you on the earlier post above.

I read the overflow issue you sent, but I cannot tell the number of points was exceeded. Why are you unable to use my data to determine that? If you tell me the problem with the data, I can generate more data for you. 

Regards,

Carlos

Please try changing some of the parameters in the trackingCfg as was discussed in the above E2E ticket. I would like you to experiment and see if this is the culprit.

Hi Sabeeh,

The plot below shows some statistics I collected during one run that failed after approx 5000 frames. This is a unusually long one as most stop earlier than that. The red crosses on top show the number of targets and the blue dots show the number of pointcloud points. The bottom plot show random problems with the frames, such as skipped frames (a certain number of frames that are never received) and frames where the totalPacketLength does not match the number of bytes between magicWord starts.

Looking at that, I did not think that changing tracking parameters would solve anything as I am only getting at most 2 targets. So I focused on things that would reduce the number of points instead. 

I changed this setting to

aoaFovCfg -1 -5 5 -5 5

and that allowed the board to run for several hours with a very small amount of frame issues. It seems that by reducing the FOV volume, I get a smaller number of points and the suspected memory overflows do not take place.

However, my detection area is now very small so this does not solve my problem as I cannot track vehicles. I would like to find away to reduce the number of points and still have the larger area. I am not a radar expert, but I suspect the cfar threshold could be helpfull? Do you have any ideas or any documentation that would help me achieve what I need?

Regards,

Carlos