I have enabled ADSB-In on a Cube Orange and notice that the SYSID of the MavLink messages are not respecting the SYSID set for the airframe. (e.g. in my case 21) The SYSID used by the ADSB MavLink are always 1. This raises a question of whether this is intended or an oversight, but also leads to a side-effect where my logs for the entire vehicle end up in a folder under MissionPlanner as ADSB/1 rather than copter/21.
Are you using ArduCopter 4.4.2? You should.
i checked the release notes for 4.4.2 - it doesn’t mention any ADSB changes. Currently on 4.4.1 @amilcarlucas
OK, please get used to always report the firmware version that you use. So that we do not need to expliciltly ask that. Waisting both our times.
Yeah sorry. So… this issue remains on 4.4.1. Don’t want to waste anyone’s time. I saw another thread that indicated this was an issue for someone else.
The solution is simple, change the serial5 options to do not forward mavlink messages… the receiver must communicate with the autopilot only, the autopilot will process and send adsb messages to the gcs.
My SERIAL5_OPTIONS are set to ZERO. My issue is related to the in built ADSB IN provided by the carrier board not an external ADSB.
The internal ADSB is on the carrier board AND connected to Serial5
@EosBandi, thanks for clarifying that, but my options are set to ZERO so why does it still end up at the GCS with SYSID = 1 when the cube is set to mavsysid=21?
Set the option to 1024 that disables forwarding mavlink messages from the port.
SERIAL5_OPTIONS = 1024 (bit 10 Don’t forward mavlink to/from)
Ah… just looked at the options mask again and yes that is something I’ll try. Many thanks
1 Like
So for the benefit of others, I can confirm that the setting of SERIAL5_OPTIONS to 1024 does indeed solve this “problem”, that is to say I no longer get confusing logs (aka with the wrong SYSID) on Mission Planner and the onboard ADSB Mavlink messages are no longer visible “off” the UAV. I can also see other ADSB enabled aircraft correctly on Mission Planner as expected. These are also logged in the .bin logs.
Does this mean no ADS-B data is sent to the GCS? Isn’t that valuable information that we could show to the user in the GCS?
Or is there another way the ADS-B data is getting to the GCS?
Wouldn’t be ideal if the ADS-B data has the same sysid as the flight controller (SYSID_THISMAV)?