Signatures and Endorsements

In addition to being a recording of personal experience, a logbook is also a record of training received.  As such, it must enable instructors to sign entries in student logbooks and issue endorsements.
MyFlightbook supports both of these scenarios, using two different paradigms.

• In the first paradigm, the student and the instructor create a relationship between their accounts, so one appears as the instructor for the other.  Because each account is authenticated to MyFlightbook, and MyFlightbook validates the relationship, I refer to this as an "Authenticated" scenario.  This provides a very secure framework for signed flights and endorsements, but it requires that both parties use MyFlightbook.
• In the second paradigm, the relationship is a one-off; there is no presumption of any ongoing relationship between the instructor and the student (a common example might be a check-out at an FBO).  This provides more limited functionality, but is very quick to set up.  I refer to this as the "Ad-hoc" scenario.  Because there is no authentication of the instructor in an ad-hoc relationship, this must be done face-to-face.

Endorsements

An endorsement is a sign-off from an instructor that determines the student hes met some criteria.  The key thing about an endorsement is that it is not tied to a specific flight.  Examples of endorsements include solo sign off, high-altitude training, tailwheel sign-off, readiness for a practical test, etc.

A wide variety of templates for common endorsements are in the system, as well as a template for a fully-customized endorsement.

Endorsements require an authenticated relationship between the student and the instructor.  The endorsement can be issued by the instructor by going to the list of their students; they can also view any previously-issued endorsements.

An endorsement, once issued, cannot be edited or deleted.  (After all, neither scenario is generally supported in the physical paper world), although as site admin I can, if needed, wade in and perform endorsement surgery as needed.  Endorsements also cannot be dated too far in the past or in the future, as a security measure.

Signatures

Most training flights result in the instructor signing the student's logbook entry for the flight.  Often, they even fill out the entry.  But one difference between MyFlightbook and a paper logbook is that saving the entry and signing it are separate sequential steps.  The reason for this is so that the signature can sign the flight as it exists in the database, without the possibility of modifying it between signing and saving.

If the instructor wishes to fill in the entry, they can do so.  But just as they can't fill in a student's logbook without the student being there to give it to them, the student must be present with their phone/tablet (or sign in on a website) and hand control over to the instructor.  For security, MyFlightbook does not allow instructors to create arbitrary new entries into a student's logbook.

There are two basic scenarios for how a flight can be signed once it has been saved:

• In-person.  This requires a phone/tablet running the MyFlightbook app.  The student goes to the Recent Flights list, finds the flight to be signed (typically at the top of the list, if you're signing the flight you just took), and chooses the "Sign" option.  At this point, choose from a list of authenticated instructors or select a new instructor for ad-hoc signing, and then hand their phone/tablet to the instructor.  If it's an authenticated relationship, the instructor provides their password to prove it's them and thus digitally sign the flight; if it's ad-hoc, they can scribble a signature with their finger (which is why it requires a phone/tablet), which serves as the signature.  In either case, the instructors can add comments and, if authenticated, the instructor can cause the signed flight to be copied to their account (minus the signature and with Dual/CFI roles reversed).
• Remotely.  This requires use of the website, and requires an authenticated relationship.  The student can request that the instructor sign specific flights.  The instructor will receive an email notifying them of the flights to sign, and can use the website to review and sign them.  Or, the student can optionally grant the instructor permission to view their logbook and sign any flights that don't already have a valid signature, as they see fit.

When a flight is signed, MyFlightbook stores a fingerprint of the key fields for the flight so that subsequent edits will invalidate the flight.  Some fields are excluded from this - e.g., it's OK if you change whether the flight is public or private, or to add/remove images.  But changing the comments, number of landings, or times (among other "core" data) will invalidate the signature.  An invalid signature can only be "revalidated" by either requesting that the instructor re-sign it, or by reverting the edit so that the flight's fingerprint matches that of the signature again.

Does the FAA recognize such digital signatures?  They claim to, and they outline the criteria for doing so in FAA circular AC No: 120-78A. I believe MyFlightbook is compliant with this AC, the FAA has thus far not indicated willingness to even evaluate, much less certify, online logbook systems for compliance.

A more in depth explanation of how signatures and endorsements work, along with why I believe MyFlightbook is compliant with AC 120-78A can be found here.

Airports

MyFlightbook's airport data comes from a variety of sources (i.e., "free"), and include codes that can be FAA (3-letter, doesn't generally use the leading "K"), IATA (3-letter, used for airline travel), and ICAO (4-letter).  I don't actually bother storing which kind of code it is, since it's generally obvious from context.

So a given airport can actually be in the database up to 3 times (though it’s pretty rare for that to actually be the case.  Some examples:

• Kahului, Maui is "OGG" (FAA/IATA) or "PHOG" (ICAO)
• Frankfurt, Germany, is "FRA" (IATA) or "EDDF" (ICAO)
• Owyhee Airport (in Oregon) is "10U" (FAA), but (to my knowledge) has no official IATA or ICAO code.

In the US, most airports in the continental US have both ICAO and FAA identifiers, and most of the time, the ICAO is the FAA with a "K" prefix.  E.g., San Francisco International is "SFO" (IATA) and "KSFO" (ICAO).  But it's very often unclear whether a given airport follows this convention.*

For this reason, I treat the leading "K" as optional on any 3-character code. So, if you type “Kxxx” and I don’t have Kxxx but I do have xxx, I’ll match to that (so that “K10U” for the Owyhee example above, or KOGG for Maui, neither of which technically exist, will still work).  Or, conversely, if you type “yyy” and I don’t have yyy but do have kyyy, then I’ll match to that.  Note that this allows ICAO and FAA/IATA codes to co-exist pretty well, which is especially nice since there are some international airports that, but for the initial ICAO character, would match some small airport in Alabama. Indeed, one such example (of many) is Newtonards airport (EGAD, just outside of Belfast) and Northeast Alabama Regional (GAD).

When I autodetect to find the nearest location, I do the following:

• Look up the closest airports to your position, sorted by that position rounded (slightly – two decimal places of nm) to try to coalesce small differences in distance.  For example, the closest airport may in the database twice with two slightly different coordinates (usually due to coming from two sources that use differing numbers of significant digits).  Note, though, that if the two sets of coordinates for the airport are further apart than the rounding will catch, then "nearest" may differ depending on whether you are on one side of the airport or the other.
• If multiple airports tie for “closest”, airports can be further disambiguated by a “preferred” flag.  So, for example, Dallas/Ft. Worth is DFW/KDFW, and the “K” version is marked as preferred, so it should be picking that up.
• Absent a “preferred” flag, I should bias towards the longer identifier (i.e., choose ICAO over FAA or IATA), but this is not implemented today.

A few other useful tidbits that you might want to know about airports:

• As a logbook (rather than a flight planner), I try to keep old airports around as long as possible, often long after they have either closed or been assigned a new identifier.  
• For the same reason, there is a strong bias towards airports over navaids, even though navaids are in the database.  But you can reverse the bias with a "@" prefix.  E.g., "BOS" is Boston Logan Airport, but "@BOS" is the Boston VOR.
• You can add your own airports or navaids to the database.
• You can also make up ad-hoc latitude/longitude waypoints. Use the form @xxxxxNyyyyyW to specify a latitude/longitude.  E.g., @38.8894N77.0353W is the Washington Monument.  (Obviously, change "N" to "S" or "W" to "E" as needed).  If you use one of the mobile apps, you can press-and-hold the Append-Nearest button (next to the Route field) to append your current location as such a waypoint.

*The latest download of FAA data has nearly 20,000 airports, but only a little more than 2,500 of them appear to have ICAO codes.  So that means more than 85% of US airports do NOT actually follow the Kxxx convention.

Models and Types on MyFlightbook

Models on MyFlightbook capture a lot of information about an aircraft so that you don't have to log it explicitly.  Capturing this information in the model means that the system can draw a straight line from the tailnumber (registration) of the aircraft you fly to the model of that aircraft has two distinct advantages: (a) you don't have to pointlessly go to the effort of logging information that the system can easily derive, and (b) it avoids errors if you log impossible things, such as multi-engine turbine time in a Piper cub.  After all, for example, A Boeing 737 is inherently multi-engine/turbine (jet)/high-performance, so time in it absolutely should (and does) accrue to your totals in each of those categories.

Models capture several details for an aircraft, including:

• The name of the model ("C-172 N", for example)
• The "marketing" name ("Skyhawk" for a C-172, "Dreamliner" for a Boeing 787).  Many (most?) aircraft don't have a separate marketing name, so it's fine to leave this blank.  Good rule of thumb: if it repeats the manufacturer or model name, just leave it blank.
• An ICAO identifier.  Confusingly (as discussed below), this is sometimes called a "type", but on MyFlightbook it is always referred to as "ICAO".  This is what you'd file on a flight plan, and is never more than four letters/numbers.  E.g., a C-172 S and a C-172 P both have an ICAO code of  "C172".
• The category/class for the model (Airplane Single Engine Land, for a C-172)
• If you fly in the military, you can also see and edit a "Mission/Design/Series" (MDS) designation.
  
• "Interesting" characteristics, such as whether it is high performance, tailwheel, complex, all-glass (no steam-gauge versions were ever produced), turbine, etc.

All of the  above is used for computing totals and currency, but there's one additional attribute of a model that probably causes more confusion than any other: the "Type" field.

Many pilots, when creating/editing a model repeat the model name here.  Some even put the specific registration/tailnumber of the aircraf they want.  But the "Type" field has a very specific purpose on MyFlightbook: it provides a grouping mechanism for aircraft that require a type rating to fly.

A license generally provides privileges to fly a specific category and class of aircraft*, such as "Airplane, Single Engine Land (ASEL)".  More sophisticated aircraft - typically jets or anything over 12,500lbs - require a type rating to fly.  That is, a specific license to fly that particular model of aircraft.  Furthermore, to be legal to fly it, you have to have recent flight experience in that particular model of aircraft as well.

For example, in the US, 61.57(a) says:

(a)General experience.

(1) Except as provided in paragraph (e) of this section, no person may act as a pilot in command of an aircraft carrying passengers or of an aircraft certificated for more than one pilot flight crewmember unless that person has made at least three takeoffs and three landings within the preceding 90 days, and -

(i) The person acted as the sole manipulator of the flight controls; and

(ii) The required takeoffs and landings were performed in an aircraft of the same category, class, and type (if a type rating is required), and, if the aircraft to be flown is an airplane with a tailwheel, the takeoffs and landings must have been made to a full stop in an airplane with a tailwheel.

So, for example, if you want to fly passengers in a Piper Seneca (a small twin-engine airplane), you merely have to have done three takeoffs + landings in a multi-engine aircraft within the 90 days preceding the flight.  Any multi-engine aircraft will do.

But note the bold-faced wording above.  A 737 requires a type rating, a Piper Seneca does not.  So if you do 3 takeoffs/landings in a 737, you are fine for carrying passengers in a Seneca.  But the reverse is not true: if you do your three takeoffs/landings in a Seneca, you are not OK to carry passengers in the 737.

Enter the "Type" field.  Boeing 737's share a common type rating.  That is, the B737-300 and the B737-900 are interchangeable from a type perspective.  For this reason, all of these models have "B737" in the "Type" field.  Thus, if you do 2 takeoffs/landings in a B737-300 and one in a B737-900, all three takeoffs/landings count towards your 61.57(a) currency and you are current to carry passengers in a B737.

So it's safe to view the "type" field as satisfying the following rules:

• If a model of aircraft does NOT require a type rating, it should be blank.  Think C-172, Piper Seneca, pretty much any glider, etc.
• If a model of aircraft requires a type rating, it should have a non-blank value for the "type" field that is shared with other aircraft that share a common type rating.  The Boeing 757 and 767, for example, have a common type rating, so the "type" field for all of the variants of these two aircraft is "B757, B767".
• If a model of aircraft requires a type rating, the "type" field must be distinct from other aircraft that require a different type rating.  So, for example, the Boeing 737 and the Boeing 747 MUST have different "type" fields, since they require different type ratings.

Beyond that, there's no real requirement.  There's no inherent reason, for example, that Boeing 737's in the system couldn't have a "type" field of "Fred Flintstone" and Boeing 757's have "Wilma Flinstone", but for the sake of making things consistent and a bit more self explanatory, we generally follow FAA guidelines for "type" designations.  Hence the Boeing 737 has a type designation of "B737", and the Airbus A380 has "A380".

Interestingly (in the US at least), the Robinson R22 and R44 do not technically require a type rating, but the currency requirements effectively mimic a type rating.  For this reason, these two helicopter models have a "type" field of R22 and R44 (respectively).

In any case, when in doubt, just leave this field empty.  I review EVERY new model (or model modification), so I will generally catch issues here.

*In some parts of the world, you effectively need a separate license - or at least sign-off - for each model of aircraft you wish to fly, and currency must be maintained in each such model.  MyFlightbook has an option to support this.

Logging landings/takeoffs and approaches

A given landing or takeoff can have many different attributes.  It can be day or night, short-field, soft-field, at a towered airport, on an aircraft carrier.  A landing can be touch-and-go, full-stop, or stop-and-go.  And of course, these attributes are not mutually exclusive: it's certainly possible to do a night short-field full-stop landing on an aircraft carrier with an operating control tower.

In fact, in MyFlightbook, there are over 60 different kinds of landings and over 30 different kinds of takeoffs (and I am periodically adding more).

And we generally want to know how many of each of these we did.

Broadly speaking, there are two approaches one could take to logging landings.  (Everything I discuss below also applies to takeoffs, but for brevity/clarity, I'll just refer to landings from here on.)

The most specific and unambiguous way would be to create an entry for each landing, and in each entry identify all of the relevant attributes.

E.g.:

Landing 1: full-stop, soft-field
Landing 2: stop-and-go, night, short-field, towered airport
...

This has a clear advantage: everything is crystal clear.  But it has two disadvantages: (a) it is harder to answer simple questions like "how many full-stop landings did I do?", since you have to look at each entry and add them up, and (b) the data entry is cumbersome and if you do a flight with multiple landings, you have to remember the details of which ones were which.

Of course, (a) above is easy for a computer, which can just sum up the subtotals and display those to you, but making (b) easy is...hard, since much of it is not something that can be reliably determined automatically.  (Touch-and-go vs. full-stop and day/night are the main things that can be auto-detected).

The simpler way is to accept some ambiguity about which attributes applied to which landings and instead just enter the totals.

E.g.:

4 total landings
1 was a daytime stop-and-go
2 were full-stop night landings
3 were on short fields
2 were at fields with a control tower
...

This is the approach that MyFlightbook takes.  There are a few key things to note above, though:

• Figuring out things like 61.57(a)/(b) currency becomes a lot easier.  Indeed, in the example above, I can see from above that the 4 total landings reset my general passenger-carrying currency for 61.57(a) in the category/class of the plane, that my (combined) 3 full-stop landings reset my tailwheel currency, and that I need one more night-landing to reset my nighttime currency.  (Assuming, of course, that I've done the requisite takeoffs too...)
• Note that they don't add up!  The total landing count is just that: the number of times that the wheels(/skis/floats) touched ground; everything else is a subset of that count, and the subsets can overlap.  The important thing is that each total stands on its own.  The only real requirement from a data consistency point of view is that none of the subsets can be greater than the total number of landings for the flight.

The advantage of this, of course, is that the data entry is much cleaner: if you have 5 identical landings, you don't have to create 5 individual landings, you just put in the totals.  After all, it's generally the # of each kind of landing that matters, not which one was which.  And besides, the latter can often be determined from context: if your flight went from ABC to DEF to GHI, you know what kind of runway ABC had, whether DEF had a control tower, and that you ended the flight with a full-stop, not a touch-and-go.

The disadvantage is that there is some inherent ambiguity, and the system can't add things up to determine things like the total number of landings - you have to tell it.

I take a similar approach (pun not intended) for instrument approaches as well.  There are over 40 different kinds of instrument approaches in the system, so if you want to know how many ILS approaches you did vs. RNAV approaches, you can track that.  As with landings, these can also overlap: an approach can be both an ILS approach and hand-flown, for example.  But what matters about approaches from an instrument currency point of view is simply the number of approaches you did on a given flight; if you want to simply describe them in your comments or in the "Approach Description"  property, that's great; you are, after all, supposed to record details about the approach somewhere, but there's no requirement that it be in any "structured" format - free-form text is fine

So it's fine to simply record "3" in the "Approaches" field on a flight where you did 3 approaches, and say "3 ILS 16R at Paine Field" in the comments; whether to explicitly record a property that lets you count how many ILS approaches you did is up to you.

Note that 61.51(g)(3)(i) also requires that you record "the location and type of each instrument approach".  You can, of course, do this however you like, e.g., writing in the comments "2 ILS-yankee approaches to runway 16R at Paine Field" and you'd meet this requirement.  MyFlightbook provides an "Approach Name(s)" property, though, for this express purpose.  

There are a few reasons for offering a separate field.  The first is that it declutters your comments.  The second is that the "Check Flights" feature (on the Logbook menu of the website) looks for this field to see if you've described your approaches, since teasing that out of comments can be...challenging.  And the third reason is that the iOS and Android apps have an "approach helper" feature: if you press the "+" button next to the approach count field, it offers a UI to make it easy to describe your approaches, and when you go back, it will append that description to the Approach Name(s) property and (optionally) increment the overall approach count.

And here I'll let you in on a little tip: you can use an abbreviated notation in either the Comments field or the Approach Name(s) and MyFlightbook will recognize it as an approach description and translate it into English when you hover the mouse over it on the website.  Use this format:

[#][Approach type][Runway]@[Airport code]

E.g. "3ILS16R@KPAE" means "3 ILS Approaches to runway 16R at KPAE".

This is the format that the approach helper uses

Night Flying and MyFlightbook

Flying at night is wonderful fun, and something I don't do nearly enough.

From a logbook perspective, you really only care about whether you are legal to fly at night and how much "night flying" you can log.  There are a few other informational things you might care to log, but these are the most important.

Being current per FAA 61.57(b) to fly at night requires that you have done 3 takeoffs and landings (to a full stop) within the prior 90 days, between one hour after sunset to one hour before sunrise.

It's a surprisingly simple statement, but in a quick read one might miss that there's 2 distinct concepts of night there: "night", and the restricted period between sunrise and sunset.  They're not the same.


You'd think that the definition of night is simply the time between sunset and sunrise, right? Uh, no, that would be too simple. Rather, the FAA defines night as "the time between the end of evening civil twilight and the beginning of morning civil twilight, as published in the Air Almanac, converted to local time".  Which simply begs the question of what the heck "civil twilight" is.  The simple definition of "civil twilight" is when the sun is below the horizon, but by less than 6°.  Simple, right?  So to determine the start/end of civil twilight, you just get out your sextant and look for the sun while it's still below the horizon to measure it's angle and, oh, umm, never mind.

It's not actually that complicated.  Sunrise/sunset are easy to find; pretty much any aviation app (including MyFlightbook) can tell you sunrise/sunset at a given location.  Take that time span and restrict it by an hour at both ends and that tells you when you can do your takeoffs/landings to satisfy your 61.57(b) recent flight experience.

"Night" is, of course, trickier, since civil twilight isn't reported in many places and you can't see it.  It's generally fine to guesstimate it and use 20-30 minutes after sunset/before sunrise as the cutoff points.

You can also use a tool on MyFlightbook that I've developed. It's a bit rough because it's meant as a debugging tool rather than as a full product feature, but you can click anyplace on earth and specify a date and you can get the times for sunrise/sunset at that location on that day, as well as a map of 24 hours showing the sun's angle against the horizon (in 5-minute increments), enabling you to see when civil twilight begins/ends, and when the 1-hour window begins/ends.

But there's a simpler way on both: if you use the MyFlightbook app on iOS or Android, and have it autodetect takeoffs/landings, it will figure out all of this for you and fill it all in on your behalf, both landings and night time.  Or, if you use the web site and have a time-stamped GPS track of your flight (such as GPX/KML or a variety of other formats), you can press "Autofill" and the system will figure this all out for you.  This will use the correct measurements of night for you.

So now you've logged your night flying.  How do you log your day flying?  You may have noticed that MyFlightbook generally doesn't have the notion of logging "day" times.  This is deliberate: you have three variables (day, night, and total), two of which are fully specified (night/total); mathematically, the third variable (day) has a unique value that can be computed from the other two.  Giving you the opportunity to enter it explicitly wastes your time if you do it correctly, and introduces errors if you don't.  If you want to know your day-X time, just subtract the night-X time from the total-X time.  (See my separate post about combination properties for more information about this).

There are a few bits of interesting technical trivia/arcana here:

• The apps will detect night-takeoffs in addition to full-stop landings.  But your currency may show that you are current even if you do not log the night-takeoffs.  They are absolutely required!  But so many people are lax about recording them that I just give a warning when I find the required landings but do not find the required takeoffs.
• Logging night time is surprisingly tricky.  Specifically, there is no way to take a starting and ending point and time and determine how much of the flight was "night", because the specific path can affect that.  E.g., a flight from San Francisco to London might go north or south of a great-circle route for winds, and thus affect how much of the flight is conducted with the sun more than 6° below the horizon.  MyFlightbook solves this by looking at successive GPS samples (latitude, longitude, and time) and accumulating the elapsed time between them if both samples are "night."  Gap in the samples can lead to errors.  For example, if a sample comes in at 8:00pm and that is not night, night begins at 8:02pm, and the next sample comes in at 8:05pm, then 3 minutes of night will be lost.  As a practical matter, iOS and Android devices report GPS samples multiple times a second, so gaps like this are rare unless the device can't get a good view of the sky.  If presented with simply a starting and ending point and time, the website will construct a synthetic path between those points, assuming a perfect great circle path and a perfectly constant speed, and compute the total night based on that.  This is obviously an imperfect approximation, but it should be reasonably good, especially for shorter/slower flights.
• Many ratings require some amount of night flying, often as PIC or solo or cross-country.  Per my post about combination properties, just log these attributes independently; the system will determine the appropriate amount of combination to credit towards your rating.
• If you fly turbine aircraft, you may find that MyFlightbook isn't reporting the usual 90-days of currency.  This is because MyFlightbook also implements 61.57(e)(4), which provides an alternative mechanism for currency.  Your night currency will be the later of either 61.57(b) or (e)(4)
• If you use the AutoFill feature on the website and don't provide a telemetry file (GPX, KML, etc.) but do provide a route consisting of a starting and ending point (no intermediate points), and start/end times in UTC, then MyFlightbook will estimate the amount of night flight by creating a pseudo flight path which assumes (a) a perfect great circle route and (b) a perfectly constant speed equal to the great-circle distance between the start and end divided by the elapsed time.

Sims/Training devices on MyFlightbook

Logging time in an aircraft is pretty straightforward.  But sims (or, more accurately, "training devices", since not all are properly referred to as "sims") are a very different beast.

A training device on MyFlightbook is just another aircraft in which you can log flights.  The difference is that the system knows that it isn't an actual flying machine.  When you add an aircraft to your account, you can indicate that it is a real aircraft or one of several kinds of training devices (discussed below).

If you are adding a training device to your account, you might choose to create it using the model of the training device (e.g., Frasca, Redbird, Flight Safety, etc.), or you might choose to create it using the model of aircraft being emulated (e.g., Cessna 172, Boeing 737, etc.)  Usually, this is just a matter of personal preference, but in the scenarios where you can count your sim time as "time in type", I would recommend doing the latter.

When you add a training device to your aircraft list, it is auto-assigned a pseudo-tailnumber that begins with the prefix "SIM".  Partly, this is a mnemonic, but the bigger benefit is that since no country has a naked "S" or an "SI" prefix, so there's no opportunity for a SIMxxxx tailnumber to overlap with an actual flying machine.  The remainder of the tailnumber will reflect the model of the "aircraft" that was selected.  E.g., a Boeing 737 simulator might get SIMB7378 or similar.

To log a flight in a training device, simply choose the SIMxxxx aircraft from your aircraft list.  Log the time of your session in the "Ground Sim field.  Most of the time, you'll leave the PIC, SIC, and Total Time fields blank (zero), but if your training session is done in appropriately rated sim and in accordance with regulations that allow you to log it as time-in-type, then you may be able to fill in these fields.  I leave that judgment to you (consult your instructor!), but be aware that if you do log time in the total time field, it will add to your time-in-type.  E.g., if it's a multi-engine sim and you log 1.5 hours of total time, that will add 1.5 hours to your total MEL time.  So don't log time in that field if you don't want it to accrue to your totals.

You generally also want to log the serial number of the training device.  Throwing that into the comments for the flight is absolutely fine.  But if you wish to keep this orderly, there is also a property titled "Simulator/Training Device Identifier" that you can employ.

While there are all sorts of certifications for training devices, MyFlightbook really only cares about how they should be treated when computing things like passenger-carrying or instrument currency (61.57(a), 61.57(b), and 61.57(c)).  As such, training devices are broken out into four buckets on MyFlightbook:

• Uncertified.  Think Microsoft Flight Simulator.  Any approaches or landings are ignored when computing 61.57 currency.
• ATD. This has a formal definition from the FAA.  If you log a landing, it will be ignored for 61.57(a)/(b).  But instrument approaches and holds apply towards 61.57(c)(3) and 61.57(c)(4) (more on this below).  Note that 61.57(c)(3) requires additional maneuvers beyond just approaches and holds.
• FTD or Simulator - IFR approaches.  You know, I've never quite followed the formal distinction between an FTD and a Simulator, but while one exists, it doesn't matter to MyFlightbook.  Like an ATD, landings are ignored, but approaches and holds do count towards instrument currency, specifically 61.57(c)(2) and 61.57(c)(4).
• FFS or Simulator - approaches and landings.  This is exactly like the FTD/Simulator above, except that if you log landings, they will count towards 61.57(a) and 61.57(b).  This almost always requires a full motion "Level D" certification.

You can have multiple kinds of training devices for the same model side-by-side.  E.g., if you fly a 737 on Microsoft Flight Simulator and then fly a full-motion Alsim 737, you can have both in your account at the same time.


Sims are mostly used for instrument training, and pilots will often pad out their instrument currency with sim time.  But be careful!  A few years ago, the FAA rewrote 61.57(c) with the goal of making mix-and-match of real aircraft and training devices easier, but they screwed it up and actually wrote words that make it harder.  See the currency notes on the MyFlightbook site for the gory details, but the short summary is that you can't mix and match approaches/holds in a real aircraft with those in a training device.  My understanding is that the FAA is working on a rewrite to fix this, but we will have to wait and see.

UPDATE: As of June 2018, the FAA has released an update to 61.57(c), and as of Nov 26 2018, you can mix-and-match aircraft and FTD/ATD/FFS all you like, getting the full 6 months in each.  MyFlightbook will automatically cut over to the new rules when they take effect.

Why are aircraft on MyFlightbook shared?

A very early design decision I made with MyFlightbook was that aircraft should be shared.  That is, if two pilots have N12345 in their account, then it is the same aircraft for both of them.

There are a variety of benefits that arise from this:

• First and foremost, you get the benefit of crowd-sourcing.  If you go to add an aircraft and it's already in the system, you pick up that aircraft.  My working assumption - strongly validated in practice - is that the existing definition is more accurate the vast majority of the time.  So, for example, if you enter a C-172, but it's already in the system as the more-specific C-172P, you'll get the C-172P.
• Crowd-sourcing has another benefit: if another pilot spots an error and fixes it, you get the benefit of the fix.  A variant of the prior example is that you have a C-172 in your profile and somebody else updates it to be the more accurate C-172P, you get the benefit of the change.  Again, in practice, probably 90+% of such changes are in the direction of greater accuracy.
• As pictures of aircraft get added to the system, everybody gets the benefit.
• Shared aircraft enables people who actually share an aircraft to keep track of maintenance and inspections, such as VOR checks.
• Club functionality would be impossible without shared aircraft.

There's a tradeoff here, of course.  The obvious downside is the fact that changes by one pilot can impact another's logbook.  So if N12345 was a Cessna C-172 and the registration gets re-assigned to a Boeing 737, and pilot #2 changes N12345 to be a 737, then suddenly pilot #1 has some extra multi-engine/turbine time in their logbook!

However, in practice this is a relatively small problem and easily managed.  I receive a notification of - and review - EVERY change made to an aircraft that has more than one pilot flying it.  (It's actually not all that much; a few edits a day, most of which are of the C-172 to C-172P variety described above; i.e., requiring no action).

So I can wade in when necessary to keep everybody straight.  And when the same registration is used for multiple aircraft (such as the 172 to 737 example), I can "clone" the aircraft across both models, so that each pilot can have the correct model for their logbook.  Pilots can even have both models side by side, if it's appropriate, such as when they take a vanity registration from one aircraft to another, or if they have a plane that is on floats half the year and wheels the other half.

Checkrides

I'm occasionally asked why I don't have things like a Multi-Engine checkride on MyFlightbook.

My flip answer is simple: because there is no such thing.

Specifically, a checkride for a license (properly “certificate” in FAA-land, but I’ll be informal on that point here) indicates a level of privileges (private pilot, instrument, commercial, ATP, etc.), which specifies what you can do as a holder of that license.  That license comes with restrictions specifying in which categories/classes (and types, for aircraft that require a type rating) those privileges may be exercised.

So a "Multi-engine Commercial Checkride" is really just shorthand for "A commercial checkride which applies to (possibly among others) multi-engine aircraft."

This is a somewhat academic distinction, of course, but there are two strong pragmatic reasons not to offer this as well:

• The number of such possible checkrides would be huge.  Specifically, it would the [the number of possible ratings] x [the number of possible category/class/(type) to which it could apply].  At the moment, that's over 200 possible checkrides, and that's not even counting type-specific checkrides.
• It's pointless to log it anyhow, because all of the information is already present in the aircraft used for the flight.  If you did your commercial checkride in a multi-engine aircraft, it's pretty clear that it was a "commercial multi-engine checkride."  If you do your instrument checkride in a helicopter, it's obviously your instrument-rotorcraft checkride.  

So congratulations on passing your checkride!  Just go ahead and log it according to the privilege you earned, and then go out and fly!

"Combination" Properties

Why doesn't MyFlightbook support the ability to explicitly log "combination" properties, such as "Solo Cross-country" or "Night PIC"?

I generally strongly avoid "combination" properties for a few reasons:

• Most importantly, this can generally be computed.  So a given flight’s “Cross-Country Instruction Received”, for example, is computed as MIN(Dual, Cross-country).  It’s an approximation, but in practice (for reasons described below), it’s way more accurate to do this than logging explicitly.
• Explicitly logging can lead to ambiguities or outright errors.  E.g., suppose you have a flight that has 2 hours of total time, 2 hours of cross-country time, and 1 hour of night.  It’s pretty obvious that this flight has 1 hour of night-cross-country (see above).  Now consider if it were possible to explicitly log "Night Cross-country."  If you logged 1.5 hours of night-cross-country, then it’s clearly an error.  If you log 1 hour of night-cross-country, then you just wasted your time.  And if you forgot to log night-cross-country, then should I count an hour of night cross-country or not?  (Probably yes since it’s obviously there).
• The number of possible combinations of PIC, Night, Cross-country, Solo, and Instruction grows very rapidly, making data entry insanely cumbersome (a given flight can have lots of these combinations), and lead to you forgetting to log all of the possible combinations that applied to a given flight.

For these reasons, I try to limit data entry to the “independent variables” (solo, night, pic, cross-country, dual received, etc.) and compute the combinations as needed.

I do these computations in the 8710 form, as well as in the various ratings-progress screens.

How are "Visited Airports" computed?

Someone asked me recently about how I count "visits" when computing visited airports. Specifically, the # of visits shown in the list of visited airports often doesn't match the number of flights in which that airport was recorded.

The issue arises from my definition of "visiting" an airport. Of course, this has no formal definition, but for me it's decidedly focused around arrival at an airport. After all, "let's go visit Grandma" is about going to Grandma's house, not leaving it. (Besides, it's almost always more of an achievement IMO to land at an airport than to takeoff from it.) So I'm really (mostly) trying to determine arrivals.  In that vein, if you don't log any landings, then the airports won't show up as "visited".

My heuristic (in addition to below) is this:

1. If a flight has a single airport listed, I count that as a visit.
2. If a flight has multiple airports, then I ignore the first airport in the list...
3. ...BUT if the first airport in the list above has no previously recorded visits, then I do count it as a visit.

The idea is that if you fly down to Martha's Vineyard for the weekend, going (say) LWM->MVY on Friday and MVY->LWM on Sunday, that was only one visit to MVY. Ignoring the leading "MVY" on the Monday flight achieves that. If on the intervening Saturday, you did some touch-and-go's at MVY (recording either "MVY" or "MVY-MVY") then you'd get two visits: LWM-MVY and MVY (or MVY-MVY). The Sunday departure (MVY-LWM) is just the completion of the visit, not a new one, so ignoring the MVY has the right result.

The logic above also prevents "MVY-MVY" from registering as 2 visits. After all, if you don't leave the pattern, it's really just one airport, right?

The reason for (c) above is to handle edge cases where you might miss an airport altogether. E.g., if you fly commercial to an airport to pick up your airplane from an airport that you've otherwise never been to (e.g., a few years ago I flew SouthWest Airlines to Sacramento to pick up our club's Mooney at Stockton; I've never otherwise been to Stockton), it should register at least one visit.
Again, there is of course no "official" definition of visited airports; it's just something I thought would be fun, but above explains why the math might seem a bit strange.