Creating a good looking paper logbook

If you've read earlier posts on this blog (such as here and here)  then you are probably aware of my opinion regarding the very concept of committing an electronic logbook to ink-and-paper.  Add to that the fact that there are superior alternative methods (such as a live link to one's logbook, or even a simple PDF) for sharing your logbook with a regulator, insurer, or interviewer, and I palm my forehead that anybody bothers.

But alas, I'm not everybody. And I can't expect everybody to share my perspectives, especially when the aforementioned regulators, insurers, or interviewers often also do not share my perspectives.

For that reason, I've made sure that MyFlightbook's support for printing is as rich, customizable, and full-featured as I can, including (currently) 14 different layouts, and a host of customization options.  

So that gives you the tools to print out your logbook.  But it begs the more subjective question: how do you make it look really good and really professional?

One user on the site named Malcolm who has invested a lot of time on this has shared with me what he learned, and I thought I'd share it here so that everyone can benefit.  (Thanks, Malcolm!)

Obviously, everyone's flying experience is unique, so the choices he made below are specific to his logbook, but hopefully his example will point people in the correct direction.

Allow me to start with a view of his finished product so that you can see what is possible:

Task 1: Select a layout

Each of the various layouts on MyFlightbook is designed to optimize for certain information (e.g., the glider layout has columns for various types of glider launches, the naval layout has carrier landings), for regulatory compliance (the EASA layout does its best to conform to the FCL.050 specification) or "familiarity" (e.g., the US layout tries to look like common US-based paper logbooks).  

Given what you want to emphasize or project, pick the layout that works best for you.

You may also wish to add additional columns (most, but not all layouts can support that) and/or customize how per-page subtotals are shown.

My personal opinion on per-page subtotals: don't.  Just don't.  They serve no purpose in an electronic world; they only existed to facilitate manual summation of fields, and they end up wasting paper.  They're just plain stupid.  Use "Continuous".  If you must use per page subtotals, you may have pagination issues.  See the FAQ for how to manually force a page break if the flights would otherwise spill onto another page.

You can also select some additional options regarding verbosity of model descriptions or font-size; this is entirely up to your personal preference.

Task 2: Get rid of the cruft

There is a ton of data that you might log on a flight that you want to track, but which is not necessarily relevant for a job interview or ramp check.  Below is a screenshot from Malcolm's logbook of data that he felt was important to track but not important to print.

Note as well that anything that you put after "///" in comments will also automatically be excluded from printing.

Some layouts support images - if you're printing as a memory book, you will almost certainly want to include these.  If it's for a job interview, you almost certainly do not.  

Signatures (available in all layouts) is a different story - you may want them to demonstrate compliance, or they may be noise to you if your training was long ago.

Task 3: Save it for easy future access

At the top of the print-view screen is a link icon (, yes I admit I'm a terrible artist).  If you click that, your browser will change the URL in your address bar to a big long URL that will take you back to this print view with exactly these layout and content settings.  Bookmark that; it will save you time if you need to come back and print again later.

Task 4: Set up your print layout

Landscape (wide) format almost always works best, since horizontal space is most critical for fitting everything.

Set both side margins at least 12mm in order to make the blank margin wide enough that the hole punch would not obliterate some of the data. Unfortunately, the PDF generator I am using at the moment does not support mirrored margins (where the inside margin is wider than the outside margin in order to accommodate the punch holes)

Page size is obviously up to you and what is available to you.

Click "Create a PDF to download".  Review the results and tweak until you are satisfied.

You're now ready to print.

Task 5: Print

Set your printer to print landscape, double-sided ("flip on short side") and print!

Task 6: Bind

Binding your logbook definitely gives it a professional look and even if it doesn't say anything about your competency as a safe pilot, it does demonstrate your attention to detail.  

Malcolm found two options for the binder:

1. Buy a 3-ring landscape format binder such as this one. The only one I was able to find was unnecessarily wide (1.5" capacity) but would work fine.
   
   
   
   
2. Or, buy a checkbook binder. These come with 7 rings in it. Using a heavy pair of pliers, it is easy to twist out four of the 7 rings and pull them out.
   
   

Since you're printing in landscape, the location for the holes will be different than in portrait mode.  As a result, punching holes will require a 3-hole punch with adjustable hole positions.  These are usually available in an office, print shop, or office supply store.  If you don't have this, you can take your printout to Staples or some other copy shop and pay them to punch the holes in it. (Bring the binder so they can be sure to put the holes in the right place. Show them the format of the binder and warn them not to punch the long side of the paper, since this is what they would be accustomed to doing.)

Malcolm also recommends using post-it arrows pointing to each checkride; his interviewer remarked on how much he appreciated that.  

I'll add two more options to consider in this vein:

• You can use flight coloring to accomplish the same goal, if you print in color, though the post-its can still help to quickly find the page containing the relevant flights.
• Or, if you skip paper and share electronically, search functionality works pretty well to quickly find check rides (or other relevant experience), rendering this all moot

I have heard from several users that there are vendors who sell fancy binders for this purpose, often at inflated prices.  But it seems that this is not necessary - pilots have received job offers using binder clips (or electronic!), and I've never heard anybody be turned down due to the lack of a binder, so my personal suggestion is that the only valid reason to go to the effort or expense of a fancy binder is if it makes YOU happy.

Got any other tips for good looking printouts?  Let me know!

Tracking changes made to a flight

This is probably the most passive aggressive feature I've ever done.  I'll explain why, but first let me explain the functionality.

I've had a few requests for the ability to track changes made to a flight since it was first saved, due to local authorities in a few jurisdictions deciding that doing so was a requirement for electronic logbooks.  

I already have a form of this functionality already for signed flights. When a flight is signed, I save a copy of the salient (I'll discuss "salient" below) details of the flight (I refer to it as a hash, but it technically isn't one) so that I can always tell if any of those "salient details" have been modified since being signed.  This is important because the signature is an attestation to the facts of a flight, and the entry no longer represents what was certified by the signing authority.  Details are here, but this is important and useful functionality to verify that the signature is valid.  As a bonus, the hash is saved in such a manner that I can determine which edits have been performed, allowing the student to undo their changes (and thus re-validate the signature if it once again matches its original signed state).

The new feature expands this ability to unsigned flights.  If you enable this functionality, then when you save a new flight, it will also produce the hash.  If you then modify that entry, you'll see the modifications in-line (on the web) and you'll see the fact of the modification in a print view (an asterisk next to the date; I don't want to waste ink and muck up the layout for purposes of showing the changes).  As with signed flights, if you revert the changes, then its goes back to being "unmodified".  If a flight is signed, then the flight is "reset" and the version that is signed provides the new baseline for modifications.  Note that enabling this feature does NOT turn on tracking for existing unsigned flights.

But it's a really stupid feature that just clutters your workspace and doesn't even solve the problem that I believe it is trying to solve.  It literally adds no value.

Allow me to back up and get philosophical for a moment.

I've found in life that one of the most useful questions is "what problem are you solving."  

It's incredibly powerful for two reasons.  The first is because the better you understand a problem, the more self-evident workable solutions become and the more clearly you can weigh one against another.  

But the other is that it helps us recognize when we already have a solution in mind that is blinding us to other, potentially better solutions.  (Heck, sometimes it can even help us figure out that we don't really have a problem at all!)

Tracking changes to un-signed flights is a solution, not a problem, so if I ask the question "what problem does it solve", I realize that nobody has addressed this head-on.

I can only guess that it has to do with verifying that nobody is fudging things and backfilling data.  

But if that's the problem to solve, tracking changes is a terrible solution, for a variety of reasons:

• It's ineffective, because it is easily worked around.  After all, if you delete a flight and add a replacement flight, there's no way to determine that the newly entered flight was a replacement for the deleted flight.  (And if you have to track deletions, then doing bulk-edits or multiple tries when you import your logbook makes you look like a terrible fraudster).  We pilots already operate on an honor system: if I have an entry from a solo flight I made on Friday, that is credible only because I say that I actually took that flight.  I could be lying to pad my logbook, and change tracking does nothing to help that.
• It's arbitrary, because it imposes a requirement beyond what paper has, while paper is still acceptable.  In a paper logbook, you can easily insert time (say, night flying or solo time) in a manner that cannot be detected (even for signed flights).  I've heard the counter argument that many edits (deleting flights, modifying existing data) cannot easily be done because you'll see the scratch-out or the "3" clumsily turned into an "8"; while that's true, it's also pretty easy to just get a new paper logbook and transcribe entries if you're really determined.  But again, since I'd think the most common source of fraud here would be adding non-existent experience (what value is there in hiding actual experience?), that's an edge case: it's easy to insert additional landings, approaches, or times into existing flights - or even entire new entries - on paper in an undetectable manner.  Thus a different standard is being applied to logbooks based on the medium, but with no clear rationale for doing so.
• It's ambiguous.  I mentioned "salient details" above. I do this because there are a lot of things that simply do not matter to the integrity of a record: if you add or remove images/videos, or if you make it public or private for example (neither of which even exists in the paper world).  For signed flights, I've excluded such values from the hash to avoid needlessly invalidating a signature.  I've yet to see any authority asking for change tracking actually define what constitutes a "change" to be tracked.  The requirement is similarly vague about what, precisely needs to be recorded about each change or whether it is OK to treat the flight as unmodified if you make a change and then change it back.
• It's insanely noisy.  If you fix a misspelling, if you remember that you forgot to log cross-country time on a given flight, if you do anything to correct a legitimate error, it flags the flight as being modified.  Good luck distinguishing fraud from legitimate edits.  (My old paper logbook is full of such corrections/additions, as I fixed math errors or went back to add experience that I had acquired but hadn't logged at the time).
• Worst of all, it's completely pointless because it is redundant.  Particularly if you submit a printed version at a job interview or to authorities, you are already affirming that "yes, this is my true and accurate logbook"; that's why there's a place to sign each page.  And, of course, signed flights already have the mechanism so there's an additional layer there for training where a 3rd party is certifying the truth of the records.

And if that's not the goal, then...seriously, what problem is being solved?  I want to know!  I have no other theories, but perhaps someone here does?  

Anyhow, this silly and boneheaded functionality is now live.

Slicing and dicing your Data

One of the critical benefits of having your logbook online is that it gives you very rich ways to analyze your flying data.  Today I'm going to discuss 6 different ways (and refer to two others!) that you can slice and dice your flying to gain insights, answer questions, or demonstrate experience.  I'll discuss this in the context of the website, but most of this functionality is also directly available in the iOS or Android apps.

Totals

The first and simplest is, of course, totals.  By default, Totals shows you, well, umm, everything that can be summed up.  Internally, believe it or not, while there's a core set of known things to total, the list is not fully pre-determined; it's largely up to you and what's in your logbook.

Here's my totals as of today:

I'm showing the drop-menu in the upper right corner to demonstrate that you can choose whether to have a big long flat list, or to have (as I have done here) totals grouped together in appropriate ways.  (Grouping is applied on the website; totals on the iOS or Android app are always grouped) 

The first group, by default, shows you your total times broken down by category, class, and (if a type rating is required), type.  An example of "type rating" in the US would be a 737, which requires a "B-737" type rating to fly.  If I had some 737 time, then you'd see 737 time broken out as a subset of AMEL time. 

If you like, you can change this to group by model instead of by category/class (go to Profile->Preferences->Currency/Totals; this will be reflected on iOS or Android apps, but you can only make the change on the website).  You can define a "model" for this purpose as either being a very specific model ("C-172 S" is distinct from "C-172 P") or by ICAO code (both a C-172 S and a C-172 P are "C172").  This creates a new section with your totals by model.  In my case, it looks like this when I use the more specific model definition:

The next sections are times by aircraft feature (complex, high-performance, turbine, tailwheel, etc.), your "core" times (Night, Cross-country, IMC, etc.), other totals (Carrier landings, ILS approaches, etc. - depending on what you've logged), and finally your bottom line total flights and hours.  

"Hours" for purposes of total time and for the category/class and model times is what you've logged in the "Total Flight Time" field.  So if you had a 1 hour session in a sim emulating a Boeing 737, if you logged an hour of total time, that will count as an hour of total time (overall), an hour of AMEL time, and an hour of AMEL (B-737) time.  (This is why, in general, you should NOT log sim time in the "Total Flight Time" field.  See my previous posts on this topic).

I titled this post "Slicing and dicing" and yes, you can slice/dice your totals.  Totals are search sensitive!  Notice that most of the totals above are blue, indicating that you can click on them (you can tap on them in the iOS/Android apps).  This does a search, and then re-displays the totals but only for the flights that matched the search.  

So, for example, if I tap on the AMEL total in one of the links above (or do a search for only flights in MEL airplanes and then click totals) I get this:

Notice the bar above that says only AMEL flights are included (and, not surprisingly, as a result my ASEL and Glider totals are zero and hence not shown).  So if I want to know my PIC time in MEL airplanes, I can just read it here: 19.23 hours.

Totals are a powerful way to get results for common queries - especially from insurance companies who seem to come up with all sorts of obscure totals that they want to know.

8710/IACRA form

The next three ways to slice/dice your data are over on the Training tab (both website and iOS/Android apps).  The first is the 8710/IACRA form.  Apologies for folks outside of the US - though this is likely useful to you nevertheless! This report mimics the 8710/IACRA form that pilots must fill out before taking an FAA checkride.

Once again, I'll be the guinea pig and use my data for an example:

This should be pretty self-explanatory and straightforward.  The two key things to note are:

• Read the footnotes!  I specifically disallow a lot of "combination" values like "night PIC" because I can compute them.
• As with totals, this form is also search-sensitive.  So if you, for example, log a lot of Microsoft Flight Sim time (doesn't count towards ratings) or want to segregate, say, your military time from your civilian time, you can do the appropriate search to include only the relevant flights and the form will update.

Rollup By Model

Also on the Training tab, this emulates the common Airline Apps page report and hopefully provides all of the relevant information for applying to many airlines (at least here in the US).  Again, my data:

Note that this is also broken down by model (ICAO code) and is search sensitive.

Rollup By Time

The final report on the Training tab provides the same data that general Totals provides, but for multiple common time periods.  My sample (truncated):

This can be a quick way to view your totals for particular time periods.  It is, of course, also search sensitive.  

Analysis

Going back to the Logbook tab - and into the first functionality that I will discuss that is web-only - is the Analysis tab.  This is where you can view your flying trends graphically.

Here's my default analysis view:

In the example above, note that I am hovering over one of the bars and seeing that (in this example), I flew 84.3 hours in 2017.  

The gist of how the analysis tab works is that you can select a value to sum for the Y axis ("Total flight time" in the example above), and a grouping construct ("Year" in the example above) for the X-axis.  MyFlightbook looks at all of the flights that match your specified search criteria (you thought maybe it wasn't search sensitive?  Silly you...), and puts then each into an appropriate "bucket" for the x-axis based on the grouping.  It then sums up the requested value for each of the flights in each bucket.  (If this sounds a lot like a pivot table in Excel, that's not accidental...we'll get there below...)

This can be pretty powerful, or merely fun.  For example, if I want to know how my flying varies by day of week, I can do that:

Or, I can group by model of aircraft and show the average so I can see which models I've flown more or less than average:

The x- and y-axes are determined by your flying, so you may be able to do even more interesting analysis. 

Finally, I'll point out that you can view and download a table of all of your flying filtered (i.e., search sensitivity) and grouped as you've selected, in case you want to do a deeper dive.

Pivot Tables

The final piece of data slicing and dicing you can do with MyFlightbook technically isn't even in MyFlightbook proper; it's in spreadsheet apps like Excel or Google Sheets.

You can download your entire logbook into a CSV file by going to Logbook->Download on the website, and from there loading it into your spreadsheet of choice. 

From there, you can apply formulas and create pivot tables to your heart's content, which will allow you to group to multiple levels (e.g., group by category/class, then by model, for example, whereas MyFlightbook's grouping only goes one level deep) or you can customize charts or do filtering searches that MyFlightbook can't do.

Using this functionality is beyond the scope of this blog post - especially since it is dependent on your spreadsheet choice.  But it is yet another level of analysis that is available to you.

Other Data Analysis

There are two other data slicing/dicing options that are worth at least mentioning.

One is airports.  You can view the airports that you've visited by going to Airports->Visited Airports (on the website; just "Visited" on the mobile apps).  Again, this is search sensitive, so you can see which airports you've visited in a given timeframe.  You can even compute the distance you've traveled or download your flights into Google Earth.

The other is analysis *within* a flight.  All of the discussion above is in the context of your whole logbook - across multiple flights.  But if you attach telemetry data to your flight, you can do additional analysis - particularly if it comes from the aircraft itself and has more than just latitude/longitude information.  For example, many units will include oil temperatures, cylinder head temperatures, exhaust gas temperatures, fuel levels, true airspeed, and so forth.  

MyFlightbook supports a wide variety of telemetry formats, including KML and GPX, but CSV may be the most powerful because it's so extensible  and thus can include things like the engine data I just described.  You can read more here about the sorts of things that you can include, but the key thing is that when you attach telemetry to a flight, you'll see a paper clip icon next to it:

If you click that icon, you can pick up to two fields to chart against a 3rd field:

Better still, if the data does include latitude/longitude/time information, you can click on a sample and see on the map beneath the chart where you were when that particular event occurred.

Hopefully somewhere in all of the various tools I've described above, you'll be able to answer any question about your logbook.  If not, please let me know and I'll see what I can do!

Custom Rating Progress

MyFlightbook has long tracked your progress towards the flight experience requirements of various ratings (113 of them at last count!).  But inevitably there are some that are useful to track but that are too narrow in application for me to create.  Over the years I've had a few requests to allow for custom ratings progress.

Today I've taken that feature out.

You can create your own custom ratings on the Training->Ratings Progress page, by selecting "Custom Ratings/Progress" from the top drop-down.  When you do this, you'll see an expandable section where you can create your own rating progress.

A bit of terminology in this context:

• A Milestone is a specific criteria to meet.  For example, "40 hours of dual instruction received in a tailwheel airplane".
• A Rating here is not really a privilege per se, it's simply a term for something to achieve when you've met all of the specified criteria.  A rating is really nothing more than a named collection of milestones.

Milestones follow the basic model of specifying a threshold that must be met, the attribute that must meet that threshold, and any constraints on the flights that qualify towards that threshold.  The constraints, in turn, are determined by a saved search.  You can also use "All flights" as the constraint.

So in the example above ("40 hours of dual instruction received in a tailwheel airplane"), the threshold is 40, the attribute here is "dual instruction received", and the "in a tailwheel airplane" is encapsulated in a saved search.

A milestone also includes 3 more fields: a regulatory reference (if one exists; otherwise, you can simply use a number as a way of sorting milestones), a title, and an optional note.

An example

Here's a simple example.  Suppose I belong to a flying club that has a tailwheel aircraft, but because of insurance requirements, I can't fly it until I have at least 300 hours of total time, at least 20 hours in tailwheel airplanes, and at least 10 hours of instruction in N6169M, the specific aircraft in question.

Step 1: Create the query for flights in N6169M.  Simple enough:

When I click "Find Matching Flights", this will be created as a query named "N6169M".  Pick any name you like, of course.

Repeat this to create a query for Tailwheel airplanes.  In my case, I'm going to name it "Tailwheel"

Step 2: Create the new rating.

Go to Training->Ratings Progress and choose "Custom Ratings/Progress, then expand the section to create a rating and fill it in:

Notice in the image above where it offers a space to fill in an optional longer description or notes; I'll show below where this appears.  For this example, I'm going to put in "This is an insurance requirement, not a regulatory requirement".  Click "Add a new rating" to create the rating and it will be available from the drop-down that contains the available custom ratings:

Notice where the note appears.  But alas, this isn't very useful yet: it has 0 milestones.  Let's create them.

Step 3: Create the milestones for the rating

Click on "Add/Edit Milestones" next to the rating:

You'll notice at the bottom of this screen that there are no milestones yet.  As we add milestones, they will appear there.

Since there's no actual regulatory requirement for this "rating", I'm just going to use 1, 2, and 3 as the Reference.

The 300 hours Total Time requirement is straightforward:

Notice that I can use simple markdown here for legibility: by surrounding words with asterisks, they will be in boldface when displayed.  You can also add hyperlinks by using the syntax "[Google](https://www.google.com)" to get it to display as Google. In this case, I added a link to the insurance documents to the note for this milestone.

Also notice that the first two milestones use "(All flights)" as the matching criteria.  When you click "Add new milestone/criteria", it shows up in the list of existing milestones:

You can add the other two milestones in the same way, choosing "Tailwheel" and "N6169M" as the "For flights matching" option as appropriate:

Note that if you make a mistake, you can click the red "x" next to a milestone and re-create it.

Step 4: Try it out

Close the milestone box above by clicking the gray "x" in the upper right corner, and you can select your custom currency from the list:

(Darn, I have all the experience but haven't been able to fly N6169M yet!  Looking forward to it...)

Limitations of Custom Ratings

Regulation-driven rating requirements tend to be complicated, and for that reason I've hand coded all of the more than 100 built-in ratings in the system.  The most common complications include things like substitutions  - for example, requiring a certain number of hours of flight experience, but allowing substitution of simulator time up to some limit.  Custom ratings progress do not possess these sorts of complications.

One other common requirement for regulatory ratings are "one-off" requirements, such as a long solo cross-country flight that is at least some distance.  Easy for me to hand-code, but getting that into a custom rating regime is...harder, so I've passed on doing so for now.

Interestingly, one other wrinkle in regulation driven requirements (at least for the FAA) is that some of them can decay over time.  Specifically, the FAA often requires a certain amount of training within a particular window prior to a checkride (e.g., 3 hours of training within the 2 calendar months preceding a checkride).  Because Saved Searches can handle these sorts of date windows, custom ratings can also encapsulate these!

But the vast majority of these sorts of things are simple requirements that follow the basic template of "Make sure you have [X hours or count, as appropriate] of [Some type of experience - total time, solo time, night flight, carrier landings] in flights that meet [some criteria]", and thus can be handled by custom ratings.

Please let me know if there are scenarios I'm not handling besides the ones above.

Default Date of Flight on iOS or Android

(Updated in mid-June 2023; please see the update below)

When using the mobile apps, the "date" field might often be filled in with a stale date - typically the date that you last flew.

So, for example, imagine that you take a flight today (the 23rd as I write this) and after the flight fill in the details of the flight and tap "Add".  The flight gets added to your account and the "New Flight" screen gets reset, including (a) the same aircraft you just used for the flight you just entered, (b) today's date (the 23rd), and (c) some other carry-forward information as appropriate (such as the aforementioned Hobbs time)  Tomorrow (the 24th) you take another flight.  When you tap on "New Flight" it will still say the 23rd because that's the data that was on that screen when you last left it.

I'm occasionally asked why this is and asked to change it so that it always defaults to "Today".  Unfortunately, there's no perfect solution here: optimizing for one scenario actually makes it worse for others, and I've always come back to the same conclusion that it would be the wrong behavior, for two main reasons:

Mostly - it changes data simply based on navigating away and then back to a screen – that’s generally badness, and there’s nothing anywhere else in this system (or any other system I can think of) that modifies data based on a view/navigate event.  For example, imagine if you were to start looking for an airline flight on a given date, then go to another tab to verify you can get the hotel you want, and then when you navigated back to the airline website tab and it had reset your date of flight or origin or destination.  

Think of “New Flight” simply as a browser tab – it’s completely independent of the other tabs, and it doesn’t update its data simply because of the passage of time.  

But perhaps the bigger reason is that it breaks a lot of very common scenarios.  

For example, if you fly today (the 23rd) and fill in some of the data after the flight, but not all of it.  Then tomorrow (the 24th) you fill in the rest of the data, it would be an error to push the date up to the 24th without you doing something.  Or, suppose you depart at 10pm on the 23rd and land after midnight on the 24th - now the date-of-flight would (incorrectly) be the 24th instead of the 23rd.

In a similar vein, it would break the scenario of entering an older flight unless you could complete it without interruption.  For example, suppose you start entering a flight from last week, but you get interrupted and have to leave the screen for a moment.  You come back and continue entering the flight but - alas - now the date has updated from last week to "today."  Not what you intended at all.

So that's why it doesn't update to "today".  But it is obviously not unusual to start a flight on a day that is after your most recent flight.  

For this reason, the apps implement a few "fail-safes" that try to ensure the date is the current (local) date, when appropriate:

• Setting a flight start, engine start, or block-out time will all adjust the date field to be consistent.  So, for example, if I last flew on April 21^st, then the date-of-flight will probably still say April 21.  But if I press “Tap for now” on block out, it will set it to whatever “Now” is locally (April 23, as I write this)
• You can press-and-hold the date field to set it to "today".  
• If you want to clear the form for a new flight, you can always do a “Reset” (tap the action button on the lower toolbar and you’ll see the Reset option), and that sets the date to Today

UPDATE, JUNE 2023

I've updated the iOS and Android apps to have a new notion of "(Today)" as the date.  Think of it as having no specific date at all, and this "floats" with the clock.  If you submit a flight that has "(Today)" (i.e., no specific date), then at that point, it is assigned whatever the current local date is. 

If you tap on the field while it says "(Today)" it will be set to the current date - and since that is a "fixed" (as in "unmoving") date, it will remain there unless or until you explicitly change it or delete it (i.e., render it unspecified/floating again). 

When you reset a flight or when the form is cleared for the next flight after submitting a previous one, the date is set to "Today".

So, for example, if you fly on Monday and fill out a new flight form that has "(Today)" as the date...:

• If you tap on "(Today)", it will set to Monday's date (fixed).  If you wait until Wednesday to add the flight to your logbook, it will be entered with Monday's date.
• If you leave the date as "(Today)" and wait until Wednesday to add the flight to your logbook, the flight will get *Wednesday's* date.
• If you pick any specific date, that date will not change by itself.  But if you delete the date, it will return to a floating "(Today)" value.

The fail-safes described above for the pre-"(Today)" behavior still all work.

Total Approaches and autofill of enumerated approaches

In a previous entry, I describe MyFlightbook's model of logging a total approach count and then optionally describing subsets of those approaches.  The idea is to strike a balance between ease of data entry and ease of computation for things like 61.57(c) instrument currency and totals.

So, for example, if you go up and practice a bunch of approaches, you might do 2 VOR approaches and one ILS approach.  In this scenario, you'd log "3" in the "Approaches" field, and then use the "Approaches - VOR" and "Approaches - ILS" properties to log 2 and 1, respectively.  Putting "3" in the approaches field lets the currency computation for instrument currency know unambiguously that you performed 3 approaches; the remaining properties are really just for your convenience if you like to know how many ILS or VOR approaches you've performed.

Expanding on that last point a bit: it's fine if you simply log "3" in the approaches field and don't bother with any of the subset properties (although 61.51(g)(3)(i) does require that you provide the location and type of each approach; this can be done in an unstructured textual manner in the comments for the flight or in the "Approach Name(s)" property).

There are a whole bunch of possible approach types in the system (ILS, VOR, RNAV, NDB, etc. - 43 different kinds at the moment, actually!) and these are flagged as approaches.  

As a convenience, when you save a flight that has one or more of these approach properties, but that has no total approaches indicated, it assumes that you were not explicitly declaring 2 total approaches but rather that you neglected to fill in that field. For that reason, it adds up the enumerated approaches and auto-fills the Approaches field.

So, for example,

Flight has:	Then:
2 ILS approaches 1 VOR approach Empty "Approaches" field	Approaches field is auto-filled to 2 + 1 = 3
2 ILS approaches 1 VOR approach 5 in the "Approaches" field	Flight is unchanged - clearly stated there were 5 approaches, and you've described 3 of them
2 ILS approaches 1 VOR approach 2 in the "Approaches" field	Error - you've described more approaches than the total that you indicated.

A key observation about this is that the math above only works because the properties that are tagged as approaches are mutually exclusive: a given approach cannot simultaneously be an ILS approach and an NDB approach, so adding the two together is OK.

There are a number of approaches that you can describe with properties, though, that are not flagged as being approaches and thus do not result in the autofill behavior described above.

The first of these is "Approaches - Visual," for the obvious reason that you don't want this to count towards your total approaches because it would mess up your 61.57(c) currency (which requires you to flight by reference to instruments).

The other exception to the autofill rule are approaches that are not mutually exclusive with other approaches.  This includes things like Category I/II/III approaches, RNP approaches, or coupled vs. hand-flown approaches.  These are subsets of the subsets, if you will: think of them as an adjective/modifier/constraint on a procedure, as opposed to a particular type of a procedure.

So, for example, if you fly 3 ILS approaches to a runway, 1 of which was a Category II approach and the others were vanilla ILS approaches, you might log 3 ILS Approaches and 1 Category II approach, but it would be a mistake for the auto-fill feature described above to fill in "4" for the total approach count.

For that reason, these "approaches" are not flagged internally as actually being approaches, and thus will not trigger auto-fill of the approaches field; they're really for your recordkeeping benefit only.

Please help me beta test the new version of the Android app

The MyFlightbook Android app is written in the programming language Java, which was the only option 10 years ago when I first wrote it.  But over the past few years, Google has been officially pushing people to use the newer Kotlin language instead.

If none of that makes sense to you, I can just summarize it this way: I need to future-proof the app, and that means translating it into a new programming language.

Fortunately, Google has provided some excellent conversion tools that do a remarkably good job at converting from one language to another.  I spent a bunch of time over the past weekend using these tools to convert the code, and testing/tweaking to make sure that it all works.

I think it's working (indeed, I found and fixed a couple of minor bugs that exist in the current Java-based version), but here's where I need your help: before I unleash this new version to replace the old, can you help me find any remaining issues?

If you're willing, please join the Beta program for the app and send me any feedback, bug reports, etc.  Instructions for how to do so can be found here under the heading "Get beta versions of apps".   It takes a few minutes to add your account to the beta, but when it happens...well, try it out!  

You shouldn't really notice any difference (I don't want to be adding features during a transition like this), but you can tell that you're running the Kotlin version by going to the Profile tab and scrolling down to the very bottom; it should say "(Kotlin)" next to the copyright information.

This uses your same data, same credentials, and everything, so you can use it in place of the production version.  And if you run into any issue that makes it not work for you then you can go back to the production version by leaving the beta program (but hopefully after sending me the steps that led to the problem!!)

Thank-you in advance!

TAA Time in a helicopter

I got an email today from someone who flies both airplanes and helicopters asking why the "TAA" time in their totals only included their airplane time - it didn't include any of their time in technically advanced helicopters.

That's because technically (pun not intended) there is no such thing as a helicopter that is a TAA.  The 2nd "A" in "TAA" is "Airplane" - indeed, 61.1 defines TAA very explicitly as "an airplane equipped with an electronically advanced avionics system".  (61.129(j) defines it further, requiring a PFD, an MFD with a continuously visible moving map, and a two-axis autopilot).  The FAA uses "aircraft" where they mean an arbitrary flying machine, the use of "airplane" is not accidental.

Since TAA time is important for commercial airplane ratings, and because it technically only applies to airplanes, I report the TAA time in totals limited to airplanes.

So why do I allow non-airplanes to be tagged as "TAA"?  Simple: there are obviously non-airplane aircraft that meet the 61.129(j) definition but for the "airplane" part and people often want to track that.

If you want to see your time in, say, technically-advanced helicopters, you can search for flights where the flight aircraft was “TAA” and then look at the resulting helicopter totals (or better, search for flights in helicopters flagged as TAA), in which case the resulting overall totals will “TAA” (in quotes, because it’s not technically TAA) time.  

In this case, you'll see a criteria label of “Technically Advanced Aircraft” (rather than "Airplane") because it is not explicitly limited to airplanes. 

Note that if you do the search above and don't also restrict to helicopters, you may see your airplane TAA totals in your resulting totals because the search is finding all TAA (Aircraft) flights, which includes both your airplane and helicopter time, but the TAA total you see will still represent *airplane* time.  

E.g., if you were to search for TAA as above, with no other criteria, and your resulting totals had, say, 30 hours total of which 25 were in helicopters and 5 were in, say, a C172 that meets the TAA criteria, then you’d see a bottom-line total time of 30, 25 hours of helicopter time, 5 hours of ASEL time, and 5 hours of TAA time.  You could then simply look at the total helicopter time (25 hours here) and say "I have 25 hours of time in a technically advanced helicopter."

But if you search for TAA AND helicopter, then you’d get a result with only 25 hours, 25 of which were in helicopters, and you will *not* see a separate line for TAA in your totals because none of the resulting time came from airplanes.

Auto-fill functionality

I updated the mobile apps today to add support for autofill.

The website has had autofill functionality for a long time, but the mobile apps haven't.  The main reason for this is that the mobile apps can function while offline and actually measure a flight using the GPS, so they've historically been more optimized around detecting flight events in real-time.  The website, on the other hand, requires that you be online. 

So I thought it might be useful to review some of what the apps and the website can do for you automatically here.

Auto-fill Total Time, Hobbs

The mobile apps allow you to tie the total time field to block, hobbs, engine, or flight times.  This is a tight coupling: if you have both start/stop of the source defined, then any change in the value of a start or stop changes the total time field in real time.

Hobbs time similarly can be sourced from flight or engine time, and is also tightly coupled.

Cross-fill

You can quickly cross-fill the "Total Time" field to any time-based field by clicking the gray arrow next to that field (website) or by pressing-and-holding on the target field (iOS or Android app).  E.g., you can fill in the time of the flight in the Total Time field and then cross-fill that to the "Dual Received" field, or the "Solo Time" field or whatever other field is appropriate.

Automatic Cross-fill

On an aircraft-by-aircraft basis, you can specify automatic cross-fill (copying of a value from one field to another) from the Total Time field to your choice of PIC, SIC, or Instructor time.  (And if PIC, you can have it fill in your name as the PIC for that flight as well).  

The rationale for doing this on an aircraft-by-aircraft basis is that you might fly professionally in a jet during the week as a second-in-command, and fly your personal 172 on the weekends.  You'd automatically log PIC time in the 172, SIC time in the jet, and not do any cross-fill when you fly with a friend in their plane.

Automatic cross-fill operates under a few rules that are important to note:

• It will never overwrite a non-zero value.  So if you have PIC cross-fill on and fly for an hour where you and a friend each are PIC for half of the flight and you log 30 minutes as PIC, then it will NOT overwrite that 30 minutes
• It happens on the server at the point that you save the flight.  In other words, you won't see it applied while you're entering the flight itself, but after you add the flight to your logbook, you'll see that the cross-fill has occurred.
• It is only applied to new flights.  So if you edit an existing flight, the cross-fill will not happen.  This is important to allow you to override the cross-fill on a flight-by-flight basis (otherwise, you'd set the PIC field to 0 because someone else was flying, and the PIC time would come right back).

Auto-Detect

The mobile apps can run while offline, usually have GPS access, and can thus detect takeoffs and landings (using speed), nearest airports, and whether it is currently "night".  You can configure a variety of settings such as threshold speeds for takeoff/landing and what criteria to use for night flight or night landings (FAA and EASA rules can vary on that).  The system then updates the flight data in real time to reflect the flight in progress.

To do this, the system must use the GPS even in the background, and because that can consume battery, it only does this when a flight might be "in progress".  "in progress" is defined in this context as having (a) either a defined engine start or a defined flight start time, and (b) NOT having a defined engine end time.

What I typically do is tap "Tap for Now" on Engine Start as part of my engine start procedure, then tap "Tap for Now" on Engine End as part of my shutdown procedure.  The app will listen to the GPS between these two events.

You can also send a GPX or KML file to the MyFlightbook app on Android or iOS.  When you do this, it sets and engine start time to the timestamp of the first sample in the file, and then plays the file as if it were real-time GPS samples, and then sets the engine end time to the timestamp of the last sample.  It uses your autodetection settings for all of the intermediate GPS samples.  (This functionality has also existed on the website for many years).

Some of the things that auto-detection will fill in include:

• Departure, arrival, and any intermediate airports
• Total landing counts, including the subsets that are full-stop day and full-stop night
• Night takeoffs
• Night flight
• Cross-country time (using a 50nm threshold; see here for why I don't do it for all cross-country flight)

It's useful to note that you can pause/play autodetection by tapping the green pause/play button on the "In the cockpit" section of the iOS or Android app.  (This button only shows when a flight is in progress).  This is useful if you, for example, fly from A to B for lunch or gas, then fly back to A and want to record it as a single flight but still get the times correct.

Autofill

Because the apps have supported auto detection for years, there generally hasn't been a real need for autofill.  But there are still a few scenarios where it makes sense, which is why I've added it.

Autofill overlaps with autodetection when there is telemetry (GPS) data present.  If so, it has all of the functionality of Auto-Detect.  But it can also work without telemetry, and it fills in a few things that Auto-Detect doesn't.

Where Auto-detection tries to fill in a flight based on GPS data (or a GPS file), the philosophy behind Autofill is to try to look at the flight and see if there are missing things that can be inferred or calculated.  Naturally, the first thing Autofill tries to do is to autodetect, if appropriate GPS data is available. 

One of the things Autofill can do is to estimate night flight.  I say "estimate" because that's the best I can do without actual GPS samples.  But if you have exactly two airports in your route of flight and start/end pairs defined for any of block, engine, or flight time - and these are in a defined timezone (i.e., UTC) - Autofill will construct a synthetic GPS path that is constant speed and great circle path from the first airport to the second.  It will then perform autodetection on that synthetic path.  

This is only an approximation, of course.  Imagine you flew from San Francisco to London - a perfect great-circle route at a constant speed will imply a certain amount of night flight.  But if you actually flew further north or south (perhaps for better winds), or if you had strong headwinds during one part of the flight and strong tailwinds during another, you would obviously have experienced a different amount of actual night flight than the constant-speed great-circle estimate.

In addition to whatever autodetection can be performed (whether with actual or synthetic GPS pdata), Autofill can also fill in:

• Total Time, if it is empty (zero) and if it can be determined from (in priority order): Hobbs time, block time, engine time, or flight time.  Note that the new Autofill functionality in the mobile apps will do this as well, even if you have an AutoTotal setting.  Imagine again that you fly a jet during the week (no Hobbs meter) and a club plane on the weekend (with a Hobbs meter), and you have AutoTotal set to use Block Time.  For your weekend flight, if you don't enter a block time but do enter a hobbs time, it will still fill in a total value for you based on that. 
• Ending Hobbs Time, if there's a non-zero starting Hobbs and the total time is known
• Ground Instruction given or received.  If you have both a defined Lesson Start and Lesson End time, then your flight time (hobbs, block, engine, or flight, in priority order) is subtracted from that, and the remainder is assigned to Ground Instruction Given (if you have Instructor time logged) or Ground Instruction Received (if you have Dual Received logged)
• Cost of Flight.  If you have a private note on the aircraft that includes something in the form "#PPH:75.00#" (where the "75.00" can be any decimal number), then that is treated that as the cost per hour for that aircraft.  So in this example, if you logged a 2 hour flight in an aircraft with "#PPH:75.00#", it would record 150.00 as the cost of the flight.  (And if you are using US conventions, that would display as $150.00).

If you have other suggestions for autofill, please send them my way!