Saturday, September 10, 2022

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!


Sunday, June 26, 2022

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:

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

Saturday, April 23, 2022

Default Date of Flight on iOS or Android

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 21st, 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

Friday, April 15, 2022

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.

Monday, February 7, 2022

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!

Tuesday, February 1, 2022

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.


Friday, January 7, 2022

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.

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!