mirror of
https://github.com/ArduPilot/ardupilot.git
synced 2026-10-06 19:00:27 +08:00
Tim TuxworthandTom Pittenger
daf1d76805
A user whose ADS-B traffic arrives as ADSB_VEHICLE over a MAVLink link - for example forwarded from a companion computer - has no ADSB_TYPE value that looks like it applies to them: value 1 reads as "you must own a uAvionix device". Value 1 already covers this case. AP_ADSB_uAvionix_MAVLink::update() sends nothing until out_state.chan >= 0, and chan is initialised to -1 and written only on receipt of UAVIONIX_ADSB_TRANSCEIVER_HEALTH_REPORT, so with no transceiver present the backend is inert. Ingest never consults the backend at all: check_startup() only tests _type[instance] > 0 before allocating vehicle_list, and handle_adsb_vehicle() runs from there. The in-tree ADS-B autotests already depend on this, setting ADSB_TYPE=1 with no simulated hardware attached. So relabel value 1 rather than adding a type, and describe both roles. The description states the condition rather than claiming the type is unconditionally receive-only, because handle_transceiver_report() is not type-gated: real hardware appearing on any channel does arm ADSB-out at 5Hz, which is the intended behaviour with a transceiver attached. Also rename the backend class AP_ADSB_uAvionix_MAVLink to AP_ADSB_MAVLink, and HAL_ADSB_UAVIONIX_MAVLINK_ENABLED to HAL_ADSB_MAVLINK_ENABLED, matching the convention used by every other MAVLink backend - AP_Camera_MAVLink, AP_Mount_MAVLink, AP_GPS_MAV and so on. The genuinely uAvionix-specific parts of the driver, the ICAO and callsign-null encodings, keep their names. The Type::uAvionix_MAVLink enumerator is renamed to Type::MAVLink to match; its numeric value is unchanged, so stored ADSB_TYPE values are unaffected. A hwdef still defining HAL_ADSB_UAVIONIX_MAVLINK_ENABLED now fails the build with the name to change to, following the convention already used in hwdef/scripts/defaults_periph.h, rather than being silently aliased onto the new name with no indication it needs updating. No functional change, and no flash cost. Co-Authored-By: Tom Pittenger <tom.pittenger@khaero.com>