[Bug] ThreatIdentityData.getRange: integer division understates threat range

[willi-werner]

Classification: Bug (standards-compliance audit)

ThreatIdentityData.getRange() computes the lower-bound threat range with (range - 1) / 10 - 0.05F. Both operands of (range - 1) / 10 are Java int (range is an autounboxed Short), so this is INTEGER division that truncates the 0.1 NM resolution before the 0.05 offset is applied. For range=12 it returns (11/10=1) - 0.05 = 0.95 NM instead of 1.1 - 0.05 = 1.05 NM; for range=127 it returns (126/10=12) - 0.05 = 11.95 NM instead of 12.6 - 0.05 = 12.55 NM. Only range values that are exact multiples of 10 (plus 1) decode correctly; all others are under-reported by up to ~0.9 NM. The bearing getter uses float multiplication (6F*...) and is correct.

• Code reference: msgs/bds/ThreatIdentityData.java:getRange():156 @ 94df15f
• Standard: DO-181E §2.2.22.1.2.2 (TIDR Threat Identity Data, Range - 7-bit subfield, bits 76-82, 'most recent range of the threat estimated by TCAS') p.153; decode per code's cited ICAO Annex 10 Vol IV §4.3.8.4.2.2.1.6.2

Proposed fix: Force floating-point division: return (range - 1) / 10.0F - 0.05F; (or (range - 1) * 0.1F - 0.05F).

---

_{Filed by the automated lib1090 standards-compliance audit (run 20260715T182455Z, subject commit 94df15f, version 5.0.0-SNAPSHOT). Finding LIB1090-013. Verified against DO-260B / DO-181E / ICAO Doc 9871.}