AWR1843BOOST: Wrong detection angle in the azimuth plane of the MRR beam steering lab code

Hi Hang,

Let me review this with my team to determine the cause of this and get back to you tomorrow.

Regards,

Aayush

Hi Aayush,

Thank you so much for your help!

Last night, I also tested the compiled code from the mrr lab (the non beam steering version), it showed me the similar case. However,  I tested it at home last night without enough distance. Today, I will test the mrr lab (non beam steering version) compiled code with enough distance and get back to you. 

Thanks again!

Best,

Hang

Hello Aayush,

I just confirmed that the compiled code of MRR lab without beam steering gave me the similar case. I was using #define SUBFRAME_CONF_USRR and #include "mrr_config_chirp_design_USRR30.h". I put a car right in front of a the AWR1843 radar, it still gave me wrong estimation angle in the azimuth plane and wrong height estimation in the z axis. Pictures are shown as below. 

Actually, I have two AWR1843Boost. I tested both of them and both gave me the same case. Hopefully, it is not the hardware issue. I also attached the code I used for compiling. Thank you very much for the help!

mrr_18xx_dss.zip

mrr_18xx_mss.zip

Hello Aayush,

I did one more test and had one founding for you. I was using #define SUBFRAME_CONF_MRR_USRR and #include "mrr_config_chirp_design_USRR30.h".

From the picture below, we can see the MRR cloud detected the vehicle with correct angle in the azimuth plane. However, the USRR cloud detected the front vehicle with wrong angle in the azimuth plane and wrong height (Z axis). The red circle I marked is the front vehicle detected by the MRR and USRR. Maybe something was wrong with the USRR code?

Thank you very much!

Best,

Hang

Hi Hang,

Thanks for the information. I am wondering how angle processing happens on the USRR frames, and if this is a known limitation with USRR frames. I'll talk to the MRR developer to see if he knows why there is this discrepancy in angle between USRR and MRR frames. I will get back to you soon!

Regards,

Aayush

Hi Aayush,

Thank you! In my application, I only need the USRR frame working properly. Actually, from my observations, not only the angle in the azimuth plane was not correct, but also the height (the z values) was far away from the actually size. 

Thank you for your help! Looking forward to hear from you!

Best,

Hang

Hi Aayush,

Thank you! In my application, I only need the USRR frame working properly. Actually, from my observations, not only the angle in the azimuth plane was not correct, but also the height (the z values) was far away from the actually size. 

Thank you for your help! Looking forward to hear from you!

Best,

Hang

Hi Aayush, 

Just double check if you have any updates on the corrections of the angle estimation in the azimuth plane and height estimation in the Z axis?From the mrr demo (https://www.youtube.com/watch?v=1PkcbE3zrYo), at least, it showed a reasonable height estimation. 

By any chance, if you know the automotive toolbox version for this mrr demo?

Since in my application, I don't use the MRR, I only use the USRR. I don't think the MRR code generates the discrepancy in angle between USRR and MRR frames. 

Do you have any feelings or hints on where the USRR process code possibly wrong. I will try my best to help on debugging it. 

Thanks again for the help!

Best,

Hang

Hi Hang,

I spoke with my team and the developer of this lab, there shouldn't be this discrepancy in the MRR and USRR cloud.

The last change made to MRR was with automotive toolbox 3.2 back in late 2020. This change was minor; minimal changes were made to move this lab to SDK 3.5 from an older SDK 3.x version. No change was made to the datapath of the lab. Toolbox 3.0 should have the version used with this video.

I could not definitively confirm or dismiss this error when I tried to recreate this on my end as my indoor environment is pretty cluttered. 

I would suggest using MRR with toolbox 3.0 and seeing if this error persists. If the error goes away, please let me know so that I can log a bug for the latest MRR lab.

Thanks and Regards,

Aayush

Hi Aayush,

Thank you so much for your help! I will do the test with automotive toolbox 3.0.0 and let you know the results!

Best,

Hang

Hello Aayush,

I just confirmed that the prebuilt image of automotive toolbox 3.0.0 for USRR also gave me wrong angle estimation in the azimuth plane. I used the image from this path "C:\ti\mmwave_automotive_toolbox_3_0_0\labs\lab0007_medium_range_radar\prebuilt_binaries\xwr18xx_mrr_demo.bin"

Here is my setup, I put a reflector right in front of the radar around 10 meters. However, the radar still gave me the wrong angle estimation. Hopefully, you can reproduce this issue and could you give me some advices on fixing it? I am only using the USRR for my project.

Thank you very much for your generous help!

Best,

Hang

Hi Hang,

Thank you for confirming this and using a strong reflector as your target. I wanted to make sure that this issue wasn't due to regression when the MRR lab was updated in toolbox 3.2.

As you also encounter this issue with the MRR lab in toolbox 3.0, it isn't likely that this is due to a bug in the lab, as the MRR lab was well tested. I have a few ideas in mind and would really appreciate if you could try these out:

1. Could you try the out of box demo in the SDK? This would be to eliminate basic issues in your physical setup as the root cause. If there is an issue with the MRR lab, you shouldn't see this discrepancy in the OOB demo. If you see the same discrepancy in the OOB demo, it is likely that the issue is with your physical setup, like the level of the mounting surface being off, object not being aligned to the EVM's boresight, etc.

2. Could you capture a few seconds of data sent from the device with a serial monitor like teraterm/putty/etc and attach it here? All you would need to do is to listen over the auxiliary data COM port at a baud rate of 921600. The MRR lab starts to send data as soon as it starts running, without waiting for any external commands. It would be helpful to see the error in data.

3. This might be a long shot, but is the enclosure in your setup metallic? Perhaps the lip of the enclosure being right next to the transmitters/receivers is causing some sort of reflection/coupling/interference? It would be worth trying a more open mounting mechanism, like the tripod mechanism in the video you linked to above, or using the L brackets provided with the EVM.

Regards,

Aayush

Hi Aayush, 

First, I tried the TI OOB from SDK 3.5. It gave the correct estimation of the reflector. I also attached the profile file. The estimation is pretty good. 

profile_2021_03_20T16_05_27_210.cfg

However, for the MRR Lab the USRR estimation were still wrong. I was using tty recorder of tera term. Please see the picture below. As you remember, I said the MRR point cloud gave me correct estimation, only the USRR point cloud didn't work. 

I am wondering by any chance TI could reproduce my current issue? That will help a lot.

Thanks again for your generous help!

awr1843_record.zip

Hi Aayush,

By curiosity, I also tested the SRR lab, because I also have two IWR1642 radars. For the SRR lab demo, the USRR can give me correct angle and range estimation in the azimuth plane. Somehow, I cannot attach picture here. But just let you know the USRR of the SRR lab of xWR1642 works. 

For now, though not 100% sure, I think something was wrong with the USRR source code of the MRR lab. I understand that the TI team tested before releasing them and actually the MRR clusters, trackers works well. However, we cannot determine/judge the USRR cloud point in the demo video. 

I have two AWR1843 radars, and both give me the same angles estimation issue in the azimuth plane. It is unlikely both of them are broken.

By any chance, the TI team can reproduce the "issue", I am currently suffering? For testing, I think just use the prebuilt MRR image, and only allow the USRR point cloud. Of course, you may need a strong reflector. 

I think I have done everything I can for the testing. I'd also like to help on debugging the USRR code, though I am a beginner. Could you let me know whether you also have such "issue" of the USRR for the MRR lab? Or any hints on debugging the source code?

Thank you so much for the help!

Best,

Hang 

Hello Aayush,

I have more updates for you. I have two IWR1642 and two AWR1843 radars at hands and tested all of them. 

(1) The USRR of the SRR lab for xWR1642 can give me correct angular estimation in the azimuth plane. 

(2) The USRR of the MRR lab for xWR1843 will not only give me wrong angular estimation in the azimuth plane but also wrong height estimation in the z axis. However, by using the equation of sqrt(x**2 + y**2 + z**2), the range is pretty accurate. 

(3) The OOB demo of xWR1843 can give me correct angular estimation in the azimuth plane. 

I am wondering if you could reproduce the issues that I observed in these tests? From these several tests, I did see the discrepancy between the MRR and USRR of the MRR lab. I used the L brackets when I was doing the tests. 

For the simplest test, maybe you can put the radar and the reflector on the same height, then 10 meters away from each other. From my observation, the height estimation is not zero, but several meters in the z direction. Then, you may also notice the wrong angular estimation of the reflector in the azimuth plane. My observations are that the MRR estimation is correct but with less point cloud, the USRR estimation is wrong. 

I understand your valuable time spent in the forum. If you also notice the same discrepancy, could you give me some hints on debugging the source code of the MRR lab for the USRR?

Thank you so much for your help!

Best,

Hang

Hi Hang,

Thankyou for running these experiments and bringing this to my attention. I discussed your findings with my team, I will be in touch with the people who tested this lab to know whether the USRR was tested. We will be going through the code to see what might be the issue. Unfortunately, there isn't a strict timeline for this activity. You will have to give me a few days to follow up on this and get back to you.

Regards,

Aayush

Hi Aayush,

I really appreciate your help!

Sure, I understand. I have been using TI products for years. I really like them. At the meantime, I will also take a look into the source code and try to figure it out. 

Looking forward to hear from you!

Best,

Hang

Hi Aayush,

I just want to double check if you can also reproduce the discrepancy of the USRR in the MRR lab that I found during the tests? Frankly speaking, if there was truly something wrong I did for the MRR lab or some issues with my AWR1843Boost, I would prefer to buy a new one for my application. 

Thanks again for your generous help!

Best,

Hang

Hi Hang,

I was able to confirm this discrepancy between USRR and MRR pointcloud in the MRR lab. Though I didn't recreate this error due to my cluttered indoor environment, a colleague confirmed that during the initial testing, he observed a very clear divergence between USRR and MRR cloud as the object moved further away. This is the same thing that you see. Apparently the error wasn't deemed significant at the time.

Regards,

Aayush

Hi Aayush, 

Thank you very much for confirming this. From my observations, even if I didn't use the MRR (only USRR), the discrepancy also happened. My guess is something was wrong only with the USRR detection code, do you agree with or help me confirm on that?

Will the TI team continue working on this discrepancy? I'd also like to help! If possible, could you give me some directions or hints on how/where I can tune the USRR source code?

Currently, I do the post-processing to correct this USRR detections. However, it will give me more than 10 seconds delay, which is not ideal for real-time application.

One more question, on the MRR beam steering lab. I know I asked this before. However, I found two different answers. I would like to ask again, I am using automotive toolbox 3.2.0, for the MRR Beam Steering lab, the beam steering is for USRR or MRR?

Thank you so much for your help!

Best,

Hang

Hi Hang,

Your guess is probably right. Since the MRR pointcloud always stays in boreshight, there is no issue with that.

The team knows about this discrepancy now, but I can't say anything about the priority that will be given to this. To find out the issue, the most straight forward way would be to review the datapath for USRR, specifically the AoA and see if something might be incorrect.

Regards,

Aayush

Hi Aayush,

May I confirm my last question? The beam steering in the "Beam Steering MRR Lab" is for the MRR application or the USRR application?

Thanks again for the help!

Best,

Hang

Hi Hang,

To the best of my knowledge, it is the USRR frames that are used for beamsteering. However, I will confirm this and get back to you tomorrow.

Regards,

Aayush

Hi Hang,

Sorry about that. The MRR chirps are used for beamforming. I checked this in the code, where phase shift configuration is applied to the MRR chirps. You can see the same in Cfg_TxPhaseShiftInitParams function.

Regards,

Aayush

Hi Aayush, 

Thank you very much!

Best,

Hang

Hi Aayush, 

Sure, please also let me know if the TI team fix the discrepancy of the USRR in the MRR lab. At the meantime, I will also debug it on my own. 

Best,

Hang