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

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

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

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

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

Here are some options:

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

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

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

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

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

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

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

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

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

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

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

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

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

Merging flights

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

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

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

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

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

Float planes and amphibs

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

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

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

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

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

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

 

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

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

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

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

Social Media

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

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

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

Today I'm announcing the retirement of this functionality.

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

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

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

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

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

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

Part 117 Support

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

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

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

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

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

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

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

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

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

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

Scenario 1: multiple flights in an FDP

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

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

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

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

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

Scenario 2: single flight in an FDP

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

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

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

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

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

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

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

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

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.

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