Please help me understand what I’m seeing here. In the attached picture you’ll see a lot more ICAO codes than identified aircraft with positions. Is that because the quality of my reception is poor, or some other reason? Are they too far away to get full data? What does squawk mean? Why do some flights list only 3-4 digit numbers instead of call sign or registration? Explanations of all the column labels would be most appreciated. Thanks!
PS. Why can’t we upload pictures to FA, or am I missing something?
Not all aircraft are ADS-B equipped. You can pick up the altitude and Mode S hex identifier of non-ADS-B equipped aircraft though.
What does squawk mean?
That is the transponder code assigned by air traffic control.
Why do some flights list only 3-4 digit numbers instead of call sign or registration?
Some airlines only program in their flight number to the transponder rather than the full ICAO identifier. FlightAware corrects this on our side, but not on the receiver (yet).
The green highlighted rows are ADS-B aircaft, which have provided ocation information and are plotted on the map. Other rows are Mode S aircraft, which do not have location information.
Maybe it us already out there and I have just missed it, but the original poster’s question is kinda on point. A “legend” page is needed, that concisely defines what everything means and the basis for the stats. Is it a mean, median, or an average? The sample period is daily? Weekly, including weekends? Rolling 7 day average? Is aircraft seen ADSB birds, ADSN plus Mode S, or everybody including Mode A/C? “Live” really means…
This has the potential to serve multiple purposes. A concise definition or specification of numbers, data fields, grid depictions, etc. documents exactly what FA’s developers are supposed to be producing code to display.
An example is the nifty graphic plot of daily positions reported and aircraft seen. Until yesterday there was a inset legend --that always read zero. Now it is starting to show a number, whose value is actually a mystery since it isn’t today’s count, it might be an average but over what period? Hard to guess.
The OP and you are referring to two different things. The OP is talking about the web interface of dump1090 while you are talking about the user stats page here in FA. The OP question can be answered by joelwiley’s response, your question can be answered by digging a little the forums. The mods have answered some of those questions in other threads.
I do agree fully that a legend or FAQ should be included to help users discern the differences between the stats, maybe it is in the works with all the updates that are planned. Let’s hope it is the case.
With the proliferation of ADS-B receivers transmitting to flightaware, perhaps FA could do some extrapolation/triangulation using data on when which receivers reported data for these non ADS-B transmissions. That would be cool.
Maybe some one can clarify this. From my understanding, for Multilateration(MLAT) to work the receivers should be equipped with GPS receivers in order to have the exact position of the receiver and possibly obtain the time from a NTP server that uses the PPS in the GPS. It will also need at least three receivers for MLAT to work.
We’re not getting any ranging between the sender and the receiver. The accuracy of what I’m hinting at would be on the scale of the spacing of the receivers (not great). Having GPS data at the receivers is not relevant. Further, timing data is irrelevant, since the various receivers would all be picking up the same transmissions. I’m thinking of something along the lines of this:
To make things simple, suppose 4 receivers A, B, C, and D all receive transmissions from a plane thusly:
First station to pick up is A.
After some time A and B pick up.
After more time A, B, and C pick up.
After more time, A, B, C, and D pick up.
Then A drops the signal.
Then B drops the signal.
Then C drops the signal.
Finally D drops the signal.
Clearly, the plane sort of flew over the receivers from point A to B to C to D and beyond.
Real life is not this simple, but it’s not that much more complex. Each receiver has a cone of reception. They pick up things that are within the cones. All you have to do is find locations that are within the cones of the receivers that are receiving data and outside the cones of everyone else.
There’s a bit of math, but it’s the type of math computers are really good at.
MLAT would require much more precise equipment than I think probably all of us are using.
Even with an accurate time source it’s still tricky to line that up with your received data unless you have e.g. a unified receiver that’s timestamping samples vs. GPS time internally. Not something that the rtlsdr dongles will do - with the dongles you have no real idea what the true receive time of a particular sample is, other than “some time before the USB subsystem handed you that block of samples”. Delays due to USB itself or waiting for the data to get through the USB subsystem are mostly unknown.
I believe you can derive a synchronized clock without needing a GPS PPS signal or similar if you use the reception time of a message that was transmitted at a known location and received by multiple receivers as a baseline. In the ADS-B case that’s relatively easy - use a position report message that was seen by a few receivers, you know the transmit location of that! You can compute a clock offset for each receiver (from the point of view of its sampling clock) based on its local reception time vs. the expected travel time for the signal from the known transmitter position to that receiver. You can manually provide each receiver location rather than getting it from GPS, assuming the receiver doesn’t move around.
The receiver sample clock should stay stable enough in the short term that you can then use that known offset to do MLAT for subsequent positionless reports (for a while, anyway - the dongles do drift considerably with temperature). You don’t care about the absolute time for MLAT, you only care about the difference in arrival times at different receivers.
dump1090 half-supports this in that it can generate a 12MHz (really 2MHz, scaled) clock timestamp on each packet based on the sample position at which it saw the message. That should be good enough for accuracy to within a few hundred metres at least. So then you just need to work out how to aggregate that data and turn it into positions! I have a few ideas but the challenge is really in collecting a useful set of data to test against - you’d need a bunch of raw message dumps from a group of receivers that can see the same patch of sky, but are somewhat spread out.
)