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


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!