IWR6843: Variability in performance

Hi Matthew,

This is a very interesting question. Thank you for all the background. I will start by saying that we should decouple the SNR of a corner reflector from the tracking distance performance for now, as these may be 2 separate issues and will help the debug.

For the HW performance, it is best to test a static repeatable test like it seems you have. Do you have actual data on the SNR of the CR you can share? You say there is no significant difference between the boards but this could be subtle. If you have tested the different performance boards with CR at different distances and measured the difference please post the numbers. Even a small but constant delta could cause this change in performance. I would also ask that you do the measurements at higher angles as well. It could be possible that the boresight power is similar, but the FOV performance varies due to board tolerances. 

In general there is no internal test mechanism in the IWR6843 to test the antenna pattern. You will need to measure the SNR performance of a CR as you rotate the board to test the antenna FOV. I do recommend you perform this test with any new batch of boards you get (if there are fab changes) to verify antenna performance.

For the human target detection, can you please let me know which demo and configuration file you are using to test? Are you looking at the tracking output from people counting or just the pointcloud output from one of the demos? Pointcloud detection should be very closely corelated with the SNR from the CR, but there are a lot more SW settings if you are using tracking to determine your detection. Further, human motion in difficult to repeat exactly so if you are at a performance boundary you may see a variability in this. The exact SW and chirp configuration will help to understand what performance should be expected.

Finally, if you do this human detection test with the TI IWR6843ISK EVM and use the same SW, what are the results? And if you have a few more details about the test setup (mounting height of the roof, approximate tilt angle) it would be helpful.

Thanks,

Jackson

Hi Jackson,

Thanks for the reply.

For the CR it is handmade, so no there is no specific data for it, I can provide the measurements for the sides if that would help. 

I agree it would be a subtle difference in the manufactured board that is causing this issue, but from a hardware perspective it is hard to control all critical elements (Impedance, trace width, copper thickness, geometry) to a higher degree than the current manufacture. I thought IPC3 would have been a solution to previous revisions, especially considering the ISK Dev kit is only IPC2.

For detection I am looking specifically at detection only, not the point cloud. My end application cannot support the point cloud information output.

I am careful to disambiguate detection and tracking, as the results are clearly different by design.

For example, the following figure represents 8 Sensors (A-H) in tracking performance. Whereby the sensor was allowed to form a track, then the SNR was saved and compared to the distance, with the target walking up and down the boresight.




To note, SNR here is calculated as the mean of the SNR readings reported for the target. Then this mean is multiplied by 10 to return the 0.1 steps back to their dBm value. Finally I added a minus sign, as the SNR values were increasing as distance got larger which is opposite to what should occur. 

Hence, SNR = -10*Mean(target's point cloud SNR values). 

From the above graph I was expecting to be able to predict detection area as there would be lower limit for the sensor to detect targets based on the SNR as provided in the config file. But unexpectedly, this was not the case.

To test detection area a grid was setup whereby a human would walk the grid (Left to Right), from outside the possible FOV then walk along the grid until they were no longer detected then re-enter at the next increment (1m further away). The furthest distance (only in Y dimension/boresight) was identified as the detection distance. This is because if at the edge of the sensors FOV, say -4,3m (far to left of the sensor, 3m forward) then the sensor would almost always detect targets at any lessor angle, for example -2,3m.

For the same sensors in the above figure the detection distances (given as only Y distance, distance down the boresight) are as follows

As indicated, B, F, G, H are higher performers with detection >6m
D, E 4-6m
A, C < 4m

Strangely, the SNR values in the figure above suggest that C (Grey dots) would be a high performer as it has SNR readings (during the tracking test) just below B, and above F and G.

A RC was then placed at 3m directly in the boresight. The RC was placed on a device to maintain a small constant rocking motion to emulate movement. 
The SNR, and X/Y distances was recorded for ~30-60 seconds for each sensor. 

On the original graph used for tracking these SNR reading look like this:

Most of the sensors RC readings at 3m matched their trends from tracking. D however was vastly different.

Happy to send you the configuration file used in an email along with hardware details, elevation, angle etc.

Based on my findings, the SNR value is not effective at estimating the detection area, and the only real option is a series of CR's. But this does not form a measurement to identify where this variability comes from or why simply some sensors are better than others. 

Thanks in advance
Matthew

Hi Matthew, sorry for the delay. Based on these findings it does seem to be a board to board variation likely causing the issues, likely not a SW issue.

However, it may still be beneficial to measure the static, or 0 doppler, response of the corner reflector with each of the boards. Your test was good since it should be perfectly repeatable, but I would still want to isolate any extra variables in the test (ie motion). To do this you should be able to enable static detections if using the 3D people counting demo binary, or you can use the out of box demo to test.

Also linked below is a production test doc that goes through some other checks of new HW.

It may also be required to calibrate the antenna differences. There is some discussion of it in the link below. Or a full procedure can be found in the overhead 3D people counting user's guide (pre-req 3).
https://www.ti.com/lit/an/spracx7/spracx7.pdf 
https://dev.ti.com/tirex/explore/node?a=1AslXXD__1.00.00.26&a=VLyFKFf__4.12.1&node=A__AOWuF2v3eDFHAsxFXhvtzQ__radar_toolbox__1AslXXD__1.00.00.26 

Regards,

Jackson