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.

IWR1443BOOST: Zone Occupancy Weird Doppler Values

Part Number: IWR1443BOOST
Other Parts Discussed in Thread: IWR6843, IWR1443

Hi,

I'm using the IWR1443BOOST board ES3.0 version, with SDK 2.1. I try to play the Zone Occupancy lab from mmwave_industrial_toolbox_2_5_2 using IWR1443BOOST.

However, when I enable the log data, I found my doppler values are very weird. There are constantly extremely big values(>20000). Also, there are never negative values, which is wrong.

 (sixth column is the doppler values)

The things I have done for debug:

1) I changed the matlab code a little bit to add the Abs Time Stamp in the final column. I undo that change, it's still the same.

2) I thought even I undo the change, the code might already be contaminated. So I download the brand new code from mmwave_industrial_toolbox_2_5_2 again and run it. Still the same.


3) I thought the board has some issues. I have another board and I try with it. Still no luck.

4) I tried to run mmwave demo visualizer website using the sensor, it works perfect, the dopper has both negative and positive values, as shown in the following:

What I suspect:

1) Maybe my .bin file was wrong? I use the 148KB xwr14xx_mmw_demo.bin from mmwave_sdk_02_01_00_04. I didn't flash two radarss file and the mss file as suggest in the zone_occupancy guide, because from a page I read that only ES2.0 support flashing two bin file while ES3.0 only need to flash the above one I mentioned. But I don't know if that cause a issue on my doppler reading. Should I try a new SDK and which version should I try?

2) Maybe mmwave_industrial_toolbox_2_5_2 is out of date? The newest one mmwave_industrial_toolbox_4_5_1 doesn't have the zone occupancy demo. Can you please inform me which latest toolbox verion have the lab zone occupancy demo?

Could you please help me solve this problem? It's really weird and bothering me.

  • Looks like exactly the problem of the following link:

    https://e2e.ti.com/support/sensors/f/sensors-forum/760639/iwr1443-question-about-the-data-captured-and-processed-by-iwr1443

    If I use the default .cfg file, I also got 16829. Did this problem get solved?

  • A update, I also tried the lab from mmwave_industrial_toolbox_4_0_0 which I believed it's the latest version. Still no luck. Now I strongly suspect that it is about the SDK..

  • Zee:

    Can you please provide point cloud data for your setup using the OOB, so that we can establish a baseline.

    -Connor Desmond

  • Hi Connor,

    Yes. Is .dat readable to you? I can record .dat data from mmwave demo visualizer 3.5.0.

    I also tried to use mmWave_Demo_Visualizer_Record, which can generate .csv file but looks like it only support SDK2.0 while my SDK is 2.1.

    This is the .dat file that I generate:

    https://drive.google.com/file/d/16_8Sw0hkQZQ-okFMP2XRwCa9mL-O3LHg/view?usp=sharing

    Can you please take a look?

    Thanks a lot!

  • Hi Connor,

    Did you get a chance to look at my data?

  • Zee:

    I want you to do the following:

    1. Make sure that you have industrial toolbox 4.0 and SDK 2.1

    2. Follow the instructions of the user guide. This includes flashing the device with the two images.

    3. Look at the results. Report back.

    Note that the zone occupancy lab is deprecated and it is recommended to use a IWR6843 device and run the area scanner lab.

    Also I did not look at the data because it is raw binary data, not point cloud data.

    Best,

    Connor Desmond

  • Hi Connor,

    For 1, I'm sure that have industrial toolbox 4.0 and SDK 2.1. 

    For 2,

    Please take a look at this thread:

    https://e2e.ti.com/support/sensors/f/sensors-forum/820441/iwr1443boost-iwr1443-cannot-run-the-lab-of-zone-occupancy-detection-in-the-mmwave_industrial_toolbox_3_6_0

  • Btw, I also tried https://github.com/radar-lab/ti_mmwave_rospkg, the ros 3D visualizer rviz for the IWR1443 using 1443es1_short_range_3d.cfg.

    It works fine (I mean the velocity is not weird, there are negative and positive numbers and lower than 5m/s). 

    But still, I want to get zone occupancy working because I like its feature better.

  • As I stated earlier support for the Zone Occupancy lab has been deprecated. This means there is no active development going into the lab. If there are no answers in the collateral or other E2E posts which solve your problem then I would suggest once again to utilize a lab that we are currently supporting e.g. Area Scanner. The last thing that I would suggest is to take your .dat file that you linked and use the python parser at the following path to get the point cloud data and see if indeed those radial velocity measurements agree of not because what is in the .dat file is what is from the device. Note this is for the OOB.

    C:\ti\mmwave_sdk_03_05_00_04\packages\ti\demo\parser_scripts, not this is a recent SDK. This will load the point cloud data into a .csv file.

    Best,

    Connor Desmond

  • Hi Connor,

    Thanks for the reply. I will try that later. I did one more trial and I think the problem is more clear now.

    So in Zone Occupancy experiment, this is how the doppler is calculated:

    detObj.doppler = detObj.dopplerIdx * dopplerResolutionMps; The dopplerResolutionMps is about 0.3.

    Then I explore about the detObj.dopplerIdx in debug mode, dopplerIdx are store in a array called bytes in the getDetObj function.

    detObj.dopplerIdx = (bytes(3,:)+bytes(4,:)*256);

    I then checked about bytes, the problem is there. For the normal points, it is always less than 10. However, for those outlier points, they are 255. Which results in detObj.dopplerIdx becomes 65000+, then detObj.doppler becomes 20000+.

    Now the problem is that why the third and fourth row is too large for the outlier points, Is there any explanation for this bytevec data structure? It is 12 bytes per point. And the 3rd and 4th is related to the doppler index. As shown in the picture:

     each column is a point data(12bytes) I want to know what each byte is standing for?

    Does that sound familiar to you? I suspect that there are some sign problems. For example, those 255 should be some negative number, -1 or -2, which also explains why I don't have negative doppler.

    I really appreciate your help!

  • Zee:

    Due to the fact that this lab is deprecated that limits the amount of support that I can give you. With that in mind I would suggest to keep digging in the source code and adjust the lab for your application. I would suggest maybe looking at the area scanner lab code and comparing to see if there are any differences that would indicate what you should change to fix this bug.

    I will be closing this thread.

    Best,

    Connor Desmond