By definition, these are not "errors", since the system won't let you save a flight that has errors in the first place. It turns out, though, that the set of issues that constitute an "error" are actually relatively small. I've found that over the years that I would add one validity check or another, only to have to pull the check because it turns out that there are valid scenarios for it.
So think of the Flight Checker as providing warnings, not errors. These are things that you can safely ignore, but that you just might want to address.
You can use the Flight Checker in one of two ways. There is a "batch mode" that examines the flights already in you logbook; you can get to this by going to Logbook->Check Flights on the website. There is also a "Check this" button that will check a flight that you are in the process of editing; click the icon in the lower-left of the flight editing screen and it will show any issues.
I am grouping these checks into distinct categories of checks. These are described below. In batch mode, you can select which checks you want to perform because some may not apply to you, or you may just wish to reduce the noise/clutter associated with too many checks. When performing a check on a flight that you are editing, all of the default groups are included.
Below lists the current categories of checks that I have, and a description of the checks within each category. I expect that over time I will be adding to this.
PLEASE LET ME KNOW if you have ideas for additional checks that I can do.
Simulator IssuesThere are some best practices associated with logging time in a simulator/training device. I discuss many of these issues here, here, and here. In that vein, here are the issues that I am looking for in this category:
- Logging Ground Simulator time in a real aircraft
- Logging PIC, SIC, or Total time in a sim
- Logging actual IMC time or cross-country time in a sim
- Failure to record the device identifier for the sim. You may have recorded it in the comments for the flight; I don't really have any way to reliably determine if this is the case, so I'm simply looking for the absence of a "Simulator/Training Device Identifier" property on the flight.
IFR IssuesHere I'm looking for some potential issues around instrument flight:
- Failure to describe the approaches that you logged. When you fly approaches, you're supposed to record the approach name and airport. I am looking for an "Approach Name(s)" property, or I look in the comments for something that looks like an approach description, following the format described here. E.g., means 3 ILS-Y approaches to Runway 16R at Paine Field (KPAE). (Note that MyFlightbook should already identify and highlight these on the website when found in comments)
- Logging simulated IFR in a real aircraft without either dual time also logged, a safety pilot named (using the "Safety Pilot Name" property), or an examiner ("Name of Examiner" property) named.
- Approaches or holding indicated with neither IMC nor Simulated Instrument time indicated. To count an approach, of course, it's supposed to be performed by reference to instruments.
Airport IssuesIn this category of issues, I'm looking at your route of flight and trying to determine if there's anything possibly amiss.
- Use of "LOCAL" or "LCL" for flights that don't leave an airport area. Both are unnecessary because you can simply say "ABC" for a flight around the airport ABC; it's obvious that it's local because it's just the one code. "LCL" is also problematic because it is the IATA code for La Coloma airport in Cuba.
- Use of an airport code that isn't in the database. Old codes are generally fine - MyFlightbook is a logbook, not a navigation tool, so I deliberately keep old codes around. So if your favorite airport ABC is now DEF, that's fine as long as ABC hasn't been re-assigned to another airport. If you have landed at airports that aren't in the system, I encourage you to add them (Airports->Add/Edit Airports on the website) - the crowd-sourcing helps create a very comprehensive dataset!
- If an airport code is explicitly a seaport and you're flying an MEL or SEL aircraft, I'll flag that.
- If an airport code is explicitly a heliport and you're flying an airplane, I'll flag that.
- I also look at the total distance for the route and the total time of the flight and compute an implied speed. If the speed is over 500kts for a piston aircraft or 1000kts for a turbine aircraft, I'll flag that. It could be that you didn't log enough time, but more likely you have a typo in one of your airport codes (or a code has been re-assigned) such that your flight from New York to Boston had a detour in New Delhi or something like that.
Cross-Country (XC) IssuesUggh. Cross-country time is a mess, as described here, so here are some things I look for:
- Logged XC time is less than the whole flight. There are legitimate scenarios for this (which is why it's neither an error nor a checkmark "this flight was XC" option), but most flights are all or nothing.
- If no XC time is logged but the route of flight is over 25nm for a helicopter or 50nm for an airplane, I'll let you know. Again, due to the crazy definitions of XC time described in the link above, this could be legitimate. I use 25 and 50 here because those thresholds apply to pretty much every definition of cross-country time as required for helicopter and airplane ratings, respectively.
- You can decorate a flight with properties that indicate a given flight was cross-country time less than 25nm, less than 50nm, more than 50nm, or more than 100nm. If you've used any of these properties, I check that the route of flight's distance is actually consistent with the property that you've used. I also check for inconsistent/incompatible issues, like recording a different amount of cross-country time from the time listed in the property, or recording time both more than or less than 50nm.
Time Accounting IssuesThis category is the simplest check of all: I'm looking to see if it violates this equation:
Total Time for a flight = PIC + SIC + Dual.
Note that this equation is not true in general in the US; the FAA allows you to log PIC time, for example, even while receiving training, if you are rated for the aircraft (so in that scenario, typically, PIC=Dual=Total); indeed, there are a variety of scenarios where multiple people can simultaneously log PIC time. But in other jurisdictions, if you are receiving training, then you cannot simultaneously log PIC time because in those jurisdictions only one pilot can ever be the PIC.
For this reason, if I detect that you're in the United States (based on your browser's locale), then I turn this check off by default (you can, of course, turn it on if you'd like).
Logged Time IssuesThis category is looking for any time field that is greater than the total time for the flight. E.g., if you log 1.2 hours of PIC time for a 1.0 hour flight. This applies to both the main flight fields (PIC, Dual, Night, etc.), but also to any time-based properties that you may have used, with the exception of Ground Instruction Given or Ground Instruction Received.
Also, since total time in a training device should almost always be zero, I don't apply this check to other than real aircraft.
UTC Time IssuesHere I'm looking for consistency in the use of timestamped UTC values, and it breaks down into two sub-categories of issues.
The first subcategories all deal with the time boundaries of a flight, specifically Engine Time, Flight Time, and Block time. These can have the following issues:
- Invalid ordering of matching time pairs (block in before block out, engine end before engine start, flight end before flight start)
- Invalid ordering of related items. Specifically, [Engine start or block out] must be prior to Flight start, and end of flight must be prior to block in which must be prior to engine end.
- All of these times must be within 48 hours of the date-of-flight. I choose 48 hours because the date-of-flight is local time every local date lasts somewhere on the planet for 48 hours.
So here I'm looking for:
- A flight start, engine start, or block-out time that is prior to the previous flight's flight end, engine end, or block-in time (respectively)
- A duty period that starts while another duty period is already open (i.e., I haven't encountered the end of the prior duty period).
- A duty period that starts prior to the end of the previous duty period.
Miscellaneous IssuesThis is the category for additional checks that don't fit neatly into any of the above.
- Redundant checkrides. For example, you only ever get your PPL rating once. If you get your PPL in a C-172, and later add multi-engine privileges in a Seneca, you're not getting a new PPL rating but rather are adding privileges to your existing one. So you should log this using the "Checkride - New Category/Class/Type" property.
- Adjacent flights that appear to be duplicates. "Adjacent" here means that they sort next to each other (see this post about sorting; it's possible that two otherwise identical flights would have an intermediate flight that would prevent detection.)
- Unsigned flights that indicate instruction with no Instructor Name
- Flights that appear to have no data