So I can sent GLOBAL_POSITION_INT and it would be interpreted as an aircraft which my receiver can hear ?
There is no place for the identity of the aircraft thus how shall I signal several aircrafts in vicinity ?
It can be only 8-bit, I would need to make local mapping between aircraft addresses (24+2bits) and 8-bit IDâs ?
This could work if I would run a traffic awareness algorithm inside the OGN-Tracker keeping an indexed list of aircrafts around.
Shall I send the positions all the time or only when I think the collision is at a significant risk ?
BTW: how shall I fill the ârelative_altâ field in GLOBAL_POSITION_INT ?
[quote=âMagicRuB, post:37, topic:15242â]
This allows you to automatically sense other aircraft via MAVLink, not just via ADSB.[/quote]
I Interpret it like that: if we have a dedicated receiver such as ADSB, FLARM, OGN it is best to produce ADSB_VEHICLE messages.
In a connected swarm, where every vehicle already sends its GLOBAL_POSITION_INT we donât need ADSB_VEHICLE.
Can I inject ADSB_VEHICLE Messages on the GCS and it will be forwarded to the flight controller and detected as obstacle object?
The GCS should be getting both the usual MAVLink packets from the swarm and any ADSB ones. Take a look at this from 2 years ago. A swam of SITL vehicles that are all on the same IP network (in this case theyâre all loopback but they could have easily just been on the same wifi network or on multiple serial ports):
This has gone in upstream re FLARM. May be worth considering for OGN too:
Yes, this would be good. I am a bit afraid to do so, as not to break things 
I have looked as well into the ADS-B and it has provision for non-ICAO addresses,
thus it would be worth to include such flag in the ADSB_VEHICLE message.
Thank you.
For the ADS-B aircraft category: it defines four category sub-sets: A, B, C, and D and within each subset there are 8 posibilities, not all are defined yet. This makes 32 possibilities.
One could define more subcategories, like FLARM/OGN one with 16 possibilities each, this would give space for other systems.
For the tslc field: time since last communication of the ADSB_VEHICLE: how shall this work ?
Normally, when a receiver get a new position it is âcurrentâ within one second or less.
In case when the receiver takes longer time to process and sends the ADSB_VEHICLE message with significant delay, shall it extrapolate the position to represent the time of message transmission or shall it leave it in the past ?
ADS-B is based on 0.2sec time granuality, thus possibly it would be worth to have tslc in 0.1sec units ?
This matches the drones which have most often the GPS running at 5Hz, correct ?
For best performance and minimal errors when extrapolating, etc. the tslc should ideally contain a localized timestamp. Then the drone could compute trajectories with best accuracies, otherwise the time error introduces a large position error when predicting.
Well, what if we introduce one more bit in the flag, which would say whether tslc is defined as of now (flag=0) thus ensuring compatibility and when the flags is 1 the tslc would contain a more precise and better defined timestamp ?
Thus I propose two more flags or fields there: ICAO_address-type and tslc-timestamp-type