Tuesday, January 22, 2019

Printing from an electronic logbook and traditional "paper" logbooks

A few months ago, I had a blog post about printing from MyFlightbook.

I had a Facebook conversation with a pilot today about why sometimes the per-page subtotals spill onto an additional page, consuming extra paper and occasionally leaving swaths of blank space on a page.

The question he asked was twofold: (a) why do I have the extra clutter of having additional category/class rows in the per-page subtotals, and (b) why can't I reliably keep a page's flights the subtotals for that page actually on a single printed page?  Specifically: "is the challenge regarding the coding of it?"

It's a perfectly legitimate question, and I realize my earlier post may not have sufficiently or clearly explained that, so I decided to dive in and answer in a bit more depth, which I'm reproducing below (lightly edited for clarity, to remove typos, and to translate from Facebook format):

First: why do my per-page subtotals subdivide by category/class?

Paper logbooks put each category/class into their own columns. This makes sense for exactly one reason - allowing you to compute category/class totals by hand. You can't do (easy) hand summation if category/classes are co-mingled in a single column. (Of course, computers don't care, that works just fine).

But there are two really bad tradeoffs for doing this: one is that columns don't scale well at all. So if you've got some ASEL time, some ASES time, some AMEL time, some glider time, some balloon time, some helicopter time, ...well, now when you go to print you have a 2-dimensional problem: each flight of your logbook needs to spill over across two horizontal pages (Or, columns need to narrow, which means everything needs to grow vertically and becomes really hard to read!!!).

The other really bad tradeoff is that it effectively means you need to limit the number of category/classes you support. This is why most paper logbooks are focused on JUST airplanes, or JUST gliders, and might have only one column for "other".

Those are bad - but necessary - tradeoffs in the paper world. But in the electronic world, these are simply terrible tradeoffs, especially since the exact problem that they're trying to solve (aiding human computation of totals) doesn't exist once computers are can do the math.

So if you did this in the electronic world, you'd get all the downside with none of the upside. That seems utterly ridiculous.

For this reason, I striped the per-page subtotals by category/class because adding rows works great (stays within the flow of reading from page to page) but adding columns doesn't.

So - why can't I do a better job of keeping things on a page, from occasionally spilling on a page?

I'll back up for a moment to another problem with paper: the form in the paper world is sized and printed before any content is added. I.e., the layout is fixed. So you have three choices when you fill in oversized data:
  • You can "spill over", with one flight spanning more than one row of the paper page;
  • You can "clip" your data - stopping when you hit the boundary of the flight's row and discarding what didn't fit;
  • Or you can "shrink to fit", making the text smaller and smaller until it fits the allotted space.
All of those are truly terrible solutions, but with paper, they are the only options; you can only choose the least evil.

In the electronic world, however, that ridiculous constraint is removed: the row can shrink or grow to accommodate the data. i.e., each row can be a unique height that is appropriate for the data contained therein.

So...your question was "is the challenge regarding the coding of it." At one level, the answer is "no, it's not complicated".

What you would do in this scenario is add a flight to the page, compute the subtotals for the page,  add those subtotals to the page as well, and see if it fits. Then repeat for the next flight. If the flight you add causes the subtotals to spill to the next page, then back up to where you were just prior to adding the flight, finish off that page, then start a new page with the new flight. There are a few other issues, but at the core, that's the process and it's straightforward.

Here we get to an architectural issue. MyFlightbook uses an abstract layout methodology (HTML). So I say "here's a row of a table; it has these cells and each cell contains this text." MyFlightbook doesn't know anything about fonts, font sizes, pixels, word wrapping, page margins, page dimensions, screen or printer resolutions, or a whole slew of other things that are required in order to figure out what to draw on a page. That is all handled on the web by the browser (which takes the HTML and converts it into stuff on a screen), or by the PDF generator that I use, which does the exact same thing as a browser, except that instead of drawing on the screen it draws into a PDF file.

So I can't implement the algorithm I described above (add a row, see if it fits, if not, start a new page). That is, I have to render the entire page in HTML, and THEN either send it to you so that your browser can render it to the screen, or send it to the PDF generator so that I can send you a PDF file. There's no ability to have the back-and-forth interaction that such an algorithm requires.

The ONLY way to solve that is to build an entire rendering engine - something that DOES know how to measure things, lay them out on the screen, perform word wrapping, make tables fit their contents (itself actually a really hard problem). I.e., I would quite literally need to re-implement most of what a browser does.

But I think about the herculean effort that represents (much bigger than all of MyFlightbook combined - and MyFlightbook actually isn't a small piece of code!), and I step back and ask "what problem would this solve?"

The answer is simple: per-page subtotals. That's it. No other purpose whatsoever is served.

And what makes per-page subtotals so important? Paper tradition. Per page subtotals serve exactly one purpose: if you're doing manual computation, you don't want to go back to the start of your logbook every time you want to compute your totals; that's ridiculous with a pen and paper. But in the electronic world, computers don't complain about doing that. So per-page sub-totals are an insane holdover from paper-and-pencil human arithmetic. Why on earth let an artifact of the 14th century drive such a massive software undertaking?

So in summary, the correct answer to the question "is the challenge regarding the coding of it", the answer is "yes. It would require literally thousands of man years of effort to actually solve an obsolete problem."

My suggestion? Turn off per-page subtotals. They are truly utterly pointless. "Continuous" mode will make much more efficient use of your paper and will still get the math right because computers don't make math mistakes. And your pagination will work great.

Declutter your life and your logbook

Marie Kondo is a surprise hit on Netflix, with her advice about getting rid of things in your life that no longer bring you joy.

Why not declutter your logbook in the same way?

After a few years of flying, you may find that your totals or currency get filled with all sorts of data that you have accumulated but about which you no longer need to be reminded on a continual basis.

MyFlightbook has options that can help.  Interestingly, MyFlightbook has no preconceived list of possible items to include in totals or in currency.  Instead, the system computes totals of all things that can be totaled and computes all currencies that could apply to your flying.  As a first stage of decluttering, the system then prunes away any total that is 0 and any currency that was never achieved.  But that can still leave a lot of "noise" values.

There are multiple options on the site that can further reduce clutter; most can be found in "Preferences" under the "Profile" tab.

Probably the easiest clutter to remove is expired currencies.  If you're an active pilot, you obviously want to know when your currency expires for any of the flying that you do on a regular basis.  But suppose that (like me) you once took a single lesson in a helicopter, in which you did 3 takeoffs/landings.  That was enough to make you current per 61.57(a), but you never pursued your rating nor do you intend to.  That expired currency is just clutter - remove it.

You can specify how long expired currency should show as follows:

And thus that meaningless expired currency will no longer crowd out your more meaningful ones.

Next on the list of clutter to remove is properties that can contribute to totals, but which aren't terribly meaningful.  By default, any property that can be counted (e.g., number of ILS approaches) or that is a time (e.g., safety pilot time) is included in totals.  But a good example of properties you might not care to track is maneuvers that you might have logged while training for a rating, but which you otherwise don't perform any more.
All of the properties you have ever used on a flight are in one of the two boxes above.  You can drag-and-drop from one to the other.  Properties on the left are "active" - ones that you use on a regular basis.  The ones on the right are inactive; by designating them as such you get two clutter-reducing benefits: 
  • These properties are not shown by default on the screen for entering new flights (but they are still available for you to use if the need arises)
  • Sums of these (such as the number of 180-degree power off accuracy landings or NDB approaches, in my example above) will not be included in your totals
One of the questions I am most frequently asked is how to log complex time.  The answer, of course, is that you don't: this is computed for you automatically, and displayed in totals.  There are actually a fair number of such totals that can show up in this manner: Turbine, Tailwheel, Complex, High Performance, and Retract (that isn't complex), and for each of these, there is total time, PIC time, and SIC time.  While any of these that are zero are pruned automatically, that's potentially 15 different items showing up in your totals!

You can turn these off under "Currency/Totals":

There's one more item that can reduce clutter in totals, and this starts to bleed over into reducing clutter in your overall logbook display.  MyFlightbook can record hobbs start/stop, engine start/stop, and flight start/stop automatically.  (You can also do tach time and block time, but these can't be detected by the mobile apps and are in the list of additional flight properties, whereas hobbs/flight/engine are "baked in" to the core flight).  

If a flight has both ends of hobbs, flight, or engine defined, and they are in the correct order (i.e., hobbs end is larger than hobbs start), then the elapsed hobbs/flight/engine time for that flight will accrue to a total elapsed hobbs/flight/engine time in your totals.

This is off by default (so is pre-de-cluttered?), but you can control it under flight entry:
This has three clutter-controlling aspects: 
  • It controls whether or not totals include total elapsed hobbs/flight/engine time;
  • It controls whether the "times and telemetry" section of the New Flight form is expanded by default; and
  • It controls whether hobbs/engine/flight times are displayed by default in your list of flights
There are two other options above - CFI time and SIC time.  These are two additional "baked in" attributes of a flight (since they are available in just about every paper logbook...ever), and they're fields that a large percentage of pilots will use, but which any individual pilot either uses frequently or never uses.  For this reason you can turn these off/on as well.  This impacts whether the CFI and SIC fields show for new flights, and whether or not columns for them are shown by default in the list of your flights.  It does not affect the display of any non-zero CFI or SIC totals.

This leads naturally to some clutter-reducing tips for the display of your flights.

You may have noticed that next to the count of your flights is a drop-arrow.  If you click that, you can see some options for controlling the display:

Showing in pages vs. all of your flights isn't about clutter as much as it is about scrolling and performance (both network and browser), but it can be a nice option if you don't want to go page-by-page through your logbook.

But the compact view and the option to show images in-line are both great ways to control clutter in your display.

The compact view simply collapses each flight to a single line, consisting of date/route/comments.  You can click to expand the flight to see more details.

Images are, by default, decluttered, in that you have to hover your mouse over a camera icon to view them.  But if you prefer to have them show without moving the mouse, you can turn on this option to see the images directly.

Finally, I'll leave you with a clutter-reducing tip for your aircraft.  If you look next to each aircraft in your aircraft list, you'll see a drop-arrow there.  Click it, and you can designate the aircraft as active or inactive:

(You can also designate an aircraft as active/inactive using the Android or iOS app; tap the aircraft and you'll see the option; don't forget to update the aircraft to save your change!)

Active aircraft show up in the list of aircraft available for new flights, and show up on the search form; inactive aircraft do not.  If you've flown a lot of aircraft over the years but are currently flying just a few, this can greatly simplify your life.

So whether or not you follow Kondo's advice in your life on the ground, I hope you can reduce the clutter in your logbook!

Sunday, December 23, 2018

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.

Monday, November 26, 2018

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)mv2 (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)mv2, 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 mv2) 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.

Saturday, November 17, 2018

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.

Sunday, September 16, 2018

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 two 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".
  • 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.

Monday, August 27, 2018

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

Tuesday, July 31, 2018

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.

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.