ADS-L iConspicuity packets
Up until now, we have used data packets according to the standard EASA ADS-L 4 SRD860 Issue 1. The standard defines an iConspicuity packet which all participating aircraft continuously broadcast. The packet contains, among other information, the current position and velocity vector of the transmitting aircraft.
An aircraft which receives an iConspicuity ADS-L packet from another aircraft knows where that aircraft is located and can then extrapolate future positions of the aircraft along the velocity vector. This is a linear extrapolation and works fine in the simple case of an aircraft following a straight line, but gives inaccurate results if the aircraft’s flight path is curved.
In the OCAP project, we extrapolate curved flight paths to generate more accurate collision warnings. For the prediction of another aircraft’s flight path, the algorithm therefore needs more than one iConspicuity ADS-L packets. With two packets (2 positions and 2 velocity vectors), the algorithm can approximate the curvature of the flight path. (If only 1 packet is available, or the time between received packets is too long, the algorithm falls back to linear extrapolation.)
Test results
During the test flight on 28.08.2024 and another test on 30.09.2024, we have recorded the generated ADS-L packets on the receiver side together with detailed path information (IGC files) on the transmitter side. The analysis of the data shows that the predicted flight paths contain a significant amount of “jitter” (variations) in the predicted path generated on the receiver side.
The first of the two images below visualizes how the predicted pathes (thin blue/green lines) are generated on board of the aircraft “koni”, based on synthetic ADS-L packets generated from the IGC data of both aircraft. We can see that the predictions for both aircraft nicely correspond to the curvature of the flight path at the corresponding point in time:
In the next image, the flight path predictions for “lisa” were calculated from the actual ADS-L packets that have been received by “koni”. We can see that the predictions contain a significant amount of “jitter” (random variations) as a result of taking position and velocity vectors of two separate ADS-L packets. We assume that one of the reasons for the jitter is local variations of the orientation of the aircraft, which is typical for paragliders.
As a result of this jitter, the predictions are less accurate. Alarms appear too early and last too long and the alarm level is less stable but toggles between levels.
Proposed extension
To improve the quality of the flight path prediction for received aircraft, we propose to extend the ADS-L iConspicuity packet with data about the curvature of the sender’s flight path, or define an extended iConspicuity2 packet with the additional information.
In practice, the prediction calculated for the own aircraft can be very precise because accurate GPS data is available for the calculation in constant, regular time intervals.
For other aircraft in the neighbourhood, the only information that we have to predict their flight path is the data packets that we receive from them. Data packets will be lost in practice, for example due to radio interference, packet collisons and weak signals, making it harder or even impossible to create an accurate prediction.
The proposed extension includes two data elements:
A recommendation for the flight path model,
and a vector Z from the aircraft's position to the center of the circle used in the flight path prediction.
The recommendation for the flight path model has one of three values:
The curved model is the default for OCAP. The algorithm extrapolates the predicted path along a circle with radius r and center Z.
The spheric model is a fallback for very small radii r. The algorithm can assume that the object is quasi static and can test a hit with the virtual sphere with center Z for predicting collisions.
The linear model is a fallback for very large radii r. In this case, the algorithm can extrapolate the predicted path along a straight line with good accuracy.
Details
To determine how to encode the components of vector Z (which accuracy and resolution) and how to select the radius limits for the spherical and linear model, we have implemented a small software tool which can, for a given resolution of the vector component, calculate and visualize the error in the XY plane.
The following screenshot from the tool shows an example.
The black arc is the predicted flight path (from bottom right to top) of an aircraft, assuming that the center Z (cross of the red and green lines) can be represented with infinite accuracy.
The brown arc shows the resulting deviation of the path if the approximated center Z’ is a distance e away from the exact center Z, at position angle eps on the small gray circle with center Z and radius e.
And the blue line at the right side shows a linear extrapolation of the flight path along the velocity vector at the start position.
The tool calculates distances f (between the end point of the black and brown arc) and flin (between the brown arc and the linear extrapolation). It can sweep eps to determine the worst-case value for e. The following video shows how the errors change for different eps and fixed e:
To simplify the analysis, we assume that the length of the velocity vector is 1m/s. The length of the predicted path, assuming an extrapolation time of 30 seconds, is then 30m. In practice, the absolute values would scale up or down, but the relative value of the error remains constant.
We use the tool to test possible representations of the vector components Z.x, Z.y and Z.z, the errors that we get with these representations and the lower and upper values of r that we should select to switch to the spheric and linear prediction models.
The result of this analysis is as follows:
We represent each vector elemen as a 10-bit signed, scaled number, with 1 sign, 3 exponent and 6 value bits.
We define the radius for switching to the spheric model to 0.5*dist, or 15*v. For an aircraft flying at a velocity of 1m/s, this is a 15m radius.
We define the radius for switching to the linear model to 1920*v. For an aircraft flying at a velocity of 1m/s, this is a 1.92km radius.
The following table shows
in column 2 how the worst-case error f decreases for increasing radii r and fixed resolution e = 0.125 * v,
in column 3 how the error of a linear approximation decreases with increasing radius,
in column 4 how the resolution of the vector components is reduced (from 0.125 to 0.25 to 0.5 and so on) for larger values of the vector component due to the scaling,
and in column 5 how the worst-case error f is affected by the scaling.
For example, at a radius of 64 meters and for a distance of 0.125 meters between Z and Z’, the worst-case error of the predicted path is 0.06 meters (second column). Starting at radius 65, the resolution of the vector components drops from 0.125m to 0.25m. For an unscaled representation of the vector components, the worst-case error would be 0.059m, but due to the scaling, the actual worst-case error is 0.117m (last column, line at radius 65m).
With 10-bit signed, scaled (3/6) numbers, we can represent values between -16192 and +16192. They represent vector component lengths of 0.125*v. For example, the value 1 corresponds to 0.125*v, the (maximum) value +16192 to 2024*v.
To compensate for the errors introduced into the calculation by representing the Z vector components as 10-bit signed, scaled values, we increase the alarm distance by a constant width of 0.5*v (blue bands in the image below).
To verify the theory, we have planned to perform simulations and tests in the coming weeks.
Comments