Thursday, June 25, 2009

Poor Man's EFB



In my continuing quest to find a low-cost, electronic solution to displaying aviation charts, I acquired and tested a small notebook computer and several on-line services (some of them free) that provide charts and procedures in electronic format. In this installment I'll look at the feasibility of acquiring and displaying various charts while in flight using a newly acquired Dell Mini 9. Though this Dell model was recently discontinued, other similar models are still available. I acquired this computer used with a 16 gigabyte solid-state disk drive and 1 GB of RAM. I upgraded the RAM to 2 GB for a nominal cost and so far I've found the drive has plenty of space to store the basics charts I need.

Before embarking on this experiment, I took the two basic publications I purchase regularly and weighed them on a scale. The Northern California Terminal Procedures SW-2 and the Southwest Airport/Facility Directory together weigh in at a pound and a half.



The Dell Mini 9 is a smidge heavier at just over two pounds, but those few ounces pack a lot of punch. The Dell has the potential to store many more charts than I could ever fit in my flight bag and on the ground it can be used to check weather, surf the net, send email and all the other stuff a full-blown computer can do when wireless access is available. The keyboard is cramped, but did I mention I was on a budget? I think I did ...



You can purchase and download VFR, low-altitude IFR, and high-altitude IFR charts on-line from NACO for a fraction of the cost of printed charts: $1.60 versus $4 to $9 for a paper chart.

Using MacGPS Pro with an old, hand-held Garmin GPS providing position data over an USB interface, I found I could display a geo-referenced position on a VFR sectional quite easily. The FAA's charting division ships the VFR charts in raster format with a separate calibration file and MacGPS Pro was able to open and georeference these charts without a problem. The physical hardware setup is cumbersome and could be made cleaner by acquiring a small Bluetooth GPS receiver, but again ... the budget.

Low-altitude en route IFR charts are a different story since the FAA decided to package these as PDF files with no geo-reference calibration provided. PDF files!? What's more, the orientation of some of the PDF charts (like L1/L2) is landscape with North being shown on the right side instead of the top. I was able to use GraphicConverter to import the PDF, rotate it 90˚ clockwise, save it as a high-resolution PICT file, and import it into MacGPS Pro, but I can't (as of this writing) get the manual chart calibration process in MacGPS Pro to work quite right for geo-referencing. It's almost as if the FAA doesn't want anyone using these charts in the very way I'm trying to use them.

There is better news to report on the terminal procedures front because there are at least four ways to get terminal procedures in PDF format and the good news is that all of them are free! I didn't investigate geo-referencing these charts, I just want to display the procedures.

A popular way to get terminal procedures is to download them from NACO at no charge, a service that has been available for several years. The bad news is that you must downlead each procedure one at a time since they come as separate PDF files. In fact, some SIDs and STARs are two page affairs and they must be downloaded as separate files. Our tax dollars at work! Downloading each procedure in advance and storing them as separate files is a hassle, but take heart because there are other options.

Visit downloadplates, download the free Perl script and you can acquire all the procedures you want from the NACO site - automatically. The script provides a variety of features for controlling which procedures are downloaded. You can download all procedures or by just by a region or state. I was able to download all of California's procedures in about an hour so this is something you want to run overnight or when you're not in a rush. And if you update every cycle, the downloadplates script can be used to download only the procedures that have been changed or added.

The downloadplates package may be best suited to nerdy, programmer types. If you are a Windows user, you'll likely need to download a Perl environment, tweak your PATH variable, and use a command line interface to run the script. If you are a Mac OS X user, you already have Perl built-in and the latest release of the script now runs seamlessly under Mac OS X. (It was a simple matter of having the script recognize the OS being used and invoke curl instead of wget - Thanks Mike for incorporating the fix!) You'll have to open a terminal window to run the script and it helps to know a bit about C shell or Bourne shell. The resulting files are downloaded into appropriately named folders for each airport and the result is that you use your file system to navigate through a hierarchy of folders to find a particular procedure.



Two sites NACOmatic and PDFPlates, provide groupings of multiple NACO procedures into a single PDF file. Nacomatic also provides the Airport/Facility Directories as PDF files. The NACOmatic terminal procedures PDF for California was about 280 Mb and took less than 30 minutes to download. The PDFPlates PDF for Volume SW-2 (Northern California) was about 134Mb and took about 18 minutes to download. The NACOMatic California A/FD file was about 18Mb and only took a few minutes to download. These times are all based on basic AT&T DSL speeds.

Both NACOmatic and PDFPlates provide bookmarks that help you locate the airport and procedure you want. I'm told that there were some issues with bookmarks and the Kindle DX, but that appears to have been solved. I've yet to get my hands on a Kindle. Since I'm using Acrobat Reader on the Dell Mini 9 and it has bookmark support, my beef is in how the bookmarks are designed for both of theses packages. I've sent suggestions to the owners of both sites and look forward to seeing a different bookmark scheme implemented in a future versions.

And remember that these are free services: If you decide to use one of these products, don't be a blogosphere deadbeat - make a donation, dammit!

Here's how NACOmatic's A/FD PDF looks on the Dell Mini 9 in Acrobat Reader.



Here's how NACOmatic's TPP PDF looks on the Dell Mini 9 in Acrobat Reader (I rotate the page counter-clockwise to make a full page procedure readable in the cockpit).



This is PDFPlates' TPP PDF on the Dell Mini 9 in Acrobat Reader.



Here's a sample PDF I distilled for just Oakland to show what I think would be a more useful bookmark schema.



So how do these procedures display on the Dell Mini 9 in the cockpit? One issue is that the Dell Mini 9's form factor is not ideal for cockpit use. The screen won't fold open all the way from the keyboard, but I found I could set the machine in my lap like an open book. This photo doesn't do justice at all to the display. With my reading glasses on and my 50-plus year old eyes, I found the Dell Mini 9's screen readable in a low-wing aircraft on a sunny day. Your mileage may vary. My preference is to rotate the page display 90˚ counter-clockwise and minimize bookmarks once I've located the procedure I need to see.



To see how operable the Dell Mini 9 would be in flight, I tried this simple test on several occasions: A pilot I was instructing and I both looked up information on an airport in the A/FD. He used his paper A/FD (which had not been bookmarked) and I used NACOmatic's PDF version of the A/FD. I found the airport data first in every case. It wasn't child's play, but I think for me it is workable. I tried the same test with instrument approach procedures and again, I always seemed to win race - though sometimes not by much.

Several pilots have asked me if I'd rely on my poor man's EFB in flight without any paper backup. My answer is a qualified "yes." I think I'd still carry paper VFR charts, since they don't take up much space and they are relatively cheap. As for the A/FD, I'm comfortable relying on the Dell Mini 9 to display the PDF version. The same goes for terminal procedures, though I will continue to print a few frequently used terminal procedures and keep those in my kneeboard. The Dell Mini 9's battery life is well over 3 hours if close it when I don't need it (which puts it to sleep). I could acquire a cigarette-lighter power adapter for $15, but that doesn't seem necessary at the moment. And last but not least, the total cost for my setup? A few hours of set-up and research time and $300 in hardware. While my setup may not be considered a full-fledged EFB, it cost a tenth of what some set-ups cost. What's more, I don't have any subscription fees (unless you count the electronic VFR and IFR charts). Not too shabby for a few days of work.

Wednesday, June 17, 2009

More EFB Musing

My quest for a relatively inexpensive electronic flight bag continues with this review of the FAA Charting Division's d-TPP Flight Java application for Windows. I'll discuss the installation process and the application's features, advantages, and drawbacks.

One problem right off the bat is that the d-TPP Java application has been designed only to run under Windows. Another problem is that it uses a third-party PDF viewer that might have some bugs, enough to cause the developer to see fit to include a warning with the product. And one reader commented in my last posting that this software appears have some licensing issues. A bit of a messy start, but pressing on ...

I performed this install on Windows XP running under VMware Fusion on my MacBook, but it should be the same on any Windoze machine. Plop the DVD into your drive and it should autorun, displaying a screen giving you the choice to run the browser-based version, install the java application, browse the DVD, or view the readme file.



Click on the Install d-TPP Flight option and you'll see more choices regarding Java. You can load the version of Java that comes on the DVD or download the latest and greatest. Preferring to live on the edge, I chose to download the latest and greatest version of Java.




Once Java was on-board I had to re-launch the DVD autorun to continue the installation - a minor annoyance. Then I saw three choices. I tried to use the custom install option, hoping to store the PDF chart repository on a USB thumb drive, but I couldn't get it work. The full install required 3.5 gigabytes of disk space. Good thing I recently upgraded my hard drive to 320GB!

After installing, I launched the application and noticed that the window wasn't sized correctly.




A simple solution was to use a cool VMware Fusion feature called unity mode, that lets you run a Windows application that appears just like any other Mac application. This allowed me to properly resize the window.



You can select an airport by entering it's three-character identifier in the field upper right. If you have a tablet computer that supports pen input, you can bring up a keypad and tap in the characters. All modern GPS units distinguish between airports and VORs that have the same name by using ICAO identifiers for airports, but in keeping with other FAA chart products the Java application doesn't use ICAO identifiers. This is really unfortunate and I suspect that the application's designer(s) was(were) handcuffed by the way the terminal procedure PDFs are stored. This should create an interesting bit of work for some programmer down the line.

When you access an airport's procedures, the airport diagram comes up by default. I resized the window and used one of the rotate buttons to rotate the diagram counter clockwise into a sort of landscape view. This could work nicely if you have a tablet PC that is sitting in your lap, but the other input buttons don't rotate - just the chart you're viewing.

You can also select the map view and then click on the state or territory you want to display a list of airports for that state or territory.






The procedures are intelligently categorized for each airport. The airport diagram is displayed by default with buttons for STARs, SIDs, and IAP (instrument approach procedures). If you select the SID or STAR option, tabs appear labeled with the first letter of the name of each procedure.





If you select an IAP, two sets of tabs appear. One set of tabs are labeled with the name of each available runway while the other tabs list the approach names. This is a very handy and concise arrangement that significantly reduces possible confusion in locating the correct chart for the correct runway. Nice job, NACO!



When you select the Takeoff Minimums (sic) and Obstacle Departure Procedures for an airport, you get all the airports for the region in what that airport is located. Unfortunately NACO's current documentation scheme doesn't provide a way to programmatically drill down to the text for a specific airport within a PDF: You must page through and manually locate it yourself.



There's even a negative view that should help preserve your night vision adaptation.



The d-TPP Java application includes a feature that lets you create a sequence of charts and this has a lot of potential. Let's say you're departing KBFI and you create a sequence that starts with the airport diagram, followed by a SID. Cool. Since you'll be arriving at KBUR, you create a sequence that starts with one or more STARs, followed by a series of possible approach procedures, and ending with the airport diagram. The problem is, when you change back to the departure airport, the sequence you originally created for that airport is not retained. In fact, anytime you change to a different airport, any sequence you may have created does not survive. Like I said, a good start but it needs work.

Even with these shortcomings, the d-TPP product provides a reasonable look-up and display capability for terminal procedures at a pretty reasonable price, especially if you already own a Windows-based notebook or tablet PC.

An issue with using d-TPP on my MacBook as an EFB has to do with the form factor and the screen/keyboard arrangement. A solution I hope to investigate is the ModBook: A MacBook with the screen and keyboard replaced by a Wacom drawing tablet in a custom aluminum case. You can supply your own MacBook to be modified or they'll provide all the hardware for a higher cost. You can still use a bluetooth keyboard with the modified computer, but in the air I think it would sit comfortably on my lap. It would weigh in at just over 5 pounds, but the modification also includes the addition of a built-in WAAS GPS receiver. I've read good reviews of the ModBook and look forward to having my MacBook converted. I'll also need to replace that new 320 GB SATA hard drive with a solid-state drive to be safely usable in the air at higher altitudes. I just need to earn a bit more money before I can embark on that experiment.

An alternative that some readers have suggested is the Kindle DX ebook reader, which can load and display PDFs. While the Kindle has a lot going for it -an incredible display, a reasonably low price, long battery life, and a great form factor - I'd personally rather have a full-featured computer for use on the ground at home, in the FBO, or at the hotel.

Another solution I've been playing with over the last two weeks is an inexpensive Dell Mini 9 with terminal procedures provided by Nacomatic.com and downloadplates. I'll cover these in my next installment.

Wednesday, June 03, 2009

Dreaming and Paper Cuts

Apologies for the delay since my last post, but I was working on some projects that actually generate income. If more of my readers would contribute a little cah-ching using the donate button in the upper right corner, well ...

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:
  • AC 91-78: Use of Class 1 or Class 2 Electronic Flight Bag
  • AC 120-76: Guidelines for the Certification, Airworthiness, and Operational Approval of Electronic Flight Bag Computing Devices,
  • Order 8900, volume 4, chapter 15, section 1: Electronic Flight Bag Operational Authorization Process


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

    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?