Ratings progress - why can't I click?

Numerous times, I've been asked for the ability to click on an item in MyFlightbook's Ratings Progress so that you can see the flights that contributed towards the progress.

The reason I haven't done this is that it's really hard to do in a way that is meaningful. 

I already do it for experience requirements that match a specific flight (e.g., long cross-country, but even that could have potentially have multiple matches). 

But for most of the remaining items, it's either silly to implement, or there are reasons why it won't work the way you might hope.  For example:

• Many of the requirements for a given rating are quite trivial.  E.g., "500 hours of total time", or “50 hours of solo time in airplanes”.  These can be viewed directly from your basic totals (which are already clickable), so adding it in ratings progress doesn't really add much value.
• More difficult are the experience requirements that can be met via multiple different subsets of flights due to alternative criteria or allowed substitutions, so the “matching flights” won’t’ tell you anything.  For example, 61.159(a)(2) (ATP rating) requires 100 hours of night flight, but 61.159(b) allows each night takeoff/landing in excess of 20 to count towards one of those hours, up to a maximum of 25 hours.  That is to say, you can meet this requirement with only 75 hours of night flight but 45 night takeoffs/landings.  If I link to a search that shows only flights with night and you only have 75 hours of night flight, it will be hard to reconcile why this item shows as met.  Or, conversely, if you have more than 100 hours of night flight and more than 45 night takeoffs/landings, which ones are the ones that contributed and which ones were disallowed because you had hit the maximum 25 substituted hours?  It’s like money: asking which flights met the criteria can be like asking which dollars from your paycheck bought a given bag of potato chips.
• Sometimes, though,  the query needs to be more precise than I could actually do as a search, such that even if I showed you all of the flights that contributed to a particular rating requirement you wouldn't be able to at-a-glance see how much each flight contributed.    A good example of this is things like night instruction.  Suppose a given flight is 3 hours long, of which you logged 2 hours of instruction and 0.8 hours of night flight.  That flight would contribute MIN(Dual, Night), or 0.8 hours of night flight towards the requirement.  But if you took all the flights with dual and night, the total of dual and the total of night would read more than you can count towards this; this is actually why this isn't done in the database - I get all of your flights and examine each one in turn doing computations that can get pretty arcane and specific because the rules can get pretty arcane and specific.

So it turns out that very few of the milestones actually would have interesting associated queries that you could get useful results from and which would actually save you any meaningful clicks/taps.

By the way, this is also why in your currency, you can click on custom currencies and due dates, but most of the regulatory ones like 61.57(a/b/c) are not clickable.  The custom currencies follow very regular rules, but the regulatory ones have two many different paths to completion.

Aircraft and Models

Aircraft on MyFlightbook are shared among pilots on the system, as discussed in my previous post on this topic.

But what happens when a tail number (i.e., registration) is re-assigned from one aircraft to another?

Here are the rules I follow:

If you are adding an aircraft to your account that is already in the system, MyFlightbook ignores the model you specify on the assumption that the existing definition which has been vetted by other pilots, is correct.  Most of the time this is the right behavior: you'll specify a vanilla C-172 but it's in the system as the more specific C-172 N, for example.  MyFlightbook sends an email about this to let you know which model was assigned if you are using an existing aircraft.

Once an aircraft is in your account, you can edit its model (web only) by clicking the pencil icon.

If you make a "minor" change to an aircraft, then the underlying aircraft is changed and all pilots with that aircraft in their system receive a notice of the change, since the changed aircraft is used in their account too.  What constitutes "minor"?  I use two criteria: (a) you're not changing the category/class (e.g., changing from a C-172N on wheels to a C-172N on floats), and (b) you're not changing the ICAO model being used.  So, for example, all C-172's have an ICAO of "C172", so changing a C-172 P to a C-172 S is a minor change.

If the change, however, is not minor, then the system will automatically clone the aircraft using the new model and put the clone in your account.  So, for example, if you flew a C-172 S years ago but now the tailnumber is assigned to a Boeing 737, you could edit the 737 to be a C-172 S and a copy of the aircraft will be created that shares the same tail number but is a Cessna instead of a Boeing.  A notification will again go out to other pilots alerting them to the new version, but nobody else's aircraft will be affected.

Sometimes, when an aircraft is cloned, you actually want both versions available to you.  A good example of this is an aircraft that is on floats part of the year and wheels for the remainder.  This is not a problem.  When you view details for the aircraft (using the web), you will see both versions of the aircraft and you can either switch from one to the other, or you can add an alternative version to live side-by-side with the original.

Are jet engines high performance?

 Are jet engines high performance?  Seems a silly question.  FAR 61.31(f)(1), seems pretty straightforward: have an engine with more than 200hp?  It's high performance.  200 or less?  Then it's not.

But I've had a few jet jockeys argue that jets (and they were all talking about transport-level aircraft like 737's and larger) are not high performance because the engines are measured in pounds of thrust and not horsepower.

Meaningful distinction?  No.  Just different ways of measuring how much "oomph" an engine has, but they can be translated from one to another.

Here's the short version:

Power is Energy Delivered over time.  200 horsepower is equal to 149,200 Joules of energy / second (J/s).  If an engine is delivering 149,201 or more J/s, then it is above 200hp, and thus high performance.  The kinetic energy of the aircraft in Joules is (1/2)mv² (m in kg and v in meters/second) so I leave it as an exercise to the reader to determine if a Boeing 737 on a takeoff role is accumulating more than 149,200 J/s.  (Hint: the answer is "yes.")

And here's the longer version:

Now bear with me here for a little math.  I'm embarrassed to admit that I actually have a degree in physics from MIT, but since I haven't used it in 30 years I need to think about this.  But with that disclaimer...

Pounds of thrust is a measure of force.  (That's actually the difference between mass and weight: weight is the force of gravity exerted on a given mass, which is why your weight is different on, say, the moon, but your mass is unchanged.)

Horsepower is a measure of power, and power in turn is the rate of energy transfer.

These are different, but related quantities.

Energy (or "work") is force multiplied by distance.   I.e.:

E = fd

Deliver that energy at a constant rate over a period of time to compute the power involved:
 

P = E/t = fd/t

Sanity check: 1 horsepower is 550 "foot-pounds per second" - i.e., foot (distance) x pounds (force) divided by time.  So the units here check out.

But alas, d/t is distance over time - a velocity!  So, power in relationship to speed is force times speed (v):

P = fv
 

So now we can relate horsepower and force: they're related by the speed.

But wait, that doesn't make sense.  A piston engine is delivering a given amount of power regardless of speed.  And a jet engine is delivering a given amount of thrust regardless of speed.  So what gives?

Let's look in the power (piston) world first.  At some given speed (v), your engine is delivering energy to the air around the aircraft (not directly to the aircraft!) at some rate of energy per unit of time, aka "power" P.  This delivery of energy, by Newton's third law, creates an equal and opposite reaction, which causes the engine (and thus the plane to which it is hopefully attached!) to move forward.

By the math above, your effective force f is P/v.  Of course, at rest (v = 0) that's an infinite instantaneous force, but that "infinite" force is for just a split second, and the aircraft starts moving.^* More to the point, since we're in the "power" world rather than the "force" world for the moment, the power delivered by the piston engine is adding energy to the aircraft, which causes it to move.

As the aircraft absorbs energy, its speed increases until the engine is putting energy ("kinetic" energy - energy of motion) into your airplane at precisely the same rate that friction^** is removing energy from the system; at that point, the total energy of the aircraft stops changing.  Kinetic Energy is (1/2)mv², which is basically a reflection of the mass and the speed.  Sure, as you burn fuel, you get lighter, but over small time periods that change is insignificant.  Therefore, if your net energy is unchanging, the speed is essentially constant.

The same thinking applies in the force (turbine "pounds of thrust") world.  The power delivered to the aircraft is P = fv as described above.  So your jet engines spool up and deliver some amount of force.  While the aircraft is at rest (v = 0), the energy delivered to the aircraft is 0, so the effective instantaneous power is obviously 0^***.  But alas: apply a force to a mass and v changes from zero to non-zero - the plane acquires energy (1/2 mv²) and begins to accelerate, absorbing more energy.

Delivery of energy over time, of course, is the very definition of power, so this can be measured in horsepower, if you like.  But this time we're in the "force" world: the thrust of the engine provides a force against the aircraft, causing it to start moving.  As the plane accelerates, so do the opposing forces of friction, draining away some of the energy that is being added by the engines.  (And, of course, as you climb, you are creating lift, which means creating additional force to oppose gravity).

Eventually, friction creates as strong a force opposing the engine's force (and you stop climbing as well): equilibrium of forces is achieved and the aircraft reaches a stable velocity, neither accelerating/decelerating nor climbing/descending.

The key thing to note is that the two examples I give below are PRECISELY the same, just looking at it from the point of view of power or force.  The only difference is that I labeled one "turbine" and one "piston."  I could have just as easily swapped those labels and everything would still work out just fine.

So this was a long and geeky way around to my esoteric point that "pounds of thrust" and "horsepower" are tightly coupled, related by the mass and speed of an aircraft.

More importantly, all but the smallest experimental/hobbyist jet engine is absolutely going to deliver more than 200hp of power to the aircraft to which it is attached.

And thus, any aircraft with such an engine qualifies as high-performance.

^*OK, perhaps worth clarifying: imagine your aircraft is chained in place.  It won't move, period.  The engine is putting energy into the surrounding air, so this results in a force being applied to the aircraft.  The chain, however, exerts an equal and opposite force, so the aircraft doesn't move.  As a result, the air absorbs all of that energy; the chain is effectively shunting the energy that would have gone into the aircraft into the air, so the air behind the aircraft is moving a bit faster than it would have been if the plane were moving.

^**If you're climbing, then some of that kinetic energy is also being converted into potential energy, providing another drain on the energy that the engine is putting into the aircraft.  So properly the equation here is that kinetic energy is added to the aircraft by the engine and is removed by friction and increases in potential energy.  If energy is being added faster than it is removed, the aircraft speeds up; if it is added more slowly than it is removed, the aircraft decelerates.

^***That's actually power to the aircraft. Energy is conserved, so if it isn't going into the aircraft, it's all going into the surrounding air. Effectively, the power is thus conserved as well.

Solo flight and commercial ratings progress

Solo time is pretty straightforward, right?  If you're the only one in the airplane, then it's solo.  Anyone else aboard, then it isn't (and shouldn't be logged as such).

But as you advance in your ratings from private to instrument to commercial, you start to fly more sophisticated and more expensive aircraft.  Building solo time can be difficult due to insurance requirements around minimum experience, or due to the lack of a appropriate ratings (e.g., working on a multi-engine rating after earning commercial in a single-engine airplane).  If a student simply doesn't have the requisite level of experience, then they can't rent from an FBO, placing a burden on getting solo experience.

For this reason, the FAA has created a substitute for solo in the requirements for flight experience for a commercial rating (61.129).  The wording is that you must either be solo or "performing the duties of pilot in command...with an authorized instructor on board."

To indicate this sort of a flight on MyFlightbook, you should log the flight and attach the "Duties of PIC" (DPIC) property and the "Instructor on Board" (IOB) to the flight.  (I'll refer to this below as "DPIC/IOB" time)

There is often confusion about this, and I have on more than a few occasions received an email complaining that MyFlightbook is not crediting all of the time it should be crediting, or is missing their long cross-country flight.

The idea is that this is supposed to emulate solo flight, so the instructor is there not to teach you, but rather to satisfy insurance restrictions.  You're doing all of the work as if you were in fact in solo flight.  The instructor, therefore, should essentially be sitting on their hands for the flight.  The mistake people typically make here is that they read "instructor on board" as meaning "I can log dual." 

Unfortunately, this is a misreading of the regulation.  The normative legal interpretation from the FAA can be found in the 2014 FAA "Kuhn" interpretation (or Google the phrase "FAA duties of PIC Kuhn"): you cannot simultaneously receive instruction and count flight towards 61.129(a/b)(4).

The money quote from the Kuhn letter is "Because this flight time is a substitute for solo flight time, the pilot is not receiving instruction and therefore cannot log this time as dual instruction received."

For this reason, MyFlightbook subtracts out any dual instruction that is logged from the amount of  DPIC/IOB time to determine how much time can credit towards 61.129's requirements.

Note too, that since this is a substitute for solo flight, you must not log it as solo either (after all, you're not alone in the aircraft).

MyFlightbook computes a flight's contributions towards solo requirements as follows:

• Compute an effective DPIC/IOB time as
  

  MIN(DPIC/IOB, Total Time - Dual Received)

  So, for example:
• A flight with 2 hours of DPIC/IOB, 2 hours of total time, and 2 hours of Dual yields

  MIN(2, 2 - 2) = MIN(2,0) = 0.

• A flight with 2 hours of DPIC/IOB, 2 hours of total time, but only one hour of instruction, yields

  MIN(2, 2 - 1) = MIN(2,1) = 1 hour.

  I.e., I'm removing the hour of instruction per Kuhn, but the other hour can count as DPIC/IOB.
• A 2 hour flight with 60 minutes of instruction and 90 minutes DPIC/IOB yields

  MIN(1.5, 2 - 1) = MIN(1.5, 1) = 1 hour.

  I.e., the flight is ambiguous, but at most one hour of this flight could possibly contribute time here, so I'll give you the hour.
• Compute an effective solo time of

  MAX(explicitly logged solo time, effective DPIC/IOB)

  This value is what is used for total solo time requirements.  Note that this also implicitly corrects for accidental logging of both DPIC/IOB time and solo time.  I suppose it's possible that you have a flight where you fly with an IOB for a while, then the instructor gets out and you fly solo, but I also suspect that's pretty rare, since usually the whole reason you had to fly with an instructor on board is precisely because you can't fly solo.
• Compute an effective night VFR solo time of

  MIN(effective solo time computed above, Night - IMC)

  (Note that this could be a bit conservative: e.g., if you had a 2 hour solo flight where the first hour was in day IMC and then it cleared up and the 2nd hour was at night in VMC, then the flight won't credit.  But that's a bit of a corner case and it means that the error is conservative - better to understate than overstate experience!)  Anyhow, this value is what is used for any night solo time requirements.
• For any activities such as takeoffs/landings or a long cross country that must have been performed while solo, add them to your experience if the effective solo time is greater than 0.
• Finally, the various 61.129(4) requirements computed using both actual solo time and the effective substituted solo time.  After all of your flights are examined and the experience is summed up, MyFlightbook will report your progress using either exclusively actual solo time, or exclusively DPIC/IOB time (whichever has more time recorded), but not both.  This is because you cannot mix-and-match: all of the solo time in 61.129 MUST be actual solo time or it must all be DPIC/IOB time (see the FAA's 2016 "Grannis" interpretation for details). 

All of the above, of course, are in the context of 61.129, and thus only apply in determining your progress towards meeting the experience requirements therein.  MyFlightbook's 8710 form, on the other hand, is a summary of experience without the context of any particular rating.  As such, the 8710 form does not include the DPIC/IOB substitution, it only looks at solo time that is recorded as such.

So by all means, go out and build your "solo" time with an instructor on board.  But don't log it as instruction received.

Printing from electronic logbooks

The "paperless" society has never actually arrived.  Despite the obvious superiority (at least in my opinion) of electronic logbooks on every dimension, old habits die hard, not just among pilots but also among airlines and regulators: lots of people still want paper renditions of their logbooks, whether as a backup to electronic, or for sharing with potential employers or regulators.

MyFlightbook has fairly rich printing support.  If you go to the Print View (under the Logbook tab on the website), you can see a printer-optimized version of your logbook, including a summary of your totals and your endorsements. 

There are two ways you can print.  You can simply print from the browser, or you can download a PDF.  If you choose to do the former, don't worry, the web-specific items (page header, and the user interface for configuring your print) will not show up on the printed page.  However, different browsers implement the HTML specification for printing a bit differently, so you may see some differences from browser to browser (one example is whether or not the table column headers are repeated on each page).  If you download the PDF, of course, this is not an issue, and better still, you don't have to kill trees - you can back it up or email as you like without ever putting ink to paper.

MyFlightbook supports an array of different style layouts that mimic common paper layouts around the world.  Some of these are rather prescriptive (e.g., EASA), specifying exactly which columns must be present, what order they must be in, etc.  Others are not so much.  This is an area where I think the FAA has overall been quite enlightened: they specify what they want you to log, but do not specify the manner in which it is logged.  This flexibility does show itself in some of the layouts, where you can add additional columns not otherwise present in the layout, or include pictures from flights; neither of these are possible with the more prescriptive layouts.

In addition to choosing a layout, MyFlightbook supports quite a few options around printing.

• You can exclude properties that aren't relevant for your printout, to reduce clutter.  E.g., if you're applying for a job, you may not want to include details like your fuel cost.  You can also choose how to separate properties when a flight has multiple properties - e.g., putting each on a line, or separating them with a comma.
• As mentioned above, depending on the layout, you can choose up to 4 additional columns.  This is useful, for example, if you want to call out turbine or complex time or a specific property.  It is only available for the layouts which are not prescriptive, however.
• Also dependent on the layout, you can choose to include any pictures that you have saved with your flights.  You probably don't need that when applying for an airline job, but if you're flying for fun, you absolutely should have it; after all, a logbook isn't just a record keeping requirement, it's a place for memories!
• You can select an approximate number of flights to display per page; subtotals will be inserted after that many flights.  This is only approximate, however, for reasons discussed below.
• You can choose which criteria to print out (e.g., only a specific date range, or only flights in a glider), and whether to include totals and endorsements.  Note that if you have uploaded PDF endorsements, you will need to print those out separately; MyFlightbook cannot embed one PDF into another, either as a file or on the printed page.
• If you are downloading a PDF file, you can specify the orientation (landscape generally works best), the page size, and any margins.

It is important to note, however, that electronic logbooks and paper are inherently different, and as a result you will never have pixel perfect fidelity between the two.  (Warning: a bit of my personal bias is about to be exposed).

The first difference is per-page subtotals (see the bottom highlighted portion in the image below).  All paper logbooks have these, but the reason for it is utterly obsolete and pointless in an electronic world: human computation.  Per-page subtotals allow you to add up your totals by hand without having to go back to the start of your logbook.  It's entirely about making pencil-and-paper computation tractable.  Of course, in the electronic world, computers don't mind going back to the start of the logbook for every computation, and they don't make math errors.  And in MyFlightbook, totals are shown at the end of all of the flights.  So there is really absolutely no good reason for this other than as an aid to human computation.

Some people like per-page subtotals even in the electronic world because they also keep a paper logbook and it allows them to double-check their paper backup; while that is true, it doesn't change the fact that it's still about human computation.  They could still keep the paper logbook and not bother with the per-page subtotals; if it's a backup, having the individual flights is enough - you could delay computing any totals by hand indefinitely unless/until the backup becomes necessary.

I've also heard some people say that airlines/etc. want per-page subtotals.  This may be true, probably because it's what they're used to.  But it really isn't necessary.  After all, can you imagine a hiring manager at an airline double checking (by hand!) the math on something that was clearly computer generated?  And if they don't trust computer generated totals, why would they trust the subtotals?  If they want to verify the totals, it would make more sense to send them the PDF for human readability, and the spreadsheet backup; then they could use the spreadsheet to verify any math (assuming that they trust Excel's math skills).

Of course, as I said above, old habits die hard, so MyFlightbook supports per-page subtotals.

A page from my old paper logbook - note the percentage of the page devoted to human computation!

Another difference between the printed page and an electronic logbook is that paper logbooks are generally designed for a certain kind of flying and don't scale well beyond that.  In particular, most logbooks have a column for SEL Airplane, MEL Airplane, and maybe one or two columns for other category/classes of flying (glider, helicopter, etc.)  As with per-page-subtotals, this is also utterly obsolete and pointless: the reason for independent columns for category/class - which is, of course, completely determined by the aircraft column - is (you guessed it) to aid in human computation of these subtotals.  Alas: if humans aren't doing the math, then there's no need for this column. 

But if pointless redundancy in the columns weren't bad enough, this paper artifact suffers two additional sins.  One is that it's limited.  E.g., I personally have ratings for SEL, SES, and MEL aircraft, but I have also taken a glider lesson and a helicopter lesson.  In a paper layout, one of those latter two has to give; there just aren't enough columns to handle that. 

Sure, you could add yet another column, but that gets to the second "sin": of all the real estate on the printed page, horizontal (i.e., columns) is the most precious.  That is because printouts are meant to be read linearly - from top to bottom.  Adding new flights and spilling over onto a new page as a result is no problem; it's just a new page.  But adding new columns means you either have to shrink everything to fit (making it hard to read), or spill out to a new page *horizontally*, which means now you have to read in two dimensions: paging from left-to-right to view all of the columns, and then paging top-to-bottom to view all of the flights.

This is (one) reason that in the paper world glider logbooks and military logbooks generally look different from general aviation logbook. But in the electronic world, you can accommodate all of this without needing new columns - or (as I've done), by supporting multiple layouts and a few optional columns.

The third difference is the layout model.  A paper logbook has a fixed form; you can shrink your handwriting to fit into the row, or you can spill from one row into the next, using multiple rows for a single entry.  Obviously, this is because paper is inherently inflexible: the boundaries of the printed form must be created before any content.  In the electronic world, however, this is not the case.  The row, therefore, grows or shrinks to fit all of the necessary data. 

This is the reason that choosing a specific number of flights per page is at best approximate.  If a given flight has a lot of data, it can easily cause some flights to spill over onto the next page (particularly if the selected paper size is small).

There's actually a more subtle reason why the flights-per-page is approximate: printing engines don't know how to render per-page subtotals; MyFlightbook has to do that before it sends it for rendering (where everything gets measured using the correct fonts and laid out on the printed page).  So MyFlightbook fills in the requested number of rows, then adds the per-page subtotals, and only then sends it to be rendered.  Which means that MyFlightbook can only guess whether or not they will fit.  MyFlightbook has some heuristics so that it automatically reduces the number of flights on a page when it sees what appear to be "tall" flight entries, but because it doesn't have a rendering engine, these heuristics are only approximate.

There are only two ways to solve this.  One is if MyFlightbook could try out a particular pagination, send it to the renderer, then get it back from the renderer, and make adjustments, and repeat until a good solution is found.  But this isn't possible because the renderer doesn't give MyFlightbook anything that can be consumed in this way: the layout is either done by your browser (when you print from there), which means it is on your computer and is sent straight to the printer without a chance to go back to the MyFlightbook server, or it is done in the PDF engine on the server, but the PDF it produces is essentially opaque.

The other way would be for MyFlightbook to do its own rendering, where it would add flights to a page one-by-one, computing subtotals totals and seeing if it all fits, then adding another flight until they don't fit any more, and then moving on to the next page.  The short answer is that this is a very hard problem to solve correctly - it basically requires writing my own browser.

For these reasons, I actually generally suggest using "Continuous" rather than targeting a fixed number of flights per page. Since there are no subtotals to compute, all of the data can be computed up front and pagination can be performed by the printing engine.  This setting also uses paper wisely, since it fits as many as possible on a page, without splitting a single flight across pages (unless that flight is so big that it literally will not fit by itself on a single page).  You give up per-page subtotals when you do this, but hey: it's generated by a computer, so as I asserted above, you don't really need per-page subtotals!!!

I'll finish this with three tips/tricks that can help your printed logbook look its best:

• If your comments on your flights are long, you can use "///" within the remarks to indicate that everything that follows should not be printed.  E.g., a comment that is "Print this /// not this" will print as simply "Print this".
• Building on that, if you use "///--" it will force a the next flight to begin a new page.  So if you are doing, say, 10 flights per page and flights 9 and 10 are spilling onto a new page by themselves, you can edit flight 8 to have "///--" and that will force it to be the last flight on the page; the 2 flights that had been alone on a page will now be the first two flights of the next 10-flight page.
• You can use simple markdown in your comments on flights for emphasis or italics.  Specifically put asterisks around text to make it bold and underscores (_) to make it italic.  E.g., *bold* or _italic_ will show up as bold or italic.

Logging Cross Country Time

Uggh, cross-country time.  Such a simple concept, such a simple phrase, such an ambiguous definition.

Well, OK, the definition in FAR 61.1 is pretty simple and unambiguous: if you land somewhere other than where you depart, it's a cross-country flight. 

Simple, right?  Except that there are 6 subsequent exceptions that impose minimum distance requirements depending on the rating being sought and the category/class of aircraft being used, some of them requiring a landing and some of them not. 

So to summarize, a cross-country flight is any flight where you depart and land somewhere else that is at least a certain distance away, unless you don't have to land and unless you don't have a minimum distance other than leaving the departure airfield.

In other words, the question of whether a particular flight is a cross-country flight is inherently unanswerable unless you provide the context in which the question is being asked.  But a flight is just a record of the flying done; while you might perform a given flight with a given purpose in mind, most of the time you're accumulating experience towards multiple potential goals, even if at the time of the flight you are not actually pursuing any of them.  So that flight you took may be cross-country for some of those potential goals, while not qualifying for others, and yet you are generally expected to log a cross-country flight as such.

It's enough to make one's head explode.

So here is how I recommend logging cross-country time:

• Do *not* bother logging anything for basic cross-country time.  Why?  Because this can be computed: if the route of flight is X-Y and X does not equal Y, then you left the departure airport (e.g., "KSEA" and "KSEA-KSEA" are both local flights, but "KSEA-KSFO" is a cross-country flight).  So logging it is just redundant work on your part, and could muddy your cross-country totals that you want to demonstrate for a rating.  If you search for "non-local flights", the resulting totals will be your cross-country time by this definition.
• Use the "Cross-country" field to capture cross-country time that meets any of the other definitions.  You can easily cross-fill from the Total Time field by clicking the arrow next to it (website) or pressing-and-holding (mobile apps).
• If you're working for a rating in a particular category/class, log the time of the flight in the Cross Country field if it meets the requirements for that rating.  E.g., if you're working towards your helicopter PPL, log it if you land 25nm away from your departure point.  If you're working towards your PPL in a fixed wing, log it if you land 50nm away.  In fact, since 25 meets all helicopter requirements and 50nm meets all fixed-wing requirements, then log any flight that has a landing exceeding these thresholds, respectively (depending on the flight aircraft, obviously) as cross-country.  Note: the mobile apps will automatically fill-in cross-country time if they are detecting takeoffs/landings and see a 50nm distance between airports in the "Route" field, since this seems to be the largest threshold available for any purpose.
• The FAA's requirements for non-rotorcraft ATP non-rotorcraft commercial (for military pilots) ratings allow for cross-country time if you go over 50nm but a landing is not required.  If you are not working on one of these ratings and would like to log this experience without "polluting" your cross-country time by logging it there, you can use the property "Cross-Country Time over 50nm (No Landing)".  If you do so, don't also log cross-country time.  When determining your progress towards one of these ratings, you can then add your cross-country time to the "no landing" cross-country time and the result - assuming you didn't log in both places - should be what you can count.  In the ATP Ratings Progress, MyFlightbook will use MAX(cross-country, no-landing cross-country) to compute how much a given flight contributes, but it's cleanest if you are careful not to log in both places.
• You can also decorate your flight with properties to identify the distance threshold used for cross-country.  There are three in the system that matter here: Cross-Country Over 50nm, Cross-Country Less than 50nm, and Cross-Country less than 25nm.  By using these properties, you can distinguish the threshold used for a given flight and you can therefore search for flights containing these properties to do the math to include/exclude cross-country time depending on your purposes.

What made me current? What will it take to regain currency?

Two questions that often arise regarding currency (particularly instrument currency) are:

1. I'm not current.  What's the least experience I need to regain my currency?
2. I am current.  What set of flights are the reason (contain the relevant flight experience) that I'm current?

MyFlightbook does already tell you what you need to do to get current (question #1 above), but it can't promise that it's the minimal path ("least experience") to get there.  This is because the “minimum” criteria is actually impossible to determine, as there may be multiple ways to get current, and there is often a tradeoff between optimizing for cost and optimizing for amount of currency gained.

For example, given the current instrument currency rules in 61.57(c) - which I should note will (thankfully) change in November - suppose that it is now July 31 and you did 5 approaches + hold in an FTD in January (short on 61.57(c)(2) by one approach), and you had also done 5 approaches + hold in an airplane, also in January (short on 61.57(c)(1) by one approach), and that was it (and you don't - yet - need an IPC).

Here are some options:

• You can do a single approach in an FTD (relatively cheap).  You'll be current per 61.57(c)(2) until...midnight tonight (July 31).
• You can do a single approach in an airplane (more expensive). You'll be current per 61.57(c)(1), also until midnight tonight.
• You could do 6 approaches + hold + some maneuvers in an ATD (cheap) and be good through Sept 30 per 61.57(c)(3).
• Or you could do an IPC (more expensive) and be good until Jan 31 2019 (longer duration).

Any of these options is OK.  Which counts as “minimal criteria?"  Depends on whether you are optimizing time (the first two are the quickest), cost (the ATD or the FTD probably win on this), or  how long you want your currency to extend.

So what MyFlightbook does here is it picks the simplest path towards currency that involves actual flight experience.  In the case of instrument currency, for example, it will tell you how many more approaches or holding you need in an aircraft, or if it doesn't matter because you need an IPC, it will tell you that.  If you've got 2 night takeoffs/landings in the past 90 days, it will tell you that you need one night takeoff/landing to get night current, etc.

In a similar vein, determining the specific flights that made you current is non-deterministic.

A simple example is that you did a lot of approaches/holding earlier in the month in preparation for your instrument checkride, took and passed the checkride, and then did a bunch more approaches/holding.  Are you current because of the checkride?  Because of the approaches at the start of the month?  The ones at the end of the month?  What if you did the 2-month ATD thing in July (good through the end of September), but you also did 6 approaches + hold in a real airplane in March – you’re current by both.

Even night currency is surprisingly complicated.  It’s not simply “3 takeoffs/landings to full stop at night”, because if you’re a turbine pilot and have the right number of hours and the right other experience, that can extend your currency (see 61.57(e)(4)).

When I compute currency, I actually compute all the ways you could be current and then OR them together, picking up the latest expiration date.  It’s deterministic in that direction, but not in reverse.

The result is that you could search for flights containing "instrument" experience or "night landing" experience, etc., but inevitably it will pick up a superset of flights; like the game Jenga, you can remove multiple distinct subsets of those flights without disturbing your ultimate currency computation.

This is also why all currencies on MyFlightbook are “clickable” except for the regulatory ones; the regulatory ones, unfortunately, have so many exceptions and alternatives that you can’t determine which flights contributed.

Update on April 2, 2020: 
I have gone ahead and made many of the regulatory currencies clickable.  I'm using the simplest test, so it's important to note that the results you see may NOT tie to the expiration date that is reported.

To use an analogy: computing a currency is like taking two numbers and multiplying them; it's deterministic and yields one answer.  4x6=24.  Deciding which flights made you current, though, is the reverse operation - it's like looking at 24 and asking "which two numbers were multiplied?"  Could be 4x6, could be 2x12, could be 3x8, could be 1x24. 

So, for example, night currency by 61.57(b) simply looks for 3 night takeoffs/landings within the preceding 90 days, and most of the time, that's the test.  But if you meet the requirements of 61.57(e), you may actually not have any night landings within 5 and a half months and yet still be night current.

Also, where currency is expired, I do not modify the query to show you the flights that contributed to that old currency.  That's a historical artifact, but I think it's much more useful to know why you are not current right now.  So, for example, if you're no longer night current, clicking on the expired night currency will show you flights with night landings within the past 90 days (in which, presumably, you will fail to see 3 night takeoffs/full-stop night landings).

Merging flights

I've had a couple of requests over the years to be able to merge flights. E.g., if you fly out to lunch and then fly back, you might record that as two flights and then decide you want them to be one. (For that, "Pause/Play" in the apps actually works pretty well, but if you take a multi-day trip, no so much due to battery consumption).

This is inherently a potentially destructive operation: for example,some fields can't be merged, or at least not in an obvious way. A good example of this is the "Fuel remaining at landing" property - if you have this set for multiple flights, there's no way to resolve that. But it should capture most of the data in an "intelligent" way: adding values that can be added, concatenating the route/comment, and concatenating (to the degree possible) flight telemetry. (If the telemetry formats don't match, the resulting data will only have the common subset, so this too is destructive).

It's also a bit of a corner case of functionality, so I'm not integrating this into the core UI. Instead, I'm putting it into my "playpen" area. Stuff in the playpen is functional, but not as thoroughly tested and without the same fit-and-finish as the main parts of the site.

The tool is here if you want to try it out, but be aware: there IS NO UNDO, and all but one of the merged flights will be deleted (the earliest of the flights is preserved as the "target" of the merge). So it's not a bad idea to make sure you have a backup of any flights, images, and telemetry before you merge flights.

Note that if you simply want to merge telemetry files, there is a separate tool, also in the playpen, where you can do this. Since this is not dependent on your logbook, it is safe to use, you cannot lose data. The output is GPX, so any flight path should be preserved, but other data that is in your input will not be present in the output.

Float planes and amphibs

Float and amphibious planes are an odd duck (if you'll pardon the metaphor) of aviation because they are one of the only cases where an airplane can change category/class, sometimes in flight.  In particular, many float planes spend one season on wheels and another season on floats.

I'll defer to you, the pilot, for how to log a flight in an amphib that begins on water and ends on land, or vice versa.  When in the air, it certainly doesn't seem like it would matter, though many pilots will use the primary certification of the aircraft for the overall time.  But surely sometimes the flight is ASES/AMES and sometimes ASEL/AMEL, especially for landings.

There are a couple of ways to handle this on MyFlightbook.

For the case of an aircraft that is seasonal, I'd recommend cloning it.  You can generally do this yourself by simply editing the aircraft's model to be the alternative model.  E.g., from a C-172 P to a C-172  (Float); the system will recognize the change and create a new version of the plane.  You will then have the option to add the other version of the plane to your logbook, and both versions will then be available to you.  You may further choose to activate one version for the summer and deactivate the other, and reverse that in the winter, to make it easier to select the correct version for a given flight.  Contact me if you need help doing this with an aircraft.

If the aircraft is primarily on land or primarily on water, then I generally recommend entering it into the system according to its primary mode.  Then, if you have a flight that you want to record in the exceptional category/class, you can override it on a flight-by-flight basis.  E.g., if most of your flights are entirely on water, then you'd enter the aircraft as a seaplane, and then override the category class to be ASEL/AMEL for the occassional tarmac-to-tarmac flight. 

You need to do this on the website.  Beneath where you select the aircraft, click on "Show Alternate Category/Class":

 

This will reveal a drop-down from which you can choose the category/class you want for this flight:

Yes, I suppose you could identify it as a Glider (lost an engine, perhaps?), but generally you'll probably just be switching between SEL/MEL and SES/MES.

My advice, then, if you're landing a floatplane on land or if you're landing an amphib categorized as ASES on water, would be to log two entries: one as SEL/MEL for the portion or attributes that you want to credit towards SEL/MEL time, and one for the portion or attributes you want to credit to SES/MES time.  

So, for example, if you want to count your 1-hour amphib flight as SES time, but you landed on pavement so want that to credit towards SEL time, you could log an hour of time in the amphib in one entry using an SES category/class and with no landings, and log a separate entry with no time but with your pavement landings.  It's a little bit clunky, I admit, but it's also powerful because this applies to any/all attributes, not just landings.

Social Media

Social media has evolved considerably since I started MyFlightbook in 2006.  Facebook had only just begun to be open to people outside of universities.

Since at least early 2010, MyFlightbook has supported the use of a technology called "oAuth" to post to Facebook and to Twitter on your behalf.  The idea behind oAuth is it allows a user of two web services to give one permission to perform operations on the other without the user's involvement.  In other words, you could tell Facebook or Twitter to allow MyFlightbook to post to your Facebook/Twitter feed.  OAuth provided a secure way to do this, that would constrain what MyFlightbook could and couldn't do, and would let you revoke those permissions at any time.  MyFlightbook also uses oAuth for cloud storage integration - allowing you to back up to DropBox, OneDrive, or Google Drive.

The advantage of this is precisely that this can happen without the user.  Backing up your logbook to Dropbox can happen in the middle of the night while you sleep.  In the case of social media, you could check a box and your flight would be posted to your Twitter or Facebook feed as a side-effect of saving a flight.

Today I'm announcing the retirement of this functionality.

While not the biggest reason, the most immediate reason, is, to be honest, frustration with Facebook's developer app review process and their utter lack of responsiveness to questions. They are changing their policies as of Aug 1, and in reviewing MyFlightbook, they are making demands that are not appropriate for the functionality I want to provide. Plus, the functionality has always suffered from the time-expiration of authorization, so after a while, your post-as-side-effect-of-saving fails. (Twitter, interestingly, has worked flawlessly and seamlessly for 7 years or so now...)

And looking at the stats, fewer than 1% of you have authorized FB on the site, and fewer than 0.3% have authorized Twitter.

And this functionality is long in the tooth anyhow. You've always been able to manually post a flight (along with a comment that you edit) using the web, and that functionality continues.

Interestingly, the main benefit to the post-as-a-side-effect-of-saving functionality was actually on the mobile apps, where in 2010 most people did not have the Facebook or Twitter app on their phone (and even if they did, inter-app communication was very limited). But now everybody does, along with a bunch of other social networks (Instagram, WhatsApp, etc., though strangely Google Plus seems to be following Windows Phone's market share trajectory...)

For this reason, the latest updates to the Android and iOS apps have removed the checkboxes, and replaced it with functionality that allows you to (manually) share a flight to...any app you like, be it Twitter, Facebook, Email, WhatsApp, or whatever else comes along

Today I am removing the corresponding "checkbox side effect" functionality from the web.  The web will continue to have "Share to Facebook" and "Share to Twitter", and of course you can always manually copy the link out of the browser window and share it wherever you like.  Generally, the link you want to share is the "ViewPublicFlight.aspx" link that you get if you click on the route of flight in the main logbook listing.

Part 117 Support

FAR 117  covers requirements for crew rest.  MyFlightbook supports it and will display your status with respect to 117 in currency if you like.  To use this, you must first turn on the option for Part 117 currency on the website by going to "Preferences" under the "Profile" tab, expanding the "Currency/Totals" section, and checking the option to track Part 117 status.

There's a lot in this reg, but 117.23(b)/(c), which concern flight time and flight duty periods, and 117.25(b), which concerns rest periods, are what MyFlightbook currently tracks.  (MyFlightbook does not currently track 117.25(c)/(d)/(e)).

There are three concepts (defined in 117.3) that are most relevant here:

• Duty means any task that a flightcrew member performs as required by the certificate holder, including but not limited to flight duty period, flight duty, pre- and post-flight duties, administrative work, training, deadhead transportation, aircraft positioning on the ground, aircraft loading, and aircraft servicing.  
• Flight duty period (FDP) means a period that begins when a flightcrew member is required to report for duty with the intention of conducting a flight, a series of flights, or positioning or ferrying flights, and ends when the aircraft is parked after the last flight and there is no intention for further aircraft movement by the same flightcrew member. A flight duty period includes the duties performed by the flightcrew member on behalf of the certificate holder that occur before a flight segment or between flight segments without a required intervening rest period. Examples of tasks that are part of the flight duty period include deadhead transportation, training conducted in an aircraft or flight simulator, and airport/standby reserve, if the above tasks occur before a flight segment or between flight segments without an intervening required rest period. 
• Rest period means a continuous period determined prospectively during which the flightcrew member is free from all restraint by the certificate holder, including freedom from present responsibility for work should the occasion arise.

Or, more succinctly: Rest is considered to be any time that is neither in an FDP or otherwise designated as duty time.

There are 4 properties that you must use for Part 117 status to be computed and displayed:

• Flight Duty Period Start (UTC)
• Flight Duty Period End (UTC)
• Duty Time Start (UTC)
• Duty Time End (UTC)

The first two properties indicate the start and end of an FDP.  The second pair of properties are used to denote additional duty period, other than flight duty period, that may needs to be blocked off from rest periods.  As noted by the "(UTC)" suffix, these are all assumed to be in UTC.  Note that any time within an FDP is already duty time, so use of duty time start/stop within an FDP is redundant.

In MyFlightbook, an FDP can be declared in a single flight, or it can be declared to start in one flight and end in another flight.  Duty times (other than FDP) will typically start before an FDP starts and end after an FDP ends, but it's possible to have a duty period without any FDP (e.g., for required training), so for that it would make sense to enter a single empty flight that declares a duty period with no corresponding flight period (and, since no flying was performed, zero for all flight times as well).

The following three scenarios illustrate the typical ways you record these times:

Scenario 1: multiple flights in an FDP

• Flight 1: Duty start 14:20 FDP Start 15:10
• Flight 2: ...
• Flight 3: ...
• Flight 4: FDP end 21:18, Duty end 21:45

In this scenario, your FDP is 6:08 (from 15:10 to 21:18), and 7:25 (from 14:20 to 21:45) is excluded from rest.

Scenario 1a: multiple flights in an FDP, duty time at only one end

• Flight 1: FDP Start 15:10
• Flight 2: ...
• Flight 3: ...
• Flight 4: FDP end 21:18, Duty end 21:45

This is the same as above, but only 6:35 is excluded from rest (from 15:10 to 21:45).

Scenario 2: single flight in an FDP

• Flight 1:  Duty start 14:20, FDP start 15:10, FDP End 21:45, Duty End 21:45

As above, the Duty Start/End at either end is optional; the FDP time will denote the end of a rest exclusion in this scenario.

Scenario 3: no FDP, just duty time (e.g., for training)

• Flight 1: Duty start 14:20, Duty End 21:45

Note: you can record FDP without additional duty time; if you do so, your 117.25(b) computation may overstate how much rest you've had.

117.23(c) requires determining flight duty time.  If a flight does not specify any duty time, specifies an invalid duty time (e.g., end before start), or is not otherwise not bracketed by an FDP start/end, then MyFlightbook conservatively blocks off the entire 24 hour period containing that flight as FDP.  So it is a good idea to record FDP's if you want this to be accurate.  However, some personal/recreational flying may be excluded from FDP limits; there is an option (in Preferences) to exclude flights that are outside of declared FDP's from part 117 computations.

If you use these properties to record your duty time and FDP, MyFlightbook should report the following in your currency:

• 117.23(b)(1) - How many flight hours you have in the preceding 672 (limit of 100).
• 117.23(b)(2) - How many flight hours you have in 365 calendar days (limit of 1,000)
• 117.23(c)(1) - How much FDP you've had in 168 hours (limit of 60)
• 117.23(c)(2) - How much FDP you've had in 672 hours (limit 190)
• 117.25(b) - have you had a 30-consecutive-hour period in the past 168 hours?
• 117 (general) - if you are currently in a rest period, how much time has elapsed since it began?