NetHogs is a lightweight Linux terminal-based tool that monitors bandwidth usage, then groups it by process, so you can see which PIDs are using the most bandwidth, and if necessary, kill them with System Monitor.

To install NetHogs on Ubuntu (tested on 9.10 Karmic), you can either use Synaptic or simply apt-get, like so:

sudo apt-get install nethogs

To run NetHogs, simply feed it the internet connection you wish to examine, and sit back.

sudo nethogs eth0

For more information and the full list of options, visit the NetHogs man page.

man nethogs

sudo nano /etc/usplash.conf

The file should be altered to read:

# Usplash configuration file
# These parameters will only apply after running update-initramfs.

xres=1280
yres=1024

The final step is to update initramfs, the initial RAM disk used by the kernel when Linux first boots up:

sudo update-initramfs -u

If you skip the last step, you will probably only see your new usplash resolution during shutdown and not when your computer boots up.

That’s it!

My first computer was an Apple IIc. I was thirteen years old and, at that age, it was one of the most beautiful things I had ever seen. It had a gorgeous, green-on-black display screen, 128KB of RAM, no hard disk, and a Slim-line internal 5.25″ floppy drive into which you loaded whatever version of Zork you were in the mood for, and fired it up. All software was written in Applesoft BASIC, and although there was no official term for it at the time, everything was open source.

A simple Ctrl-C (or some such keystroke) was all that was required to break the flow of whatever program you were running and take a peek under the hood. I wrote my first computer program on the IIc. There might have been limits to what that little machine could do, but there were no restrictions. If you could imagine it, you could build it, and if you didn’t know quite how to build it, you just found someone else’s program that did something close, and figured out how they had done it. The Apple IIc was more than a tool, it was a teacher.

In college I used PCs and Macs, none of which I owned, of course — it just wasn’t expected in those days — and I reluctantly deciphered the library’s Unix terminals for the sole purpose of emailing friends with Pine. Until my junior year, by which time I was accustomed to using the university’s computer labs for my paper-writing and other needs, I kept that old Apple IIc around, with a dot-matrix printer, just in case.

It wasn’t until after graduation that I could finally afford (almost) to purchase my own computer. After buying and returning a couple of defective laptop PCs from a big box electronics retailer, I finally decided to go back to Apple, and I sprung for a Powerbook G3. It was beautiful, and it was definitely a Mac, but something was missing.

By this time, of course, Apple had come a long way in user interface design. The G3 ran MacOS 8, so it wasn’t without flaws, but it was intuitive, easy to use, and gorgeous. Only it wasn’t mine. It was Apple’s. As long as what I wanted to do was what Apple wanted me to do, things were fine. But as soon as I started thinking out of the box … well, it just wasn’t right. It wasn’t the IIc.

A few years later, after doing the obligatory post-college drift for awhile, I went to flight school. By then the G3 was nearly obsolete, but there was no money for anything new, and anyway a computer wasn’t a requirement for my new pursuit. But one night, while grilling burgers in the muggy Florida evening, a friend of mine offered to give me an old Dell desktop, complete with keyboard and VGA monitor. “It doesn’t work,” he said. “It’ll turn on, but nothing shows up on the screen. Anyway, I just bought a new one, so if you want it, it’s yours.”

And there it was: my first project box. A discarded old beige tower that probably didn’t work anyway. There was little I could do to make it any less useful than it already was, so I took it. I felt no pressure, no fear. It wasn’t an appliance, it was junk, and I could experiment with it all I wanted. I gambled that a cheap video card was all it would need to be back in shape, and I was right.

But once I had ripped the insides apart, and learned all I could from it, the fun stopped. So I got it to run Windows 95 again, so what? There was no magic in running Microsoft Word. The project box sat idle.

And then I discovered Linux.

It was Red Hat Linux 7, to be exact, in CD format, from the back of a loaned copy of a For Dummies book, written by none other than Jon ‘maddog’ Hall himself. I wiped Windows from the hard disk and installed Linux for the first time.

The old Dell box was lacking a bit in the memory department, and it ran the Red Hat GUI a little slow, so I decided to configure it to boot to the command line. Suddenly there it was: the text interface on a black screen — the characters were white, but they might as well have been green, and that blinking cursor that awaited my command — I was back in my parents’ basement, on the IIc, thirteen years old. The World was inside that box, and it was mine to explore.

A few years, a new Windows laptop, and several project boxes later, I tried Ubuntu, a new flavor of Linux that showed promise as a truly useful, user-friendly OS. Again there was no pressure, no fear, just a learning curve — only as steep as I wanted it to be — and there was Linux, the teacher. I was hooked. My “project” box became my primary computer, and when its hardware became too outdated to warrant patching up, I built a high-end AMD64 box from the ground up, specifically to run Linux.

Now, that computer, running Kubuntu 7.10, is my primary electronic tool, and my laptop sits mostly idle. It’s as slick a system as anything I could ever want, and the best part is, I own it. I run it. I control it. And I understand it, because I built it. I use Linux for all the same reasons everyone else does: stability, security, freedom, exclusivity, variety — but mostly I use Linux because it’s like my old Apple IIc, and because it made me love computers again.

(1) Press Alt+F2 to bring up the Run Command dialog box.

(2) Type kcontrol and click Run.

(3) Select “Appearance & Themes” from the left sidebar menu.

(4) Select “Launch Feedback” from the sub-menu.

(5) In the “Busy Cursor” box, select “No Busy Cursor” from the drop down menu.

That’s it! Banished for good!

After a fresh install of Kubuntu 7.10 “Gutsy Gibbon,” there are a few extra tasks necessary to get everything set up and running smoothly, especially when it comes to multimedia support and internet tools. This short tutorial will allow you to quickly enable some of the features missing in a vanilla installation.

The goal of this process is speed of setup, so I’ll use terminal commands rather than the more-familiar graphical menu, however I will make an effort to keep things simple and straightforward. Comments are welcome. (You might want to read all the way to the end before jumping into the commands.)

(1) Add the Mediabuntu Repositories. This will give you access to some of the restricted plugins and libraries below. Open a terminal (Applications> System> Konsole) and paste the following code, hitting “Enter” after each one.

sudo wget http://www.medibuntu.org/sources.list.d/gutsy.list -O /etc/apt/sources.list.d/medibuntu.list

Then, add the GPG key:

wget -q http://packages.medibuntu.org/medibuntu-key.gpg -O- | sudo apt-key add - && sudo apt-get update

(2) Enable Multimedia Support. Install all plugins and libraries for restricted formats such as DVD, MP3, WMV, MOV, AVI. Open a terminal and paste the following code:

sudo apt-get install kubuntu-restricted-extras libdvdcss2 libdvdread3 libdvdnav4 w32codecs gstreamer0.10-ffmpeg gstreamer0.10-plugins-bad gstreamer0.10-plugins-bad-multiverse gstreamer0.10-plugins-ugly libgstreamer0.10-0 libgstreamer-plugins-base0.10-0

(3) Get Firefox. Take Back the Web with the best browser on the planet. Includes the Flash and Java plugins, and two Firefox Add-ons: Greasemonkey and Web Developer. (Just remove the last three packages if you don’t want the Add-ons.

sudo apt-get install firefox mozilla-firefox-locale-en-gb flashplugin-nonfree sun-java6-plugin firefox-greasemonkey firefox-dom-inspector firefox-webdeveloper

(4) Install Pidgin. Pidgin is a multi-protocol instant messaging client that I happen to like better than Kopete. The code below includes a package of additional plugins, including OTR (Off The Record messaging).

sudo apt-get install pidgin pidgin-otr pidgin-plugin-pack

(5) Bring out the GIMP. The GNU Image Manipulation Program may not be Photoshop, but it’s damn close. And, oh yeah, it’s free. You need it:

sudo apt-get install gimp

(6) Add Microsoft TrueType Fonts. By default, Kubuntu doesn’t enable support for fonts like Arial, Verdana, Trebuchet and Times New Roman. Get them here:

sudo apt-get install msttcorefonts && sudo fc-cache -fv

The Whole Shebang. Lazy? Me too. Accomplish ALL of the above in One Swift Stroke: (cross your fingers)

sudo wget http://www.medibuntu.org/sources.list.d/gutsy.list -O /etc/apt/sources.list.d/medibuntu.list && wget -q http://packages.medibuntu.org/medibuntu-key.gpg -O- | sudo apt-key add - && sudo apt-get update && sudo apt-get install kubuntu-restricted-extras libdvdcss2 libdvdread3 libdvdnav4 w32codecs gstreamer0.10-ffmpeg gstreamer0.10-plugins-bad gstreamer0.10-plugins-bad-multiverse gstreamer0.10-plugins-ugly libgstreamer0.10-0 libgstreamer-plugins-base0.10-0 firefox mozilla-firefox-locale-en-gb flashplugin-nonfree sun-java6-plugin firefox-greasemonkey firefox-dom-inspector firefox-webdeveloper pidgin pidgin-otr pidgin-plugin-pack gimp msttcorefonts && sudo fc-cache -fv

~$ mysql -u username -p

Create a database:

create database db_name;

Delete a database:

drop database db_name;

List all databases:

show databases;

Select a database:

use db_name;

List tables of current database:

show tables;

List fields of a table:

describe table_name;

Table query structure:

select * from table_name where id = "5" 

Export a MySQL Database:

~$ mysqldump -u username -p db_name > FILE.sql 

Import a MySQL Database:

~$ mysql -u username -p db_name < FILE.sql 

http://my.blog.com/archive/2007/10/pretty-urls

Note that every part of the URL is relevant for a human reader. For comparison, here’s an example of an “ugly” URL:

http://www.mysite.com/nuke/modules.php?name=Forums&file=posting&mode=quote&p=14488&sid=0293840293840577

To enable the mod_rewrite module in Apache2 on Ubuntu:

(1) Add the rewrite.load to /etc/apache2/mods-enabled/

sudo ln -s /etc/apache2/mods-available/rewrite.load /etc/apache2/mods-enabled/

(2) Edit the apache configuration for your virtual hosting (/var/www/):

sudo nano /etc/apache2/sites-enabled/000-default

(3) Change the AllowOverride value to “All” for the document root directory:

<directory /var/www/>
  Options Indexes FollowSymLinks MultiViews
  AllowOverride All
  Order allow,deny
  allow from all
  # This directive allows us to have apache2's default start page
  # in /apache2-default/, but still have / go to the right place
  # Commented out for Ubuntu
  #RedirectMatch ^/$ /apache2-default/
</directory>

(4) Restart the server:

sudo /etc/init.d/apache2 restart

With this setup, you’ll be primed and ready to go to run popular content management software on your local box–like Drupal, Joomla or Silverstripe; start a Wordpress or Textpattern blog; or even roll your own community site from scratch using a hot framework like CakePHP.

(If you’re just getting started with web design, it’s a good idea to check out the tutorials at w3schools.com, although you don’t have to know a single line of code to install a well-designed product like Wordpress.)

This short tutorial assumes you’ve already installed some version of Ubuntu on your computer (–that takes care of the “Linux” part–), and leads you through installing an Apache web server, the PHP scripting language, and a MySQL database server.

(These instructions were tested on Kubuntu 7.10 “Gutsy.”)

(1) Install everything. Open a terminal and paste the following code, which will grab Apache, PHP, and MySQL all at once. That was easy.

sudo apt-get install apache2 php5-mysql libapache2-mod-php5 mysql-server

(2) Test Apache. Once installed, the Apache web server should be running. To find out for sure, open up a browser and enter http://localhost/ in the URL field. You should see something like this:

If you click on the apache2-default/ folder, you should see a message that says, “It works!” If instead of seeing the above, you get some sort of “Unable to connect” message, then the server is not running.

Try restarting Apache, then repeat step two:

sudo /etc/init.d/apache2 restart

(3) Enable PHP. Open a terminal and paste the following code, which will enable support for the PHP module in Apache’s configuration file:

sudo ln -s /etc/apache2/mods-available/php5.load /etc/apache2/mods-enabled/

Now, restart the Apache server (so the new module will take effect).

sudo /etc/init.d/apache2 restart

(4) Learn PHP. Quick. Create your first PHP script to test that the new module works. Open a terminal and paste the following code:

sudo nano /var/www/phpinfo.php

Whoa! What happened? Never used nano before? It’s a simple terminal-based text editor. Check out the keyboard shortcut commands at the bottom of the screen. You’ll figure it out.

Here’s the code to paste into nano:

<?php
  phpinfo();
?>

Don’t forget to save the file using Ctrl-O and then exit with Ctrl-X. Are we having fun yet?!

(5) Test PHP. Jump back over to the browser and reload the localhost page. You should see your new phpinfo.php file in there. Hey cool; we learned something: The Apache web root is located at /var/www, so any PHP files you save in there will be parsed by the server’s PHP engine.

Anyway, click on your new file. You should see some variant of this:

Great! We’re in.

(6) Test MySQL. This should already be installed and running, if step one went as planned. You should have already created a root username and password. If that’s the case, then just open a terminal and type:

mysql -u root -p

You’ll be prompted for the password you created earlier, and then you should see something like this:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 26
Server version: 5.0.45-Debian_1ubuntu3-log Debian etch distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>

Done! That’s it. You’re all set up. Check out the MySQL Command Reference for a few things to try in the monitor, if you like. Now you’re ready to start building your first dynamic website.

Fortunately, that’s another tutorial.

Lately I have been fooling around with Kubuntu on a desktop computer and I really wanted to use it on my laptop. However, I was hesitant to partition my hard drive because I have a lot of documents and pictures and software that I would hate to lose in the event something went wrong. Additionally, I don’t have a tremendous amount of free space on my hard drive to devote to another operating system. So I decided to try to install Kubuntu on a USB flash drive.

I found some posts in the Ubuntu forums that helped figure out how to make installing Kubuntu to a USB drive possible; this one was the most helpful. It’s very thorough and the thread covers many issues that arise with different hardware configurations. My experience was slightly different than what the post describes so I will detail the steps I took to install Kubuntu on a USB drive.

First off, my laptop is a Dell E1405, and the USB drive I used is the SanDisk Cruzer 4Gb which periodically goes on sale for a little less than 40 bucks. I think the write speed is slow but it has a nice orange light which will dazzle you while you wait. The 2 Gb version will work, but I had to do a lot of software removal to make it happen (I will be testing Xubuntu on the 2Gb drive in the near future). I highly recommend just using 4Gb or more.

Secondly, I’m still relatively new to Linux. This certainly isn’t the be-all-end-all tutorial, and I can’t guarantee that these steps will work on hardware other than Dell’s E1405 with an Intel Pro wireless card, or the San Disk Cruzer USB drive.

Preparing the USB Drive

Before you do any thing else. Uninstall ALL of the software that comes pre-installed on the USB drive. When you plug in the USB drive SanDisk U3 software automatically loads. Use the icon in the system tray to find the uninstall feature. It is a bit hidden and I don’t remember exactly what tab it is under. It might require a right click. After I uninstalled U3 I also re-formatted the drive, not sure if it is necessary.

Getting Kubuntu

Head over to the Kubuntu download page and download the Feisty Fawn 7.04 Live CD and the Alternate install CD. There is a Ubuntu Documentation page that will tell you how to burn the files on to a CD to make a bootable .ISO image using the Infra Recorder software. (The Live CD is not part of the actual install process but it is helpful in determining what you computer calls the devices that we will be installing Kubuntu on. It is also nice to have around for future use.) After your CDs are burned make sure to take them out of the CD drive. You should then restart your computer and enter the BIOS Setup page as your computer restarts. Verify that your computer will boot in the order of CD, USB, then Hard Drive.

Finding Your USB (Device Node) Name

Insert the Live CD and exit the BIOS. The live CD takes a little while to load. Once you are on the Kubuntu Desktop, plug in your USB device. You can find the device node by putting the mouse pointer over the device icon or by using the system menu icon, the second icon from the left on the bottom panel menu, and select “Storage Media.” In the Storage Media expanded menu you can see the internal drive and the USB drive. Write down the name. On my Dell E1405 the USB drive is listed as /dev/sdb and the hard drive as /dev/sda with the various drive partitions numbered like /dev/sda2. So I know that I will be doing all of my installing to sdb and NOT my internal drive sda. Other computers use device nodes like hda or hdb.

Installation

When you are ready to install, log out and get the Live CD out of the tray. When you restart the computer, enter the BIOS and insert the Alternate Install CD. Exit the BIOS. The Install Menu screen be present now.

The “Install in Text Mode” is the first option. Select it for a normal install. I’ll just walk through my notes here and what I remember the installer asking and the choices I made. IMPORTANT: Be careful not to install GRUB Loader to the Master Boot Record! This step comes after the timezone and username selections.

• Choose your Language and Country.

• Detect keyboard layout. For US keyboards select “No” then select Origin–>U.S. English and Layout –>U.S. English.

• Network configuration. If you are not connected to a network you can hit “Cancel” or if a network is not present select “Configure later”

• Hostname. Choose a name for your computer.

• Partition Disks. Select “Guided – use entire disk.” Select your USB drive. It should show a description of your USB drive and include the device node that you found earlier (e.g. sdb). Do NOT choose your internal drive!

• Finish Partitions and write changes. Write to disk–> yes

• Choose Timezone

• Choose Username, Username Account, and Password.

• Write in your USB device node. Once again, mine was: /dev/sdb. (The text says you could use (sdb) instead of /dev/sdb but the installer didn’t like when I tried it that way.)

Configuring the GRUB Bootloader

Your installation should now be complete. Be sure to eject the disk before you shut down your computer. When you start up again you will have to do some editing in the GRUB menu. GRUB is looking at the wrong drive to boot so we need to tell it to look at the correct drive. This editing is temporary for this start up only.

When the GRUB menu appears, use an arrow key to move the line selection so that the automatic start up timer stops. If you missed the timer the system will try to boot and will give you some sort of Error 17 message about invalid partitions or something. The ESC key should bring you back to the GRUB menu.

Select the first line in the grub menu “Ubuntu Kernel….” Type ‘e’ to edit.

In the next menu select the first line Root (hd1,0). Type ‘e’ to edit.

Use the arrows and back space to edit the line grub edit> root (hd1,0) to read grub edit> root (hd0,0)

Hit the ENTER key to make the change and you will be directed back to the previous menu.

Now hit “b” to boot Kubuntu!

You can make this boot change permanent by entering the terminal from Kmenu-> System-> Konsole(Terminal Program)

Editing GRUB menu.lst

On my first attempt at installing Kubuntu on a USB I edited the menu.lst to make the permanent change. It works fine until you do a kernel update. In my latest attempt I have not permanently edited the file and I have not done a kernel update.

To edit type:

sudo nano /boot/grub/menu.lst

Use the arrow keys to navigate down until you see this just past the line that reads

## ## End Default Options ##

title           Ubuntu, kernel 2.6.20-15-generic
root            (hd1,0)

kernel/boot/vmlinuz-2.6.20-15-genericroot=UUID=75660762-f5cf-4b5d-97$
initrd          /boot/initrd.img-2.6.20-15-generic
quiet

savedefault

change root (hd1,0) to (hd0,0) make this change for the recovery mode “title Ubuntu, kernel 2.6.20-15-generic (recovery mode)” and memtest “title Ubuntu, memtest86+” too. Both are the right underneath the first group that you just edited.

The tutorial mentions making changes to ## default grub root device

## e.g. groot=(hd0,0)

# groot=(hd1,0)

so that # groot=(hd1,0) also is changed to (hd1,0). One user posted a comment about the kernel update reading the line with only one # to determine the location of the Boot Loader. As I mentioned previously, I have not made these permanent edits yet and do not know if they work. I bricked my USB Kubuntu after a kernel update and had to start over again. I’ll try making these edits in the near future and post my findings when I can. In the meantime I edit the GRUB every time I start up … I think it’s kinda fun.

Hardware Issues

If your hardware differs from mine or something is not working, check out the tutorial I mentioned above. This tutorial makes many edits in the terminal which I found my with hardware configuration or Kubuntu version to be unnecessary.

The only major glitch I had with hardware was my screen resolution. The intel i810 driver didn’t want to give me the native 1280×800 resolution. There was a quick fix found here. Once again there are several steps listed, but for some reason all I had to do was go to the Terminal and type:

sudo apt-get install 915resolution

After logging out and back in, my resolution worked. Again if you have troubles or different hardware that link is a good place to start and you may need to follow the additional steps to get your screen resolution working.

The other nice thing is that you can mount your internal hard drive so that you can read (and possibly write) files. This is great when you need to access something from your hard drive and you don’t want to shutdown your computer and restart without the USB.

That’s all for now. Hope this helps.

On August 6, 1997, Korean Air flight 801, a Boeing 747, crashed at Nimitz Hill, Guam, with 237 passengers on board. The airplane had been cleared to land at Guam International Airport and crashed into high terrain about 3 miles southwest of the airport. 228 people were killed, and the airplane was destroyed by impact forces. Post-crash analysis revealed no mechanical defects with the aircraft (NTSB, 1997).

The National Transportation Safety Board calls this type of accident Controlled Flight Into Terrain (CFIT), in which a functioning airplane is essentially flown into the ground due simply to the pilots’ lack of a clear picture of where they are (Arthur, 2003). According to a study from the Flight Safety Foundation, nearly 80 percent of all fatal airline accidents can be attributed to CFIT or approach-and-landing accidents (North, 1999). Clearly something needs to be done to address this situation and reduce these preventable pilot-error accidents.

During times of reduced visibility, pilots rely solely on the instrumentation in the cockpit and reports from Air Traffic Control (ATC) to maintain a mental picture of their position in space relative to terrain, airports, navigational aids and other air traffic. This “picture” is known as Situational Awareness (SA). Historically, airline and corporate cockpits provided situational awareness through a jungle of dials and gauges, each with its own purpose, communicating such information as bearing and distance from navigational aids (NAVAIDS), aircraft attitude, altitude, airspeed, heading, and various system-health data.

However, with the advent of TV-like screens to display data, called Electronic Flight Instrumentation Systems (EFIS), in military and later commercial cockpits, this instrument jungle was considerably reduced. One CRT or LCD screen was adequate to present the aircraft’s airspeed, attitude, altitude and heading to the pilot. This reduced the number of places to which a pilot’s eye had to travel around the instrument panel when “scanning” the gauges during low-visibility flight. The subsequent decrease in pilot workload meant an increase in situational awareness.

But it was not enough. The problem was this: the early EFIS systems simply replicated the presentation of the old electro-mechanical dials and gauges on a TV-like screen. Little attempt was made to utilize this technology to bring a more user-friendly and intuitive presentation to the cockpit (Nordwall, 2003). Pilots still had to read numbers and chase needles, then mentally create the situational-awareness “picture.”

An emerging concept called Synthetic Vision is a revolutionary attempt to rectify this problem, using EFIS technology to bring maximum situational awareness to the cockpit in the hopes of reducing pilot-error accidents, especially CFIT.

The Synthetic Vision System

Simply put, the idea behind the Synthetic Vision System (SVS) is to use currently-available liquid-crystal (LCD) display technology, Global Positioning System (GPS) receivers and an onboard digital database of terrain, obstacles and airports to provide pilots with a computer-generated, three-dimensional view of the outside world during reduced-visibility flight (Stark, 2001). The primary focus of current research is to provide technology that will not only inhabit the instrument panels of futuristic air transports, but will also be available for retrofit into existing aircraft, including airliners, corporate jets, helicopters and even general aviation light planes.

The Synthetic Vision Systems Project was begun under NASA’s Aviation Safety Program whose stated goal is “to develop and demonstrate technologies that contribute to a reduction in the aviation fatal accident rate by a factor of 5 by year 2007.” The program is a partnership that includes NASA, the Federal Aviation Administration (FAA), members the aviation industry and the Department of Defense.

The purpose of the SVS Project is to design and test a variety of intuitive displays that provide pilots with a perspective view of terrain, obstacles and even real-time traffic and weather information that is “congruent with the pilot’s natural mode of spatial information gathering” (Stark, 2001). Essentially, this means that the more accurately a display can simulate flight under daylight, high-visibility conditions, the better a pilot’s situational awareness.

In addition to experimenting with different views of terrain, coloring, shading, texturing and display size, NASA’s SVS Project is also evaluating several types of course guidance symbology. Current EFIS systems use a variation of the classic “flight director” symbology, in which a crosshairs or miniature aircraft is presented on the attitude indicator (or “artificial horizon”) and guides the pilot to the proper pitch and bank attitudes in order to track the desired course.

However, the 3-D view of the terrain provided by the SVS allows for a novel type of course guidance that shows both current position and the future path of the aircraft. Such systems are called “Tunnel Guidance” or “Highway In The Sky” (HITS). These can appear as a series of boxes strung out in space through which a pilot must fly in order to stay on course.

HITS symbology “allows the pilot to assess the future trajectory relative to the environment at a glance, thus increasing the likelihood of detection of conflicts between the programmed path and the terrain,” as well as allowing smoother and less-tiring aircraft control since the pilot can more easily anticipate future control movements (Theunissen, 2000). In addition, HITS symbology allows a more accurate flight path over all phases of flight including departure, enroute and approach, compared to traditional tracking of the Course Deviation Indicator (CDI) needles found in current cockpits (Chelton). [See image, above right.]

And Synthetic Vision Systems aren’t just prototypes that are gestating in government simulators and university research programs. Actual flight-ready hardware is getting some real-world tests in one of the toughest and historically most dangerous flight environments in the world: Alaska.

The Capstone Program

Due to the rugged terrain, limited navaid and ATC coverage, and unpredictable weather, the state of Alaska was chosen to initiate tests of new technology that will improve aviation safety and efficiency, and eventually provide the techniques essential to the modernization of the entire National Airspace System. The Capstone Program is a joint industry and FAA Alaskan Region effort to provide a working environment for day-to-day operations of these new systems.

Begun in 1999, Phase I of the Capstone Program provided commercial operators in the Yukon-Kuskokwim delta region with GPS navigation receivers, multi-function color LCD displays, and transceivers that helped aircraft see each other during flights in reduced visibility, all free of charge with participation in the program. This equipment provided pilots with access to non-radar (i.e. no ATC) environments that had previously been limited to visual flight operations, and increased the number of airports served by instrument approaches. Pilots’ situational awareness was increased dramatically, simply by bringing information into the cockpit which included terrain, weather, traffic and accurate aircraft position.

Phase II of Capstone began in 2002, moving to the more “environmentally challenged” Southeast Alaska, which is plagued with bad weather, low visibility and rugged terrain. Phase II heralded the first commercial flight of an aircraft equipped with an SVS on March 31, 2003, using a twin-engine Piper Seneca and a Chelton FlightLogic� Electronic Flight Information System with Synthetic Vision (EFIS-SV).

The Chelton FlightLogic� system consisted of two separate LCD displays. The Primary Flight Display (PFD) featured real-time SVS 3-D terrain and HITS flight path symbology. The Navigation Display (ND) presented a GPS-driven moving map which had the capability to depict the aircraft’s selected course, terrain, obstacles, air traffic and weather data all on the same screen. Initial tests have shown the SV-HITS system provides precision-approach accuracy to course guidance along the entire route of flight, and significantly reduces the chances for CFIT accidents.

Research on SVS and Human Factors

Substantial research is currently being done to evaluate the effectiveness of Synthetic Vision Systems in improving situational awareness, refining aircraft control in low-visibility flight scenarios and reducing or eliminating instances of Controlled Flight Into Terrain. The following example studies focus on slightly different pilot groups and evaluate different facets of pilot performance while using SVS on both a quantitative and qualitative level.

Both studies utilize a simulated Synthetic Vision System as part of their experimental group, each displaying computer-generated 3-D terrain and several using tunnel-in-the-sky guidance. In both studies, use of the SVS system was found to reduce pilot workload, improve aircraft control, and increase situational awareness substantially compared to baseline display systems.

Research Example # 1: Private Pilots

The first investigation was undertaken by Takallu, et al., at the NASA Langley Research Center in Virginia. The focus was on low-time General Aviation (GA) pilots having limited instrument flight skills. A common GA accident scenario involves non-Instrument-rated pilots inadvertently flying from Visual Meteorological Conditions (or VMC, in which the ground and horizon are clearly visible and are used as the primary aircraft course and attitude references) into Instrument Meteorological Conditions (or IMC, in which the ground and horizon are obscured by clouds, fog or haze, and the flight instruments become the primary means of controlling the aircraft’s course and attitude). In such a scenario, the low-time Private Pilot is taught to execute a 180 degree level turn by reference to the instruments in order to hopefully return to visual conditions. Loss of aircraft control or CFIT commonly results.

In this study, 17 GA pilots with Private Pilot, Airplane Single-Engine Land ratings participated. None of the pilots had any instrument training beyond that required for the Private Pilot certificate. The pilots were tasked to evaluate three (3) different instrument display concepts in a flight simulator at Langley’s General Aviation Work Station.

• Display 1, referred to as the Attitude Indicator (AI) was the baseline display, designed to replicate the standard “six-pack” of round electro-mechanical gauges in the average light plane cockpit.
• Display 2, referred to as the Electronic Attitude Indicator (EAI) featured an enlarged attitude indicator representative of the current EFIS “glass cockpit” displays found in most commercial and corporate aircraft.
• Display 3 was called the SVS display, but was identical to the EAI except that instead of the “brown ground-blue sky” depiction of the standard electronic attitude indicator, the SVS featured computer-generated terrain imagery. No tunnel-in-the-sky symbology was incorporated.

Visual cues were also presented in the flight simulator, giving pilots the ability to look out the “window” for attitude references as much as meteorological conditions would permit. Pilot performance parameters such as heading, airspeed, altitude, bank angle and pitch attitude were evaluated on a quantitative basis. Human factors questionnaires were administered after each session, evaluating the pilots’ perceptions of situational awareness on a qualitative basis.

Each flight session was five minutes in length and involved a straight and level flight beginning in VMC and progressing rapidly into IMC. Pilots were expected to maintain aircraft control using visual cues (i.e. out the “window”) while possible, and then transition to the instrument display when visual reference to the horizon was lost. Once IMC was encountered, the pilots were tasked with executing a 180 degree level turn followed by a constant-airspeed climb and a constant-airspeed descent of 1000 feet each, all by reference to the instrument display. Each of the pilots flew four scenarios three separate times, once with each display type.

The results were as predicted: In every one of the scenarios, pilots demonstrated smoother control inputs, smaller and fewer control input errors, and smaller deviations of airspeed, heading and altitude with the SVS display. Interestingly, however, in several cases, such as altitude control, errors were greater with the EAI display than with the baseline AI display, seeming to suggest that simply depicting standard gauges on an LCD screen does little to improve pilot performance.

In addition, pilots overwhelmingly reported a lower workload and improved situational awareness (SA) during flight in IMC with the SVS display compared to the other two. According to the authors, these findings demonstrated that a display which intuitively presents flight-critical data to the pilot and more realistically simulates visual flying cues will lead directly to a reduced level of flying errors, vastly improved SA, and a reduction of loss-of-control and CFIT accidents.

Research on SVS and Human Factors

Research Example # 2: Professional Pilots

Arthur, et al. conducted the following experiment in the Visual Imaging Simulator for Transport Aircraft Systems (VISTAS III) at the NASA Langley Research Center. The hypothesis for this experiment is that “a Synthetic Vision System will improve the pilot’s ability to detect and avoid a potential CFIT compared to conventional flight instrumentation.” The major focus was to test SVS display size configurations that would easily retrofit into existing corporate and airline fleets.

Since the goal of the study was to evaluate the effect of Synthetic Vision of avoiding CFIT, the flight scenarios featured what the authors termed a “rare event” technique, in which an unexpected, potential CFIT incident was incorporated once for each pilot at the conclusion of a series of IMC approach and departure attempts.

The Displays. Three display sizes were evaluated, a Size “A” display that could be retrofitted into existing Primary Flight Display (PFD) slots on Boeing 757-767 aircraft, a Size “D” that would fit in B-777 PFD slots, and the largest was a Size “X” that represented probable display space alloted on future aircraft. Each of the display concepts included a Terrain Awareness and Warning System (TAWS) and a Vertical Situation Display (VSD), which showed a vertical profile of the terrain along the desired course. Both TAWS and the VSD were incorporated into one secondary Navigation Display (ND).

The PFDs incorporated the SVS technology, or the baseline display as appropriate. Six of the PFD concepts used some variation of a Synthetic Vision System. One PFD concept was used as the baseline, and depicted the conventional Electronic Attitude Direction Indicator (EADI) found in most of today’s airline and corporate cockpits. Course guidance on the baseline EADI display was the traditional “flight director” symbology. Guidance on the SVS displays was provided by “Highway-In-The-Sky” symbology.

The Pilots. Sixteen pilots participated in the test, 15 airline pilots and one NASA researcher. The subjects averaged 8200 hours of logged flight experience. The pilots were briefed on the display concepts and participated in a two-hour training session. The “rare event” scenario was not mentioned, although the pilots were expected to maintain separation from the terrain at all times.

The Flight Scenarios. The pilots were tasked with flying a circling approach in IMC to runway 7 at the “terrain challenged” Eagle County Regional Airport in Colorado. At 200 feet above ground level, the pilots were expected to go around and execute a missed approach procedure the led to a nearby navaid. All of the pilots flew the same procedure several times with different displays. The final run for each of the pilots ended with the “rare event” CFIT scenario. In the rare event scenario, the missed approach course was altered in the flight management computer, so that the PFD’s flight director or HITS symbology would provide guidance into the terrain. The pilots were not informed that this run would be any different than the previous.

The Results. As predicted, the users of the SVS displays demonstrated significantly more accurate lateral and vertical tracking of the desired course compared to the users of the baseline EADI display. Twelve of the 16 test subjects flew the CFIT “rare event” scenario with one of the SVS PFDs. All twelve pilots noticed and avoided the CFIT. “On average, pilots with an SVS display noticed the potential CFIT 53.6 seconds before impact with the terrain.” The remaining four pilots flew the CFIT scenario with the baseline display. All four pilots had a CFIT event. Three pilots impacted the terrain and one passed within 58 feet of a mountain peak, unaware of any terrain conflict. In addition, two unplanned CFIT impacts occurred with the baseline display while executing the circling maneuver from base leg to final approach.

This experiment clearly demonstrated the benefit of the Synthetic Vision System in providing better pilot situational awareness, increased accuracy, lower cockpit workload, and more confidence in knowledge of terrain clearance. The rare event scenario illustrated dramatically the advantage of SVS for identifying and avoiding potential CFIT incidents.

Current and Future SVS Applications

In 2003, Chelton Flight Systems (mentioned earlier in conjunction with the Capstone program) received the first FAA certification of a Synthetic Vision System with Highway-In-The Sky technology. The Chelton EFIS-SVS can now be found on a wide range of general aviation aircraft, from the Beechcraft King Air 200 to the Bell 206 helicopter.

Chelton’s EFIS-SVS was also used on Steve Fossett’s non-stop, non-refuelled flight around the world. His aircraft, the GlobalFlyer, was equipped with two of the displays, one used as a PFD and the other as ND.

Chelton Flight Systems EFIS provided Mr. Fossett with critical information on aircraft performance and navigation. It was his primary source for flight instrumentation, providing a real-time moving map perspective along the entire route of flight, along with seamless three-dimensional terrain modeling. Coupled to a three-axis autopilot, the EFIS played a significant role in reducing pilot workload and in keeping the aircraft flying through a steady flow of green rectangular boxes that created a virtual Highway-In-The-Sky, affirming the aircraft was on course. ~ Chelton Flight Systems

Other avionics manufacturers such as Honeywell and Rockwell Collins are getting on board as well. Both companies are offering larger, integrated avionics displays with easily reconfigurable software that can change to suit the aircraft and the operator. Although these systems don’t specifically offer SVS, the new packages are ready to accept the software as soon as it is certified.

Gulfstream’s PlaneView cockpit also offers large LCD displays, and several Gulfstream aircraft have the option of incorporating Gulfstream’s proprietary Enhanced Vision System (EVS), which received provisional FAA certification in late 2002. Gulfstream’s EVS uses an infared sensor to “see” through clouds and fog and depict that image on a head-up display (HUD) in front of the pilot. (Hughes, 2003.)

Summary

Reduced visibility is one of the leading contributors to aviation accidents worldwide. Current EFIS and classic “steam-gauge” cockpit displays have proven to be inadequate in providing pilots with accurate situational awareness and terrain avoidance information. With the computing and display technology available today, a more intuitive means of presenting flight critical data must be designed and evaluated.

Synthetic Vision is that means. Laboratory research and flight test programs have proven that SVS-equipped aircraft are safer and easier to fly. The current number of pilot-error accidents due to low-visibility flight is unacceptable and any technology that can contribute to a reduced accident rate should be implemented as soon as possible.