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.

Tuesday, July 24, 2018

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.  But surely sometimes the flight is ASES/AMES and sometimes ASEL/AMEL

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.


Thursday, July 19, 2018

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.

Wednesday, July 18, 2018

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?

Saturday, July 7, 2018

Technically Advanced Airplanes (Aircraft)

I need some help from all of you. I've just implemented support for "TAA" ("Technically Advanced Airplanes") in anticipation of the new rules regarding commercial training that take effect in August. I'm building off of the existing "glass" definition, which can be defined either in the model (e.g., a Boeing 787 is always glass, no example of a 787 has ever had steam gauges), or at the individual aircraft level (e.g., a C-172S may have come from the factory with glass or with steam gauges, even though almost nobody ever got steam, or a specific aircraft may have been upgraded).

While "glass" to my knowledge has never been formally defined (except perhaps to mean "no six-pack"), the new 61.129(j) does define it. Specifically, to be TAA, you must have:
  1. A continuously visible PFD
  2. A continuously visible MFD with moving map that shows the aircraft's position, and
  3. An integrated autopilot that is capable of 2-axis control
(I suppose the FAA also uses "Airplane" for the second "A" of "TAA", not "Aircraft", so perhaps it must also be an airplane? For now I'm going to allow it to apply to any aircraft...)

The way I see this, I'm mapping the existing "Glass" definition to any aircraft with a PFD, such as the Piper Cub in which I did my seaplane rating (i.e., "a" above); aircraft that meet the tighter definition (i.e., including (b) and (c) above) need to be flagged as such, ideally at the model level, but only if it's impossible to get the model in other than the TAA configuration. So again, a B787 is always TAA, and I *think* a Cirrus SR-22 is also TAA, but I'm not sure if a first-generation SR-20 would be (because I don't know if the autopilot was standard).

So if you can help me by updating any models that can only ever be TAA - per the definition above - that will help a lot, because when the model is so defined, all of its aircraft come along for the ride. (I've already mapped all jets that are glass-only because I can't imagine they had a PFD but no MFD/autopilot. But, say, Cessna Caravans? I've seen them without autopilots...)

And if you have an aircraft where TAA was either a factory option or something you did after market, then please leave the model alone but go ahead and update your aircraft to indicate that it is TAA. Note that if you did an upgrade after-market, you can also add the date of the upgrade and the system will treat flights in that aircraft as being TAA after that date and non-TAA before that date.

Friday, July 6, 2018

Recent FAA Revisions

Finally got around to reviewing the recent finalized changes to the FARs.  Lots and lots of stuff in there, particularly around ATDs, FTDs, and Full Flight Simulators, but it looks like the impacts on MyFlightbook and MyFlightbook users will be essentially limited to two areas.

The first is the change to 61.57(c) (Instrument currency).  This is an area that I've complained about for a while, because the changes introduced here a few years ago in an attempt to make them more flexible actually had the opposite result: 61.57(c)(4), which was supposed to allow mix-and-match of aircraft and training devices actually made it so that you had to do approaches and holding in an aircraft, and ATD, AND a full-simulator or FTD.  And 61.57(c)(5) was a complete superset of 61.57(c)(2), rendering it utterly pointless.

The new rule, in summary, now reads pretty simply: 61.57(c)(1) now says you need to do 6 approaches and holding within the preceding 6 months (yeah, yeah, and intercepting/tracking too), and (c)(2) explicitly says that you can do (c)(1) in whatever combination of aircraft, ATD, FTD, or Full Simulator you like.  Much simpler, much more in line with what I'm sure was the original intent.  And super easy to implement (and to reverse engineer how MyFlightbook arrives at a particular IFR expiration date).

This rule is effective on November 26; I'm coding up MyFlightbook to automatically cut over to the new rules on that day.

The updates clarify the definitions of what counts as an ATD/FTD/FFS, but this doesn't result in any changes to MyFlightbook, since I've always simply relied on you to tell the system what a device is certified as.  The updates also say that you don't need an instructor while using a training device to maintain curency.  This is very welcome news!  It also, though, does not impact MyFlightbook because it's always been something "out of band" - you had to do it in order to log it, but there was nothing to enforce in the logging process itself.

The other change that may have a noticeable impact on Myflightbook is the new rules for training towards a complex rating.  Specifically, 61.129(a)(3)(ii) now says that in addition to complex or turbine aircraft, you can count time in a technically advanced airplane (TAA) towards the 10 hours of complex time, and it also removes the requirement for seaplanes to be in a complex seaplane (i.e., a complex or turbine or TAA seaplane can now count toward the seaplane requirement).

Two interesting artifacts here:
  • You can apply time in a complex multi-engine airplane towards the SEL commercial rating requirement (that's actually unchanged)
  • Both the MEL and MES ratings do NOT adopt the TAA option; these must still be complex.
The regs also now provide a formal definition of "TAA", which essentially comprises three things:
  • A continuously visible PFD (i.e., replacing the "6-pack")
  • A continuously visible MFD (i.e., GPS with moving map, showing your position)
  • An autopilot capable of 2-axis control, integrated with navigation and guidance.
While I do have the notion of glass models (steam gauges never an option) and glass aircraft (may be the result of an upgrade), this is not a level of detail that I currently support on the system.  I am coding up my commercial ratings progress to account for TAA, but at the moment I have no way to determine if a given aircraft qualifies, so essentially all aircraft are not TAA (and thus you must have complex or turbine)...for now.  I'll need to address this, but it does mean that you'll probably need to update your aircraft to indicate whether or not it is TAA.  Also note that since the TAA substitution is only for commercial SEL, and it really only applies to piston aircraft (since turbine counts towards the requirement), I really only need to do a TAA option for single-engine piston aircraft.

The TAA definition and the use of TAA towards SEL commercial ratings goes live on Aug 27; I am coding this so that MyFlightbook cuts over on that date.

Interestingly, one of the biggest changes doesn't actually impact MyFlightbook: the 

Most of the other changes fall into one of the following three categories, none of which directly affect MyFlightbook functionality:
  • Operational rules - i.e., you need to have a certain rating to perform a certain operation, or have a certified instructor or PIC in the cockpit with you, etc.
  • Definitional rules - like the aforementioned definitions of ATD/FTD/FFS.
  • Experience Substitutions - for example, for ATP ratings there are new options for credit towards flying experience that you can use based on previous military or flight engineer experience.  MyFlightbook has not supported these alternatives historically because it doesn't generally have access to enough information to do so; as a result, these changes don't really impact MyFlightbook.
  • Renumbering.  E.g., with the (welcome) deletion of 61.57(c)(3)-(5), 61.57(c)(6) (Glider IFR currency) is now 61.57(c)(3). 

Friday, June 1, 2018

Achievements

One of the fun things about an electronic logbook is that it provides an opportunity to do analysis that is difficult or impossible to do with paper logbooks.  Of course, there's the usual compliance-oriented reporting, but many of us fly for fun, so why not inject some fun into our logbooks as well?

MyFlightbook awards badges for achieving flying milestones, such as accumulating a certain number of hours of a particular sort of flying, or hitting various training milestones, or ...., well, or what? 

I'm often asked for a full list of what badges are available.  While the code is open source so anybody can look at it, I generally decline to provide an answer.  I think the fun of it is precisely in stumbling across achievements that you hadn't even thought about.  The idea is to model this after video games when shooting the 1,000th bad guy or otherwise demonstrating some new skill or achievement earns you a medal or a new weapon or new spell-casting ability or somesuch.

As I think of new badges, I add them (and I'm always open to suggestions). 

So I suggest people simply fly and see what badges they earn!

Saturday, May 5, 2018

Security of passwords

Thanks to Twitter, I had to spend about an hour yesterday changing various similar passwords on a whole slew of sites. While a pain in the neck, probably wasn't a bad thing for me to do.

You may wonder if MyFlightbook suffers the same problem. The answer is "no."

I'll get into some more technical details at this point, so everything that follows is really only interesting if you care about such arcana.

Like Twitter (and industry standard), passwords on MyFlightbook are "hashed" before being saved into the database. That is, a one-way encryption operation is performed, which is mathematically non-reversible.  (Generally this involves "salting", which adds data to the password, and other one-way mathematical functions from which you can't derive the inputs given the output.  In MyFlightbook's case, I use the HMAC SHA1 hash.) 

The result of this operation is what's stored in the database; your password is NOT recorded anywhere on the website.  This is why if you lose your password, I can reset it for you, but I cannot recover it for you.

When you sign in, I perform the same operation on the password that you provide and compare the result from that with what's in the database to see if it's a match. Twitter's bug was that they logged the password in a file somewhere before doing the hash; MyFlightbook doesn't ever store this.

The mobile apps (iOS and Android) are slightly different in that they do keep your password on the device; they do this in order to periodically re-authenticate on your behalf, or to sign-in to the website.  On these devices, however, the operating system provides a secure/encrypted "sandbox" in which the app plays.  In other words, if somebody had a hack that could penetrate into the sandbox, then access your MyFlightbook password would be the least of your problems.

For most operations, the mobile apps do not need to send the password to the server.  Instead, when you authenticate, they provide your email/password to the server, which then sends back a "token" that says "you're authenticated."  Subsequent operations like uploading flights or retrieving totals then pass that token to the server, which accepts it as proof of identity.  The apps periodically refresh their tokens.

It's important to note that ALL communication that includes a password is always over a secure channel (https), whether this is using the web site or a mobile app.  This ensures that your password cannot be sniffed.

There are some places where the mobile apps need to send you to the website, and must authenticate you in doing so.  In these cases, it passes your email and password to the website over a secure channel, which then redirects you (removing the password) to the requested page.  For example, if you are using the mobile app and want to view your progress towards a given rating, the app will pass your email and password to the website, which will authenticate you and then switch over to the Ratings Progress page, stripping your email/password.  All of this is over https, so stripping it is unnecessary to avoid snooping, but stripping it also means that it won't be exposed in the URL of the page being viewed.