IWR6843AOPEVM: Status of MMWSDK-2444

Morten Nissov said:

• Is it present in the OOB release for iwr6843aop

Yes

Morten Nissov said:

Is there an upcoming change to be expected in the near future?

• If no, how I fix this locally?

I don't know of a plan to fix it in the near future. I would just apply the phase compensation on every range bin instead of just the single range bin.

Morten Nissov said:

What order of magnitude bias would you expect. Essentially if the sensor is uncalibrated, how erroneous would you expect the range? Under the assumption that this range bias error exists for all range bins aside from the calibrated one.

Your angle estimation may suffer if the bias is not applied properly, but it's only really noticeable at longer ranges (15+ meters).

Best,

Nate

When should I look specifically for this change?

Your angle estimation may suffer if the bias is not applied properly, but it's only really noticeable at longer ranges (15+ meters).

By suffer what do you mean? 1 degrees off, 10 degrees off? Also how does this affect the angle estimation, what order of magnitude in range errors should one expect? Either in terms of cm or multiples of the resolution if that is more relevant.

This will result in angle errors. I cannot give a good estimate for 1 degree vs 10 degrees. I would expect it to be somewhere in between. It will not result in range errors.

Best,

Nate

Does the range bias not cause range errors? Sorry I don't quite see the relationship

Edit: Documentation from mmwave_sdk_03_06_02_00-LTS/packages/ti/demo/xwr68xx/mmw/docs/doxygen/html/ states

For most boards, a range bias of few centimeters has been observed. User can estimate the range bias on their board and correct using the calibration procedure described in Range Bias and Rx Channel Gain/Phase Measurement and Compensation.

Shouldn't this then result in error in range estimation?


Edit2: Also just to be clear, this bug is affecting performing during normal operating conditions right? And not just during the calibration procedure?

Hello, 

Nathan is currently out of office and will respond when he returns next week.

Best Regards,

Josh

I'll leave this follow-up question here for Nathan or anyone who happens to see it.

Looking in packages/datapath/dpc/dpu/aoaproc/src/aoaprochwa.c I see the bias/phase calibration is used in DPU_AoAProcHWA_process when calling AoAProcHWA_rxChanPhaseBiasCompensation. Here the correction is applied to every detected object from what I can see.

Looking further in AoAProcHWA_XYZestimation (in the same file), I see the range bias subtracted at the beginning of the function

range = objIn[objInIdx].rangeIdx * params->rangeStep;

/* Compensate for range bias */
range -= aoaHwaObj->dynLocalCfg.compRxChanCfg.rangeBias;

Sorry if this is a bit too trivial, but I don't really see the bug here. I fully accept that maybe I am looking the wrong place, can you point me in the right direction or provide some further explanation of how the bug enters and a proposed fix?

Thank you. Your patience is greatly appreciated.

Best Regards,

Josh

Hi,

As far as I understand, the issue is that the range bias is only applied on the detected objects, where it should be applied on each range bin regardless of whether an object is detected or not.

Best,

Nate

Hi,

Does this bug then actually deteriorate measurement quality? Furthermore, do you have access to a more detailed description than what is available in the release notes?

Morten


Edit: Just a quick follow-up. Maybe I'm misunderstanding something very obvious, but it's only detected objects which are published as measurements anyway right? So it doesn't seem like this bug has a negative impact on the measurement output. Please correct me if I'm wrong about this.

Hi Morten,

Unfortunately we don't have a more detailed description. I suspect that it would not deteriorate detection quality based off the release notes assuming you're only looking at the detected points, but it will be your responsibility to ensure that the detection quality is good enough for your application.

Best,

Nate

Hi Nate,

Is there any application of this demo which is not only looking at detected objects? From what I understand, measurements can only come from the list of detected objects.

Is there perhaps someone you can put me in contact with who has better knowledge of this firmware?

Morten

Hi Morten,

The heatmaps are used for interpolation on detected points, so they may be affected. Unfortunately this is as much information as I'm able to give you. If you're not able to use this device for your purposes, consider using the IWRL6432, our lower-power part.

Best,

Nate

Is there anything about the lower power sensor which should be different in this regard?

Hi Morten,

It doesn't have this bug listed in the release notes, so it should not be an issue.

Best,

Nate

Sorry for the late response.

Does this one have a different SDK? Can you point me towards this? I've been looking in `packages/ti/datapath/dpc/dpu/aoaproc/src/aoaprocdsp.c` as far as investigating this behavior is concerned. Is this incorrect?