IWR6843ISK: Validation checkpoints for custom Python raw-ADC people-tracking pipeline

Hi Danilo,

Question 1: Your RD-first strategy has a known limitation: near-stationary or very slow-moving targets.

TI's people counting demo actually uses the opposite order: Range → Static Clutter Removal → Angle of Arrival (Capon) → CFAR → Doppler Estimation; specifically, because Capon beamforming provides superior localization for slower targets like people. The rationale is that for the same range bin, multiple targets may exist at different angles and Doppler velocities; estimating angle first (via Capon) and then extracting Doppler per (range, angle) peak gives better separation.

Your RD-first approach will struggle when:

• Targets are near-stationary (sitting, standing still): They fall into or near the zero-Doppler bin, where static clutter removal may suppress them, leaving no stable RD anchor.
• Two people are at the same range and similar velocity but different angles: RD CFAR will see one merged peak; only angle processing can separate them.
• Closely spaced people with similar Doppler: The RD map cannot resolve them, and your RA refinement step becomes the only discriminator rather than a validator.

For your use case at ~10 FPS with walking people, the RD-first approach should work well for normal walking speeds. The failure edge cases are slow/stationary targets and same-range-same-Doppler crossings.

Question 2: This strategy can mask TDM-MIMO phase compensation errors. Key considerations:

• In TDM-MIMO, a Doppler correction step must be performed before angle-FFT to compensate for velocity-induced phase changes between TX time slots. If this correction is wrong, the angle estimate will be incorrect—but only for moving targets. By restricting to a single Doppler slice, you might get consistent (but systematically biased) angle estimates that appear stable.
• G-track (TI's tracker) assumes the point cloud azimuth is already correct and does NOT compensate for TDM-MIMO phase errors. So, if your Doppler compensation is wrong, the tracker will faithfully track incorrect positions.
• Strong zero-Doppler clutter from antenna sidelobes is a known issue with 2Tx/4Rx TDM-MIMO on the IWR6843ISK, significantly worse than 1Tx/4Rx configurations.

Validation recommendation: Aim the sensor at a single corner reflector at a known angle. Compare your angle estimate against ground truth across different Doppler bins. If the angle estimate shifts with Doppler, your TDM-MIMO phase compensation has an error.

Question 3: TI's approach in the people counting demo handles this differently: no peak grouping is applied after CFAR; instead, the full point cloud is passed to the tracker, which performs clustering. The tracker itself finds the centroid.

For validation:

• TI's "Sense and Direct: HVAC Control" demo includes a classifier that uses micro-Doppler features from the point cloud for activity classification, demonstrating how point-cloud-level features (not raw ADC heatmap patches) can characterize human targets.
• Recommended validation scene: Place a single person walking at a known path (e.g., along a tape line on the floor). Compare your refined blob-center output against the known ground-truth path. If your refinement reduces the lateral scatter of the track relative to the ground truth, it's helping. If it introduces a systematic offset, it may be smoothing an angle processing error.
• Compare against TI's OOB_parser.py from the 3D people counting visualizer source code, which provides a validated TLV parsing baseline. Run the on-chip people counting demo simultaneously and compare its point cloud centroids against your blob-center estimates for the same scene.

TI does not publish specific reference datasets with ground-truth body-center annotations for the IWR6843ISK, so controlled single-person path tests are your best available validation method.

• Decrease gating parameters to limit the size of a single track, which forces leftover points to form new tracks rather than being absorbed.
• Increase allocation thresholds to suppress ghost tracks from spawning on noise or sidelobe detections.
• TI's people counting design expects accuracy of ±0 for <5 people and ±1 for 6-7 people, 90% of the time, with a maximum assumed density of 3 people per square meter.

Recommended validation scenario: Two people walking parallel paths at decreasing lateral separation (start at 1.5m apart, decrease to 0.3m). Record at each separation. Your merge/DBSCAN should:

• Consistently report 2 targets at separations above the angular resolution limit (~15° for IWR6843ISK at typical ranges)
• Gracefully degrade (not oscillate between 1 and 2) at the resolution boundary

Question 5: The DCA1000 UDP packet includes a 10-byte header with a 4-byte sequence number and 6-byte running byte count, specifically designed for detecting packet loss and maintaining frame synchronization.

Transport health metrics you should report:

Additional considerations:

• The DCA1000 has a known, unpatched bug where some chirps contain all-zero ADC samples, causing high-intensity artifacts at close range in the RD map. Detect frames with zero-value chirps and discard them.
• If you experience packet loss, increase the DCA1000 packet delay parameter (configurable 5–500 µs) to reduce drops—this is a network/PC-side issue, not a radar hardware problem.
• Monitor the DCA1000 hardware LEDs: FPGA_ERR_LED (LVDS buffer overflow), DDR_FULL_LED (DDR3 saturation), HEADER_ERR_LED (missing LVDS headers).

Question 6: Compare intermediate artifacts, not just final tracks. This is the most effective debugging strategy for custom raw-ADC pipelines.

TI's on-chip processing splits across cores:

• HWA: Range-FFT (1D FFT, performed inline during chirp arrival)
• DSP: Doppler-FFT, CFAR detection, Angle-of-Arrival estimation
• R4F (Cortex-R4F): Tracker (clustering, Kalman filtering)

The most meaningful intermediate checkpoint for debugging custom raw-ADC processing is the CFAR candidate list (post-detection, pre-tracker).

1. Radar cube consistency: Validates your frame reconstruction and sample ordering are correct.
2. RD heatmap peaks: Validates your FFT windowing, static clutter removal, and Doppler processing.
3. CFAR candidate counts ← Most diagnostic level: The HWA's CFAR engine outputs a FFTPEAKCNT register with the detected peak count [16]. If your CFAR candidate count per frame diverges significantly from TI's on-chip demo output for the same scene, the error is in your signal processing chain (not tracking).
4. RA heatmap / angle estimates: Validates your TDM-MIMO phase compensation and virtual antenna ordering.
5. Tracker inputs: Validates your clustering/merge logic.

Practical comparison method: Run the on-chip OOB demo with LVDS streaming enabled simultaneously. The UART output gives you TI's point cloud (range, azimuth, Doppler, SNR per point). Compare:

• Your CFAR candidate count vs. TI's point count per frame
• Your angle estimates vs. TI's azimuth values for the same detected range bins
• Your detection SNR distribution vs. TI's reported SNR

The OOB_parser.py in the 3D people counting visualizer provides the reference parsing format.

I hope this helps.

Best,

David