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


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.


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!

Thursday, March 18, 2021

Saved Searches and Flight Coloring

Do you ever find yourself doing the same search over and over?  Want to highlight your flight reviews or IPCs to make them easy to spot in a printout?

MyFlightbook allows you to name a search (aka "query") for future use.  It's pretty simple to use.  To give a search a name, use the drop-arrow next to the search box:

Just type in a name, and when you click "Find Matching Flights", you will not only see the results of the search, but the search will have been saved in your account as well.

The image above is from the website, but it's the same basic idea on the mobile apps; you can give it a name on the bottom of the screen where you fill in the search form.

Previously created queries are listed below the edit box where you type the name:

Click on the name of the search to apply it, or click the red "X" to delete it.  

You can update an existing saved query by simply re-using its name with a new search.

This can be super handy for common searches.  Each year at tax time, for example, I want to know about my angel flights from the previous year (that's the query that's shown above).

Flight Coloring

Saved searches are a nice power feature, but where they get really powerful is when you combine them with a relatively new feature: Flight Coloring.

Flight coloring allows you to specify a background color to use in the logbook display for flights that match a saved search that you have created.

Flight Coloring is a two step process: first, save the search with a name.  Then, go to Preferences (under the Profile menu)

You'll see all of your saved searches there; next to it, you'll see a sample area.  Click that and you can choose a background color (pale colors work best), or click "Remove Color" to remove the color.  

Your logbook will then display matching flights using the color you've selected:

You can even choose to have these flights highlighted in the print layout - this can be useful, for example, if you are going for a job interview and want to make it easy to find finds that are significant to demonstrate experience or training.

More Tips about Searching on MyFlightbook

MyFlightbook has a very rich and powerful set of search options.  You can learn more in the FAQ.

Wednesday, March 10, 2021

Pending Flights

Can a flight be in your account but not in your logbook?  Yes.  MyFlightbook supports the notion of a "pending flight", which is simply a flight that is awaiting (pending) addition to your logbook.

Pending flights are designed primarily to address two scenarios:

  • You fly professionally and have a schedule of upcoming flights.  You might want to get those into the system before you fly them, but obviously you can't claim the time or experience before actually doing so.
  • You perform a bulk import and some of the flights have errors.  The flights with errors can be moved into the list of pending flights, allowing the error-free flights to be added to your logbook.  You can then fix the errors at your leisure.

There are other scenarios as well, of course, but those are the big ones.

There are two main features of a pending flight that distinguish it from a regular flight.  The first is that it is NOT included as a flight in your logbook: it is ignored for purposes of computing totals, currency, visited airports, and so forth.  Think of it as a scratch pad for flights.  The second is that error checking is basically suppressed.  You can have a pending flight in the future, you can have one that does not have an aircraft assigned, or that violates other integrity checks.  Obviously, a pending flight with such errors in it cannot be added to your logbook until the errors are addressed.

Creating Pending Flights

The most common way for pending flights to be added to your account is via Import.  If you import a file and some flights have errors, you'll have the option to import anyhow, with flights containing errors shunted over to the pending flights list.  If so, you'll see something like this at the end of the process:

In the example above, 5 flights were imported but 2 of them had errors; they ended up in pending flights, and the other 3 were added to the logbook.

MyFlightbook can import from a variety of sources, including some scheduling programs, which often lack required information such as the aircraft used for the flight.  These sources can only import to pending flights.  If you import debriefed flights from CloudAhoy, the same holds true - you will need to review these flights before adding them to your logbook.

The other way to create a pending flight is to do so explicitly when creating a flight.  Use the drop-menu next to the "Add Flight" button and you'll see the option to save as a pending flight instead of as a regular flight in your logbook:

Note that pending flights can have telemetry associated with them, but they cannot have images; you'll need to add any images after you add the flight to your logbook.

Reviewing Pending Flights

Go to "Pending Flights" under the Logbook tab to view any flights that are pending addition to your logbook.  You'll see a list of your pending flights (if any).  At the bottom is an option to bulk-delete them if you decide they were added in error or are an artifact from an import attempt prior to a successful import.

Otherwise, you can selectively delete pending flights that you don't need, or click on a flight in the list to edit it.  When you're done editing, click "Add Flight".  If you've addressed any errors in the flight, then the flight will be added to your logbook and removed from the pending flights list.  You can also use the menu next to the "Add Flight" button to update the pending flight.  Updating the flight preserves whatever changes you made, but keeps the flight in your pending flight list.

Mobile App Support

Both the iOS and the Android apps support pending flights.  The basic model is exactly the same, except that the pending flights are integrated into the recent flights list.  You can explicitly save a new flight as pending as well.  On Android, you can do this from the menu.  On iOS, tap the "action" icon (the box with an up-arrow) along the bottom toolbar.

Note that because the mobile apps can work while offline, they have another sense of the word "pending" that does not have meaning on the website: namely, the notion of having a flight that has not yet been uploaded to the server.  I am using the terminology "Awaiting Upload" to describe these flights.  So a flight that is "awaiting upload" is still local to your device, and may be waiting to go into your logbook or into pending flights, whereas a flight that is in your pending flights list is in fact up on the server and therefore available to any of your devices.

Tuesday, January 26, 2021

Can my logbook change without me doing anything?

The short answer is "yes."  Should you be concerned?  Well, obviously the only person who can answer that is you, but I think the answer is "no" and this post will go into excruciating detail about the ways in which your logbook can change without your action, and you will at least understand my perspective for why you shouldn't be concerned.

There are three ways your logbook can change without you doing anything.  A MyFlightbook admin can make a change; this is actually the only way that you logbook can be directly affected without any interaction on your part.  The second way is that an instructor can sign flights, revoke a signature, issue an endorsement, or add flights.  The other is that your logbook can be indirectly changed through a change to crowd-sourced data upon which it relies.

Allow me to address each of these scenarios. 

Site Admin Changes

Site admins can do anything to your logbook because they can emulate your account.  (There are other admins with lesser privileges too, who do not have this ability).  Why such great power?  Customer support, primarily: I can't track down an issue if I can't see what you see.  

This is, of course completely standard industry practice: when you call Amazon or Expedia or your bank, they can get into your account to some degree or another for precisely these reasons; they wouldn't be able to fix the quantity on your purchase, fix your reservation, or explain a credit card charge if they didn't have these tools.  These are trusted employees, and (particularly where money is involved!) the tools have audit trails so they can't do anything nefarious without getting caught.  And the system works.

I am one of two site admins, and I do pretty much all of the admin work.  I would estimate that more than 95% of the time that I emulate an account, I make no changes at all - I'm trying to track down a bug report, or explain why something is happening, or I need to see some data "in context" to inform a development decision and so forth.

But there are a (very) few scenarios where I will make a change to your logbook.

The most common reason - by far - is fixing aircraft.  I have a very specific way to do anonymous aircraft and sims/training devices to avoid conflicts with registered aircraft, but people will often create aircraft with tail numbers like "BE23" for an anonymous Beech 23 (which could conflict with a Chinese aircraft, which begin with "B") or "FTD" for a sim ("F" is the prefix for French aircraft).  No big deal, it's just a naming thing, and with the press of a button I can map your flights in the misnamed aircraft to the correctly named one and thus keep the set of aircraft clean.

Another area is images.  Data admins (data admins are a distinct set of admins, with more limited capabilities than site admins; all site admins are data admins, but not all data admins are site admins - think of them as Wikipedia editors) have the ability to review images for flights and/or aircraft, and remove any deemed inappropriate.  E.g., if it's porn, if there's a copyright complaint, etc.  Been months (maybe years?) since I last deleted such an image, but I will do it periodically.

There is only one other - rare - scenario where I will modify a flight of yours, that I can think of: signed Flights can sometimes be marked as having a valid signature when they are no longer in sync with what was signed, or vice-versa.  I periodically review these flights and set the state correctly.

That's really it for what ever might happen directly to your logbook without your participation.

Instructor changes

You can have an instructor sign a flight ad-hoc, but this requires that you be face-to-face with the instructor, so I don't think that counts as "without you doing anything".
But if you set up a student/instructor relationship with an instructor, you may grant them certain permission to make changes that they can exercise unless/until you revoke those permissions.

Specifically, an instructor can:
  • Issue new endorsements.  No specific permission is required - if they're your instructor, they can do this.  They cannot delete or edit endorsements.
  • Sign flights that you have requested that they sign.
  • If you've granted the instructor permission to view your logbook, they can also sign any unsigned flight they encounter (or re-sign any flight that they had originally signed but which has been modified), even if you did not request that signature.
  • If you've granted the instructor permission to add flights to your logbook, then they can, umm, add flights to your logbook.  They can also revoke signatures from flights that they have signed (e.g., if they mistakenly signed the wrong flight).

Crowd-sourcing Changes

Perhaps of more interest is the indirect stuff.  When you log a flight in N12345, your flight entry doesn't know anything about N12345 - it's just a reference to an aircraft somewhere else in the database.  And that aircraft, in turn, references a model definition that is in yet another location in the database.  So attributes like "it's a Boeing 737" or "it has a glass cockpit" are not stored in your flight.  See here for considerably more detail about how this all works, but the important thing is that the data about aircraft and models comes from the MyFlightbook user community - and can be edited by the MyFlightbook community as well.

The key point is that if the model of an aircraft that you fly changes, or if the definition of a model used by one of your aircraft changes, then your totals and/or your currency could potentially change.  Yikes!

Or is "yikes" an overreaction?

If you (or someone else) changes an aircraft or a model and you (or they) are the only person with any logbook references to that aircraft/model, then by definition there is no problem: the change made affects the person making the change and nobody else, thus all is good.

On the other hand, if the change is to an aircraft or model that is used by pilots other than the one making the change, then obviously that could be an issue.

In this scenario, an email goes out both to any data admins on the site as well as to any pilot potentially affected by the change.  The purpose of this is twofold: (a) the data admins will review the change.  That's non-negotiable.  But - often more importantly - (b) the affected pilots can see if there's any problem with the change, and they will contact the data admins if there is.  The affected pilots, kinda by definition, actually fly these aircraft and as a result know them better than any admin could.

The vast, vast, vast majority of these changes fall into one of two categories.  The details are described here, but the gist is that most edits are either:

  • A "minor" change that actually improves the accuracy of the data.  E.g., specifying that a "C-172" is actually a "C-172 P".  Either way, it's still a C-172, and your totals/currency/etc. don't change.
  • A more significant change, which ends up resulting in the aircraft being cloned.  Two common examples here are a tail number re-assignment (N12345 was a C-172 but is now a B-737) or an aircraft that is on wheels part of the year and floats on part of the year being edited to indicate the opposite undercarriage.  In this case, your logbook still doesn't change: the clone is detected automatically, and your logbook preserves a reference to the original, not the clone.  (You still get an email, in case the clone is either more accurate for you, or in case you want both versions.)

There are the occasional edits that are in error, or otherwise require reverting.  These are very rare (a few a month, perhaps) and typically corrected within hours of occurring. That's really the primary risk here.  But it is always (a) reviewed by a data admin, so it is (b) fixed promptly.

And the benefits of the two non-erroneous edit examples above vastly outweigh the downside of the rare and short-lived erroneous data.  (And, of course, rare-and-short-lived-erroneous-data happens all the time with curated data, not just crowd-sourced).

As I write this, MyFlightbook has 6-figures of users (wow!) and 8-figures of flights in the database, and has been around for 15 years.  And the examples of this leading to problems of inaccurate computations for things like totals/currency has been...basically nil.

There's one other set of data in MyFlightbook that allows for crowd-sourcing: airports.

Airports in MyFlightbook are a bit of an odd-duck: they're in the database, but they're not "connected" to your logbook in any meaningful way.  You can add airports to your flight that aren't in the airport database and it is no problem.  I keep old airport codes around as long as I can - after all, if you flew to KOLD years ago and it's now KNEW, then KOLD should continue to work.

At a high level, I use airports for 3 purposes:

  • Mapping your flight
  • Showing where you've been
  • In ratings progress, determining if you've met cross-country distance requirements

So if you have a flight that references XYZ and XYZ isn't in the database or refers to something other than what you thought it referred to ("LCL" being a great example - people use that for local flights, but it's an airport in Cuba), then the worst downsides are that your map looks wrong, there's in error computing where you've been, or MyFlightbook thinks you have or haven't met a rating requirement. But none of those are "material" - your logbook still accurately has the record of the flights you've taken and where you visited, as you recorded it.

Most of my airport data (currently over 58,000 airports, heliports, and seaports) comes from various (free) data sources, including the FAA.  Airports entered into the system are considered "native", and cannot be overwritten or deleted by anybody - not even an admin.  Well, OK, I suppose as site developer, I can go directly into the database and delete something...but I just don't do that because direct database access is juggling with very sharp running chainsaws; the point is, there's no tool to do this.

MyFlightbook users can add their own airports (currently over 2,500!).  This is a great addition to the system, with all of the aforementioned benefits of crowdsourcing.  These airports CAN be deleted by either the user who created them, or by a data admin (if they review and decide it's inappropriate for one reason or another), but not by other users.

There are a few changes that can occur in the airport database:

  • By far, the most common is that a new airport is added.  Note that if KOLD becomes KNEW, then I don't change the KOLD entry in the airport database, I add KNEW alongside it so that either code works for the airport.  I'll probably designate KNEW as "preferred", but KOLD will continue to work.
  • If a user enters an airport that looks like its in the same location as an existing airport, and it appears to be an "official" code for the airport (typically ICAO, IATA, or FAA), then I'll "absorb" it into the system, making it native.  Then it can't be deleted.
  • If a code assigned to one airport is assigned by an official organization (ICAO, IATA, FAA) to a new airport, then I'll overwrite the existing name/location for the code with the new name/location.  This is the scenario where KOLD used to be in California but is now an airport in Florida.  
  • I have a tool that looks for user-created airports that are duplicates of existing airports (e.g., with existing FAA or ICAO or IATA codes).  The idea is to try to find where someone made up a code for an airport but that didn't need to do so.  In this tool, I usually simply coalesce the airports and mark the official one as "preferred", but I can also decide to delete the (presumably) made-up airport code, especially if I'm worried about a potential conflict.  If I do this, then the "Route" field of the creating-user's flights containing that code is updated to reflect the remaining airport.  I've only rarely deleted airports in this manner, and because this maps to a more current code, it should map correctly and compute distances correctly. [Update Jan 26: I'm removing the piece of this code that updates the route for user flights].

With the exception of the last scenario, no flights for any users are changed.  The only change that you would notice is in the third scenario: if you have a flight with KOLD in the route, then it will map using the new location rather than the previous location.  Of course, that's what it would do in ForeFlight, Garmin, or any other mapping app, as you'd expect.  

I think it's more accurate to say that changes in the airport database don't change your logbook, but they can change the map or analysis of your logbook.

And that's about it.  Personally, I think the tradeoffs - the benefits of lots of eyes keeping the data accurate and up to date - vastly outweigh the rare and ephemeral errors.

Hopefully this explains what can - and cannot - be affected by MyFlightbook's crowd-sourcing.

Sunday, January 10, 2021

Models - In Depth and Best Practices

Aircraft and models on MyFlightbook are crowd-sourced and shared amongst its users.  This has a huge benefit for the comprehensiveness of the data and - with a bit of curation - with the accuracy of the data as well.  The ability for any registered user on the system to make changes here is a powerful tool.  Any powerful tool, however, carries risk if used incorrectly.  In this post, I'll talk about how the models part of system works, how it is properly used, and how the risk is managed.  (Spoiler alert: in practice, the system works well and so the risk is negligible.)

The difference between an aircraft and a model on MyFlightbook

The important thing to understand on MyFlightbook is that a "model" encapsulates a set of attributes that are common across a set of multiple airframes.  This includes attributes like the category/class of the aircraft, whether it is turbine or piston, high-performance, has retractable gear, and so forth. For more detailed information, please read my previous post.
So, for example, there is one "Cessna C-172 R" in the system, but there are (as of this writing) nearly 1,600 distinct aircraft in the system that are tied to the "Cessna C-172 R" model.  It is the "Cessna C-172 R" model that captures the fact that it is an airplane, single-engine/land ("ASEL"), piston, not high-performance, not tailwheel, ICAO code "C172", marketing name "Skyhawk", and so forth.

Data points that vary from airframe-to-airframe are stored on that aircraft's record in the database.  The tail number (registration) is the most obvious such piece of data, but there are private notes (notes only you can see), shared notes (visible to anyone who flies that aircraft), maintenance records, glass/TAA upgrades, and other data.

It's worth briefly pointing out two special cases within this model.  The first is that not all aircraft in the system are flying machines - some are training devices/sims.  While there are some special rules around these, you use them in your account the same way you would use any other aircraft, it's just that instead of being a flying machine it's an ATD or an FTD or an FFS.  In fact, some models of aircraft (such as anything created by Frasca or Redbird) are flagged as "Sim only", so the system knows not to let you create registered aircraft with that model.  See here for more information about simulators/training devices.

The other special case is that of an "anonymous" aircraft.  An anonymous aircraft is just like any other aircraft, except that it has no specific tail number.  Internally, it has a pseudo-tailnumber that is the hash mark (#) followed by a series of digits that represent the model.  For example, the anonymous C-172R is "#000099". That tail number is used for unambiguous identification of an aircraft when importing/exporting, but in general the system will show the underlying model name ("Anonymous C-172R") rather than the #000099 tail number.  Because that's a single number for an anonymous instance of a given model, anonymous aircraft are necessarily shared amongst pilots.

Relationship between Aircraft and Models

A key attribute of how shared aircraft/models work is to understand that these relationships are all computed in real-time.  That is, an aircraft in the database does not have any information about its associated model, it only has a reference to the model.  In turn, the model holds a reference to the manufacturer and even to the category/class.

So when you see "N12345 - Cessna C-172 (ASEL)" in your account, that is all being assembled in real time: I look up "N12345" in the database and find the ID of a model.  I then look up that model and find that it has model name of "C-172", an ID of a manufacturer and an ID of a category/class.  I then look up the manufacturer that has that ID and find that the manufacturer is named "Cessna" and I look up the category/class by its ID and discover that it is "ASEL".  

Because none of this data is stored directly in the aircraft, all changes happen immediately to all related aircraft.  For example, if you were to edit the C-172 model to be a helicopter rather than ASEL, then instantly not only would N12345 become a helicopter, but ALL aircraft in the system that are linked to that model would also become helicopters.  Any subsequent totals computation or currency computation involving any aircraft tied to that model would suddenly now have helicopter time and helicopter currency.

That can be risky, but in practice it works just fine.  First and foremost, there's an honor system involved that people don't make random edits like changing a C-172 to be helicopter.  For 14 years and counting, this has worked extraordinarily well.  But as a backup ANY edit to a model results in an email being sent to the site admins, which details the specific change, and that can be reviewed and modified (or reversed) by the admin.  As it turns out, the vast majority of edits to models are minor things like indicating high-performance, or editing the name to be consistent with other similar models.

Admins also review any newly created models in the system for errors, consistency, and redundancy; if a new model is redundant with another existing model, then the two will typically be coalesced.  No notification is generated when that occurs.

Editing aircraft works in the same way, but obviously the scope of the impact is limited to pilots in that specific aircraft, and there are a few other rules involved (see this post about aircraft edits).  In this case, email about the changes is sent not only to the admins for review, but to other pilots who fly that aircraft as well.  This ensures that all changes are reviewed, and that errors are quickly caught and fixed.

Best Practices and Conventions

Please try to follow these guidelines when editing models:

  • If a specific aircraft is wrong (e.g., is the wrong model), then edit the aircraft, not the model.
  • Only edit a model if the definition of the model itself is wrong and thus if all aircraft associated with that model need to be corrected.  E.g., if you see a Boeing 737 listed as piston, then you should edit it.
  • Please do a search for existing models before creating or editing a model; there's a good chance that the model you want is already in the system.  When you create a model, the system will also check to see if it looks like you're creating a duplicate and will show you existing models that look like matches.  While it's best to re-use an existing model, you can proceed if it truly isn't a match.
  • The FAA (and other authorities) have a particular level of granularity for models; ICAO uses another.  Since MyFlightbook launched in 2006, it's been pretty clear that the community prefers more granularity/precision to less.  So you'll see many model designations on MyFlightbook that might map to the same designation within these registries.  That's OK and a good thing.  There's no problem with having more fine-grained distinctions based on upgrade packages, aircraft vintage (e.g., when one manufacturer gets sold to another), and so forth.  As a simple example, there are enough G1000-equipped C-172S’s out there that it’s got its own model designation in the system, even though it’s simply a C-172S.
  • Glass and TAA are one area where things are often confused, since these can be part of the base design (All Boeing 787's that have ever been made are glass/TAA), a factory option (even if everybody orders glass as a practical matter), or an upgrade to a specific airframe.  In general, the model should indicate glass/TAA only if it is part of the base design.  If it's a factory option, it should either be indicated on the airframe, or alternatively it's OK to create a new model that is explicitly a glass-only variant.  For example, there are so many G-1000 equipped C-172S's that there is both a "C-172S" in the system that is not marked as glass (so you'd indicate glass on the specific airframe if it is glass), but there is also a "C-172S G-1000" model in the system that is all glass.

An admin will review EVERY new model and EVERY edit to a model in order to check for redundancy and consistency.  Generally, this requires some triangulation between multiple sources.  Not only that, but I often have more granularity than any one of the sources. If two variations look identical, I’ll merge them, but otherwise I will allow it.  I do, however, try to enforce some consistency.

Here are some of the conventions I try to follow.  Some are a bit more ambiguous than others.

The “Model” field is probably the least well defined.  I tend to use a combination of:
  • The FAA registry page or comparable non-US websites.  Note that this is not always super precise (sometimes listing a C-150 as a “150” instead of, say, a “C-150M”) and if registrations have been reassigned the old one assignment might not be present.  But it will generally distinguish, say, a C-172S from a C-172P.
  • Wikipedia
  • MyFlightbook user community.  In particular, this helps with 4 specific conventions:
    • Hyphenation conventions.
    • Distinguishing float vs. wheel versions of an aircraft: generally you would name a C-172 on floats “C-172 (Float)” to highlight the distinction from its wheeled counterpart. (See here for more on floats/amphibs).
    • Distinguishing sim-only versions of an aircraft.  E.g., a Flight Safety 737 would typically be “B-737 (SIM)” so that nobody thinks they can create a real flying 737 using that model.
    • Where models can have conversions that make them high-performance or give them a constant-speed prop, we’ll generally add “(FP)” for “Fixed Prop”, “(CSP)” for “Constant Speed Prop” or “(HP)” for “High Performance next to the model name.  E.g., “C-172 M/180HP (CSP)” for the superhawk variant of the 172 M that has a constant speed prop and a 180HP engine.
Note that because of the desire for high-precision, sometimes the model in MyFlightbook will deviate from the "nameplate" model.  An example here is the PA24.  Piper made multiple PA24 models; the plain "PA-24" had a 180hp engine, while subsequent variants with more powerful engines included the horsepower after the model - e.g., "PA-24-250" with a 250hp engine, or the "PA-24-260" with a 260hp engine, and so forth.  But the 180hp engine was simply "PA-24" on the nameplate; there technically was never a "PA-24-180".  On MyFlightbook, though, there is both a "PA-24" and a "PA-24-180".  This is because the former could mean "It was a PA-24 with 180hp", or it could mean "It was a Piper PA-24, but I don't remember which variant it was."  So the latter allows you to very clearly indicate the 180hp meaning.

The ICAO designation field is much more precise, and we treat the ICAO website as an authoritative source. Note that this really only applies for Airplanes and Helicopters on MyFlightbook.  ICAO tends to lump all balloons into "BALL" and gliders into "GLID", but that's a coarser granularity than the community generally want, so please leave the ICAO field blank for anything that is not an airplane or helicopter.  

Also note that the ICAO code is very coarse: multiple different variants of an aircraft often share a single ICAO code; the C-172 is a great example: all C-172’s are “C172”, whether it’s a C-172P, C-172N, C-172RG, etc. 

For the Type Rating field (generally only jets or large aircraft), MyFlightbook treats the FAA Type ratings taxonomy as authoritative.  It isn’t totally comprehensive, but I use it when possible.

Summary - don't sweat it!

There's a lot to digest above, but the key thing to remember is that someone will review any (a) new model, (b) edit to an existing model, or (c) edit to an aircraft that has the potential to impact other pilots.  So do your best, but don't worry about getting everything just right; we've got your back.  

At the end of the day, this results in a super comprehensive and increasingly accurate data set, which benefits us all.

Friday, December 25, 2020

Searching, Totals, and Insurance

One of my motivations for writing MyFlightbook was frustration 15 years ago filling out insurance reports, which seem to want to know how much time you have in purple airplanes on Thursday nights in months ending in "y".  These numbers were painfully difficult to extract from my paper logbook, but I knew that they were trivial for software.  MyFlightbook has obviously evolved a bit beyond that since then, but the need for these sorts of numbers remains.

Sadly, there's no standardization for what insurance companies, flying clubs/FBOs, or employers want to know, so sometimes the information you want can be found in several places, but the search tools are designed to make it easy to ultimately get what you want.

How Search and Totals Relate

By default, looking at "Totals" on MyFlightbook shows you the totals (and some subtotals) across all of your flights.  Pretty much anything that can be summed shows up here: flight times, counts of landings or approaches, and so forth.  So if you want to know how much PIC time and SIC time you have, just go to totals and you'll see it.

But sometimes you want to know how much PIC and SIC time you have in, say, Boeing 737s.  This means you want to do the usual totals but on only the subset of your flights that were in 737s.  If you do a search for flights where the model of aircraft is a 737, and then click on "Totals" on the screen where you see your results from the search, the resulting totals reflect only 737 time, so you can read the PIC and SIC totals right off of this screen.  (Note: here I'm discussing the web interface; on the iOS or Android apps, the order is reversed: you go to the totals screen and do the search from there; when you return to totals, the totals are update to reflect only matching flights).

In other words, Search acts as a filter on your flights, and totals are then computed on only those flights that survive the filter.  As a result, you don't want to select the totals you're looking for in your search criteria.

Notice that in the example above, I did not suggest searching for flights with PIC time and/or flights with SIC time, even though those are the times for which you are "searching".  That could yield incorrect results.  Why?  Because you want PIC/SIC totals, but searching for PIC/SIC time filters on PIC/SIC time.  

So, for example, consider the following 3 flights:




If you search for flights with PIC and SIC time, none of these flights will match, and your total will erroneously be 0.  The moral of the story here is to use search to filter flights, not to specify the totals you want to see.

Getting Totals for Insurance/FBOs/Clubs/Employers

For the most part, you can simply read the results in the "Totals" screen for most of the values that you need: your total time, your PIC time, time in category/class, and so forth.

But often the insurance company wants to know things sliced a bit differently, such as how many hours you have this year vs. last year, how many hours you have in a particular model of aircraft, how much night PIC/SIC you have, and so forth.

You can generally do a search to find these results - e.g., searching by date range, or searching based on model.  When you do the search, the resulting totals will include the values you want. 

But often you can get this information from readily available reports, which can generally be found under the "Training" tab.

One of the most useful reports here is the "Rollup by Model".  This is analogous to the "" format, a sample of which is shown below:

The advantage of this report is that it breaks totals down by model of aircraft, letting you directly read your total for each model.  It also includes a breakdown by time, showing you your total for all dates, as well as trailing 12-month and 24-month periods.

In a similar vein, the "Rollup by Time" report shows you your basic totals striped by time periods, so that you can easily read out year-to-date and previous-year totals.

Of course, one of the key set of values people need when applying for new ratings is the 8710 / IACRA report.  This one is worth diving into a bit because of how it computes "combination" values like night-PIC/night SIC.

Let's again consider the sample flights above:




If we were to simply sum the totals here, we would get the following, which is a correct summary of your total times:

  • Night: 1.7
  • SIC: 2.5
  • PIC: 1.8
  • Total: 4.3

But you cannot easily glean from this how to apportion your night-PIC and night-SIC.  What the 8710 / IACRA report does in this situation is to add MIN(Night, PIC) and MIN(Night, SIC) for each flight to the night-PIC and night-SIC totals.  So in this example, it would accrue 0.5 hours of night-SIC and 1.2 hours of night-PIC, which would be the correct values here.

Alternatively, you could search on flights with PIC time and then read the "Night" total to get night-PIC value, and then do the same SIC time, but I generally would advise against that both because it's easier to just read the values out of the 8710 report, but also because it won't always yield the results you intend.  

For example, imagine that you were a safety pilot for someone on a one-hour night flight, and you log half an hour of PIC time and half an hour of SIC time for the flight.  In that case, this flight properly is 30 minutes each of night-PIC time and night-SIC time.  But if you simply search for flights with PIC time, this will survive the filter and thus the "Night" total will reflect the total night on the flight, which is a full hour.  Doing that search and reading the "Night" total would thus be overstating your night-PIC time by half an hour.

Note that the 8710 form (and the other reports) can also be filtered using the same search criteria as the main totals page, so if you want to know, say, your night-PIC time in a particular model of aircraft, you can search on that model and the resulting 8710 will show your your night-PIC in that aircraft.

Other common totals

Often you need other totals, such as time flying glass avionics.  This is not generally broken out for you in any of the built-in reports on MyFlightbook, but it's easy to get.  In this example, just do a search for the criteria in question (in this case, flight aircraft is glass) and the resulting totals will reflect your total time, PIC time, etc. in glass aircraft.

What gets a little trickier is if you want to know things like your time NOT in glass avionics-equipped aircraft.  While MyFlightbook makes it easy to find flights/totals that meet a criteria, it's a little harder to find flights/totals that don't meet a given criteria.   So a little math is in order: first you find the totals for all of your flights.  Then, find your totals for flights that meet the opposite criteria of what you want (in this example, glass cockpits).  You can then simply subtract one from the other.

Other searching tips

MyFlightbook offers pretty sophisticated tools for finding exactly the subset of flights you want.  Here are some tips/tricks for effective searching:

All searching is case insensitive and partial word searches.
  • By default, a flight must match ALL of the criteria that you specify in order to be included in the result set.  The more criteria you specify, the fewer flights will match.  But some sections of search criteria (namely flight characteristics and presence of flight properties) allow for you to specify "ANY" or "NONE" criteria.  "ANY" in this case means that any of the criteria will satisfy that section.  (If there are additional criteria specified outside of that section, then that criteria must also be met).  "NONE" works in the same way: if the specified criteria is met with NONE specified, then the flight is rejected.
  • If you search for "Local" flights, it will find any flight that has exactly one airport in the route, or that has the same airport twice.  E.g., "KSFO" or "KSFO-KSFO" are both considered local flights.  "Non-local" flights will return anything that leaves the home field.  I.e., this is basic cross-country by the 61.1 definition.
  • When searching in the "Flight visited any of these airports" field, you can use "!" as a prefix or suffix. !ABC matches flights that depart from ABC (i.e., ABC is the first airport in the route of flight), and ABC! matches flights that arrive at ABC (i.e., ABC is the last airport in the route of flight).
  • In the "Model Contains" field, you can type a partial string to match on the full name of a model (including manufacturer).  For example, if you type "Cessna" then you'll match flights in any Cessna.
  • In the "Model Contains" field, if you search for "icao:xxx", then it will only find flights in aircraft that have an exact match to xxx in the ICAO designation for the model.  E.g., "icao:b772" will match flights in a Boeing 777-200, but not in a Boeing 777-300 (which has an ICAO code of B773).
  • There is also a field where you can search for any text within the flight (route, comments, properties, etc.). This roughly follows Google conventions:
    • ILS VOR = must contain "ILS" and must contain "VOR" (but not necessarily in that order, separated by anything)
    • "VOR DME" = must contains "VOR DME" (inclusive of spaces)
    • ILS OR VOR = contains ILS OR contains VOR
    • -ILS = must NOT contain ILS
    • -"VOR DME" = must NOT contain "VOR DME"
    • -"VOR-DME" must NOT contain "VOR-DME" (i.e., the hyphen inside the quoted text is preserved, not negation)
    • -VOR -ILS = contains neither VOR nor ILS ("NOT VOR AND NOT ILS")
    • -VOR OR ILS = doesn't contain VOR OR does contain ILS.
  • You can also specify trailing dates in the free-text field. If you type "Trailing:" followed by a number followed by one of D, W, M, or CM, then this will override any other date setting and set the date to the specified number of Days (D), Weeks (W), Months (M), or Calendar Months (CM) prior to today. For example:
    • "Trailing:90d" - restricts to the 90 days leading up to today
    • "Trailing:36CM" - restricts to the 36 calendar months prior to today.  (E.g., if today is Nov 8 2020, then this will find flights on or after Nov 1 2017)


Wednesday, October 21, 2020

Electric aviation

Over the past few years, we've seen a flood of drones - almost all electrically powered - take flight in our skies, making up the vast majority of electric flight today.  But we're also starting to see more and more manned electric aviation in our skies, such as the recent test flight of Ampaire's 6-seat modified 337, Bye Aerospace's forthcoming 2- and 4-seat all-electric trainers, and the recently certified (in Europe) Pipistrel Velis Electro.  I think there's an interesting trend here that is well worth watching, and I'd like to weigh in here with some of my thoughts.

At a high level, I think it's worth stating up front: these are early days, there are significant challenges to solve, and fleet turnover is a very very slow process.  While I do think it's very possible we could see an electric equivalent to the Cessna 172 within a decade, I suspect that an electric transport aircraft (i.e., more than 30 people, more than 1,000nm range) is unlikely within even 20 years.  But 30?  There I'm not so sure.

I'm an amateur in this space, but I think I'm qualified to weigh in here nevertheless.  I am a (piston) pilot myself, so I know a little about aviation. I have one degree in physics and two in electrical engineering, so I'm something of a geek on the technology side.  I've spent the last 14 years as an "angel investor" in early stage companies, so I have at least a bit of experience trying to spot technology trends.  And I've been driving electric for almost 8 years ago, so I've experienced the liquid-fuel-to-electrons transition directly, learning a few things in the process.  

As the saying goes, though: It's hard to make predictions, especially about the future.  So below I'm going make observations based on the trends I see, with some extrapolation, rather than making outright predictions.

Why Electric Aviation?

Why is electric aviation ("EA") even interesting to consider, when existing fossil/liquid fuel based aviation (I'll refer to this as "LFA") works pretty darned well?  There are many reasons.

But first, a disclaimer: for the sake of this discussion - I'm going to make a simplifying assumption that the environmental impact of both LFA and Electric Aviation (EA) are both identically zero.  Why?  Three reasons: (a) I don't want to get into a policy/political discussion; I think the technology/economic trends are fascinating enough, (b) you don't need environmental arguments for EA to be an attractive proposition, and (c) EA is still not real enough that any statements about its environmental impact pro or con are meaningful.  Perhaps in a later post I can talk a bit about that, but for this post I will not make any argument involving emissions/environment/etc., nor about any policy to try to push EA over LFA: I'm going to assume here that policy is frozen as it is today, with the small exception of fixing obviously broken things like requiring an oil gauge for each engine in order to be more technology agnostic.

Where was I?  Oh, right: what benefits does EA offer over LFA?  Many, I think (obviously assuming that the technological and economic issues can be addressed).

The first is reliability. Electric motors have few moving parts, and very few failure modes.  They deliver torque across a wide RPM range.  You can't over or under lean; the engine doesn't need air to operate so it can deliver full power at any altitude. There is no fuel contamination, no detonation or pre-ignition, and the "TBO" is generally...well, forever.  (OK, my lack of turbine expertise is clearly showing through here; but I am comfortable asserting that electric engines are much simpler.)

Related to reliability is safety, but don't think I can make a definitive call either way on that.  Batteries have obviously had issues with thermal runaway, but equally obviously all liquid fuels are by definition highly flammable.  New battery designs have improved safety, but its hard to say whether future battery technologies will be safer - or will have different dangers to be aware of.  Something to watch...

A related advantage of EA is maintainability.  With so few moving parts, there just isn't a lot to inspect or maintain: no belts to break, hoses to burst, no oil to check/change/drain, no starter motor, no fuel filters or air filters, etc. Electric motors are lightweight and can allow for more aerodynamic designs (for example, for a single-engine propeller airplane you can have a narrow cowling because you don't need airflow through the engine; this also allows more of the propeller's lift to become thrust) and the "fuel" has no weight at all - you can always apply all of your useful-load to payload, take-off with "full-tanks" even with full load, and you have no fuel-related center-of-gravity issues to manage in-flight.

Electric motors are also significantly more efficient. Your car's internal combustion engine turns only about 20-35% of the gasoline's chemical engineering into forward motion, a jet engine has higher thermodynamic efficiency, turning about 55% of the fuel's energy into useful work; electric engines, on the other hand, are commonly north of 85-90% efficiency.  These latter numbers are energy-in/energy-out, so net propulsive efficiency (= energy-in / kinetic-energy of the aircraft that results) is a bit lower due to propulsion inefficiencies, but here I'm just comparing the power plant.

Electric engines have low operating costs.  This obviously varies on a lot of factors, but a joule of energy delivered electrically is often significantly cheaper than a joule of energy in liquid form.  When coupled with low maintenance costs, the impact on cost-per-mile can be significant.  By analogy, my experience with my EV has been that it's about $0.03/mile (I go about 3.3 miles on a kWh, which costs me about $0.10 where I live), whereas my previous car, a 25-mpg sedan (a lighter car, believe it or not), would cost $0.08/mile at $2/gallon (a price I think I never saw while I owned it), nearly 3x as much; as they say, your actual mileage may vary, but the principle stands.

Electric aircraft are quieter.  Sure, a propeller makes noise, but take the engine out of the equation and the noise level can drop considerably.  Switch from one or two high-RPM propellers to more low-RPM propellers (see below), and the noise level drops significantly more.

But perhaps the biggest advantage of electric aviation is the most subtle: the engine is abstracted from its power source.  In other words, it doesn't know or care from where its energy source is derived.  All conventional LFA engines are intimately connected with their fuel source.  (Try putting Jet-A into your piston aircraft and see how that works out for you.) A huge part of the engineering of LFA engines is all about getting a very specific liquid fuel to the right place at the right time with the right mixture with the air and only then converting it to energy from which to produce thrust.  Think of carburetors and fuel injectors, air filters and ducts, mixture controls, spark plugs, valves, exhaust systems (again I'm displaying my piston familiarity and turbine ignorance here...), all of which makes the LFA engine intimate with its energy source.  

None of that is true in an EA engine.  The wires are carrying electric current.  It simply doesn't matter if the source of that energy is dead dinosaurs (yeah, I know it's probably plant-based, but that's a less interesting metaphor),  nuclear, solar, or humans-in-vats a la "The Matrix".  

That abstraction carries at least five very under-appreciated but significant benefits:

  • The engine is simpler, more reliable, more maintainable, higher efficiency, etc. precisely because it can throw out all of the stuff related to the liquid fuel and work with electrical energy in a much simpler manner.  
  • There's no notion of having the right grade of fuel.  (Look at how difficult it is to come up with a drop-in replacement for 100LL, for example!)  Electrons are electrons.
  • Because the engine is simpler/lighter, and wires are much easier to route than fuel and exhaust, non-traditional designs that improve performance and safety become more feasible.  For example, instead of just one or two big engines, you could have 10 small engines.  An engine failure in such a design is effectively a non-event.  You could even imagine designs where you - the pilot - could snap-in or remove engines on the fly (no pun intended), removing engines for efficiency in a lightly loaded flight and adding more when you need more thrust, perhaps allowing you to trade off range and useful load on a mission-by-mission basis.
  • It enables software (rather than hardware) control, which means updates and improvements are easy and inexpensive to deploy widely.  (Over-the-air updates is one of my favorite features of my EV, by the way - and many of the enhancements simply could not be done with internal combustion).
  • Most importantly, it means that the engine - and thus the aircraft - can enjoy any improvements to the energy source.  So if you buy an electric airplane in year 1 and in year 6 a new battery technology is available that is lighter, cheaper, and higher capacity, then your aircraft can suddenly have longer range and more useful load.
Of course, allowing the engine to be ignorant of its power source just pushes that problem to the power source itself.  Which makes a great segue to...

Technology trends

With all of the above, why does LFA continue to dominate?  Two words account for almost the entire reason: energy density.  There are a few other factors I'll discuss, but this is the big one.

It's actually the exact same reason that gasoline/diesel cars continue to dominate automotive transportation.  For all of the many advantages of electric engines, having a dense power source is critical, and today, liquid fuels provide that.  This is changing, more rapidly on the ground than in the air, but the transition in ground transportation is driving innovations that will benefit EA.

First let me distinguish two kinds of energy density, both of which are important.

  • Volumetric Density is a measure of how much energy you can store per unit volume.
  • Specific Energy or Gravimetric Density is a measure of how much energy you can store per unit of mass (weight).

Obviously, for aviation, both space and weight are at a premium, so you want a very high volumetric density, in order to pack as much energy as possible into whatever space you have, and a very high specific energy, to carry as much energy as possible for every bit of weight you can carry.

Batteries in 2020 have improved - dramatically - over the past 20 years, to the point that cars with more than 300 miles of useful range are economically viable.  But aviation is an energy-intensive endeavor.  How do current batteries stack up against liquid fuels?

Gravimetric Density
Volumetric Density
100LL44 MJ/kg
31.6 MJ/L
Jet Fuel43 MJ/kg
35 MJ/L
"Standard" Lithium-Ion
(actual numbers vary
based on technology)
~750 KJ/kg
~1.2 MJ/L

Wow.  So liquid fuels are about 58x more dense on a weight basis, and 25-30x more dense on a volumetric basis.  Those are truly daunting ratios.  For EA to compete head-to-head with LFA, it needs to make up a deficit of almost 60x.  Game over?

No.  And here's where I'm going to do some back-of-the-envelope math and extrapolate various trends.  I'm going to switch now to rough numbers, since we're talking trends, various technologies, and long timelines.

The first thing I'd observe is that significantly more energy is wasted as heat with liquid fuels than in an electric system.  Going electric means going from 30-50% efficiency to potentially over 90%.  It's not quite a 2x improvement, but it's close. So for the sake of rough math, let's say that the hurdle for EA to overcome comes down from roughly 60x to roughly 30x.  Still an order of magnitude.

Where is battery technology headed over the coming years?  The first place to look is to extrapolate trends to date.  They're encouraging, having more or less tripled over the last 10 years:

Of course, as they say "past performance is no guarantee of future performance": battery advances are dealing with difficult physics and chemistry, and each advance is hard fought and hard won, but the incredible growth of solar and EV's have produced a tailwind of R&D here that does not show signs of abating any time soon.

It's hard to say what that means for our 30x multiple: the first 3x is certainly easier than the next 3x.  But there are encouraging signs that there may be some step functions ahead of us.

The picture below is from a webinar in which I was a speaker in a few months ago for my angel investing group, showing various technologies on the horizon.  Current commercial Lithium-Ion Batteries (LIB) are the dark blue.  (For comparison, lead-acid, which is in your car and in your aircraft's starter motor, is the red dot in the lower left corner; the aqua oval is Nickel Metal Hydride).

All of these are shown as rough regions rather than precise dots because within each technology there are a variety of technology choices that can be made, and in the case of just about everything to the right of LIB, these are technologies that are available in a lab environment but not not yet ready for widespread commercialization.  Chemistries like Lithium-Sulfur and Lithium-Air (Li/O2) are on the horizon and can increase gravimetric density by approximately a factor of 4-5.  This alone would reduce the hurdle from 30x to about 6x.  And given the optimizations and improvements that inevitably happen once a technology leaps from the lab to being commercialized, I would be surprised to see us hit a hard wall.  

6x may sound like it's still a big gap - and it is.  It is not remotely adequate for long-haul flights, for example.  But it's also no longer a full order-of-magnitude problem; at that point, EA and LFA can find themselves in the same ballpark. And given the opportunities to play with the aerodynamics of the aircraft themselves, fine-tune L/D ratios without being constrained by one- or two- big engines, and adjust operating speeds for efficiency, it's more than sufficient for a huge range of shorter-range flights.  Boston-New York, London-Paris, or Miami-Orlando runs are quite good examples of routes flown today by 737-class aircraft but which do not need the range that aircraft provides, and which are short enough that slowing down by 25-40% wouldn't appreciably impact the value proposition of flying vs. other modes of transportation.  And as 6x becomes 5x and smaller, the set of flights for which this is interesting simply grows monotonically.

Volumetric densities don't show quite the same sort of potential increase - perhaps 2-4x improvement.  But batteries have geometric advantages over liquid fuels.  For one, since wires are easier to distribute than fuel lines, you can distribute them more broadly throughout the aircraft, which can actually help with things like center-of-gravity design.  Another advantage is that you don't have to worry about gravity/low-points, pumps, and the like.  So if the gravimetric density is high enough, you can get creative about the volumetric challenge in ways that you simply can't with liquid fuels.

The net result is that advances in batteries alone could achieve energy densities sufficient for a significant number of real-world mission profiles over the next decade or two.  

But of course, there's no requirement that energy storage be entirely in batteries.  Remember the value of abstraction of the energy source from the engine?  This means that you can get the benefits of electric propulsion with other sources of energy.  For example, low-temperature fuel-cells can provide electricity using highly energy-dense chemical (liquid) fuels, virtually eliminating any energy density issue.  Or you could pair electric propulsion with some sort of combustion (turbine or piston) power generation; this is how many modern trains work.  More fancifully as a thought experiment, if someday the Mr. Fusion from "Back to the Future" were to become reality, you could swap that in and fly indefinitely.  The bigger and more interesting point here is that going electric means you can mix-and-match to fit your mission profile and to take advantage of whatever technology advances arise on the energy source/storage side of the equation without having to completely redesign your propulsion system.

Enough about energy density, there are a few other technology challenges for electric aviation worth discussing.

One, of course, is charging.  One advantage of LFA is that you can turn around very quickly after a flight.  While fast-charging technology exists for batteries today, it is still slower than filling a tank with a liquid, and is harder on the battery itself than a slower charging rate; these are both areas of active research.  There is already one solution, though, to electric "fast charging:" battery swapping, where you keep a cache of fully-charged batteries, and when a plane lands you literally remove the depleted battery and replace it with a fully-charged one, which you then recharge at your leisure.  There is no technology challenge to this at all; rather, it presents a logistical and economic challenge.

I should note, though, that even without battery swapping EA can actually have an advantage in charging over LFA: batteries can charge unattended.  So while slow charging is hugely limiting if the mission requires fast turnarounds, it is generally not a problem for missions where you don't need a quick turnaround, such as trips where the plane flies outbound one day and returns another.  By analogy to my electric car: yes it takes longer for my car to charge than my old car took to refuel, but I personally save significant time because I don't have to be involved: I used to devote about 15 minutes out of my commute ever few days to detour to a gas station to fuel my car.  But now, I plug it in and abandon it at the end of the day and it's fully charged waiting for me in the morning.

As for charging infrastructure, I don't think there's any meaningful technology challenge to overcome; it's a matter of building it out, and that's an economic, not technical, issue.

Another technology area to watch is trends in 3-D printing and lightweight materials like carbon fiber.  Costs and efficiencies for both continue to improve dramatically as economies of scale from other industries kick in.  Both of these technologies can yield lighter weight (and often stronger!) aircraft and novel and efficient aerodynamic designs.  Of course, both LFA and EA would (and should!) benefit from these improvements, but my key observation here is that while it improves LFA in the missions that it already serves, it has a disproportionate positive impact on EA by enabling it to serve previously unachievable missions.

Finally, I recall a presentation given by NASA at Oshkosh a few years ago about research regarding an Electric 737 equivalent, and the speaker commented that the most difficult technological issue was not energy storage per se, but rather heat dissipation, from the enormous power (2.4MW!) that must be delivered in a small space during high-power operations.  In LFA, the combustion (which generates most of the heat) happens right at the motor where it can be quickly air-dissipated; in EA, the bulk of the heat is generated from resistance in the batteries and in the wires as current travels between the energy source and the engine, raising a novel engineering challenge.  Some of that heat can clearly be used for cabin temperature control and for heated airfoils for flight into icing, but this won't eliminate the heat management challenge.

Economic Trends

Even if the technological challenges above are addressed, EA will be confined to niche applications unless it can compete economically with LFA.  As discussed earlier, EA is very likely to have lower operating and maintenance costs than equivalent LFA from the outset.  

It's the capital costs that are high today - in particular, batteries are expensive.  And they are life limited, so while an electric aircraft engine might have a TBO well beyond that of an LFA engine, the batteries likely will need to be replaced every few years.  Add in potential spare battery packs if you want to do battery swapping, and the costs - today! - can be quite large.

The key trend to watch here, though, is that battery costs have been falling.  Dramatically. Indeed over the past decade, they hit predicted prices years or even decades sooner than expected.  I love this chart from S&P Global which shows a decline of 87% over the decade:

SNL Image

This is why the original Tesla Model S and Roadster were so expensive, but now you're seeing electric cars enter the market at up-front prices that are in the ballpark of their internal combustion equivalents (in fact, depending on the study you cite, up-front unsubsidized price parity for EVs is nearly upon us).

The shape of the graph above shows an exponential decline.  The funny thing about those sorts of trends: they almost never have a sudden flattening.  Economies of scale and incremental improvements tend to keep them going for a while, and the S&P article cited above forecasts another 50-60% drop within the next 5-10 years.  And if the accuracy of previous forecasts about price is any guide to the accuracy of this one, then we should assume it is overly conservative and will in fact be a lot faster than predicted.

Newer more dense battery technologies will undoubtedly enter at the higher end of the price spectrum, but they will also benefit from the efficiencies (manufacturing, safety, supply chain, packaging, distribution, etc.) that drive the shape of the curve above, so my expectation would be that it will follow a similar shape, with faster rates of decline.

EA will also be able to draft off of the tailwinds from increasing EV penetration.  EV growth is driving battery management sophistication, charging infrastructure and methods of payment, investment in lightweight materials like carbon fiber, and so forth.  All of the benefits of traversing those learning curves will accrue to EA.

The other big challenge for EA is charging infrastructure.  LFA has a massive installed infrastructure to ensure that fuel is available to a lot of airports; today, at least, there is very little comparable charging infrastructure.  The good news here is that - as mentioned above - this is not a technology problem, or a distribution problem.  There's nothing really to invent, and just about every airport today that has fuel (and many that don't!) already has electricity.  It's an economic/business challenge: upgrades are often required to the electrical panels to support higher amperage loads, charging stations themselves have to be installed and maintained, payment/customer-support infrastructure needs to be handled, and so forth.

As an aside: the distribution of "fuel" is easier for EA than for liquid fuels.  100LL, Gasoline, and Jet A all need distinct distribution pipelines, refineries, storage, and pumps.  Adding charging infrastructure to an airport, though, can share and build on the electrical infrastructure that's already in place, and it serves a single universal energy source to any electric aircraft.

The good news is that EVs provide a great template for how to do this, and the scale of the problem for aviation is significantly smaller - both in terms of fleet size and in terms of the number of charging stations needed.  For example, the US currently has about 168,000 gas stations, but only about 4,000 airports that have fuel services of one sort or another, so the scale of the problem is significantly smaller than that for EVs.  And there's yet another benefit of the abstraction I mentioned above: in electric aviation, there's no need to find an airport with fuel appropriate to your aircraft: electricity is electricity, the only difference might be charging speeds that are available.


I certainly don't want to be a Pollyanna about electric aviation, particularly for long-range or high-capacity aviation.  There are significant and very real technological and economic challenges to overcome  But I also think that the trends are actually aligned for tremendous innovation as well.

Despite the significant technological hurdles, electric aviation is already "taking off" (pun intended), as evidenced by the examples at the top of this post.  Technology development is almost never a linear extrapolation of prior trends.  New technologies rarely are able to compete as drop-in replacements for existing missions: the first PCs were effectively toys; the first cell-phones didn't displace landlines, cars didn't merely replace horses and buggies, they created entirely new modes of transportation.  (Interestingly, EVs are being held to the "drop-in replacement" standard, and they're actually doing pretty well at that!).  These technologies find niches where they can compete, and grow from there rather than taking on incumbent technologies head-on from day one.  Drones are an obvious such niche, where the tradeoffs actually work very well in favor of electric already today.  And I think Bye is wise to focus on the training sector, where range/endurance is not the most critical factor.
And what's fascinating to me about Bye, Pipistrel, and Ampaire is that they are showing that electric manned flight is not impossible.  That's actually the critical step - after that, it's a matter of slow but steady iterative improvement that expand the set of achievable missions.
I believe, though, that we're going to be surprised, not just by how soon we'll be seeing electric aircraft in our skies, but perhaps even more by their application to missions we aren't even thinking about today.  For example, looking back:
  • 15 years ago nobody predicted the widespread adoption of drones; today, they outnumber manned aircraft (by a good margin).
  • EA could open up small-capacity medium-range point-to-point markets that are simply impractical today with LFA turbine aircraft, providing congestion relief from major airports and a better passenger experience (no TSA lines, shorter travel between airport and home/destination, etc.).  And when you realize that the main NIMBY opposition to new airports or expanded operations at existing ones is typically noise based, you can imagine the potential advantages of EA playing out in unexpected ways.
  • We're now seeing a lot of discussion of eVTOL (Electric Vertical Take-Off-and-Land) short-hop autonomous concepts and other applications that can be ideal for electric aviation, none of which were in the public consciousness 10 years ago. Indeed many of these simply aren't practical with LFA and can provide new niches in which EA can grow, possibly complementing rather than replacing traditional LFA.

I would bet that in 2035, we'll be discussing applications of EA that I can't even fathom from my 2020 perspective, and thus cannot list here.

Not all endeavors to achieve this will work, of course.  Indeed, I expect most will fail - it's a super hard problem, after all.  But that's a healthy and an inherent part of the "creative destruction" of capitalism and it happens as any new technology emerges (anybody remember Compaq? Lycos or AltaVista? Blackberry?).  At a high level, all of the trends are pointing in the right direction to enable this next generation of flight, which suggests that there will be winners that ultimately emerge, and for that reason more than any other I would not ignore developments in this nascent sector.


Just one week after publishing this, I see a new announcement from Tecnam and Rolls-Royce about a new all-electric 9-passenger aircraft, goal of delivery within the "second half of the 2020s".  I'm excited!