I found this while on github, if it could be made to work with mission planner it would give a much more complete picture of what is in the airspace than just adsb.
do you have sample output data?
I found another project that looks even more promising and is plug and play with pixhawk.
2 Likes
I am working on adding OGN support to Ardupilot.
I can envisage few methods how to achieve this, but now I al working on adding a hardware module which reads the MAVlink port to obtain the time/position/speed/baro data to transmit this information to the OGN ground stations.
I have actually some questions, about information available on MAVlimk, where is the best place to ask for example why the time I see there is off by 3 seconds, etc.
1 Like
I have actually some questions, about information available on MAVlimk,
where is the best place to ask for example why the time I see there is off
by 3 seconds, etc.
Either here or on our gitter channel is fine.
Time from mavlink comes from GPS, so if you’re seeing satellites it should
be accurate. A 3 second latency would involve a large-ish buffer, so
consider where one of those might be.
Thank you Peter,
First the time I see in the GPS_RAW_INT is not UTC but boot time.
According to specification it should be UTC in microseconds, but it is boot time in microseconds.
Then, when I add the difference between UTC and boot taken from SYSTEM_TIME, the UTC time I obtain is three seconds in the future, thus it can not be expalined by buffering the data.
Am I correct saying the GPS is set to 5Hz ? I can see times which are (about) at the 0.2sec multiples.
I think the reporting frequency on MAVlink port is set to 2Hz thus I am getting times every 0.4 0r 0.6sec
This is not very convienent and OGN protocol asks for positions at full seconds, but this I can deal with somehow.
Pawel.
.
I have the “old” ATmega autopilot and so it could be the issues I see are corrected with the new hardware/software.
Nevertheless in the code I can see that the time give in the GPS_RAW_INT is simply the hal.scheduler->milis()*1000, so this part is understood.
The 3 second difference I suspect has to do with the leap seconds. Posisbly the time is read as GPS-time and then it gets converter to Unix time but the most recent three leap seconds are not taken into account.
I have found it actually: it is indeed taken from the GPS time with a fixed offset.
uint64_t AP_GPS::time_epoch_usec(uint8_t instance)
{
const GPS_State &istate = state[instance];
if (istate.last_gps_time_ms == 0) {
return 0;
}
const uint64_t ms_per_week = 7000ULL86400ULL;
const uint64_t unix_offset = 17000ULL86400ULL + 52107000ULL86400ULL - 15000ULL;
uint64_t fix_time_ms = unix_offset + istate.time_weekms_per_week + istate.time_week_ms;
// add in the milliseconds since the last fix
return (fix_time_ms + (hal.scheduler->millis() - istate.last_gps_time_ms)) * 1000ULL;
}
@Michael_Oborne: The overall system of FLARM is outlined here: https://flarm.com/technology/eid/
In this short overview of UAS Electronic Identification, there is also a reference how to obtain their protocol
Additionally, they very recently announced, that " FLARM and uAvionix Collaborate to Create Electronic Conspicuity Solutions for Manned and Unmanned Aircraft".
Acc. to their website, “FLARM is the state-of-the-art traffic information, collision avoidance and remote electronic identification technology used in general aviation, installed in over 35’000 manned aircraft”
With the new EU regulations having been published recently, an increasing push towards the implementation of EIDs will be seen, I am sure.
If the Ardupilot community can proactively contribute to taking part in this development, this will certainly help this open source solution to thrive in the coming regulatory changes, both here and in the US.
P.S.: The EU regulation can be reviewed here, and states in Annex IX “Essential requirements for unmanned aircraft”, right in 1.3.: “… to mitigate risks … arising from the operation, the unmanned aircraft must have the corresponding and specific features and functionalities … According to the needs those features and functionalities must ensure easy identification of the aircraft and of the nature and purpose of the operation;…”