The idea of an electronic flight bag is an easy sell to anyone who has endured the agony of filing Jepp revisions, pilots who have struggled to buy charts for an area they are passing through, or those who have had to lug 30 pounds of paper on a cross-continent trip. EFB solutions are out there, but many of them cost a couple of thousand dollars just to get started and can end up costing several hundreds of dollars each year in subscriptions.
This got me, a humble flight instructor on a limited budget and a Mac aficionado, thinking (perhaps dreaming is a better word) about a low-cost, home-grown EFB. In this installment, I'll be looking at how the FAA defines EFBs, what regulations govern their use, and part of NACO's Digital Terminal Procedures Publication or d-TPP product. I'm planning for this to be an on-going topic that I'll revisit as time and budget allows because frankly, I'm committed to an electronic solution to the mess of paper charts.
As usual, the FAA has provided several disparate sources of guidance regarding the approval and use of EFBs:
The FAA divides EFBs into three types, prosaically named Class 1, Class 2, and Class 3. And no government system would be complete without a bunch of acronyms thrown in for good measure, so let's cut to the chase. A Class 1 EFB is an off-the-shelf (OTS) portable electronic device (PED) for electronically displaying charts that may or may not be connected to an aircraft power supply and sits in your lap without being attached (even temporarily) to the aircraft or the pilot. In the wrong hands, Velcro is obviously a very dangerous substance.
Class 2 EFBs utilize a yoke mount, seat rail mount, or attach to the pilot via a kneeboard. Why the distinction between Class 1 and Class 2? Ya got me! And for completeness, Class 3 EFBs are permanently installed in the aircraft, which raises the question "How you can call a Class 3 EFB a 'flightbag' when it can't be removed from the aircraft?" While the EFB data may portable, you can't exactly stack a Boeing flight deck onto your wheeled suitcase and drag it behind you through the airport terminal.
The above-mentioned sources state that no approval is required for Class 1 or 2 EFBs when operating under part 91. The FAA would like you to carry current charts and apparently they don't care whether those charts are printed on paper or stored and displayed electronically. Speaking of PEDs, the other relevant regulation is 14 CFR 91.21, which requires the pilot in command or operator to ensure the EFB "... will not cause interference with the navigation or communication system of the aircraft on which it is to be used."
A complete EFB solution provides the ability to view both terminal procedures, the Airport/Facility Directory (or an equivalent), and IFR and VFR charts, but I was wondering if I could cook something up for a lower cost even if it would just allow me to display terminal procedures. Low cost is important because ideally a pilot would have access to a second EFB as a backup.
Well the FAA's aeronautical charting division offers the Digital Terminal Procedures Publication for a fairly reasonable price of $184.60 per year or $14.20 for a one-time purchase. That's only a little more than my Jeppesen paper chart subscription for California. The main issue with d-TPP is that you get everything - all terminal procedures for the conterminous 48 states, Alaska, Hawaii, and US Territories in the Pacific and Caribbean. This just cries out for re-packaging, I'd say into six regions at the very least: Western US, Central US, Eastern US, Alaska, Hawaii & Pacific Territories, and Caribbean. Re-packaging would not only reduce the size of each product's PDF repository, it would open up the possibility of on-line purchase and download rather than having to physically ship out a DVD.
Why would someone purchase d-TPP on DVD when they can get the same thing for free at the NACO website? The problem with the "for free" part is it requires you to have an internet connection and as of this writing, that's not practical in flight. So I snagged a one-time DVD to give it a test drive and here's what I found.
The d-TPP DVD (try saying that fast three times) package contains a passle of PDF files, one for each terminal procedure or airport diagram, and each cleverly named in a way that encodes the name of the airport and some other data. The file naming convention allows most any computer's filesystem to access those files using one or more indicies: A poor-man's database if you will. The d-TPP package provides two mechanisms for accessing procedures; one HTML-based (using a web browser) and the other a Java-based application. This sounds pretty cool since HTML and Java should provide platform-independent solutions, but the charting division has managed to screw-up what could have been a good system. In this installment I'll just be covering the HTML interface.
Before you get your feathers ruffled about my being a Mac user, let me just say I've programmed for a living using a bunch of different operating systems in my lifetime, including IBM 360/370/390 mainframes running VM, MVS, and UTS; Harris mini-computers; HP-UX, SunOS, and a few other versions of Unix; and various versions of Windows. Luckily I have forgotten most of these experiences and that's probably why I enjoy using a Mac. It's simple and it mostly hides the complexities of the underlying OS. I am still forced to use Windows systems on a regular basis in some situations, but I just hold my nose.
The operating system discussion is germane because the HTML/XML implementation used in d-TPP relies on non-standard features (available only in Internet Explorer) to provide search and filtering features. It's not that NACO couldn't provide a system that would work with most any browser, they simply chose not to do so. Having just enough programmer brain cells left, I was able to quickly hack some of the XML files to provide basic look-up of procedures using Firefox and even (gasp!) Safari under MacOS X. It seems the programmers wrote the HTML/XML one way and then they (and their managers) were apparently too unmotivated or under-funded to fix it. If you don't believe it, here's a comment from their own code.
A big problem indeed, but at least they documented their code. The thing is, it would be relatively simple to provide an installer that would do what I did by hand to the XML files and then there would at least be some basic cross-platform support.
Now back to my EFB dreams. Here's what the hacked d-TPP interface looks like on my Mac.
You can click on a state or territory, but then you get a list of all the airports for that state or territory: You can't look up a specific airport and that makes it not very usable in flight.
The charting folks really need to provide an interoperable version that provides all the filtering or, at the very least, the ability to look up a specific airport. If you use Windows then you will have access to all the filtering functions found on-line at the NACO website, but you'll need lots of free disk space or you'll need to have the d-TPP disk loaded so you can retrieve files off the DVD.
A problem with a Mac-based EFB mainly has to do with the form factor of your basic MacBook, but there is a solution I hope to be exploring in a future post. And I'd be remiss if I didn't mention that there is also an issue with conventional hard disk drives used in many laptops, notebook, and tablet PCs. Hard disks have moving parts and among those parts is a set of heads that sit above a disk surface that is spinning at 5400 RPM or faster. This design relies on a thin cushion of air to provide separation between the heads and the spinning disk. At altitudes above 9,000 to 10,000 feet, the air gets too thin and can result disk crashes. The solution is to use a solid-state disk drive and while these drives are available, the cost per gigabyte is much greater than with conventional disk drives. Hmm ... looks like my proposed budget just grew again.
Some of you might observe that it would just be easier to buy a tablet PC, use commercial EFB software, and be done with it. Well that would require the use of Windows, something I'd prefer to avoid and besides, I did say I was dreaming, right?
Class 2 EFBs utilize a yoke mount, seat rail mount, or attach to the pilot via a kneeboard. Why the distinction between Class 1 and Class 2? Ya got me! And for completeness, Class 3 EFBs are permanently installed in the aircraft, which raises the question "How you can call a Class 3 EFB a 'flightbag' when it can't be removed from the aircraft?" While the EFB data may portable, you can't exactly stack a Boeing flight deck onto your wheeled suitcase and drag it behind you through the airport terminal.
The above-mentioned sources state that no approval is required for Class 1 or 2 EFBs when operating under part 91. The FAA would like you to carry current charts and apparently they don't care whether those charts are printed on paper or stored and displayed electronically. Speaking of PEDs, the other relevant regulation is 14 CFR 91.21, which requires the pilot in command or operator to ensure the EFB "... will not cause interference with the navigation or communication system of the aircraft on which it is to be used."
A complete EFB solution provides the ability to view both terminal procedures, the Airport/Facility Directory (or an equivalent), and IFR and VFR charts, but I was wondering if I could cook something up for a lower cost even if it would just allow me to display terminal procedures. Low cost is important because ideally a pilot would have access to a second EFB as a backup.
Well the FAA's aeronautical charting division offers the Digital Terminal Procedures Publication for a fairly reasonable price of $184.60 per year or $14.20 for a one-time purchase. That's only a little more than my Jeppesen paper chart subscription for California. The main issue with d-TPP is that you get everything - all terminal procedures for the conterminous 48 states, Alaska, Hawaii, and US Territories in the Pacific and Caribbean. This just cries out for re-packaging, I'd say into six regions at the very least: Western US, Central US, Eastern US, Alaska, Hawaii & Pacific Territories, and Caribbean. Re-packaging would not only reduce the size of each product's PDF repository, it would open up the possibility of on-line purchase and download rather than having to physically ship out a DVD.
Why would someone purchase d-TPP on DVD when they can get the same thing for free at the NACO website? The problem with the "for free" part is it requires you to have an internet connection and as of this writing, that's not practical in flight. So I snagged a one-time DVD to give it a test drive and here's what I found.
The d-TPP DVD (try saying that fast three times) package contains a passle of PDF files, one for each terminal procedure or airport diagram, and each cleverly named in a way that encodes the name of the airport and some other data. The file naming convention allows most any computer's filesystem to access those files using one or more indicies: A poor-man's database if you will. The d-TPP package provides two mechanisms for accessing procedures; one HTML-based (using a web browser) and the other a Java-based application. This sounds pretty cool since HTML and Java should provide platform-independent solutions, but the charting division has managed to screw-up what could have been a good system. In this installment I'll just be covering the HTML interface.
Before you get your feathers ruffled about my being a Mac user, let me just say I've programmed for a living using a bunch of different operating systems in my lifetime, including IBM 360/370/390 mainframes running VM, MVS, and UTS; Harris mini-computers; HP-UX, SunOS, and a few other versions of Unix; and various versions of Windows. Luckily I have forgotten most of these experiences and that's probably why I enjoy using a Mac. It's simple and it mostly hides the complexities of the underlying OS. I am still forced to use Windows systems on a regular basis in some situations, but I just hold my nose.
The operating system discussion is germane because the HTML/XML implementation used in d-TPP relies on non-standard features (available only in Internet Explorer) to provide search and filtering features. It's not that NACO couldn't provide a system that would work with most any browser, they simply chose not to do so. Having just enough programmer brain cells left, I was able to quickly hack some of the XML files to provide basic look-up of procedures using Firefox and even (gasp!) Safari under MacOS X. It seems the programmers wrote the HTML/XML one way and then they (and their managers) were apparently too unmotivated or under-funded to fix it. If you don't believe it, here's a comment from their own code.
As decided on 12/30/2003, if the user uses Netscape for this software they are not going the entire gamut of items that is possible with IE. [Aside: Although IE and Netscape both adhere to DOM, there are a few crucial differences between the two. One of them is that IE allows a loose reference to DOM elements ... The same code would work in IE also implying that to make all of this cross-browser compatible write all the code following DOM principles. As originally, none of it was written that way (everything was written using IE's looser syntax) we decided it was best not to rewrite everything from scratch. The concept of the data island is Microsoft specific, hence that brings up a really big problem ...
A big problem indeed, but at least they documented their code. The thing is, it would be relatively simple to provide an installer that would do what I did by hand to the XML files and then there would at least be some basic cross-platform support.
Now back to my EFB dreams. Here's what the hacked d-TPP interface looks like on my Mac.
You can click on a state or territory, but then you get a list of all the airports for that state or territory: You can't look up a specific airport and that makes it not very usable in flight.
The charting folks really need to provide an interoperable version that provides all the filtering or, at the very least, the ability to look up a specific airport. If you use Windows then you will have access to all the filtering functions found on-line at the NACO website, but you'll need lots of free disk space or you'll need to have the d-TPP disk loaded so you can retrieve files off the DVD.
A problem with a Mac-based EFB mainly has to do with the form factor of your basic MacBook, but there is a solution I hope to be exploring in a future post. And I'd be remiss if I didn't mention that there is also an issue with conventional hard disk drives used in many laptops, notebook, and tablet PCs. Hard disks have moving parts and among those parts is a set of heads that sit above a disk surface that is spinning at 5400 RPM or faster. This design relies on a thin cushion of air to provide separation between the heads and the spinning disk. At altitudes above 9,000 to 10,000 feet, the air gets too thin and can result disk crashes. The solution is to use a solid-state disk drive and while these drives are available, the cost per gigabyte is much greater than with conventional disk drives. Hmm ... looks like my proposed budget just grew again.
Some of you might observe that it would just be easier to buy a tablet PC, use commercial EFB software, and be done with it. Well that would require the use of Windows, something I'd prefer to avoid and besides, I did say I was dreaming, right?
