ADSB selected the most dangerous vehicle by CPA calculation

[error414]

Base of this PR is add posibility to choose CPA calculation. If vehicle flies from warning zone to alert then vehicle is showed in OSD as alert (blinking).

Manual is changed https://github.com/error414/inav/blob/error414/feature/adsb-intercept-calc/docs/ADSB.md and Martinov created nice video with explanation https://discord.com/channels/791437907478577172/881440734761345086/1473447570234806486

Next changes:

1. ADSB calculation was removed from OSD thread and moved to ADSB thread (500ms). OSD thread takes soo much time so better to move ADSB calculation to his own thread. ADSB thread takes a few uS.

2. added two new MSP2 commands, ADSB_LIMITS and ADSB_WARNING_ICAO. "Limits" returs ADSB limits from OSD settings, and "adsb_warning_icao" returns icao of plane which is selected as dangerous. MSP commands are new functionality in configurator

3. in configurator, selected vehicle as dangerous is marked red or orange depend of if iot's warning or alert

4. map is spread to whole VISIBLE area

5. visually represented ADSB limits on map, see screenshot

Configurator: iNavFlight/inav-configurator#2569

BTW: MSP is breaking change so maybe better to merge it to INAV 10.

[qodo-code-review]

ⓘ You are approaching your monthly quota for Qodo. Upgrade your plan

Review Summary by Qodo

Implement CPA-based ADS-B threat detection and MSP2 configurator integration

✨ Enhancement

Walkthroughs

Description

• Implement CPA (Closest Point of Approach) calculation for ADS-B threat detection
  - Adds calculateCPA() and calculateMeetPoint() functions for trajectory prediction
  - Introduces findVehicleForAlert() and findVehicleForWarning() with CPA-based selection logic
• Move ADSB processing from OSD thread to dedicated ADSB task thread
  - Relocate taskAdsb() from fc_tasks.c to adsb.c with 500ms period
  - Improves OSD thread performance by offloading calculations
• Add two new MSP2 commands for configurator integration
  - MSP2_ADSB_LIMITS returns warning/alert distance thresholds
  - MSP2_ADSB_WARNING_VEHICLE_ICAO returns dangerous vehicle ICAO and alert status
• Add CPA configuration option and simulator tools
  - New adsb_calculation_use_cpa setting to toggle between distance and CPA modes
  - Python simulator script for testing ADS-B traffic injection

Diagram

flowchart LR
  A["ADSB Vehicle Data"] --> B["CPA Calculation"]
  B --> C["Threat Detection"]
  C --> D["Alert/Warning Selection"]
  D --> E["OSD Display"]
  D --> F["MSP2 Response"]
  G["ADSB Task Thread"] --> B
  H["Configuration Setting"] --> C

Loading

File Changes

1. src/main/io/adsb.c ✨ Enhancement +194/-113

Implement CPA calculation and threat detection logic

src/main/io/adsb.c

---

2. src/main/io/adsb.h ✨ Enhancement +23/-14

Add CPA-related structures and function declarations

src/main/io/adsb.h

---

3. src/main/fc/fc_msp.c ✨ Enhancement +43/-0

Add MSP2 commands for ADSB limits and warning vehicle

src/main/fc/fc_msp.c

---

View more (12)

4. src/main/fc/fc_tasks.c ✨ Enhancement +1/-9

Move ADSB task to dedicated thread with 500ms period

src/main/fc/fc_tasks.c

---

5. src/main/io/osd.c ✨ Enhancement +19/-12

Update OSD warning display to use new threat detection

src/main/io/osd.c

---

6. src/main/io/osd.h ✨ Enhancement +2/-1

Add CPA calculation mode configuration field

src/main/io/osd.h

---

7. src/main/msp/msp_protocol.h ✨ Enhancement +1/-1

Increment API version for MSP2 changes

src/main/msp/msp_protocol.h

---

8. src/main/msp/msp_protocol_v2_inav.h ✨ Enhancement +3/-0

Define new MSP2 ADSB command identifiers

src/main/msp/msp_protocol_v2_inav.h

---

9. src/main/fc/settings.yaml ⚙️ Configuration changes +6/-0

Add CPA calculation mode configuration setting

src/main/fc/settings.yaml

---

10. src/main/CMakeLists.txt ⚙️ Configuration changes +1/-0

Include ADSB header file in build

src/main/CMakeLists.txt

---

11. docs/ADSB.md 📝 Documentation +38/-0

Document CPA mode operation and threat detection logic

docs/ADSB.md

---

12. docs/Settings.md 📝 Documentation +10/-0

Document new CPA calculation setting

docs/Settings.md

---

13. dev/adsb/adsb_uart_sender.py 🧪 Tests +82/-0

Add Python simulator for ADS-B traffic injection

dev/adsb/adsb_uart_sender.py

---

14. dev/adsb/aircraft.json 🧪 Tests +52/-0

Provide sample aircraft data for simulator testing

dev/adsb/aircraft.json

---

15. dev/adsb/readme.md 📝 Documentation +87/-0

Document ADS-B simulator usage and configuration

dev/adsb/readme.md

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (5) 📎 Requirement gaps (0)

1. send_adsb() lacks JSON validation 📘 Rule violation ⛯ Reliability

Description

The new simulator reads aircraft fields from a JSON payload without validating presence, types,
ranges, or ASCII callsign encoding, which can crash or send malformed MAVLink data. This violates
the requirement to validate external inputs and handle invalid data deterministically.

Code

dev/adsb/adsb_uart_sender.py[R26-36]

+def send_adsb(mav, aircraft):
+    for ac in aircraft:
+        icao = int(ac["icao_address"])
+        lat = int(ac["lat"] * 1e7)
+        lon = int(ac["lon"] * 1e7)
+        alt_mm = int(ac["altitude"] * 1000)
+        heading_cdeg = int(ac["heading"] * 100)
+        hor_vel_cms = int(ac["hor_velocity"] * 100)
+        ver_vel_cms = int(ac["ver_velocity"] * 100)
+        callsign = ac["callsign"].encode("ascii").ljust(9, b'\x00')
+

Evidence

PR Compliance ID 1 requires validating external inputs/payloads before use and handling invalid data
deterministically. The added code directly indexes JSON keys and converts/encodes them without
checks or fallback, so malformed JSON entries can raise exceptions (e.g., KeyError, ValueError,
UnicodeEncodeError) and terminate the tool.

dev/adsb/adsb_uart_sender.py[26-36]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The ADS-B simulator uses unvalidated JSON fields (missing keys, wrong types/ranges, non-ASCII callsign) which can crash the tool or send invalid MAVLink payloads.

## Issue Context
Compliance requires validating external inputs/message payloads before use and returning deterministic errors/fallbacks.

## Fix Focus Areas
- dev/adsb/adsb_uart_sender.py[26-36]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. args.rate can divide zero 📘 Rule violation ⛯ Reliability

Description

The simulator computes period = 1.0 / args.rate without validating that --rate is positive and
non-zero, which can raise a runtime exception. This violates the requirement to range-check external
inputs and fail deterministically.

Code

dev/adsb/adsb_uart_sender.py[R59-69]

+    parser.add_argument("--baud", default=115200, type=int)
+    parser.add_argument("--rate", default=1.0, type=float)
+    args = parser.parse_args()
+
+    ser = serial.Serial(args.com_port, args.baud)
+    mav = create_mavlink(ser)
+
+    aircraft = load_aircraft(args.json_file)
+
+    period = 1.0 / args.rate
+    last_hb = 0

Evidence

PR Compliance ID 1 requires validating numeric ranges for external inputs before using them.
--rate is user-controlled input and is used as a divisor without checking for <= 0.

dev/adsb/adsb_uart_sender.py[59-69]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`--rate` is not validated and can cause division by zero/negative sleep periods.

## Issue Context
Compliance requires validating external numeric parameters for safe ranges and failing deterministically.

## Fix Focus Areas
- dev/adsb/adsb_uart_sender.py[59-69]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. meetPointDistance truncates precision 📘 Rule violation ✓ Correctness

Description

CPA distance is computed in meters as a float but is truncated to an integer meter value and later
converted to centimeters for comparisons, losing precision and mixing units. This can select the
wrong “most dangerous” vehicle near alert thresholds.

Code

src/main/io/adsb.c[R98-108]

+    calculateCPA(
+            pos,
+            ((float)vehicle->vehicleValues.horVelocity) * 0.01f,  // cm/s -> m/s (bez integer dělení)
+            CENTIDEGREES_TO_DEGREES(vehicle->vehicleValues.heading),
+            &t_cpa,
+            &d_min
+    );
+
+    vehicle->calculatedVehicleValues.meetPointDistance = (int)d_min;
+    vehicle->calculatedVehicleValues.meetPointTime = (int)t_cpa;
+}

Evidence

PR Compliance ID 2 requires consistent base units throughout calculations and avoiding premature
casts that reduce precision. The CPA distance d_min (meters, float) is cast to int meters, then
later treated as centimeters via * 100u, which both mixes units and truncates before comparisons.

src/main/io/adsb.c[98-108]
src/main/io/adsb.c[232-236]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
CPA distance is computed as float meters, truncated to integer meters, then converted to centimeters for comparisons, causing unit inconsistency and precision loss.

## Issue Context
Distance thresholds (`alertDistanceCm`, `warningDistanceCm`, `dist`) are in centimeters; CPA-derived values should use the same base unit to keep comparisons correct.

## Fix Focus Areas
- src/main/io/adsb.c[98-108]
- src/main/io/adsb.c[232-236]
- src/main/io/adsb.h[36-40]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View more (3)

4. readme.md wrong script name 📘 Rule violation ✓ Correctness

Description

The new simulator documentation instructs users to run python adsb_sim.py, but the added script
file is named adsb_uart_sender.py. This will mislead users and desynchronize documentation from
the implemented tool.

Code

dev/adsb/readme.md[R14-17]

+## Usage
+```bash
+python adsb_sim.py <com_port> <json_file> [--baud BAUD] [--rate RATE]
+```

Evidence

PR Compliance ID 3 requires documentation to be updated to match code location and behavior. The
README references a script name that does not exist in the PR diff.

dev/adsb/readme.md[14-17]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Documentation references `adsb_sim.py`, but the committed simulator script is `adsb_uart_sender.py`.

## Issue Context
Compliance requires docs to match code locations/names after changes.

## Fix Focus Areas
- dev/adsb/readme.md[14-17]
- dev/adsb/readme.md[28-35]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. ADSB.md setting name mismatch 📘 Rule violation ✓ Correctness

Description

Documentation describes the toggle as adsb_calculation_use_cpa, but the added settings
documentation and YAML define it as osd_adsb_calculation_use_cpa. This inconsistency can cause
users/configurators to use the wrong parameter name.

Code

docs/ADSB.md[R70-78]

+## Alert and Warning
+The ADS-B warning/alert system supports two operating modes, controlled by the parameter adsb_calculation_use_cpa (ON or OFF).
+
+---
+
+### ADS-B Warning and Alert Messages (CPA Mode OFF)
+The ADS-B warning/alert system supports two operating modes, controlled by the parameter **adsb_calculation_use_cpa** (ON or OFF).
+
+When **adsb_calculation_use_cpa = OFF**, the system evaluates only the **current distance between the aircraft and the UAV**. The aircraft with the **shortest distance** is always selected for monitoring.

Evidence

PR Compliance ID 3 requires shared semantics (including parameter names) and documentation to be
synchronized. docs/ADSB.md introduces a different setting name than
docs/Settings.md/settings.yaml added in the same PR.

docs/ADSB.md[70-78]
docs/Settings.md[4485-4492]
src/main/fc/settings.yaml[3693-3698]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`docs/ADSB.md` documents the setting as `adsb_calculation_use_cpa`, but the exposed setting name is `osd_adsb_calculation_use_cpa`.

## Issue Context
Compliance requires documentation and shared semantics to be consistent across modules/docs.

## Fix Focus Areas
- docs/ADSB.md[70-78]
- docs/Settings.md[4485-4492]
- src/main/fc/settings.yaml[3693-3698]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

6. OSD PG version regression 🐞 Bug ⛯ Reliability

Description

PG_OSD_CONFIG version was reset from 15 to 0 while the osdConfig_t layout changed, which forces
resets and also risks accidentally matching and loading incompatible legacy “version 0” EEPROM data
into the new struct layout. This can result in corrupted OSD settings depending on what version is
stored on a given craft.

Code

src/main/io/osd.c[227]

+PG_REGISTER_WITH_RESET_TEMPLATE(osdConfig_t, osdConfig, PG_OSD_CONFIG, 0);

Evidence

The OSD config PG version is now 0, and PG load logic only restores EEPROM blobs when the stored
version exactly matches the compiled PG version. Since the struct layout has changed (a new field
was inserted before later fields), any accidental version match with an older layout would memcpy
mismatched offsets, corrupting settings.

src/main/io/osd.c[225-228]
src/main/config/parameter_group.c[86-94]
src/main/io/osd.h[532-540]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`PG_OSD_CONFIG` was changed from version 15 to version 0 even though `osdConfig_t` changed layout. PG loading only restores EEPROM data on exact version match, so a non-monotonic reset to `0` increases the chance of accidentally matching and loading incompatible historic layouts (and forces resets when versions don’t match).

## Issue Context
- `pgLoad()` resets to defaults and only `memcpy`s EEPROM data when `version == pgVersion(reg)`.
- `osdConfig_t` has a new field inserted before later fields, so loading an incompatible layout would corrupt subsequent fields.

## Fix Focus Areas
- src/main/io/osd.c[225-228]
- src/main/io/osd.h[532-540]
- src/main/config/parameter_group.c[86-94]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

7. CPA lon scale mismatch 🐞 Bug ✓ Correctness

Description

CPA meet-point uses current UAV lat/lon as the conversion origin but reuses
posControl.gpsOrigin.scale, which is derived from a different latitude. This distorts the
east/west component of the relative vector used for CPA, skewing meetPointDistance/time and thus
dangerous-vehicle selection.

Code

src/main/io/adsb.c[R86-93]

+    gpsOrigin_t uavPosition = {
+            .alt = gpsSol.llh.alt,
+            .lat = gpsSol.llh.lat,
+            .lon = gpsSol.llh.lon,
+            .scale = posControl.gpsOrigin.scale,
+            .valid = posControl.gpsOrigin.valid,
+    };
+    geoConvertGeodeticToLocal(&pos, &uavPosition, &vehicle->vehicleValues.gps, GEO_ALT_RELATIVE);

Evidence

geoConvertGeodeticToLocal scales longitude deltas by origin->scale, and that scale is explicitly
computed from origin->lat. In CPA code, the origin latitude is taken from current GPS, but scale
is taken from posControl.gpsOrigin.scale (computed for the home/origin latitude), so the
conversion is internally inconsistent.

src/main/io/adsb.c[83-93]
src/main/navigation/navigation_geo.c[108-127]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
CPA conversion uses a `gpsOrigin_t` whose `lat/lon` come from the current UAV position but whose `scale` comes from `posControl.gpsOrigin.scale` (home/origin latitude). Since `geoConvertGeodeticToLocal` uses `origin->scale` to scale longitude deltas, this produces an inconsistent coordinate conversion for CPA calculations.

## Issue Context
`navigation_geo.c` shows `origin->scale` is computed from `origin->lat` and is directly used when converting lon deltas. CPA should use a scale consistent with the chosen origin latitude.

## Fix Focus Areas
- src/main/io/adsb.c[83-93]
- src/main/navigation/navigation_geo.c[108-127]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[github-actions]

Test firmware build ready — commit 36e2c23

Download firmware for PR #11346

228 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

[qodo-code-review]

Review Summary by Qodo

Implement CPA-based ADS-B threat detection and move calculations to dedicated thread

✨ Enhancement

Walkthroughs

Description

  This description is generated by an AI tool. It may have inaccuracies
• Implement CPA (Closest Point of Approach) calculation for ADS-B threat detection
  - Added calculateCPA() function to predict aircraft collision trajectories
  - New findVehicleForAlert() and findVehicleForWarning() functions select dangerous vehicles
  based on CPA or distance
• Move ADSB calculations from OSD thread to dedicated ADSB task thread (500ms period)
  - Moved taskAdsb() function to adsb.c with recalculation logic
  - Improves OSD thread performance by offloading heavy computations
• Add two new MSP2 commands for configurator integration
  - MSP2_ADSB_LIMITS returns warning/alert distance thresholds
  - MSP2_ADSB_WARNING_VEHICLE_ICAO returns ICAO and alert status of dangerous vehicle
• Add ADSB simulator tool for development and testing
  - Python script to inject simulated ADS-B contacts via MAVLink protocol
  - Includes sample aircraft JSON configuration file

Diagram

flowchart LR
  A["ADSB Task<br/>500ms"] -->|recalculate| B["Vehicle Data"]
  B -->|CPA enabled| C["calculateCPA"]
  C -->|predict trajectory| D["meetPointDistance<br/>meetPointTime"]
  B -->|find threat| E["findVehicleForAlert"]
  B -->|find threat| F["findVehicleForWarning"]
  E -->|select| G["Most dangerous vehicle"]
  F -->|select| G
  G -->|MSP2 commands| H["Configurator"]
  H -->|display| I["OSD Warning/Alert"]

Loading

File Changes

1. src/main/fc/fc_msp.c ✨ Enhancement +43/-0

Add MSP2 commands for ADSB limits and warning vehicle

src/main/fc/fc_msp.c

---

2. src/main/fc/fc_tasks.c ✨ Enhancement +1/-9

Move ADSB task to dedicated thread with 500ms period

src/main/fc/fc_tasks.c

---

3. src/main/io/adsb.c ✨ Enhancement +194/-113

Implement CPA calculation and threat detection logic

src/main/io/adsb.c

---

View more (12)

4. src/main/io/adsb.h ✨ Enhancement +23/-14

Add CPA-related fields and new threat detection functions

src/main/io/adsb.h

---

5. src/main/io/osd.c ✨ Enhancement +19/-12

Update OSD warning display to use new threat detection

src/main/io/osd.c

---

6. src/main/io/osd.h ⚙️ Configuration changes +2/-1

Add CPA calculation mode configuration option

src/main/io/osd.h

---

7. src/main/msp/msp_protocol.h ✨ Enhancement +1/-1

Increment API version for MSP protocol changes

src/main/msp/msp_protocol.h

---

8. src/main/msp/msp_protocol_v2_inav.h ✨ Enhancement +3/-0

Define new MSP2 ADSB command identifiers

src/main/msp/msp_protocol_v2_inav.h

---

9. dev/adsb/adsb_uart_sender.py 🧪 Tests +82/-0

Add ADSB simulator script for development testing

dev/adsb/adsb_uart_sender.py

---

10. dev/adsb/aircraft.json 🧪 Tests +52/-0

Add sample aircraft configuration for simulator

dev/adsb/aircraft.json

---

11. dev/adsb/readme.md 📝 Documentation +87/-0

Document ADSB simulator usage and aircraft format

dev/adsb/readme.md

---

12. docs/ADSB.md 📝 Documentation +38/-0

Document CPA mode and alert/warning behavior

docs/ADSB.md

---

13. docs/Settings.md 📝 Documentation +10/-0

Document new CPA calculation configuration setting

docs/Settings.md

---

14. src/main/CMakeLists.txt ⚙️ Configuration changes +1/-0

Add adsb.h to build sources

src/main/CMakeLists.txt

---

15. src/main/fc/settings.yaml ⚙️ Configuration changes +6/-0

Add CPA calculation mode setting definition

src/main/fc/settings.yaml

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (3)   📘 Rule violations (8)   📎 Requirement gaps (0)

🐞\ ≡ Correctness (3) ⭐ New (1)

📘\ ≡ Correctness (6) ⛨ Security (1) ⚙ Maintainability (1) ⭐ New (3)

1. CPA distance treats 0 invalid 📘 ≡ ⭐

Description

findVehicleForAlert() requires meetPointDistance > 0, making a valid CPA of 0 meters (direct
intercept) indistinguishable from “no data” and excluded from alert selection. This violates the
requirement to use consistent, non-ambiguous sentinels for invalid/no-data states.

Code

src/main/io/adsb.c[R228-234]

+        } else if (osdConfig()->adsb_calculation_use_cpa &&
+                   vehicle->calculatedVehicleValues.dist <= warningDistanceCm &&
+                   vehicle->calculatedVehicleValues.meetPointTime >= 0 &&
+                   vehicle->calculatedVehicleValues.meetPointDistance > 0) {
+            const uint32_t meetPointDistanceCm = ((uint32_t)vehicle->calculatedVehicleValues.meetPointDistance) * 100u;
+            if (meetPointDistanceCm > alertDistanceCm) {
+                continue;

Evidence

The checklist forbids ambiguous sentinels like 0 for invalid/no-data when 0 can be a valid
value. The new CPA logic explicitly excludes meetPointDistance == 0, which can be a real
closest-approach distance.

src/main/io/adsb.c[228-234]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The CPA-based alert selection treats `meetPointDistance == 0` as invalid data, which can suppress alerts for direct-intercept trajectories.

## Issue Context
A closest point of approach distance of `0` meters is physically valid (collision course). Invalid/no-data should use a dedicated sentinel (e.g., `-1`) rather than excluding `0`.

## Fix Focus Areas
- src/main/io/adsb.c[228-234]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. CPA ignores sub-1m CPA 🐞 ≡ ⭐

Description

CPA alert selection drops vehicles with meetPointDistance == 0 and stores CPA distance as whole
meters, so collision courses with CPA < 1m can be ignored in CPA mode until the aircraft is already
inside the instantaneous alert radius. This undermines the “predictive” alert behavior intended by
CPA mode.

Code

src/main/io/adsb.c[R228-233]

+        } else if (osdConfig()->adsb_calculation_use_cpa &&
+                   vehicle->calculatedVehicleValues.dist <= warningDistanceCm &&
+                   vehicle->calculatedVehicleValues.meetPointTime >= 0 &&
+                   vehicle->calculatedVehicleValues.meetPointDistance > 0) {
+            const uint32_t meetPointDistanceCm = ((uint32_t)vehicle->calculatedVehicleValues.meetPointDistance) * 100u;
+            if (meetPointDistanceCm > alertDistanceCm) {

Evidence

calculateMeetPoint() casts the float CPA distance in meters to int, truncating sub-meter values
to 0, and findVehicleForAlert() requires meetPointDistance > 0 before considering CPA-based
alerting. Since CPA mode is meant to warn before entering adsb_distance_alert, this combination
can suppress the alert for the most dangerous case (near-zero CPA).

src/main/io/adsb.c[83-108]
src/main/io/adsb.c[208-239]
src/main/io/adsb.h[34-55]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
CPA distance is truncated to whole meters and CPA alerts are skipped when `meetPointDistance == 0`. A predicted CPA < 1m (or exactly 0m) is a critical case that should still trigger alert selection.

### Issue Context
- `d_min` is computed in meters.
- `meetPointDistance` is stored as `int32_t` and later multiplied by 100 to compare with cm thresholds.

### Fix Focus Areas
- src/main/io/adsb.c[83-108]
- src/main/io/adsb.c[208-239]
- src/main/io/adsb.h[34-55]

### Suggested fix approach
- Store CPA distance in **centimeters** (or millimeters) to avoid truncation.
 - Example: `meetPointDistanceCm = lrintf(d_min * 100.0f)`.
- Remove the `> 0` gate; treat 0 as valid.
 - If a sentinel is needed, use `-1` for “unknown” and allow `0`.
- Update field comments/units in `adsb.h` accordingly and adjust the comparison logic to avoid repeated unit conversions.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. send_adsb() lacks JSON validation 📘 ≡

Description

The new simulator reads aircraft fields from a JSON payload without validating presence, types,
ranges, or ASCII callsign encoding, which can crash or send malformed MAVLink data. This violates
the requirement to validate external inputs and handle invalid data deterministically.

Code

dev/adsb/adsb_uart_sender.py[R26-36]

+def send_adsb(mav, aircraft):
+    for ac in aircraft:
+        icao = int(ac["icao_address"])
+        lat = int(ac["lat"] * 1e7)
+        lon = int(ac["lon"] * 1e7)
+        alt_mm = int(ac["altitude"] * 1000)
+        heading_cdeg = int(ac["heading"] * 100)
+        hor_vel_cms = int(ac["hor_velocity"] * 100)
+        ver_vel_cms = int(ac["ver_velocity"] * 100)
+        callsign = ac["callsign"].encode("ascii").ljust(9, b'\x00')
+

Evidence

PR Compliance ID 1 requires validating external inputs/payloads before use and handling invalid data
deterministically. The added code directly indexes JSON keys and converts/encodes them without
checks or fallback, so malformed JSON entries can raise exceptions (e.g., KeyError, ValueError,
UnicodeEncodeError) and terminate the tool.

dev/adsb/adsb_uart_sender.py[26-36]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The ADS-B simulator uses unvalidated JSON fields (missing keys, wrong types/ranges, non-ASCII callsign) which can crash the tool or send invalid MAVLink payloads.
## Issue Context
Compliance requires validating external inputs/message payloads before use and returning deterministic errors/fallbacks.
## Fix Focus Areas
- dev/adsb/adsb_uart_sender.py[26-36]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View more (5)

4. args.rate can divide zero 📘 ≡

Description

The simulator computes period = 1.0 / args.rate without validating that --rate is positive and
non-zero, which can raise a runtime exception. This violates the requirement to range-check external
inputs and fail deterministically.

Code

dev/adsb/adsb_uart_sender.py[R59-69]

+    parser.add_argument("--baud", default=115200, type=int)
+    parser.add_argument("--rate", default=1.0, type=float)
+    args = parser.parse_args()
+
+    ser = serial.Serial(args.com_port, args.baud)
+    mav = create_mavlink(ser)
+
+    aircraft = load_aircraft(args.json_file)
+
+    period = 1.0 / args.rate
+    last_hb = 0

Evidence

PR Compliance ID 1 requires validating numeric ranges for external inputs before using them.
--rate is user-controlled input and is used as a divisor without checking for <= 0.

dev/adsb/adsb_uart_sender.py[59-69]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`--rate` is not validated and can cause division by zero/negative sleep periods.
## Issue Context
Compliance requires validating external numeric parameters for safe ranges and failing deterministically.
## Fix Focus Areas
- dev/adsb/adsb_uart_sender.py[59-69]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. meetPointDistance truncates precision 📘 ≡

Description

CPA distance is computed in meters as a float but is truncated to an integer meter value and later
converted to centimeters for comparisons, losing precision and mixing units. This can select the
wrong “most dangerous” vehicle near alert thresholds.

Code

src/main/io/adsb.c[R98-108]

+    calculateCPA(
+            pos,
+            ((float)vehicle->vehicleValues.horVelocity) * 0.01f,  // cm/s -> m/s (bez integer dělení)
+            CENTIDEGREES_TO_DEGREES(vehicle->vehicleValues.heading),
+            &t_cpa,
+            &d_min
+    );
+
+    vehicle->calculatedVehicleValues.meetPointDistance = (int)d_min;
+    vehicle->calculatedVehicleValues.meetPointTime = (int)t_cpa;
+}

Evidence

PR Compliance ID 2 requires consistent base units throughout calculations and avoiding premature
casts that reduce precision. The CPA distance d_min (meters, float) is cast to int meters, then
later treated as centimeters via * 100u, which both mixes units and truncates before comparisons.

src/main/io/adsb.c[98-108]
src/main/io/adsb.c[232-236]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
CPA distance is computed as float meters, truncated to integer meters, then converted to centimeters for comparisons, causing unit inconsistency and precision loss.
## Issue Context
Distance thresholds (`alertDistanceCm`, `warningDistanceCm`, `dist`) are in centimeters; CPA-derived values should use the same base unit to keep comparisons correct.
## Fix Focus Areas
- src/main/io/adsb.c[98-108]
- src/main/io/adsb.c[232-236]
- src/main/io/adsb.h[36-40]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

6. readme.md wrong script name 📘 ≡

Description

The new simulator documentation instructs users to run python adsb_sim.py, but the added script
file is named adsb_uart_sender.py. This will mislead users and desynchronize documentation from
the implemented tool.

Code

dev/adsb/readme.md[R14-17]

+## Usage
+```bash
+python adsb_sim.py <com_port> <json_file> [--baud BAUD] [--rate RATE]
+```

Evidence

PR Compliance ID 3 requires documentation to be updated to match code location and behavior. The
README references a script name that does not exist in the PR diff.

dev/adsb/readme.md[14-17]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Documentation references `adsb_sim.py`, but the committed simulator script is `adsb_uart_sender.py`.
## Issue Context
Compliance requires docs to match code locations/names after changes.
## Fix Focus Areas
- dev/adsb/readme.md[14-17]
- dev/adsb/readme.md[28-35]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

7. ADSB.md setting name mismatch 📘 ≡

Description

Documentation describes the toggle as adsb_calculation_use_cpa, but the added settings
documentation and YAML define it as osd_adsb_calculation_use_cpa. This inconsistency can cause
users/configurators to use the wrong parameter name.

Code

docs/ADSB.md[R70-78]

+## Alert and Warning
+The ADS-B warning/alert system supports two operating modes, controlled by the parameter adsb_calculation_use_cpa (ON or OFF).
+
+---
+
+### ADS-B Warning and Alert Messages (CPA Mode OFF)
+The ADS-B warning/alert system supports two operating modes, controlled by the parameter **adsb_calculation_use_cpa** (ON or OFF).
+
+When **adsb_calculation_use_cpa = OFF**, the system evaluates only the **current distance between the aircraft and the UAV**. The aircraft with the **shortest distance** is always selected for monitoring.

Evidence

PR Compliance ID 3 requires shared semantics (including parameter names) and documentation to be
synchronized. docs/ADSB.md introduces a different setting name than
docs/Settings.md/settings.yaml added in the same PR.

docs/ADSB.md[70-78]
docs/Settings.md[4485-4492]
src/main/fc/settings.yaml[3693-3698]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`docs/ADSB.md` documents the setting as `adsb_calculation_use_cpa`, but the exposed setting name is `osd_adsb_calculation_use_cpa`.
## Issue Context
Compliance requires documentation and shared semantics to be consistent across modules/docs.
## Fix Focus Areas
- docs/ADSB.md[70-78]
- docs/Settings.md[4485-4492]
- src/main/fc/settings.yaml[3693-3698]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

8. OSD PG version regression 🐞 ≡

Description

PG_OSD_CONFIG version was reset from 15 to 0 while the osdConfig_t layout changed, which forces
resets and also risks accidentally matching and loading incompatible legacy “version 0” EEPROM data
into the new struct layout. This can result in corrupted OSD settings depending on what version is
stored on a given craft.

Code

src/main/io/osd.c[227]

+PG_REGISTER_WITH_RESET_TEMPLATE(osdConfig_t, osdConfig, PG_OSD_CONFIG, 0);

Evidence

The OSD config PG version is now 0, and PG load logic only restores EEPROM blobs when the stored
version exactly matches the compiled PG version. Since the struct layout has changed (a new field
was inserted before later fields), any accidental version match with an older layout would memcpy
mismatched offsets, corrupting settings.

src/main/io/osd.c[225-228]
src/main/config/parameter_group.c[86-94]
src/main/io/osd.h[532-540]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`PG_OSD_CONFIG` was changed from version 15 to version 0 even though `osdConfig_t` changed layout. PG loading only restores EEPROM data on exact version match, so a non-monotonic reset to `0` increases the chance of accidentally matching and loading incompatible historic layouts (and forces resets when versions don’t match).
## Issue Context
- `pgLoad()` resets to defaults and only `memcpy`s EEPROM data when `version == pgVersion(reg)`.
- `osdConfig_t` has a new field inserted before later fields, so loading an incompatible layout would corrupt subsequent fields.
## Fix Focus Areas
- src/main/io/osd.c[225-228]
- src/main/io/osd.h[532-540]
- src/main/config/parameter_group.c[86-94]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

9. Unbounded callsign MAVLink payload 📘 ⛨ ⭐

Description

adsb_uart_sender.py encodes and pads callsign but never enforces the MAVLink field’s fixed
length, so oversized JSON values can create malformed payloads or runtime errors. This violates the
requirement to validate external inputs and payload sizes before use.

Code

dev/adsb/adsb_uart_sender.py[R28-36]

+        icao = int(ac["icao_address"])
+        lat = int(ac["lat"] * 1e7)
+        lon = int(ac["lon"] * 1e7)
+        alt_mm = int(ac["altitude"] * 1000)
+        heading_cdeg = int(ac["heading"] * 100)
+        hor_vel_cms = int(ac["hor_velocity"] * 100)
+        ver_vel_cms = int(ac["ver_velocity"] * 100)
+        callsign = ac["callsign"].encode("ascii").ljust(9, b'\x00')
+

Evidence

The checklist requires validating external inputs/payload sizes before parsing/serializing. The new
code consumes JSON fields directly and builds a MAVLink callsign byte field without
truncation/validation.

dev/adsb/adsb_uart_sender.py[28-36]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The simulator reads aircraft data from a JSON file and constructs a MAVLink `ADSB_VEHICLE` message, but does not validate required keys/types or enforce the fixed-size `callsign` payload length.

## Issue Context
MAVLink fields like `callsign` are fixed-length; using `ljust(9)` does not truncate longer values. Also, `encode("ascii")` can raise if non-ASCII input is provided.

## Fix Focus Areas
- dev/adsb/adsb_uart_sender.py[28-36]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

10. CPA lon scale mismatch 🐞 ≡

Description

CPA meet-point uses current UAV lat/lon as the conversion origin but reuses
posControl.gpsOrigin.scale, which is derived from a different latitude. This distorts the
east/west component of the relative vector used for CPA, skewing meetPointDistance/time and thus
dangerous-vehicle selection.

Code

src/main/io/adsb.c[R86-93]

+    gpsOrigin_t uavPosition = {
+            .alt = gpsSol.llh.alt,
+            .lat = gpsSol.llh.lat,
+            .lon = gpsSol.llh.lon,
+            .scale = posControl.gpsOrigin.scale,
+            .valid = posControl.gpsOrigin.valid,
+    };
+    geoConvertGeodeticToLocal(&pos, &uavPosition, &vehicle->vehicleValues.gps, GEO_ALT_RELATIVE);

Evidence

geoConvertGeodeticToLocal scales longitude deltas by origin->scale, and that scale is explicitly
computed from origin->lat. In CPA code, the origin latitude is taken from current GPS, but scale
is taken from posControl.gpsOrigin.scale (computed for the home/origin latitude), so the
conversion is internally inconsistent.

src/main/io/adsb.c[83-93]
src/main/navigation/navigation_geo.c[108-127]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
CPA conversion uses a `gpsOrigin_t` whose `lat/lon` come from the current UAV position but whose `scale` comes from `posControl.gpsOrigin.scale` (home/origin latitude). Since `geoConvertGeodeticToLocal` uses `origin->scale` to scale longitude deltas, this produces an inconsistent coordinate conversion for CPA calculations.
## Issue Context
`navigation_geo.c` shows `origin->scale` is computed from `origin->lat` and is directly used when converting lon deltas. CPA should use a scale consistent with the chosen origin latitude.
## Fix Focus Areas
- src/main/io/adsb.c[83-93]
- src/main/navigation/navigation_geo.c[108-127]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

11. ADSB task comment wrong frequency 📘 ⚙ ⭐

Description

The ADSB task period was changed to TASK_PERIOD_MS(500) (2 Hz) but the trailing comment still
states it is updated at 1 Hz. This creates a misleading in-code contract/documentation mismatch.

Code

src/main/fc/fc_tasks.c[561]

+        .desiredPeriod = TASK_PERIOD_MS(500),      // ADSB is updated at 1 Hz

Evidence

The checklist requires shared behavior/documentation to remain consistent after behavior changes.
The modified line changes runtime behavior but leaves an incorrect comment about the update rate.

src/main/fc/fc_tasks.c[561-561]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The comment describing the ADSB task update frequency no longer matches the configured period.

## Issue Context
The period is now 500 ms (2 Hz) but the comment still says 1 Hz.

## Fix Focus Areas
- src/main/fc/fc_tasks.c[561-561]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more