I updated the mobile apps today to add support for autofill.
The website has had autofill functionality for a long time, but the mobile apps haven't. The main reason for this is that the mobile apps can function while offline and actually measure a flight using the GPS, so they've historically been more optimized around detecting flight events in real-time. The website, on the other hand, requires that you be online.
So I thought it might be useful to review some of what the apps and the website can do for you automatically here.
Auto-fill Total Time, Hobbs
The mobile apps allow you to tie the total time field to block, hobbs, engine, or flight times. This is a tight coupling: if you have both start/stop of the source defined, then any change in the value of a start or stop changes the total time field in real time.
Hobbs time similarly can be sourced from flight or engine time, and is also tightly coupled.
Cross-fill
Automatic Cross-fill
On an aircraft-by-aircraft basis, you can specify automatic cross-fill (copying of a value from one field to another) from the Total Time field to your choice of PIC, SIC, or Instructor time. (And if PIC, you can have it fill in your name as the PIC for that flight as well).
The rationale for doing this on an aircraft-by-aircraft basis is that you might fly professionally in a jet during the week as a second-in-command, and fly your personal 172 on the weekends. You'd automatically log PIC time in the 172, SIC time in the jet, and not do any cross-fill when you fly with a friend in their plane.
Automatic cross-fill operates under a few rules that are important to note:
- It will never overwrite a non-zero value. So if you have PIC cross-fill on and fly for an hour where you and a friend each are PIC for half of the flight and you log 30 minutes as PIC, then it will NOT overwrite that 30 minutes
- It happens on the server at the point that you save the flight. In other words, you won't see it applied while you're entering the flight itself, but after you add the flight to your logbook, you'll see that the cross-fill has occurred.
- It is only applied to new flights. So if you edit an existing flight, the cross-fill will not happen. This is important to allow you to override the cross-fill on a flight-by-flight basis (otherwise, you'd set the PIC field to 0 because someone else was flying, and the PIC time would come right back).
Auto-Detect
The mobile apps can run while offline, usually have GPS access, and can thus detect takeoffs and landings (using speed), nearest airports, and whether it is currently "night". You can configure a variety of settings such as threshold speeds for takeoff/landing and what criteria to use for night flight or night landings (FAA and EASA rules can vary on that). The system then updates the flight data in real time to reflect the flight in progress.
To do this, the system must use the GPS even in the background, and because that can consume battery, it only does this when a flight might be "in progress". "in progress" is defined in this context as having (a) either a defined engine start or a defined flight start time, and (b) NOT having a defined engine end time.
What I typically do is tap "Tap for Now" on Engine Start as part of my engine start procedure, then tap "Tap for Now" on Engine End as part of my shutdown procedure. The app will listen to the GPS between these two events.
You can also send a GPX or KML file to the MyFlightbook app on Android or iOS. When you do this, it sets and engine start time to the timestamp of the first sample in the file, and then plays the file as if it were real-time GPS samples, and then sets the engine end time to the timestamp of the last sample. It uses your autodetection settings for all of the intermediate GPS samples. (This functionality has also existed on the website for many years).
Some of the things that auto-detection will fill in include:
- Departure, arrival, and any intermediate airports
- Total landing counts, including the subsets that are full-stop day and full-stop night
- Night takeoffs
- Night flight
- Cross-country time (using a 50nm threshold; see here for why I don't do it for all cross-country flight)
Autofill
Because the apps have supported auto detection for years, there generally hasn't been a real need for autofill. But there are still a few scenarios where it makes sense, which is why I've added it.
Autofill overlaps with autodetection when there is telemetry (GPS) data present. If so, it has all of the functionality of Auto-Detect. But it can also work without telemetry, and it fills in a few things that Auto-Detect doesn't.
Where Auto-detection tries to fill in a flight based on GPS data (or a GPS file), the philosophy behind Autofill is to try to look at the flight and see if there are missing things that can be inferred or calculated. Naturally, the first thing Autofill tries to do is to autodetect, if appropriate GPS data is available.
One of the things Autofill can do is to estimate night flight. I say "estimate" because that's the best I can do without actual GPS samples. But if you have exactly two airports in your route of flight and start/end pairs defined for any of block, engine, or flight time - and these are in a defined timezone (i.e., UTC) - Autofill will construct a synthetic GPS path that is constant speed and great circle path from the first airport to the second. It will then perform autodetection on that synthetic path.
This is only an approximation, of course. Imagine you flew from San Francisco to London - a perfect great-circle route at a constant speed will imply a certain amount of night flight. But if you actually flew further north or south (perhaps for better winds), or if you had strong headwinds during one part of the flight and strong tailwinds during another, you would obviously have experienced a different amount of actual night flight than the constant-speed great-circle estimate.
In addition to whatever autodetection can be performed (whether with actual or synthetic GPS pdata), Autofill can also fill in:
- Total Time, if it is empty (zero) and if it can be determined from (in priority order): Hobbs time, block time, engine time, or flight time. Note that the new Autofill functionality in the mobile apps will do this as well, even if you have an AutoTotal setting. Imagine again that you fly a jet during the week (no Hobbs meter) and a club plane on the weekend (with a Hobbs meter), and you have AutoTotal set to use Block Time. For your weekend flight, if you don't enter a block time but do enter a hobbs time, it will still fill in a total value for you based on that.
- Ending Hobbs Time, if there's a non-zero starting Hobbs and the total time is known
- Ground Instruction given or received. If you have both a defined Lesson Start and Lesson End time, then your flight time (hobbs, block, engine, or flight, in priority order) is subtracted from that, and the remainder is assigned to Ground Instruction Given (if you have Instructor time logged) or Ground Instruction Received (if you have Dual Received logged)
- Cost of Flight. If you have a private note on the aircraft that includes something in the form "#PPH:75.00#" (where the "75.00" can be any decimal number), then that is treated that as the cost per hour for that aircraft. So in this example, if you logged a 2 hour flight in an aircraft with "#PPH:75.00#", it would record 150.00 as the cost of the flight. (And if you are using US conventions, that would display as $150.00).
