Over the years, i have been building a "General Purpose Cockpit" designed to support my many and varied interests in the computer simulation world. It has served mostly as a testbed for evaluating emerging technologies and as a scaffold to mount various projects, such as the one described in this article.

Unlike most cockpit projects out there, I attempt to use off-the-shelf componentry instead of the popular cockpit electronics. This gives me considerable freedom with component selection and frees me from any particular architecture's limitations.

This article describes the first of several "General Purpose Panels" to be built into the simulator. The panels will not be identical appearance, but address specific needs I find in various simulations. However, they can be completely re-used in other simulations and games.

Design

There are two components to the panel: the switches and the alpha display. The switches will go to a keyboard encoder. I chose the Hagstrom KE72 from Hagstrom Electronics. This device converts switch closures (and opens) to user-defined keystrokes. If you want to set the "Wings Level" autopilot, arrange to have a switch send the letter "L" on both switch close and open. This particular keyboard encoder sends actual keystrokes out the PS/2 port. The operating sytem has no idea that the encoder exists, as it does not require a driver. The encoder supports a total of 72 switches, a total of 10 were used in this panel.

The alpha display comes Matrix Orbital: a Canadian company. These displays are increasingly being used by case-modders to fulfill every sort of task. It behaves very much like an old-style terminal. This one has 2 lines of 20 characters each. Just like the old terminal displays, it has a cursor, and can be configured so it scrolls. My typical write operation is 40 characters long which results in a complete update of the display upon any write action.

Hardware-wise, most alpha displays are parallel devices. With a little work, you could wire it up directly to parallel (printer) cable, and plug it into your printer port. This one has a USB interface, which raised the price a bit, but bought a lot of programming convenience. It can also drive 6 LEDs if you configure its onboard hardware correctly. It also has support for a keypad - which was not used in this particular design.

Once properly installed, the operating system sees the display as a "Virtual COM port". It is indistinguishable from a "real" COM port, except it does not consume the parallel connector on your computer.

Software-wise, your message will go out the virtual COM port via normal file I/O, but hardware-wise it goes to the display via USB. This is a very clever way to communicate with USB devices without getting overly involved with fancy protocol or specialized drivers.

A Rotary Solution

Toggle and pushbutton switches can handle the majority of tasks, but sometimes one wants to turn a knob, to dial a radio or GPS for instance.

A good friend came to the rescue with the invention of the "T8b" rotary device. He worked very hard to fulfill my specification for a robust, reliable and affordable rotary device. After several evolutionary iterations, it became a microprocessor-controlled unit which mounted directly behind the rotary encoder.

The design is brilliant. It uses Greyhill's quadrature encoding to reject error conditions. It  buffers actuations, holding them in memory if necessary, then sending them at the rate the Hagstrom card can accept them. This means that every click you feel through your fingers results in a synthesized switch actuation on the Hagstrom board - no matter how fast you want to turn it. Other designs do not "hold" the extra clicks, and consequently lose them. The PCB can accept 16, 20, and 36 "clicks" per dial revolution with no software changes. Most important, they have an excellent "feel". Each click is definitely transmitted to your hand. You absolutely know how many clicks you sent to the simulation - the microprocessor takes care of the rest. It works like a charm when making cursor selections with the GPS.

Although an excellent product, it may never go into production. I just don't want to inventory, build, support, or market these things. If anyone seriously wants to bring these to market, contact me by email.

Construction

Most of the parts were readily available at the local RadioShack, hardware store, glass store or by poking around the basement. Enough planning - it's time to build.

By far, the trickiest part would be drilling all those holes with some precision. A full-size drill diagram was made in Photoshop and taped to a Lexan sheet. The manufacturer of the alpha display supplied an excellent scale drawing of their board, along with drill holes. It was largely a matter of taking my time, securely clamping down the workpiece and NOT screwing up.

Test parts fit. Note how clear LED lens snaps in from the front. LED snaps into it from the rear.

Once drilling was complete, a parts test fit was done. This also helps with the placement of the mask for the alpha display when it's time to paint.

For the first time in a long time, it was beginning to look like something. It was disassembled and then painted.

The drilled holes in the Lexan sheet would provide mounts for all assembled components. The switches mount in their normal (thread with nut) manner. I found some clear plastic LED mounts that double as lenses. The LEDS snap into them from the rear of the board. I replaced two screws holding the alpha display board with longer versions. You can see them in the above illustration.

Wiring the components was very much a point-to-point affair. The 6 LEDs were wired from a header on the alpha display board. The switches are bus-grounded together (the blue wire). I like using 24 gauge telephone wire. You get 4 wires bundled into one cable, and it's really inexpensive. Notice there is no connection at all between the Hagstrom switches and the alpha display. Neither section is aware of the other. You cannot light a LED by flipping any of the switches. It's actually busy enough in the back to resemble an real piece of electronic equipment.

The front looks much cleaner. Painting the backside of the panel leaves the front very shiny. One has to be very careful to mask the section so only the backlit area of the alpha display is shown. The display looks very dark when turned off.

Programming

Time to make it work. This little panel can be used in two different ways, depending on the simulation or game's ability to support it.

Simple Mode

The simpler mode involves merely using the alpha display as text labels for the switches. I wrote a small program to initialize the display so one can send text to it with a simple "echo" command under the window's command prompt. Here is an example of the script:

The above three lines (minus the comments) form a batch file which can be executed with a mouse click. Once executed, you have a labeled panel with defined switches ready to go.

Panel running in "Simple Mode". It provides several functions of the GPS pushbuttons and dials.

One note: I am not sure if one can load the USB version of the Hagstrom card from a shell script. In this case, you would have to load the key definitions via the Hagstrom program separately.

The neat part is: no formal programming is necessary. The PS/2 version of the Hagstrom card has a simple syntax for keystroke definition, and the text for the alpha display gets loaded by simply changing the text after the "echo" statement in the script.

In this mode, the application has no idea the panel exists, and the panel has no idea the application exists. This means that it could be re-defined and re-used for any game or simulation that supports keyboard input.

Slightly Less Simple Mode

If you are handy with programming, you can change the appearance of the alpha display on-the-fly with a little work. You can also drive those six LEDs, in any manner desired. The Hagstrom section remains unchanged from above and behaves exactly the same.

The following example works with Dr Martin Schweiger's Orbiter space flight simulator: a highly recommended adjunct to FlightSim. It basically takes over where FlightSim leaves off - giving you the ability to fly the rest of the solar system. The good doctor releases an API, and one can query many of the program's internal variables similar to what is done with FlightSim.

The panel will become an autopilot for Orbiter. When at rest, the alpha display shows the functions for the switches. In this example we get the Altitude Hold, Wing Leveler, Prograde or Retrograde autopilots, plus Orbit normal and antinormal orbits. The two toggle switches are 3-position, center-off switches that will fit the pro-and retro options used in the autopilot. The LEDs will represent the state of the switches.

Panel used as an autopilot in Orbiter. The display shows the functions of the buttons.

The program's sequence works like this: I press the "WING LVL" button to engage the wings level autopilot. The button has been pre-defined to send the proper keystroke (the letter "L" for example) out the Hagstrom encoder via the PS/2 port. Orbiter picks up the keystroke and activates the autopilot.

Meanwhile, a small C++ program (which I wrote) monitors the state of Orbiter's autopilot. When the autopilot changes state, I send an appropriate message reflecting the state of the autopilot to the alpha display and light the LED associated with the button. This is very similar behavior to the way the light functions in the cruise control in your car: the button does not light the LED, the computer lights it - reflecting the state of the autopilot. If I cancel the autopilot with a button push, the LED goes out, and the alpha display reverts back to the text labels described at the start. If your joystick can send keystroke events, it is really neat to push the button on the joystick, and watch the panel respond accordingly.

Used this way, the panel is a bit more intelligent - providing status information and visual feedback in addition to label names.

Installation

All the panels in the cockpit have a consistent width, which happens to be the width of a GoFlight rack-mounted component. This allows me to implement a rack-mount solution of my own. Here's a shot of the completed panel mounted above a GoFlight GF-45 display. The GF-45 is user-programmable, so they get double-duty in Orbiter as well as within FlightSim. I ripped the GF-45 out of its box, and mounted it on a Lexan sheet similar to the manner of the Autopilot. This gives a consistent appearance for all panels I plan to build.  The resulting appearance is consistent for any panel I will create.

I like the flexibility of the design - the panel can be as stupid or intelligent as you like. It works for simulations that do not publish an API, or even better for those that do. If you do not know how to program, that's fine - if you can program, that's even better.

Elden Slick
meldenslick@hotmail.com