Tuesday, May 28, 2019

What constitutes a "valid" flight entry?

With any data system, one must be prepared to do validation on the data that goes in.  A logbook is no exception to that rule.

It turns out, though, that there are surprisingly few validation checks that can be universally applied to a flight - there are a lot of things that look like an error in some scenarios, but which are perfectly valid in others.

An example that I am asked about frequently is that the system does not flag flights where Dual plus PIC plus SIC does not equal Total time.  For much of flying in much of the world, that equation is satisfied, but (in particular) it is not here in the US, where you can simultaneously log Dual and PIC if you're appropriately rated for the aircraft yet receiving instruction.

Probably the most common scenario where a flight frustrates data validation is "catch-up" flights, where you make one or more entries in your logbook to represent totals from prior (typically paper) logbooks.  Such flights typically include large numbers (larger than any single flight could actually have), and a mix of things that might be difficult or impossible to do in a typical actual wheels-up-to-wheels-down scenario.

Over the years, it seems that whenever I put in a validation check, I soon find counter examples of perfectly acceptable flight entries that violate my rule.

So in an evolutionary process of "survival of the fittest", here are the checks that have withstood the test of time:

  • Valid aircraft - every flight must be associated with an aircraft (even if no actual flying was done; you can generally use any aircraft you like for ground sessions - since the times are zero, any aircraft will work).  This is because the aircraft's model determines all sorts of attributes about the flight, such as the category/class, whether it was complex or high performance or turbine, etc.
  • No negative numbers.  I've yet to find a scenario where negative numbers are allowed.
  • Hobbs start after hobbs end.  (I don't currently validate tach time because I don't currently perform any computations on tach time).
  • Flight start after flight end or engine start after engine end (I don’t currently validate block time) 
  • Full-stop night landings + full stop day landings greater than the total landings (unless total landings is 0, in which case I auto-fill it)
  • Full-stop Night landings indicated without any night flight.
  • Night takeoffs at towered airports + night takeoffs at non-towered airport (which, kinda by definition, is all of the possible night takeoffs) is greater than total night takeoffs
  • More described approaches (e.g., a property indicating two ILS approaches) than logged approaches
  • Comments or Route field too long (13K and 128 characters, respectively)
  • Date before 1900 or more than 2 days from "right now" in Pacific time

Wednesday, May 15, 2019

International functionality Part 3: Functionality

In my previous two posts, I discussed how internationalization affects languages and regional conventions; in this third and final post, I will discuss actual functional changes that vary based on different jurisdictions.

While most software functionality does not vary worldwide (think Microsoft Office or the Chrome browser, which do the exact same things wherever they are), other software must be responsive to local markets and the rules, regulations or conventions therein, which means actual changes in functionality depending on where you are.  While aviation is largely harmonized across the world, it is nevertheless governed by each country and that results in a wide variety of rules.

At one level, simple logging of data is not really dependent on local rules.  After all, what you did on a flight is what you did regardless of where you are. The complexities tend to arise when performing things computations or reports on that data.

A challenge here compared to the language or regional conventions discussed in the prior two posts is that those can typically be determined automatically.  But functional rules generally need to be declared explicitly, because it is not uncommon for someone in one jurisdiction to follow the rules from another jurisdiction.  As a result, all of the functionality I'll describe here are things that are configured explicitly (generally in Profile->Preferences on the website)

Probably the most important (or visible) functionality that can vary is currency rules. By default, MyFlightbook implements US (FAA) rules.  MyFlightbook does also support Canada currency and EASA LAPL (European Light Plane) currency rules.

The FAA "groups" currency by category/class/type, so if you do your takeoffs and landings in a Piper Archer, you're current in a Cessna 172 as well, and vice versa.  But some countries require currency to be specific in a model: you need to have performed your takeoffs and landings in that model in order to be current in that model.  MyFlightbook supports either model.  You can also choose to view your totals grouped by category/class/total, or by model.

Different countries have different certification rules for pilots.  In addition to FAA rules, MyFlightbook supports some EASA, Canadian, and Australian ratings.  Adding new ratings is generally pretty straightforward, so if you can point me to a reference document, send it my way and I'll see what I can do.

Another visible place where different regional conventions are on display is in printing formats.  Some regions, like the US, specify what you should record, but make no particular recommendation on the form or layout in which it is displayed.  Others (Europe) can be very prescriptive (see prior posts about printing here and here).  MyFlightbook currently supports layouts that approximate the EASA standard, as well as layouts that conform to typical layouts in South Africa, Canada, and New Zealand.  If you have an additional layout, send it to me; it's generally pretty easy to add.

There are a few other bits of functionality that, while not strictly international or regulatory, do tend to correlate with region:
  • Input or display of times in decimal vs. hour:minute (HH:MM) format.  You can turn this setting off/on in Profile->Preferences on the website, or in settings on the mobile apps.
  • How night flight and night landings are computed.  You can set this on the web site next to the "autofill" button, or in settings on the mobile apps.  Night can be computed based on sunrise/sunset, or an offset from the start/end of civil twilight.  Night landings can either be anything at night, or 1 hour offset from sunrise/sunset.
  • On the mobile apps, you can also adjust how total flight time is computed from flight/block/engine times.

I'm a US-based pilot and fly on FAA conventions, so that's what I know best, but my goal is for MyFlightbook to be useful to pilots worldwide.  I hope this series of posts help explain MyFlightbook's international support, and I hope you'll contact me if there's any functionality you'd like to see (or bugs I need to fix!)

International functionality Part 2: Local conventions

In my last post I discussed how MyFlightbook handles different languages.  In this one, I will discuss how MyFlightbook handles regional differences.

Language and Region are independent variables.  E.g., English is spoken in both the US and the UK, but we express our dates differently.  I am writing this on May 15, 2019.  In the US, the short form of that date would be written 5/15/2019 (i.e., month/day/year), but in the UK, it would be 15/5/2019 (day/month/year).

Besides dates, there are several other conventions that vary based on locale:
  • Times.  E.g., by default is 4:15pm expressed  as "4:15 PM" or as "16:15"?
  • Decimal points and thousands separators.  E.g., one-thousand two-hundred fifty-two and a half would be "1,252.5" in the US or "1 252,5" in France.
  • List separators: typically a comma or a semicolon.  This is particularly important for CSV
  • Currency symbols.  Obviously, the US uses $, but Europe uses €
All modern operating systems provide services that software like MyFlightbook can use that makes all of this automatic and transparent.  MyFlightbook uses those services, so all conventions should be followed appropriately.

The trick is to ensure that MyFlightbook knows which region should be used.

For the apps on iOS or Android, you can set your device's region by going into the device's settings app.  There's a language and region area where you can set both the preferred language (as discussed in the last post, the iOS and Android apps are translated into French as well as English) and your preferred region.  Most people do not need to do anything here because their device comes pre-configured for their language and region.

The website gets slightly more complicated because it is one instance of the software that is running on a machine in the US (in the cloud somewhere; I actually have no idea where), so it is using US conventions, but it needs to service people from all over the world.  How to solve this?

Whenever your browser requests a page, it sends a list of language-region codes along with the request.  A language region code looks like "en-us": the "en" part means it is requesting English language, and the "us" part means it wants to use US conventions.

The list of these codes is in priority order.  So a request might include the following list: "en-us", "en-gb", "fr-ca", "fr-fr".  This tells the server that English is preferred, then French.  And that the preferred regions are US if possible, then UK ("gb" = "Great Britain"), followed by Canada, then France.

Note that this is sent by the browser, so if you are using a Windows or Mac OS with, say, French Canadian conventions, but your browser is set up for English/US, then you will get English.  The MyFlightbook server can't see your OS's settings, it can only see what the browser sends.

This can be set in various ways, depending on the browser.  In Chrome, you'd go to settings (using the menu or the URL chrome://settings/), then go to advanced, and you can specify language/region there:

In Firefox, you'd go to Options (or about:preferences) and find Languages from there:

In my next post, I'll talk about regional functionality.

International functionality Part 1: Languages

In the software world from which I come (I'm an alum of Microsoft and Expedia), we would think of internationalization along three dimensions: translation into a local language, localization to use local conventions, and functionality that varies by locale.  I figured it might be worth a discussion of how MyFlightbook breaks down along these dimensions.

I'll talk about each of these in successive blog posts, starting here with the first: translation.

Translation is pretty straightforward, albeit very lightly implemented.  While I know varying degrees of several languages, I'm essentially monolingual.  The fact that English is the world-wide language of aviation certainly makes it easier for MyFlightbook to get away with being all English than for other software programs, but nevertheless I am rigorous about ensuring that all of the code - whether on the website or in the mobile apps - can be localized and is not tied to English, even if much of the time English happens to be the only available language. 

In fact, thanks to a French-speaking user who did the initial translation (and Google Translate, which helped with subsequent translations, which might be humorous, but I wouldn't know...), the iOS and Android apps are entirely bi-lingual.  If you set your iOS or Android device to use French, the MyFlightbook UI will appear in French.

It's not seamless, however: much of the text used in display does come from the server, and the server is only lightly translated.  So if you are using French settings, you may still see English inserted in numerous places because that text derives from the database or from the web site (which only has a few pages translated.)

The key thing, though, is that the code is structured to be easily translated.  Specifically, this means that all text is kept outside of the code and loaded (based on language) as it is needed.  Keeping the text separate from the code makes translation easier, since a linguist can take a file with text in it and just go through and translate each item, without having to have any coding capabilities.  And it means that new languages can be added simply by adding appropriate translated text files.

If anybody is interested in helping to translate the website, all of the text is separate from the code, so it's pretty straightforward to do.  (It's just a lot of text...)

Supporting different languages actually goes beyond just translation, though, particularly since MyFlightbook *pilots* speak and use a huge variety of languages.  Most of this is pretty transparent - the system uses Unicode so it can handle data in Kanji, Hindi, Hebrew, Arabic, etc. without any issues.  The main thing that the code needs to handle here is right-to-left languages like Hebrew or Arabic and ensuring that the appropriate alignment occurs based on language (i.e., not hardcoding left or right alignment, but instead keying off of the language).

In my next post, I'll talk about localization.

Wednesday, May 1, 2019

Drones and MyFlightbook

Probably the fastest growing area in aviation these days is in the unmanned aerial system ("UAS", aka "unmanned aerial vehicle" or "UAV", or more colloquially, "drone") space.  And many UAS pilots are using MyFlightbook to record their flights.

MyFlightbook supports UAS as a psuedo-category/class.  E.g., as a peer to AMEL or Helicopter.  You can create UAS aircraft using one of many UAS models on the system, and include drone flights next to manned flights.  Since they are separate category/class, flights in one should not pollute things like currency or totals in the other.

Of course, since these are flights in your logbook, any times you record will accrue in your totals.  But alas, it's also easy to back these out, if you like, by using the search functionality.

There are a variety of flight properties that are in the system today that are focused on UAS scenarios.  As of this writing (more are added all the time!), the system has the following:

Property NameDescription
UAS - AutonomousIndicates that the flight was an autonomous UAS flight
UAS - Hand-held TransmitterIndicates that the UAS flight was controlled by a hand-held transmitter
UAS - Lost Link ReturnIndicates that the UAS executed return procedures after a loss of communication
UAS LaunchesNumber of times that a UAS (drone) was launched
UAS RecoveriesNumber of times that a UAS (drone) was recovered
UAS: Air Vehicle Operator TimeTime spent operating a drone
UAS: Mission Payload Operator TimeTime spent managing the paylod in a drone
UAS: Ground Control Station TimeTime spent in ground control for a drone
UAS: Maritime Flight HoursTime spent flying a drone (UAS) over water
UAS: Electro-Optical Sensor TimeTime spent using an electro-optical sensor (drone/UAS)
UAS: Infrared Sensor TimeTime spent using an infrared sensor (drone/UAS)
UAS: Short Wave Infrared Sensor TimeTime spent using a short-wave infrared sensor (drone/UAS)
UAS: Medium Wave Infrared Sensor TimeTime spent using a medium-wave infrared sensor (drone/UAS)
UAS: Synthetic Aperture Radar Sensor TimeTime spent using a synthetic aperture operations with a drone (UAS)
UAS: Hyperspectral Imaging Sensor TimeTime spent doing imaging (hyperspectral) with a drone (UAS)
UAS: Multispectral Imaging Sensor TimeTime spent doing imaging (multispectral) with a drone (UAS)
UAS: Signals Intelligence TimeTime spent doing signals intelligence with a drone (UAS)
UAS - 107.73 - Aeronautical Knowledge TestIndicates that the pilot took and passed a knowledge test (initial or recurrent) covering the areas specified in 107.73
UAS - 107.74 - Training CourseIndicates that the pilot successfully passed a training course (initial or recurrent) covering the areas specified in 107.74

As part of ensuring that unmanned aircraft are utilized safely - and don't conflict with manned aircraft! - the FAA introduced part 14CFR107, governing unmanned systems. 107.65, in particular, defines recent experience required to operate a UAS under many circumstances.  It works like currency, except that it focuses on recent knowledge training rather than flight experience.

To be current per 107.65, you must have done one of the following three things in the preceding 24-calendar months:
  • Pass an initial knowledge test, 
  • Pass a recurrent knowledge test, or 
  • Have a valid flight review (of the manned flight variety, per 61.56) and take a knowledge course.

To indicate that you have done either of the first items above, add an entry into your logbook with the "UAS - 107.73 - Aeronautical Knowledge Test" property; if you take the appropriate course, add an entry with the "UAS - 107.74 Training Course" property.  And, of course, if you are a licensed pilot of manned aircraft, you'll want to show that you have a valid flight review anyhow; you can do this by adding a property to the appropriate flight: "Flight Review," "BFR", or one or the various checkrides that qualify.

MyFlightbook will show (and update) 107 currency once you have met any of the requirements above.