Here is an early look at a system I am putting together to prewarm me of any special/unusual aircraft that will be flying in my locality.
The system uses a few different protocols via the OpenSkyNetwork.
By issuing this REST command string to the API :-
| "https://opensky-network.org/api/states/all?lamin=47&lomin=9&lamax=48&lo… HTTP/1.1\r\nHost: opensky-network.org\r\nConnection: close\r\n\r\n" |
|
or you could just test now by pasting this into your internet browser :- https://opensky-network.org/api/states/all?lamin=47&lomin=9&lamax=48&lo… |
The resulting payload back reveals this data in json format.
|
This is basically all the flights within the selected coordinates contained in the query (luckily I live within a bounding box 47-48,9-10 decimal coords ..phew)
|
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
icao24 callsign origin_country time_position last_contact longitude latitude baro_altitude on_ground velocity true_track vertical_rate sensors geo_altitude squark spi position_source
|
Unique ICAO 24-bit address of the transponder in hex string representation. Callsign of the vehicle (8 chars). Can be null if no callsign has been received. Country name inferred from the ICAO 24-bit address. Unix timestamp (seconds) for the last position update. Unix timestamp (seconds) for the last update in general. WGS-84 longitude in decimal degrees. WGS-84 latitude in decimal degrees. Barometric altitude in meters. Boolean value which indicates if the position was retrieved from a surface position report. Velocity over ground in m/s. True track in decimal degrees clockwise from north (north=0°). Vertical rate in m/s. A positive value indicates that the airplane is climbing, a negative value indicates that it descends. IDs of the receivers which contributed to this state vector. Is null if no filtering for sensor was used in the request. Geometric altitude in meters. The transponder code aka Squawk. Whether flight status indicates special purpose indicator. /Origin of this state’s position: 0 = ADS-B, 1 = ASTERIX, 2 = MLAT |
To access this data an ESP32 is used, one part retrieves the data via Wifi link to the OpenSkyNetwork, second part displays the data to a simple VGA screen.
Below is just one of the first feasibility checks where the tracking interval is 7 seconds.
Its still a "Work in progress", still have scaling issues with the map underlay and need better way to display the call sign, also need to replace dots with plane sprites at the right angle of a dangle.
The end plan is to use Machine Learning...... i.e. point the API to Major airports and log all the "Call Signs" over say one week so that a data set can be made.
Then after it has been taught, it will listen and report and flag an alarm only when it finds a new "Call Sign", it is highly likely (be my reckoning) that these will belong to special or rare flights.