Flight Checker

This week I launched a "Flight Checker" feature on MyFlightbook.  The purpose of this functionality is to analyze your flights, looking specifically for data issues and failure to follow best practices

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 Issues

There 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 Issues

Here 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., 3-ILS-Y-RWY16R@KPAE 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 Issues

In 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) Issues

Uggh.  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 Issues

This 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 Issues

This 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 Issues

Here 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.

The second subcategory looks for time issues across multiple flights.  This is mostly important for Part 117 computations, which involve two more matching pairs of UTC times: duty start/end and flight duty start/end.  The difference here from the times in the first subcategory above is that these duty periods can start on one flight end end on another flight.  But I'm also looking for problems with the time boundaries described above.

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.

I'm also looking at this flight in relation to preceding flights and looking for inconsistencies between it and the previous flight.  For example, starting a new duty period that is prior to (i.e., overlapping with) the previous flight's duty end, or a block out time that is prior to (overlapping with) the previous flight's block time.

Miscellaneous Issues

This is the category for additional checks that don't fit neatly into any of the above. 

These include:

• 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

Early March Updates

I haven't posted updates here in a while, but I have been making updates to the site. Mostly small changes, but one big one that I'm releasing in "Beta" form, which means you'll need to type in a specific URL to get it.

The big one: today I've launched, in beta, a "flight checker." It's in beta, so you need to type in URL's directly to use this.

If you go to https://myflightbook.com/logbook/Member/CheckFlights.aspx, you can scan your logbook for common issues that are not errors per se, but are either minor consistency issues, failures to follow best practices, or other minor things. These are grouped into categories (simulator issues, IFR issues, time issues, airport/route issues, etc.) but can help with "debugging" your data and ensuring that i's are dotted and t's are crossed.

You can also use this to check a flight in real-time before entering it - add "lint=1" to the URL of the new flight page (either "?lint=1" if there isn't already a "?" in the URL, or "&lint=1" if there is) and you'll see a green checkmark in the lower right corner that you can click to see any potential issues in the flight before you submit it.  E.g., if you go to https://myflightbook.com/logbook/Member/LogbookNew.aspx?ft=Add&lint=1you'll see this:

 

If you click the checkmark, it will give you immediate feedback on the flight you're trying to enter.

Please give me feedback on this.  I'm particularly interested in the following:

• Are there bugs in my checks?
• Are there checks I should be doing but am not doing?
• Are there checks that I'm doing but which are actually valid and should have a way to turn off?

The small stuff:

• SFAR 73 now (should) properly use a 1- or 2-year flight review computation based on your flying experience.

• You can now add a flight directly to your pending flights (e.g., if you want to finish it later, or if it's a planned flight that you haven't yet flown). This is in the drop-menu next to the "Add Flight" button:

• If you have multiple criteria in a search, there's a "clear all" criteria to remove all of the criteria with a single click
  

• In the raw data report for flight analysis, I now strip out any column that has all zero values, reducing clutter for flying that you've never done.

• If you search for flights that contain a true/false property (e.g., "Charity Flight"), the resulting totals should now include an item telling you how many flights had the property. (This had previously been missing because you can't exactly sum up true/false properties).