AP_ADSB: uAvionix Transponder Updates

[nicholas-inocencio]

Replaces #28411, which targeted the wrong branch.

This PR contains updates to the interface with the ping200X. Co-requisite with the MissionPlanner PR ArduPilot/MissionPlanner#3429

Changes:

• Added parsing for GDL90 Transponder Status V3
  • Fixes buggy behavior when ping200X has both UCP and UCP-HD out protocols enabled
  • Includes new fields for on-ground state, board temperature, NIC, and NACp.
• Improved behavior when ping200X times out (due to power loss, serial connection error, etc.)
  • UAVIONIX_ADSB_OUT_STATUS_FAULT_STATUS_MESSAGE_UNAVAIL is now 1 if the GDL90 ownship, transponder status, and heartbeat have been missed for 10 seconds, and is otherwise 0 when one of those messages is received. See the co-requisite MissionPlanner PR for changes to how the GCS handles that field.
• Fixed NIC indication when using ArduPilot's GPS as a GPS source for the ping200X
  • Setting ADSB_OPTIONS=1, which forwarded the AP's GPS data to the transponder, would result in a NIC of UNKNOWN due to an invalid HPL
  • HPL is now estimated using the horizontal accuracy
• Improved initialization of control message and frontend status
  • Attempts to poll ping200X for config message to set the control message defaults
  • Fixes a display error where a squawk of 0 was listed when the transponder had never been powered before connecting to the GCS

[nicholas-inocencio]

@magicrub Your help is appreciated!

[magicrub]

@nicholas-inocencio I haven't looked through all the changes quite yet but a quick glance shows me that the whitespace needs some tweaking to follow our code style guide. Also, the commits need to get squashed. I suggest 2 commits: anything in your API AP_ADSB/GDL90_protocol/ (and maybe code in the driver that is specific to those API/struct changes) and then everything else in AP_ADSB.

[nicholas-inocencio]

@nicholas-inocencio I haven't looked through all the changes quite yet but a quick glance shows me that the whitespace needs some tweaking to follow our code style guide. Also, the commits need to get squashed. I suggest 2 commits: anything in your API AP_ADSB/GDL90_protocol/ (and maybe code in the driver that is specific to those API/struct changes) and then everything else in AP_ADSB.

(Apologies, I accidentally closed the PR.)

Thanks Tom, I'll take a good look at the style guide and commit guidelines.

[nicholas-inocencio]

@magicrub The entirety of GDL90_Message_Structs.h (and hostGDL90Support.h) are using 2-space indents instead of 4 as the style guide prescribes. Should I correct this in this PR, or only fix the lines I changed?

EDIT: I fixed all the style changes in a separate commit.

[magicrub]

for your own SDK type stuff we don't care about the style, just the stuff in the ArduPilot libraries that others would be looking at and/or potentially editing.

[magicrub]

How does this effect older Ping200X units that aren't using v3?

[magicrub]

This will always be true. the _ms != 0 is always non-zero because you set it above so there's no change from previous behavior

[nicholas-inocencio]

This is checking _Config, not _Control; _Config is only updated by handle_msg case GDL90_ID_TRANSPONDER_CONFIG.

[magicrub]

Suggested change

	const uint32_t now_ms = AP_HAL::millis();
	run_state.last_gcs_send_message_Transponder_Status_ms = now_ms;
	run_state.last_gcs_send_message_Transponder_Status_ms = AP_HAL::millis();

[magicrub]

If you want to cache the time, thats fine.. but do it above the millis() check a couple lines up so both take advantage of it

[nicholas-inocencio]

How does this effect older Ping200X units that aren't using v3?

Using a tool available online, older ping200X units can be field configured to send v3.

Even if it only got v1, ArduPilot would work fine. The important thing is that handle_msg uses different structs (transponder_status_v3 vs. transponder_status) for each version because the fields have different offsets. The fields absent from v1 are non-critical or have other sources; NIC_NACp is the most important one and it can be read from the ownship report.

[magicrub]

@nicholas-inocencio I just did a bench test and it's looking good. I backported it to my 4.5 branch and it was a clean cherry-pick. In my particular test I didn't have GPS lock so I couldn't reliably transmit but I that's just my setup. Your code seems to be operating OK so far. I'll test again with a proper setup on Friday and if that goes well we can merge it

[magicrub]

Fully tested and merged, thanks @nicholas-inocencio !