ADS-B: Add a MAVLink in only type #24107
Conversation
|
Could this be generic to accept any kind of ADS-B in via MavLink? |
It already did accept any MAVLink ADS-B in. This change actually makes it easier to not send any control packets out. |
There was a problem hiding this comment.
I see what you're trying to do but moving the "basic" ADSB-In only option to type=5 rubs me the wrong way. There's a lot of documentation out there that says =1 and those who use ADSB-out, especially on MAVLink, are a waaaay smaller audience size. If anything, I'd say lets just rename the current MAVLink class to MAVLink_out and make it type=5 and type=1 does nothing in update()
| _frontend.out_state.chan = -1; | ||
| _frontend.out_state.chan_last_ms = 0; // if the time isn't reset we spam the message |
There was a problem hiding this comment.
this worthy of a stand-alone PR.
WickedShell
force-pushed
the
wickedshell/adsb-mavlink-in-only
branch
from
2841696
to
a4327dd
Compare
libraries/AP_ADSB/AP_ADSB.h
Outdated
| uAvionix_UCP = 3, | ||
| Sagetech_MXS = 4, | ||
| None = 0, | ||
| uAvionix_MAVLink_In = 1, |
There was a problem hiding this comment.
while we're at it.. how about we just call this "MAVLink_In"
| @@ -38,13 +38,18 @@ bool AP_ADSB_uAvionix_MAVLink::detect() | |||
|
|
|||
| void AP_ADSB_uAvionix_MAVLink::update() | |||
| { | |||
| // if we are an in only instance then we are done here, the work below is all related to sending outputs | |||
| if (_frontend.get_type(_instance) == AP_ADSB::Type::uAvionix_MAVLink_In) { | |||
There was a problem hiding this comment.
this is better as != uAvionix_MAVLink_InOut
| @@ -6,7 +6,7 @@ BATT_VOLT_MULT 12.02 | |||
| BATT2_AMP_PERVLT 39.877 | |||
| BATT2_VOLT_MULT 12.02 | |||
| # setup ADSB | |||
| ADSB_TYPE 1 | |||
| ADSB_TYPE 5 | |||
|
Dev call question: Change the current setups to be in only, or do as the PR presents and make them in/out and change the default to be in only on the builds that enable this by default. Or we can do as tom suggests and change everything to be in only and break all exsisting in/out setups. |
| @@ -56,7 +56,7 @@ const AP_Param::GroupInfo AP_ADSB::var_info[] = { | |||
| // @Param: TYPE | |||
| // @DisplayName: ADSB Type | |||
| // @Description: Type of ADS-B hardware for ADSB-in and ADSB-out configuration and operation. If any type is selected then MAVLink based ADSB-in messages will always be enabled | |||
| // @Values: 0:Disabled,1:uAvionix-MAVLink,2:Sagetech,3:uAvionix-UCP,4:Sagetech MX Series | |||
| // @Values: 0:Disabled,1:uAvionix-MAVLink-InOut,2:Sagetech,3:uAvionix-UCP,4:Sagetech MX Series,5:uAvionix-MAVLink-In | |||
There was a problem hiding this comment.
Feel free to change the order of the Type values here if you want the "-In" option to be higher on the drop-down list.
I guess users won't be confused by which way is "In" (or "out")?
There was a problem hiding this comment.
ADS-B world tends to talk about "ADS-B out" as a sentence, so it seemed slightly clearer to me.
There was a problem hiding this comment.
The industry terminology is "-out" or "-in"
WickedShell
force-pushed
the
wickedshell/adsb-mavlink-in-only
branch
from
a4327dd
to
fd40146
Compare
WickedShell
force-pushed
the
wickedshell/adsb-mavlink-in-only
branch
2 times, most recently
from
f8e18d2
to
7cca215
Compare
This does two main things:
Along these lines it changes the CubePilot boards to default to Rx in only, which is the hardware they ship with by default. ( @bugobliterator )
I chose to keep the existing
ADSB_TYPE1 as not changing behavior, otherwise I would break anyone who currently had setup uAvionix MAVLink out. The other option I considered was adding an options parameter, which would be reasonable, but the initial discussions with @magicrub revolved around adding a new type, which is what this presents.This was tested using a PingRx receiver, and some extra debug prints. I don't have anything that actually transmits to test with, but adding prints in the opposite case of the else's left me pretty convinced that this is working as intended if you have an actual transceiver.