I recently came across FlightAware and love the service. I have noticed that you list estimated arrival times that are 15-30 minutes later than FBOWEB’s flight tracking. For example tonight you listed USC394 estimated arrival time as 23:56. It never changed thoughout the flight. FBOWEB showed its estimated arrival at 23:16 and it fluctuated a couple minutes +/- during the flight. The actual arrival time was 23:20. This is just one example, but your estimated times are regularly off by 15-30 minutes. Any ideas why?
We add the duration that the pilot listed in their flight plan to the departure time to estimate the arrival time. If the flight encouters unpredicted winds, or ATC delays, the ETA will be off.
I’m not sure how FBOweb estimates arrival times. Since their estimation was early I’d guess they use the distance remaining divided by the current speed, but in general that will mispredict on the side of being early.
FBOweb was early by less than 5 minutes and you were late by more than 35 and this is fairly common. I think what is causing the problem is most of the flights that I watch are 135 freight haulers flying regular runs. Their flight plans are “canned” and prefiled. I bet their time enroute is calulated on a no wind senario since they cannot guess the winds ahead of time. Then you go by their generic no wind estimates.
The quality of the filed ETA or ETE can certainly vary and your theory sounds very plausible – that the overall reliability and accuracy of the filed times is poor for cargo flights where scheduling is less important than passenger traffic.
It’s difficult to say if we would provide better ETAs overall by disregarding the filed ETA or ETE in a flight plan and calculating it ourselves, though. I really don’t know for sure. The problem is that I don’t think we’ve got a way to know which flights are inaccurate and which are accurate. An ETA which seems too long based purely on distance and flight speed might just be the result of the pilot’s familiarity with the approach delays at the destination airport.
Certainly in some cases we’d do more harm than good by ignoring the filed ETE and overriding it with a synthetic calculation. Perhaps there’s a solution which could incorporate both values, but I’m not sure.
I am bringing this back up. Tonight flight USC601 showed an arrival time on your tracker of 22:23. It landed at 22:00 yet showed as in flight for the next 20 minutes.
At work I have to use FBOweb’s tracking becuase they are more accurate. I think it is more than the way they calculate arrival time vs the way you do. Their tracking seems to be more live. It is adjusted in flight. When they first take off their estimates are WAY off, but it is because they are making less progress during climbout. We are used to that and know not to rely on arrival times during the first 1/4 of the flight. After that they are very accurate. When they land that is reflected within a couple minutes. Doesn’t the FAA publish the A/C location periodically while in flight? Wouldn’t updating from that more often make your times more accurate?
Paul
PS: I just noticed that when you did move the flight from the Enroute to the Arrivals list the time of arrival was updated from 22:23 to 22:06.
This subject has come up many, many times, as you know. I don’t think that FA is calculating “wrong”, but it does seem to confuse the heck out of folks when they compare times with another system.
How about considering adding a way to list BOTH ETAs: “Planned Arrival” time based on the pilot’s flight plan, and “Estimated Arrival” based on the current speed/distance calculation.
Incidentally, I think you are actually doing it the “right” way now if you are only going to list one ETA. If the pilot says he will get there at a certain time, that is probably the time you should post. You don’t know whether he’s going directly to the airport at the current speed or or has some other agenda in mind, so should “trust” his estimate. However, we have seen that many of the estimates are pretty far off, either from sloppy planning or unexpected conditions. An FBO using FA to plan for an inbound will likely want to know the earliest time he might show up, considering current conditions, so they can be ready to provide excellent service. Give them both ETAs and then who can complain? Somebody will, of course, but that’s another issue!
USC601 should have been listed as arrived at 22:06 within 6 minutes of landing.
As BTaylor mentions, we never know what the pilot plans on doing, so we use the ETA they provide us. We may add predictions in the future, and clearly mark them as such.
The data is all there to provide a real time estimate. I was watching USC242 go from MKC to CPS in a dedicated window. The canned data had “Proposed/Assigned” of 00:00 departure and 01:30 arrival at 7000 at 180 kts… The “Actual/Estimated” showed 23:48 and 01:24.
The “Actual/Estimated” times stayed the same for the entire flight yet the groundspeed and altitude fluctuated throughout. This does not seem like much of an estimate if all you do is adjust for takeoff time. The A/C actually arrived at 00:56.
It also seems that you are actually updating the distances live while enroute because the distances looked about right at 00:50 but you were still saying the flight was more than 30 minutes away despite it being almost over the airport
It would be GREAT if you could provide an estimated time that actually is estimated based on inflight conditions. You are already tracking the groundspeed and real position for the flight so you have inflight data to do so.
We have some technology to calculate estimated arrival times although you cannot estimate an arrival time on the basis of current position and airspeed. Like most things, it’s not that simple. You have to take in a huge number of factors into consideration such as previous aircraft making that journey and traffic at an airport.
If an aircraft is 120nm away and doing 240kts, what would that mean? It certainly doesn’t mean that the aircraft is 30min from arriving because what if the aircraft is asked to reduce speed? And then is vectored for sequence? Or initially vectored for a visual approach but due to traffic, asked to fly to a final approach fix on the approach?
If you want a program that will estimate 30 minutes and then revise it to 35 minutes when it slows down and then 5 minutes when it’s nearby the airport and then 10 minutes when it’s at the FAF and just jump around aimlessly, that’s pretty easy to do.
However, something that makes a valid prediction needs to not change significantly if it’s going to be relied upon. In most cases, the filed time ETE is the most accurate.
Personally I am thrilled with the service flightaware provides…and for FREE. Clearly the flightaware staff have chosen what they feel is the best way to display the data available. As in any decision, it won’t please everyone, but I think they’ve not only done a great job but also been responsive to comments/suggestions provided over the last six months.
To the flightaware staff – keep up the great work and thank you for the commitment to keep this data available to all for free.
To those who are unhappy with flightaware – you are most certainly welcome to go to another site (including some of the expensive pay sites) or create your own site/service if you think you can do it better. If you’re going to stay here, please at least keep your comments/suggestions constructive so we don’t frustrate the flightaware people to the point they stop doign this for us.
just my opinion and you all know what opionions are like
