×

Notice

The forum is in read only mode.

Accuracy of baro_altitude data from API

5 years 10 months ago #628 by Anton
Hello,

I am using the REST Api to get track by aircraft ADS-B data to plot 3d trajectories in matlab. Longitude and latitude are pretty accurate but the altitude data is strange. When i look up the trajectories of an airplane form departure to arrival the altitude allways rises by the same numbers. It starts at 0 and then goes 304,609,1219,1524,1828,2438(...) at every plane that i look up. Also it sometime stays at the same value for over 30 seconds at takeoff, which i dont get.
Is there an explanation for that?

Example:
Warning: Spoiler!
5 years 10 months ago - 5 years 10 months ago #632 by schaefer
Hi Anton,

our trajectory compression rounds the altitude down in 1000ft steps. For visualisations I'd recommend to discard repeated altitudes and do linear interpolation in between.

Matthias

Note: will be fixed soon.
5 years 9 months ago #692 by danmilon
Related to baro_altitude, I'm sometimes getting funny values. For example:
(Pdb) pp state.__dict__
{'baro_altitude': 35326.32,
 'callsign': 'SKW3339 ',
 'geo_altitude': 10637.52,
 'heading': 236.21,
 'icao24': 'a163c2',
 'last_contact': 1550184247,
 'latitude': 36.9906,
 'longitude': -106.1594,
 'on_ground': False,
 'origin_country': 'United States',
 'position_source': 0,
 'sensors': None,
 'spi': False,
 'squawk': '1645',
 'time_position': 1550184169,
 'velocity': 166.51,
 'vertical_rate': -0.65}

That's a poor ERJ175, it cannot fly 35km up in the air!
Any idea what might be wrong?
5 years 9 months ago #693 by fuchs

(Pdb) pp state.__dict__
{'baro_altitude': 35326.32,
 'callsign': 'SKW3339 ',
 'geo_altitude': 10637.52,
 'heading': 236.21,
 'icao24': 'a163c2',
 'last_contact': 1550184247,
 'latitude': 36.9906,
 'longitude': -106.1594,
 'on_ground': False,
 'origin_country': 'United States',
 'position_source': 0,
 'sensors': None,
 'spi': False,
 'squawk': '1645',
 'time_position': 1550184169,
 'velocity': 166.51,
 'vertical_rate': -0.65}


baro_altitude looks like a value in feet. Is that data directly taken from our API or did you use some third-party library for retrieval?
5 years 9 months ago #694 by danmilon
I do some post-processing, including converting to feet, but what I pasted is the StateVector result straight from the official python library.
Also vertical_rate can be way off sometimes. Let me try to get some more samples.
5 years 9 months ago - 5 years 9 months ago #695 by strohmeier
Edit: The below didn't refer to the API.

Just a note: There's no officially maintained OpenSky Python library for the Impala shell, although we're extremely grateful for Xavier's excellent work!

That said, are you using github.com/xoolive/opensky_data ? It is not longer maintained, instead it is recommended to use github.com/xoolive/traffic.
As mentioned there, bugs or inconsistencies with our descriptions exist in the old repository and this may well be one of them, I think it's in feet there.
5 years 9 months ago #696 by danmilon
5 years 9 months ago #697 by strohmeier
Ah, okay, apologies. We just had the same question about the repository above, got my wires crossed there.
5 years 9 months ago #698 by danmilon
Here's another state vector for aaf55f, and a screenshot from the website:
(Pdb) pp state.__dict__
{'baro_altitude': 24475.44,
 'callsign': 'N805KP  ',
 'geo_altitude': 24559.26,
 'heading': 122.11,
 'icao24': 'aaf55f',
 'last_contact': 1550509915,
 'latitude': 33.307,
 'longitude': -94.5425,
 'on_ground': False,
 'origin_country': 'United States',
 'position_source': 0,
 'sensors': None,
 'spi': False,
 'squawk': '4433',
 'time_position': 1550509840,
 'velocity': 61.95,
 'vertical_rate': -1.3}

I assume sensors sometimes report corrupted data? IIRC when I was reading one of the opensky papers, it mentioned corrupted or in any way invalid data, and attempts to filter them out. Is such a system already in place?
Attachments:
5 years 9 months ago #700 by fuchs
Thanks for the input. That's definitely something we need to investigate.

Here's another state vector for aaf55f, and a screenshot from the website:
I assume sensors sometimes report corrupted data? IIRC when I was reading one of the opensky papers, it mentioned corrupted or in any way invalid data, and attempts to filter them out. Is such a system already in place?


Most of this corrupted data can be summarized as delayed (several minutes) or fake. The latter is caused by software like Mode S Mixer, which encodes MLAT results as Mode S frames. OpenSky aims for collecting real aircraft signals and we need to filter stuff like that. Apart from that, we have seen such frames containing complete rubbish caused by wrong encoding. Delayed data can be found with some sanity checks. That said, we have some filters in place.
5 years 9 months ago #701 by danmilon
Interesting, thanks.
Powered by Kunena Forum
This website uses cookies to offer you the best experience of our services. By using this website you agree to our privacy policy!