I can add a second, independent data point to this — different setup, same direction of error, and at a range that may help narrow it down.
Setup.
Six DWM3001CDK units, SDK 1.1.1 CLI firmware, but self-built from source rather than the precompiled binary. Channel 5. Boards standing on edge with the antenna ends facing each other, on a bench.
Result.
At 440 mm taped antenna-to-antenna, the reported median was 530 mm — an overshoot of +90 mm. Across six captures at short range the overshoot ran 90–130 mm.
The measurements are internally very consistent. n ≈ 613 ranges per 60 s capture, per sample sd 26 mm, so the median has a standard error near 1 mm. Both boards reported the same median independently, to the millimetre, in every capture. So whatever this is, it is a bias rather than instability.
Where our numbers diverge, and I think this is the useful part:
|
Taped |
Reported |
Overshoot |
Ratio |
| Yours |
304.8 cm |
~493 cm |
+188 cm |
1.62 |
| Mine |
44.0 cm |
53.0 cm |
+9 cm |
1.20 |
Neither a fixed offset nor a fixed scale factor fits both. A constant antenna-delay error would give the same absolute overshoot at both distances; a pure scale error would give the same ratio. We have one distance each, so neither of us can distinguish them alone.
The question worth answering, and it needs two points from one setup: what does your error look like at a second, substantially different separation — say 1 m and 5 m with the same boards, same mounting, nothing else changed? If the overshoot stays near 188 cm, it is an offset. If it scales with distance, it is not, and antenna-delay calibration will not fix it however carefully it is applied.
I am setting up to do exactly that over 2–10 m and will post what I get.
Calibration — I have less to add than you do. You have already done more here than I have: RESTORE, LISTCAL, dual-hoe_non_aoa.json via load_cal.py, and re-tested. What I can confirm is that the factory OTP values look sane and consistent across a batch. All six of my units read cal_rev 2, so none takes the CAL_REV_DW3001C_PVT2 branch in platform_l1_config.c that would substitute the hard-coded CH5_ANTDELAY_DW3001C_PVT2 constant for the die’s own value. Channel 5 delays across the six spanned 16365–16370 — 5 ticks, about 23 mm at 4.69 mm/tick. Real per-unit variation, but nowhere near either of our errors.
Worth checking on yours if you have not: OTP 0x1F decodes as platform_id = word >> 16, cal_rev = (word >> 8) & 0xFF. If either board came back cal_rev 1, its channel-5 OTP value is not what the firmware uses, and LISTCAL would show the substituted constant rather than the die’s own — which would look like correct calibration while not being the die’s.
On the 1.0.2 A/B test. I would be interested in that result too. I have a working build environment for 1.1.1 from source, so if it turns out 1.0.2 ranges correctly on the same hardware, I can help narrow down where between the two the behaviour changed rather than just confirming that it did.
Happy to share raw captures if useful — they are JSON, one record per line, with first-path and total received power per reception.