Howto talk:Build your own Panel or Cockpit - Cockpit Systems and Hardware

This stuff is in need of a serious re-write and not all of it belongs on this page.

The Instrument and Radio Panels consist of a number of physical switches, rotary encoders, meter movements, numeric and alphanumeric displays, moving and non-moving dials, pointers, led indicators, rotation sensors. Even a small plane such as the C172P has over 100 distinct items that must communicate with the simulator.

Three things you need to make happen with some combination of hardware and software: In both directions between the cockpit hardware and the simulation software, there are constraints that need to be taken into account so that the cockpit hardware appears to exactly mirror what's going on in the simulator software.

• Movement of something in the cockpit and the simulation program should start and end at the same apparent time
• The rate of movement should appear be the same between them
• No significant change can be ignored or delayed on either end.
• A series of insignificant changes in one direction might add up to something that would be apparent if handled in total, but would not be apparent if handled individually. You may have to manage this situation so you are not extensively handling something insignificant when you could be doing something else.
• A series of insignificant changes that bounce around an insignificant range should be managed for the same reason.

The things that may need managing are rapidity of changes, hardware and software latency and message priority. These factors may affect the order in which events in the simulation program and in the cockpit hardware are handled by the systems you put in place to acquire, communicate, and modify data on the path between the sim and the cockpit. If your hardware is fast enough and your handling of messages is timely, the cockpit will feel right. Noticeable delays will make it seem less real.

From the hardware perspective this communication involves

1. Physical cockpit hardware: switches, encoders, instrument movements etc.
2. Low level interfaces to gather or distribute raw data for the cockpit hardware
3. A Master Client to
   1. interpret between raw and simulator data
   2. handle communication between the cockpit and the simulator software

For the complete C172p there are:

• 12 volume controls
• 9 multi position switches
• 17 meter movements
• 70 spst switches
• 9 spdt switches
• 17 rotary encoders
• 7 instruments with rotational movement
• 12 3 to 6 digit numbers
• 4 3 letter Alpha displays
• 23 on/off indications on radios and instruments

The low level interfaces can use an ATMega processor of some type, probably an ATMEGA8535 or ATMEGA8515. Each of these can handle inputs and outputs for specific controls, switches, instruments and radios.

The simplest implementation would about 300 gpio pins to drive every hardware element. However, there is a way to reduce the pin count dramatically. The technique is called multiplexing. There are a number of chips that support multiplexing in various contexts. The simplest to use allow you to send pairs of 8 bit bytes to a device that will set the values of 16 outputs, 1 per bit. The same device can accept 16 inputs and tell you what the value of the individual bits are in two 8 bit bytes you read back from the device. These devices communicate using the SPI or I2C bus with a processor such as the Arduino, Raspberry Pi or BeagleBone.

You can use multiplexers directly to get 16 additional gpio pins per multiplexer. Need 64 switches, use 4 multiplexers. 128, use 8. A particular multiplexer will limit the number of similar multiplexers you can connect to I2c or SPI bus. Other chips and different designs could give you more.

Can the following be done? Can we use just two 16 bit multiplexers to sense the positions of 256 switches? Will it scale to the full 256 switches, or will there be some factor of circuit design that makes it difficult to make it work reliably. A prototype should tell us these things.

Due to processing time limitations, you may need to use more than one low level processor.

Processing the multiplexed data:

Rotary encoders are essentially a pair of switches. These may need to be handled with higher priority because each switch transition is needed in order to detect the direction of movement. Since there are 17 rotary encoders in the c172 cockpit, We'll need to get back to each rotary encoder to sense if a change has occurred. Usually only one rotary encoder is in actual motion at any given time, so the amount of time actually needed is driven by the rate at which the encoder is spitting out it's gray codes Multiplexing further reduces the number of cycles needed, as 8 encoders can be serviced at once using 16 bit multiplexers. If we prioritize the servicing of any encoder detected to be in motion, we can easily handle most or all the de-bouncing in code. Some of the de-bouncing can be reduced using appropriate capacitors in the encoder circuits.

Rotary encoders determined to be "not yet in motion" need to be serviced often enough so that the first actual transition is detected. On the other hand, regular toggle switches can be delayed for a number of milliseconds, as once a switch is thrown, it stays in position. One assumes you do not throw switches rapidly back and forth in a cockpit. If we service each group of 16 switches every 100ms or so, things should work fine.

Magnetic encoders are quite good at resolving the angle at which a given control is positioned. This will be needed for the VOR, ADF and Magnetic Compass instruments. They are quite cheap. An encoder with a magnet can be had for about $6 USD. chips using SPI or I2C are available.

Two bytes of data are needed to handle the 12 bits of resolution these encoders provide. Calibration is the sticky point. The outputs are definitely non-linear. Some chips have the capability of handling non-linearity internally, but programmers for the devices are expensive. We're going with a cheaper alternative. Don't bother to program the chip, just let it do its thing and we'll handle the calibration in our software with lookup tables. Additional processing of the read values may be needed to eliminate vibration induced jitter.

We'll need some kind of air coil to drive various instrument's meter movements such as the airspeed indicator, attitude indicator, fuel guages, VOR needles etc. These can either be hand made or manufactured units (manufacatured units are about $16-20 USD in the quantities we'll need, or as low as $6 for a large group purchase.) While making these by hand sounds intimidating, It may not be that difficult to do. Hand built is certainly cheap. There are chips using spi or I2c interfaces that can drive an air coil directly. As with Magnetic Encoders, calibration will be needed and we'll handle that in similar software.

From a software perspective, we'll need programming for:

1. A client handling communications between a Raspberry Pi and our Simulation Software
2. Managing communication between the raspberry pi and lower level interfaces
3. Interpreting various types of simulator properties
4. Handling raw data for
   1. A/D conversion of slider and rotary potentiometers
   2. Single and multi position switch data
   3. Data from rotary encoders
   4. Data going to numeric displays
   5. Rotational position sensing for certain instruments and controls
   6. Rotation of an air coil for any meter like movements.

Main Page: Howto: Build your own Panel or Cockpit