Dump1090 and ADS-B questions

I’ve had numerous receivers off and on over the years, and recently had an idea I want to explore with an add-on software for Dump1090. Been doing a lot of research on ADS-B and trying to understand Dump1090. Does anyone know at what point ADS-B switches to/from ground reporting vs airborne?

Also, from my reading of the dump1090 source code, it basically runs a socket based server to send decoded messages out. I want to intercept those messages, and focusing only on the following data: Callsign, timestamp, lat/long, and maybe one or two other in the vast array of data it can send out. I haven’t yet figured out which modes Dump1090 uses for sending out the data or what format is easiest to work with, and advice would be appreciated. Mostly going to want only data on or right near an airport, and throw out most of the rest.

Are you aware that dump1090 produces JSON data which can be used to work with?

simply point your browser to http://[your device]/dump1090-fa/aircraft.json

This contain many of the information you’re looking for. Can be parsed via Python or any other language

You’ll just have to re-decode the raw messages, which isn’t trivial :wink:

First of all get dump1090-fa or readsb installed and running via the usual service, then:

view1090-fa --show-only 123456
viewreadsb --show-only 123456

This console output is the best explanation of individual messages you can get easily.
Apart from that you can look at this: https://mode-s.org/decode/book-the_1090mhz_riddle-junzi_sun.pdf (also has a python library associated but i found the dump1090-fa source code a better read … and i modified my readsb code for stuff i was interested in)

Just change the displayModesMessage() function in mode_s.c and recompile.
That way you can just display what you want.

readsb has the feature --filter-DF 17 which might be useful to you if you only want certain types of messages.
You could easily just hard code that as well in displayModesMessage() if you want further stuff.
Maybe also look at --cpr-focus in readsb.

https://github.com/wiedehopf/readsb

For airliners it’s typically a certain speed as far as i know … usually from 60 to 100 knots.
For smaller craft i’m not sure.
Click some tracks on here and make sure you have K enabled: https://globe.adsbexchange.com/
Should give you a good cross section of the transition at least at the well covered airports.

Larger aircraft usually have a weight-on-wheels sensor (“squat switch”) which is the primary source for this (airspeed might used as a fallback)

I’ve looked at quite a few transitions and it seems to be not quite as simple as that.
The squat switch triggers the auto spoilers and that happens pretty much right at touchdown.

Yet the vast majority of transitions from transmitting airborne to ground happens way beyond the 1000 ft marker and at speeds that are lower than touchdown speed.
This is a bit of handwaving but having seen some livestreams and comparing the touchdown / spoiler deployment with the ADS-B data i’m pretty certain.

And on takeoff the data transitions to airborne happens significantly earlier than positive climb being achieved and the transition just doesn’t match where i would expect the weight on wheel sensor change state (during rotation).

I don’t have any solid information how the aircraft are wired so this is just speculation based on observation of very detailed ADS-B data.

A short takeoff example with screenshot:
Takeoff 5 mins ago, wind at LGA less than 10 kts.
At 95 knots ground speed the aircraft starts transmitting airborne CPR messages.
The baro altitude shows 25 / 50 ft for the next 10 seconds, then it shows 0 ft.
This slight decrease in baro altitude is followed by the climbout.
My speculation would be that this altitude drop corresponds to the aircraft rotating which changes the airflow around the aircraft which changes the reading of the barometric altitude.
This drop is consistently observable across many types so i’m fairly confident in that assumption, especially because it’s always followed by the climbout.

The only logical conclusion is that the aircraft started transmitting “airborne” more than 10 seconds before rotation.
Thus i’m convinced that transition doesn’t happen with the weight on wheel sensor change.
I’m pretty sure the weight on wheel sensor is required to show ground for ADS-B to show ground, but it’s not the only requirement, the second logic requirement i’d guess is airspeed.

OAK, also just a short moment ago, takeoff by an MD11 which is known for pretty high rotation speeds.
Wind is calm, density altitude -900 ft, so the groundspeed of around 100 knots in the very worst case corresponds to 120 knots maybe?
Don’t think even an empty MD11 would rotate at that airspeed.
Also you have again the 12 seconds between ADS-B ground → air transition to positive climb.


If anyone has actual knowledge of which input the ADS-B transponder is connected to in the aircraft in regards to ground state and what that ground state logic is … would be better than my speculation of course :slight_smile:

The spec itself is somewhat hand-wavy about the precise details, but there’s specifically an exception that overrides to airborne above a speed / altitude threshold:

If a transmitting ADS-B participant is equipped with a means, such as a weight-
on-wheels switch, to determine automatically whether it is airborne or on the
surface, then such information shall be used to determine whether to broadcast
the Airborne Position Message (§2.2.3.2.3), or the Surface Position Message
(§2.2.3.2.4).

[…]

If Ground Speed > 100 knots OR Airspeed >100 knots OR Radio Altitude > 50 feet,
then the Air/Ground status shall be changed to “Airborne” and the Airborne Position
Message (see §2.2.3.2.3) shall be broadcast irrespective of the automatically
determined Air/Ground status.

[…]

Note:
Modern aircraft with integrated avionics suites commonly contain sophisticated
algorithms for determining the air/ground status based on multiple aircraft
sensors. These algorithms are customized to the airframe and designed to
overcome individual sensor failures. These algorithms are an acceptable means
to determine the air/ground status and do not require additional validation.

For aircraft without a WOW sensor etc, there’s an involved set of conditions in the spec that depends on aircraft category, ground speed, air speed, radio altimeter height… you should read the spec for the details :wink:

Well that nicely explains the two screenshots above.

But yeah … most aircraft with WOW sensors typically land / rotate at more than 100 knots so it seems the 100 knots effectively becomes the primary source for air / ground status and WOW sensors only matter for a few types or certain circumstances.

Thanks for quoting … i don’t keep a copy around as the wise people who are in charge of the specification think it should cost $$.
I should see if i can find a “public library” where i can take a look in such cases.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.