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

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:06 (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"). 

Sunday, November 19, 2017

Signatures and Endorsements

In addition to being a recording of personal experience, a logbook is also a record of training received.  As such, it must enable instructors to sign entries in student logbooks and issue endorsements.
MyFlightbook supports both of these scenarios, using two different paradigms.

  • In the first paradigm, the student and the instructor create a relationship between their accounts, so one appears as the instructor for the other.  Because each account is authenticated to MyFlightbook, and MyFlightbook validates the relationship, I refer to this as an "Authenticated" scenario.  This provides a very secure framework for signed flights and endorsements, but it requires that both parties use MyFlightbook.
  • In the second paradigm, the relationship is a one-off; there is no presumption of any ongoing relationship between the instructor and the student (a common example might be a check-out at an FBO).  This provides more limited functionality, but is very quick to set up.  I refer to this as the "Ad-hoc" scenario.  Because there is no authentication of the instructor in an ad-hoc relationship, this must be done face-to-face.

Endorsements

An endorsement is a sign-off from an instructor that determines the student hes met some criteria.  The key thing about an endorsement is that it is not tied to a specific flight.  Examples of endorsements include solo sign off, high-altitude training, tailwheel sign-off, readiness for a practical test, etc.

A wide variety of templates for common endorsements are in the system, as well as a template for a fully-customized endorsement.

Endorsements require an authenticated relationship between the student and the instructor.  The endorsement can be issued by the instructor by going to the list of their students; they can also view any previously-issued endorsements.

An endorsement, once issued, cannot be edited or deleted.  (After all, neither scenario is generally supported in the physical paper world), although as site admin I can, if needed, wade in and perform endorsement surgery as needed.  Endorsements also cannot be dated too far in the past or in the future, as a security measure.

Signatures

Most training flights result in the instructor signing the student's logbook entry for the flight.  Often, they even fill out the entry.  But one difference between MyFlightbook and a paper logbook is that saving the entry and signing it are separate sequential steps.  The reason for this is so that the signature can sign the flight as it exists in the database, without the possibility of modifying it between signing and saving.

If the instructor wishes to fill in the entry, they can do so.  But just as they can't fill in a student's logbook without the student being there to give it to them, the student must be present with their phone/tablet (or sign in on a website) and hand control over to the instructor.  For security, MyFlightbook does not allow instructors to create arbitrary new entries into a student's logbook.

There are two basic scenarios for how a flight can be signed once it has been saved:
  • In-person.  This requires a phone/tablet running the MyFlightbook app.  The student goes to the Recent Flights list, finds the flight to be signed (typically at the top of the list, if you're signing the flight you just took), and chooses the "Sign" option.  At this point, choose from a list of authenticated instructors or select a new instructor for ad-hoc signing, and then hand their phone/tablet to the instructor.  If it's an authenticated relationship, the instructor provides their password to prove it's them and thus digitally sign the flight; if it's ad-hoc, they can scribble a signature with their finger (which is why it requires a phone/tablet), which serves as the signature.  In either case, the instructors can add comments and, if authenticated, the instructor can cause the signed flight to be copied to their account (minus the signature and with Dual/CFI roles reversed).
  • Remotely.  This requires use of the website, and requires an authenticated relationship.  The student can request that the instructor sign specific flights.  The instructor will receive an email notifying them of the flights to sign, and can use the website to review and sign them.  Or, the student can optionally grant the instructor permission to view their logbook and sign any flights that don't already have a valid signature, as they see fit.
When a flight is signed, MyFlightbook stores a fingerprint of the key fields for the flight so that subsequent edits will invalidate the flight.  Some fields are excluded from this - e.g., it's OK if you change whether the flight is public or private, or to add/remove images.  But changing the comments, number of landings, or times (among other "core" data) will invalidate the signature.  An invalid signature can only be "revalidated" by either requesting that the instructor re-sign it, or by reverting the edit so that the flight's fingerprint matches that of the signature again.

Does the FAA recognize such digital signatures?  They claim to, and they outline the criteria for doing so in FAA circular AC No: 120-78A. I believe MyFlightbook is compliant with this AC, the FAA has thus far not indicated willingness to even evaluate, much less certify, online logbook systems for compliance.

A more in depth explanation of how signatures and endorsements work, along with why I believe MyFlightbook is compliant with AC 120-78A can be found here.

Friday, November 17, 2017

Airports

MyFlightbook's airport data comes from a variety of sources (i.e., "free"), and include codes that can be FAA (3-letter, doesn't generally use the leading "K"), IATA (3-letter, used for airline travel), and ICAO (4-letter).  I don't actually bother storing which kind of code it is, since it's generally obvious from context.

So a given airport can actually be in the database up to 3 times (though it’s pretty rare for that to actually be the case.  Some examples:
  • Kahului, Maui is "OGG" (FAA/IATA) or "PHOG" (ICAO)
  • Frankfurt, Germany, is "FRA" (IATA) or "EDDF" (ICAO)
  • Owyhee Airport (in Oregon) is "10U" (FAA), but (to my knowledge) has no official IATA or ICAO code.
In the US, most airports in the continental US have both ICAO and FAA identifiers, and most of the time, the ICAO is the FAA with a "K" prefix.  E.g., San Francisco International is "SFO" (IATA) and "KSFO" (ICAO).  But it's very often unclear whether a given airport follows this convention.*

For this reason, I treat the leading "K" as optional on any 3-character code. So, if you type “Kxxx” and I don’t have Kxxx but I do have xxx, I’ll match to that (so that “K10U” for the Owyhee example above, or KOGG for Maui, neither of which technically exist, will still work).  Or, conversely, if you type “yyy” and I don’t have yyy but do have kyyy, then I’ll match to that.  Note that this allows ICAO and FAA/IATA codes to co-exist pretty well, which is especially nice since there are some international airports that, but for the initial ICAO character, would match some small airport in Alabama. Indeed, one such example (of many) is Newtonards airport (EGAD, just outside of Belfast) and Northeast Alabama Regional (GAD).

When I autodetect to find the nearest location, I do the following:
  • Look up the closest airports to your position, sorted by that position rounded (slightly – two decimal places of nm) to try to coalesce small differences in distance.  For example, the closest airport may in the database twice with two slightly different coordinates (usually due to coming from two sources that use differing numbers of significant digits).  Note, though, that if the two sets of coordinates for the airport are further apart than the rounding will catch, then "nearest" may differ depending on whether you are on one side of the airport or the other.
  • If multiple airports tie for “closest”, airports can be further disambiguated by a “preferred” flag.  So, for example, Dallas/Ft. Worth is DFW/KDFW, and the “K” version is marked as preferred, so it should be picking that up.
  • Absent a “preferred” flag, I should bias towards the longer identifier (i.e., choose ICAO over FAA or IATA), but this is not implemented today.
A few other useful tidbits that you might want to know about airports:
  • As a logbook (rather than a flight planner), I try to keep old airports around as long as possible, often long after they have either closed or been assigned a new identifier.  
  • For the same reason, there is a strong bias towards airports over navaids, even though navaids are in the database.  But you can reverse the bias with a "@" prefix.  E.g., "BOS" is Boston Logan Airport, but "@BOS" is the Boston VOR.
  • You can add your own airports or navaids to the database.
  • You can also make up ad-hoc latitude/longitude waypoints. Use the form @xxxxxNyyyyyW to specify a latitude/longitude.  E.g., @38.8894N77.0353W is the Washington Monument.  (Obviously, change "N" to "S" or "W" to "E" as needed).  If you use one of the mobile apps, you can press-and-hold the Append-Nearest button (next to the Route field) to append your current location as such a waypoint.

*The latest download of FAA data has nearly 20,000 airports, but only a little more than 2,500 of them appear to have ICAO codes.  So that means more than 85% of US airports do NOT actually follow the Kxxx convention.

Thursday, November 16, 2017

Models and Types on MyFlightbook

Models on MyFlightbook capture a lot of information about an aircraft so that you don't have to log it explicitly.  Capturing this information in the model means that the system can draw a straight line from the tailnumber (registration) of the aircraft you fly to the model of that aircraft has two distinct advantages: (a) you don't have to pointlessly go to the effort of logging information that the system can easily derive, and (b) it avoids errors if you log impossible things, such as multi-engine turbine time in a Piper cub.  After all, for example, A Boeing 737 is inherently multi-engine/turbine (jet)/high-performance, so time in it absolutely should (and does) accrue to your totals in each of those categories.

Models capture several details for an aircraft, including:
  • The name of the model ("C-172 N", for example)
  • The "marketing" name ("Skyhawk" for a C-172, "Dreamliner" for a Boeing 787).  Many (most?) aircraft don't have a separate marketing name, so it's fine to leave this blank.  Good rule of thumb: if it repeats the manufacturer or model name, just leave it blank.
  • The category/class for the model (Airplane Single Engine Land, for a C-172)
  • "Interesting" characteristics, such as whether it is high performance, tailwheel, complex, all-glass (no steam-gauge versions were ever produced), turbine, etc.
All of the  above is used for computing totals and currency, but there's one additional attribute of a model that probably causes more confusion than any other: the "Type" field.

Many pilots, when creating/editing a model repeat the model name here.  Some even put the specific registration/tailnumber of the aircraf they want.  But the "Type" field has a very specific purpose on MyFlightbook: it provides a grouping mechanism for aircraft that require a type rating to fly.

A license generally provides privileges to fly a specific category and class of aircraft*, such as "Airplane, Single Engine Land (ASEL)".  More sophisticated aircraft - typically jets or anything over 12,500lbs - require a type rating to fly.  That is, a specific license to fly that particular model of aircraft.  Furthermore, to be legal to fly it, you have to have recent flight experience in that particular model of aircraft as well.

For example, in the US, 61.57(a) says:
(a)General experience.

(1) Except as provided in paragraph (e) of this section, no person may act as a pilot in command of an aircraft carrying passengers or of an aircraft certificated for more than one pilot flight crewmember unless that person has made at least three takeoffs and three landings within the preceding 90 days, and -
(i) The person acted as the sole manipulator of the flight controls; and
(ii) The required takeoffs and landings were performed in an aircraft of the same category, class, and type (if a type rating is required), and, if the aircraft to be flown is an airplane with a tailwheel, the takeoffs and landings must have been made to a full stop in an airplane with a tailwheel.

So, for example, if you want to fly passengers in a Piper Seneca (a small twin-engine airplane), you merely have to have done three takeoffs + landings in a multi-engine aircraft within the 90 days preceding the flight.  Any multi-engine aircraft will do.

But note the bold-faced wording above.  A 737 requires a type rating, a Piper Seneca does not.  So if you do 3 takeoffs/landings in a 737, you are fine for carrying passengers in a Seneca.  But the reverse is not true: if you do your three takeoffs/landings in a Seneca, you are not OK to carry passengers in the 737.

Enter the "Type" field.  Boeing 737's share a common type rating.  That is, the B737-300 and the B737-900 are interchangeable from a type perspective.  For this reason, all of these models have "B737" in the "Type" field.  Thus, if you do 2 takeoffs/landings in a B737-300 and one in a B737-900, all three takeoffs/landings count towards your 61.57(a) currency and you are current to carry passengers in a B737.

So it's safe to view the "type" field as satisfying the following rules:
  • If a model of aircraft does NOT require a type rating, it should be blank.  Think C-172, Piper Seneca, pretty much any glider, etc.
  • If a model of aircraft requires a type rating, it should have a non-blank value for the "type" field that is shared with other aircraft that share a common type rating.  The Boeing 757 and 767, for example, have a common type rating, so the "type" field for all of the variants of these two aircraft is "B757, B767".
  • If a model of aircraft requires a type rating, the "type" field must be distinct from other aircraft that require a different type rating.  So, for example, the Boeing 737 and the Boeing 747 MUST have different "type" fields, since they require different type ratings.
 Beyond that, there's no real requirement.  There's no inherent reason, for example, that Boeing 737's in the system couldn't have a "type" field of "Fred Flintstone" and Boeing 757's have "Wilma Flinstone", but for the sake of making things consistent and a bit more self explanatory, we generally follow FAA guidelines for "type" designations.  Hence the Boeing 737 has a type designation of "B737", and the Airbus A380 has "A380".

Interestingly (in the US at least), the Robinson R22 and R44 do not technically require a type rating, but the currency requirements effectively mimic a type rating.  For this reason, these two helicopter models have a "type" field of R22 and R44 (respectively).

In any case, when in doubt, just leave this field empty.  I review EVERY new model (or model modification), so I will generally catch issues here.

*In some parts of the world, you effectively need a separate license - or at least sign-off - for each model of aircraft you wish to fly, and currency must be maintained in each such model.  MyFlightbook has an option to support this.


Tuesday, November 7, 2017

Logging landings/takeoffs and approaches

A given landing or takeoff can have many different attributes.  It can be day or night, short-field, soft-field, at a towered airport, on an aircraft carrier.  A landing can be touch-and-go, full-stop, or stop-and-go.  And of course, these attributes are not mutually exclusive: it's certainly possible to do a night short-field full-stop landing on an aircraft carrier with an operating control tower.

In fact, in MyFlightbook, there are over 60 different kinds of landings and over 30 different kinds of takeoffs (and I am periodically adding more).

And we generally want to know how many of each of these we did.

Broadly speaking, there are two approaches one could take to logging landings.  (Everything I discuss below also applies to takeoffs, but for brevity/clarity, I'll just refer to landings from here on.)

The most specific and unambiguous way would be to create an entry for each landing, and in each entry identify all of the relevant attributes.

E.g.:
Landing 1: full-stop, soft-field
Landing 2: stop-and-go, night, short-field, towered airport
...
This has a clear advantage: everything is crystal clear.  But it has two disadvantages: (a) it is harder to answer simple questions like "how many full-stop landings did I do?", since you have to look at each entry and add them up, and (b) the data entry is cumbersome and if you do a flight with multiple landings, you have to remember the details of which ones were which.

Of course, (a) above is easy for a computer, which can just sum up the subtotals and display those to you, but making (b) easy is...hard, since much of it is not something that can be reliably determined automatically.  (Touch-and-go vs. full-stop and day/night are the main things that can be auto-detected).

The simpler way is to accept some ambiguity about which attributes applied to which landings and instead just enter the totals.

E.g.:
4 total landings
1 was a daytime stop-and-go
2 were full-stop night landings
3 were on short fields
2 were at fields with a control tower
...
This is the approach that MyFlightbook takes.  There are a few key things to note above, though:
  • Figuring out things like 61.57(a)/(b) currency becomes a lot easier.  Indeed, in the example above, I can see from above that the 4 total landings reset my general passenger-carrying currency for 61.57(a) in the category/class of the plane, that my (combined) 3 full-stop landings reset my tailwheel currency, and that I need one more night-landing to reset my nighttime currency.  (Assuming, of course, that I've done the requisite takeoffs too...)
  • Note that they don't add up!  The total landing count is just that: the number of times that the wheels(/skis/floats) touched ground; everything else is a subset of that count, and the subsets can overlap.  The important thing is that each total stands on its own.  The only real requirement from a data consistency point of view is that none of the subsets can be greater than the total number of landings for the flight.
The advantage of this, of course, is that the data entry is much cleaner: if you have 5 identical landings, you don't have to create 5 individual landings, you just put in the totals.  After all, it's generally the # of each kind of landing that matters, not which one was which.  And besides, the latter can often be determined from context: if your flight went from ABC to DEF to GHI, you know what kind of runway ABC had, whether DEF had a control tower, and that you ended the flight with a full-stop, not a touch-and-go.

The disadvantage is that there is some inherent ambiguity, and the system can't add things up to determine things like the total number of landings - you have to tell it.

I take a similar approach (pun not intended) for instrument approaches as well.  There are over 40 different kinds of instrument approaches in the system, so if you want to know how many ILS approaches you did vs. RNAV approaches, you can track that.  As with landings, these can also overlap: an approach can be both an ILS approach and hand-flown, for example.  But what matters about approaches from an instrument currency point of view is simply the number of approaches you did on a given flight; if you want to simply describe them in your comments or in the "Approach Description"  property, that's great; you are, after all, supposed to record details about the approach somewhere, but there's no requirement that it be in any "structured" format - free-form text is fine

So it's fine to simply record "3" in the "Approaches" field on a flight where you did 3 approaches, and say "3 ILS 16R at Paine Field" in the comments; whether to explicitly record a property that lets you count how many ILS approaches you did is up to you.

And here I'll let you in on a little tip: you can use an abbreviated notation in the Comments field and MyFlightbook will recognize it as an approach description and translate it into English when you hover the mouse over it.  Use this format:
[#][Approach type][Runway]@[Airport code]
E.g. "3ILS16R@KPAE" means "3 ILS Approaches to runway 16R at KPAE".

If you are using the iOS or Android app, there's a button next to the comments field that brings up a helper to help enter these sorts of descriptions.  When you go back to the flight-entry screen, it will append a description as described above, and optionally even bump up the number of approaches to reflect the newly added description.

Night Flying and MyFlightbook

Flying at night is wonderful fun, and something I don't do nearly enough.

From a logbook perspective, you really only care about whether you are legal to fly at night and how much "night flying" you can log.  There are a few other informational things you might care to log, but these are the most important.

Being current per FAA 61.57(b) to fly at night requires that you have done 3 takeoffs and landings (to a full stop) within the prior 90 days, between one hour after sunset to one hour before sunrise.

It's a surprisingly simple statement, but in a quick read one might miss that there's 2 distinct concepts of night there: "night", and the restricted period between sunrise and sunset.  They're not the same.


You'd think that the definition of night is simply the time between sunset and sunrise, right? Uh, no, that would be too simple.Rather, the FAA defines night as "the time between the end of evening civil twilight and the beginning of morning civil twilight, as published in the Air Almanac, converted to local time".  Which simply begs the question of what the heck "civil twilight" is.  The simple definition of "civil twilight" is when the sun is below the horizon, but by less than 6°.  Simple, right?  So to determine the start/end of civil twilight, you just get out your sextant and look for the sun while it's still below the horizon to measure it's angle and, oh, umm, never mind.

It's not actually that complicated.  Sunrise/sunset are easy to find; pretty much any aviation app (including MyFlightbook) can tell you sunrise/sunset at a given location.  Take that time span and restrict it by an hour at both ends and that tells you when you can do your takeoffs/landings to satisfy your 61.57(b) recent flight experience.

"Night" is, of course, trickier, since civil twilight isn't reported in many places and you can't see it.  It's generally fine to guesstimate it and use 20-30 minutes after sunset/before sunrise as the cutoff points.

You can also use a tool on MyFlightbook that I've developed. It's a bit rough because it's meant as a debugging tool rather than as a full product feature, but you can click anyplace on earth and specify a date and you can get the times for sunrise/sunset at that location on that day, as well as a map of 24 hours showing the sun's angle against the horizon (in 5-minute increments), enabling you to see when civil twilight begins/ends, and when the 1-hour window begins/ends.

But there's a simpler way on both: if you use the MyFlightbook app on iOS or Android, and have it autodetect takeoffs/landings, it will figure out all of this for you and fill it all in on your behalf, both landings and night time.  Or, if you use the web site and have a time-stamped GPS track of your flight (such as GPX/KML or a variety of other formats), you can press "Autofill" and the system will figure this all out for you.  This will use the correct measurements of night for you.

So now you've logged your night flying.  How do you log your day flying?  You may have noticed that MyFlightbook generally doesn't have the notion of logging "day" times.  This is deliberate: you have three variables (day, night, and total), two of which are fully specified (night/total); mathematically, the third variable (day) has a unique value that can be computed from the other two.  Giving you the opportunity to enter it explicitly wastes your time if you do it correctly, and introduces errors if you don't.  If you want to know your day-X time, just subtract the night-X time from the total-X time.  (See my separate post about combination properties for more information about this).

There are a few bits of interesting technical trivia/arcana here:
  • The apps will detect night-takeoffs in addition to full-stop landings.  But your currency may show that you are current even if you do not log the night-takeoffs.  They are absolutely required!  But so many people are lax about recording them that I just give a warning when I find the required landings but do not find the required takeoffs.
  • Logging night time is surprisingly tricky.  Specifically, there is no way to take a starting and ending point and time and determine how much of the flight was "night", because the specific path can affect that.  E.g., a flight from San Francisco to London might go north or south of a great-circle route for winds, and thus affect how much of the flight is conducted with the sun more than 6° below the horizon.  MyFlightbook solves this by looking at successive GPS samples (latitude, longitude, and time) and accumulating the elapsed time between them if both samples are "night."  Gap in the samples can lead to errors.  For example, if a sample comes in at 8:00pm and that is not night, night begins at 8:02pm, and the next sample comes in at 8:05pm, then 3 minutes of night will be lost.  As a practical matter, iOS and Android devices report GPS samples multiple times a second, so gaps like this are rare unless the device can't get a good view of the sky.
  • Many ratings require some amount of night flying, often as PIC or solo or cross-country.  Per my post about combination properties, just log these attributes independently; the system will determine the appropriate amount of combination to credit towards your rating.
  • If you fly turbine aircraft, you may find that MyFlightbook isn't reporting the usual 90-days of currency.  This is because MyFlightbook also implements 61.57(e)(4), which provides an alternative mechanism for currency.  Your night currency will be the later of either 61.57(b) or (e)(4)
  • If you use the AutoFill feature on the website and don't provide a telemetry file (GPX, KML, etc.) but do provide a route consisting of a starting and ending point (no intermediate points), and start/end times in UTC, then MyFlightbook will estimate the amount of night flight by creating a pseudo flight path which assumes (a) a perfect great circle route and (b) a perfectly constant speed equal to the great-circle distance between the start and end divided by the elapsed time.