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.


Friday, May 4, 2018

Change to commercial checkrides

The FAA has removed the requirement that applicants for a commercial rating provide a complex or turbine aircraft for their checkride.

Lots of good commentary on this elsewhere on the web, but I'll focus on its implications for MyFlightbook here.

MyFlightbook has never enforced this requirement on the checkride itself.  It simply assumes that if you marked the flight as having been a commercial checkride, that in fact it was and that you passed.  (If you managed to do so without having a complex aircraft prior to this rule change, then your DPE probably should no longer be allowed to conduct checkrides!).

The main place where this affects MyFlightbook is in your progress towards your commercial rating.  Specifically, 61.129(a/b)(3)(ii) requires 10 hours of complex (or turbine) training.  MyFlightbook does enforce this in computing your progress.

The removal of the checkride requirement explicitly states that "there is no change ... to the commercial pilot aeronautical experience requirements of § 61.129(a)(3)(ii) or part 141 appendix D." 

This is interesting because it only slightly reduces the cost burden to getting a commercial rating - instead of 10hrs + checkride in a complex aircraft, you now only need 10hrs, which, if access is to the aircraft is a challenge is also only marginally easier.

But from a logbook perspective, it means that there is essentially no change.  You still need the 10 hours of complex/turbine training, and MyFlightbook will still look for it.

Friday, March 30, 2018

What's with these "flight properties"?



All pilots keep logbooks, but the sorts of things that they want to log vary greatly from pilot to pilot.  If you were to draw this as a very simplified Venn diagram for the logbook requirements for only three such groups, it might look like this:




Of course, there are many more groups than these three, and there are subgroups within them.  Instrument rated pilots log stuff that VFR-only pilots do not; helicopter pilots have their maneuvers to record, and seaplane pilots have others; students working towards a rating have yet other experiences to record.

See that small piece where all three overlap?  These are the "Core" fields that all pilots might need to record on any given flight.  These include the familiar fields like Night, IMC, Dual, PIC, and Total time.  These are attributes that apply to pretty much any flight by pretty much any pilot.  This is why they are on the main flight form for MyFlightbook.

The set of things that somebody might want to record outside of those core fields currently (as of March 2018) numbers about 600, from Aerobatic Time to Zero-visibility Takeoffs.  This is a huge set of potential fields, and as the diagram above illustrates, any given pilot will typically use only a small subset of them.

For this reason, I've designed flight entries on MyFlightbook to have the concept of "properties" that you can attach to a flight.  Yeah, I suppose the terminology is a bit geeky (it does come from computer science), but it's "property" as in "attribute," as in "a property of this flight is that it included Aerobatic time."  Think of them as ornaments that you can attach to a flight.

The benefit to this architecture is that it allows your flights to efficiently use the subset of properties that match your flying, without cluttering things up (either on the screen or in the database) with things you'll never need. 

Specifically:

  • All previously-used properties are available to you, either on the new flight form (website) or at the top of the list of properties (mobile apps).
  • On the mobile apps, you can press-and-hold a property to make it stick to the new flight screen for quick access.  (Press and hold again to remove it).  On the website, where the assumption of more real estate means they can be displayed there automatically, you can control whether or not they show up on the Preferences screen.
  • When you download a backup of your flights, a column is provided for each of the core fields, and also for each of the properties that you have ever used, but no column is provided for properties that you have never used.
Another advantage of the property architecture is that I can add new ones whenever I like, and doing so doesn't require a database or code change. 

People often ask me for new properties specific to their flying.  Sometimes the request is for something that could be just as easily handled with a note in the comments.  But other times, a new property is in order.

Here is the rough criteria I apply on deciding whether (or how) to honor the request for a new property:

  • Is this something needs to accumulate in totals (e.g., time in a particular capacity, such as being a safety pilot)?
  • Does this have semantics for currency or progress towards a rating?  Examples might include a checkride (resets the flight review requirement), or unusual attitude recoveries (which are necessary for instrument currency in an ATD).
  • Do you need to be able to search for this deterministically?  E.g., you could easily record your charity flying by simply putting "Charity" in the comments for the flight; you could then get your charity totals by searching for "Charity".  But this could yield false positives (e.g., if you have a flight with the comment “flew to my friend’s charity event”) or false negatives (e.g., if you misspelled "charty flight" in the comments).
  • What is the way to add this with the broadest applicability?  E.g., I myself fly for Angel Flight, but I don’t have an “Angel Flight” property – too many possible charities!  Instead, I have a “Charity Flight” property and just put “Angel Flight” in the comments.
  • What are the right semantics for the property?  E.g., "Unusual Attitude Recoveries" could be a count ("I did 4 unusual attitude recoveries on this flight"), a time ("I spent 0.7 hours performing unusual attitude recoveries"), or a true/false ("This flight included unusual attitude recoveries").