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

Auto-fill functionality

I updated the mobile apps today to add support for autofill.

The website has had autofill functionality for a long time, but the mobile apps haven't.  The main reason for this is that the mobile apps can function while offline and actually measure a flight using the GPS, so they've historically been more optimized around detecting flight events in real-time.  The website, on the other hand, requires that you be online. 

So I thought it might be useful to review some of what the apps and the website can do for you automatically here.

Auto-fill Total Time, Hobbs

The mobile apps allow you to tie the total time field to block, hobbs, engine, or flight times.  This is a tight coupling: if you have both start/stop of the source defined, then any change in the value of a start or stop changes the total time field in real time.

Hobbs time similarly can be sourced from flight or engine time, and is also tightly coupled.

Cross-fill

You can quickly cross-fill the "Total Time" field to any time-based field by clicking the gray arrow next to that field (website) or by pressing-and-holding on the target field (iOS or Android app).  E.g., you can fill in the time of the flight in the Total Time field and then cross-fill that to the "Dual Received" field, or the "Solo Time" field or whatever other field is appropriate.

Automatic Cross-fill

On an aircraft-by-aircraft basis, you can specify automatic cross-fill (copying of a value from one field to another) from the Total Time field to your choice of PIC, SIC, or Instructor time.  (And if PIC, you can have it fill in your name as the PIC for that flight as well).  

The rationale for doing this on an aircraft-by-aircraft basis is that you might fly professionally in a jet during the week as a second-in-command, and fly your personal 172 on the weekends.  You'd automatically log PIC time in the 172, SIC time in the jet, and not do any cross-fill when you fly with a friend in their plane.

Automatic cross-fill operates under a few rules that are important to note:

• It will never overwrite a non-zero value.  So if you have PIC cross-fill on and fly for an hour where you and a friend each are PIC for half of the flight and you log 30 minutes as PIC, then it will NOT overwrite that 30 minutes
• It happens on the server at the point that you save the flight.  In other words, you won't see it applied while you're entering the flight itself, but after you add the flight to your logbook, you'll see that the cross-fill has occurred.
• It is only applied to new flights.  So if you edit an existing flight, the cross-fill will not happen.  This is important to allow you to override the cross-fill on a flight-by-flight basis (otherwise, you'd set the PIC field to 0 because someone else was flying, and the PIC time would come right back).

Auto-Detect

The mobile apps can run while offline, usually have GPS access, and can thus detect takeoffs and landings (using speed), nearest airports, and whether it is currently "night".  You can configure a variety of settings such as threshold speeds for takeoff/landing and what criteria to use for night flight or night landings (FAA and EASA rules can vary on that).  The system then updates the flight data in real time to reflect the flight in progress.

To do this, the system must use the GPS even in the background, and because that can consume battery, it only does this when a flight might be "in progress".  "in progress" is defined in this context as having (a) either a defined engine start or a defined flight start time, and (b) NOT having a defined engine end time.

What I typically do is tap "Tap for Now" on Engine Start as part of my engine start procedure, then tap "Tap for Now" on Engine End as part of my shutdown procedure.  The app will listen to the GPS between these two events.

You can also send a GPX or KML file to the MyFlightbook app on Android or iOS.  When you do this, it sets and engine start time to the timestamp of the first sample in the file, and then plays the file as if it were real-time GPS samples, and then sets the engine end time to the timestamp of the last sample.  It uses your autodetection settings for all of the intermediate GPS samples.  (This functionality has also existed on the website for many years).

Some of the things that auto-detection will fill in include:

• Departure, arrival, and any intermediate airports
• Total landing counts, including the subsets that are full-stop day and full-stop night
• Night takeoffs
• Night flight
• Cross-country time (using a 50nm threshold; see here for why I don't do it for all cross-country flight)

It's useful to note that you can pause/play autodetection by tapping the green pause/play button on the "In the cockpit" section of the iOS or Android app.  (This button only shows when a flight is in progress).  This is useful if you, for example, fly from A to B for lunch or gas, then fly back to A and want to record it as a single flight but still get the times correct.

Autofill

Because the apps have supported auto detection for years, there generally hasn't been a real need for autofill.  But there are still a few scenarios where it makes sense, which is why I've added it.

Autofill overlaps with autodetection when there is telemetry (GPS) data present.  If so, it has all of the functionality of Auto-Detect.  But it can also work without telemetry, and it fills in a few things that Auto-Detect doesn't.

Where Auto-detection tries to fill in a flight based on GPS data (or a GPS file), the philosophy behind Autofill is to try to look at the flight and see if there are missing things that can be inferred or calculated.  Naturally, the first thing Autofill tries to do is to autodetect, if appropriate GPS data is available. 

One of the things Autofill can do is to estimate night flight.  I say "estimate" because that's the best I can do without actual GPS samples.  But if you have exactly two airports in your route of flight and start/end pairs defined for any of block, engine, or flight time - and these are in a defined timezone (i.e., UTC) - Autofill will construct a synthetic GPS path that is constant speed and great circle path from the first airport to the second.  It will then perform autodetection on that synthetic path.  

This is only an approximation, of course.  Imagine you flew from San Francisco to London - a perfect great-circle route at a constant speed will imply a certain amount of night flight.  But if you actually flew further north or south (perhaps for better winds), or if you had strong headwinds during one part of the flight and strong tailwinds during another, you would obviously have experienced a different amount of actual night flight than the constant-speed great-circle estimate.

In addition to whatever autodetection can be performed (whether with actual or synthetic GPS pdata), Autofill can also fill in:

• Total Time, if it is empty (zero) and if it can be determined from (in priority order): Hobbs time, block time, engine time, or flight time.  Note that the new Autofill functionality in the mobile apps will do this as well, even if you have an AutoTotal setting.  Imagine again that you fly a jet during the week (no Hobbs meter) and a club plane on the weekend (with a Hobbs meter), and you have AutoTotal set to use Block Time.  For your weekend flight, if you don't enter a block time but do enter a hobbs time, it will still fill in a total value for you based on that. 
• Ending Hobbs Time, if there's a non-zero starting Hobbs and the total time is known
• Ground Instruction given or received.  If you have both a defined Lesson Start and Lesson End time, then your flight time (hobbs, block, engine, or flight, in priority order) is subtracted from that, and the remainder is assigned to Ground Instruction Given (if you have Instructor time logged) or Ground Instruction Received (if you have Dual Received logged)
• Cost of Flight.  If you have a private note on the aircraft that includes something in the form "#PPH:75.00#" (where the "75.00" can be any decimal number), then that is treated that as the cost per hour for that aircraft.  So in this example, if you logged a 2 hour flight in an aircraft with "#PPH:75.00#", it would record 150.00 as the cost of the flight.  (And if you are using US conventions, that would display as $150.00).

If you have other suggestions for autofill, please send them my way!

What constitutes a "valid" flight entry?

With any data system, one must be prepared to do validation on the data that goes in.  A logbook is no exception to that rule.

It turns out, though, that there are surprisingly few validation checks that can be universally applied to a flight - there are a lot of things that look like an error in some scenarios, but which are perfectly valid in others.

An example that I am asked about frequently is that the system does not flag flights where Dual plus PIC plus SIC does not equal Total time.  For much of flying in much of the world, that equation is satisfied, but (in particular) it is not here in the US, where you can simultaneously log Dual and PIC if you're appropriately rated for the aircraft yet receiving instruction.

Probably the most common scenario where a flight frustrates data validation is "catch-up" flights, where you make one or more entries in your logbook to represent totals from prior (typically paper) logbooks.  Such flights typically include large numbers (larger than any single flight could actually have), and a mix of things that might be difficult or impossible to do in a typical actual wheels-up-to-wheels-down scenario.

Over the years, it seems that whenever I put in a validation check, I soon find counter examples of perfectly acceptable flight entries that violate my rule.

So in an evolutionary process of "survival of the fittest", here are the checks that have withstood the test of time:

• Valid aircraft - every flight must be associated with an aircraft (even if no actual flying was done; you can generally use any aircraft you like for ground sessions - since the times are zero, any aircraft will work).  This is because the aircraft's model determines all sorts of attributes about the flight, such as the category/class, whether it was complex or high performance or turbine, etc.
• No negative numbers.  I've yet to find a scenario where negative numbers are allowed.
• Hobbs start after hobbs end.  (I don't currently validate tach time because I don't currently perform any computations on tach time).
• Flight start after flight end or engine start after engine end (I don’t currently validate block time) 
• Full-stop night landings + full stop day landings greater than the total landings (unless total landings is 0, in which case I auto-fill it)
• Full-stop Night landings indicated without any night flight.
• Night takeoffs at towered airports + night takeoffs at non-towered airport (which, kinda by definition, is all of the possible night takeoffs) is greater than total night takeoffs
• More described approaches (e.g., a property indicating two ILS approaches) than logged approaches
• Comments or Route field too long (13K and 128 characters, respectively)
• Date before 1900 or more than 2 days from "right now" in Pacific time