User:Callahanp/Howto Build your own Panel or Cockpit

From FlightGear wiki
Jump to navigation Jump to search
WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.

The focus of this Howto is currently on gaining a handle on the scope of your cockpit project. It is a companion to Howto: C172P Cockpit Project which will feature concrete examples of the general topics discussed here. The Howto: C172P Cockpit Project is a work in progress and is under active development. Both howtos will be updated periodically when major additions are possible. Small edits will not appear in their history unless made by others. The Talk pages for both howtos will list major changes. So Read on, and check back to see what progress we've made. You can also join the projects by emailing the primary author through the wiki.

Callahanp (talk) 19:56, 8 November 2017 (EST) So to begin:

The Flight Simulation Bug Has Bitten!

Ok! You've decided you want to build a Simulator Cockpit, an Instrument Panel or Radio Stack. Possibly some controls like Yokes, Rudder Pedals, Throttles, Flaps, Light Switches etc.

You'll have to do a bit of digging, but there's plenty of information out there about projects like the one you are starting. There's a short list below of the kind of thing you'll find on the internet related to cockpit building. This Howto is intended to be a guide to setting up and running your own project.

There are several other Flightgear cockpit projects. You should check these out for ideas, approaches and solutions. You'll find them in the Cockpit Building Category If you're contributing any new wiki pages on cockpit building be sure to add this category.

First Steps

This section of Howto Build your own Panel or Cockpit is about what to do first. Its about thinking about your flight simulator from start to finish, but at a very high level. In every complex project you need a map of the territory. You may not know much about the details of building simulators, but if you can build yourself a map of the kind of things you personally need to do to get it done you'll not get lost as often.

I deliberately wrote this using the word "you". Its your project. You're unique. Your project's going to be unique. Its yours. You may be the kind of person who can skip this exercise and start building things. You may know everything you need to know to get the job done and it may seem trivial to you. I'm not. And I think most of us fall somewhere between needing step by step instructions and not needing a plan at all.

A word of caution though: You can't fly a plan. You need to start working on building something right away even if its just a prototype of something small. The question I ask myself is "What did you build today?" If the answer is nothing, I'm either overplanning or writing wiki pages.

So lets get started by looking at things you may need to think about and maybe write down some notes about your thoughts.

Mission Statement

To get started on your simulator, write a one page document as an overview of what you are trying to accomplish, and what you need to do. Keep it simple and short. The purpose is to clarify your own thinking about the project, not to be a "Grand Design". If it turns out to be longer than a page, remove some details. The details will come back to you later. This should not take you long, but you may want to take a few tries at it over several days.

Keeping track

You're going to want to organize things for yourself to make it easy to find what you need in the moment. Some things you'll want to keep track of:

  • Mission Statement
  • Sketches of what you want to build
  • Designs
  • Prototype information including why you did them and what you learned
  • Work Product Item Documentation
  • Screenshots, photographs and videos you have made
  • Screenshots, photographs and videos others have made
  • Ideas about how to build things.
  • Contact Information for your support team
  • Application Notes and Datasheets for electronic parts
  • A set of bookmarks related to your project, including vendors you'll use

Set this kind of thing up the way you want it. There's no "recommended" way. Just don't spend too much time organizing and too little building.



See C172P Cockpit Project/Concept


Keep the startup simple. You'll probably want to get working on something right away. But there are a few things you should probably do first.

Do everything you can to clarify your ideas about the project. Write 4 sentences about your project that would tell a reader exactly what you're building and what you hope to get out of it. Draw some crude pictures. Label things. Write down a list of questions you need to answer. Think you know what you need to buy? Write it down, but don't buy it yet.

Don't you dare write a 20 page plan. You'll never finish.

You need to keep an eye on two things: Your goal, and what you've built.

Start Simply. In your simulator program, using the plane that you want to build a cockpit for. There's a single switch. Its in the lower panel of your cockpit. It's labeled Taxi Lt. It seems to be a simple on-off switch. Now what? I'm not going to tell you. You have to look up what to do about that. Its going to be in your cockpit. You have to know.

Too easy? Find out how to do the same for the other 70 or so switches in your cockpit.

You've probably got a lot of questions about your project and the cockpit you're building. Questions you don't yet have answers to.

Write them down, make categories of questions, Find the one you think is the simplest to find an answer to and keep going.

Draw Pictures, Take Screenshots of simulations of the cockpit you want to build. Figure out which pieces you want to buy ready made and build the rest.

Read some datasheets, learn some electronics, learn to program. You don't need to know everything about these subjects, just enough to know that there are still things to learn and enough to recognize when that's the case.

One is an inventory of the groups of similar switches (count them), individual gauges, instruments, radios and controls. The count of these items can give you a clear idea of how many little projects you'll have on your hands if you've decided to build your own instruments or what to try to buy if you're going that route.

If you're going to do everything, at some point you could do a second more detailed inventory. A second inventory that's more detailed catalogs everything. Its going to give you

  • Include every distinct identifiable part in screen shots of your chosen aircraft's cockpit.
  • Include every thing that moves and the character of that movement. the effect of anything you can touch that changes something visible in the cockpit

You'll want to catalog things that move or change one by one. If there's 4 5 digit numbers and a decimal point, that's 4 things.

and the different ways they move, like turn and also pull on the inner frequency adjustment knobs on the KX165 Nav/Comm receiver.  If one thing moves or changes something else, include a note to that effect, like the knob on the adf turns the outer ring compass card on the instrument, or the each of the two frequency knobs change the displayed frequency by a certain amount and when pulled, change it by a different amount.  Don't forget the Outside Air Temp indicator. It's out of the way on some aircraft and easy to miss.

like inner and outer dials, things that you pull like the cage , push or pop out like circuit breakers

If it moves independently or stays stationary and is distinct part of the visible cockpit it belongs on the list of things you are going to make. Take note of instruments that seem challenging, including every switch, volume control, intensity control, instrument adjustment, dial, needle, moving card, stationary card, decal, label, bezel, faceplate,

You may want to clarify your ideas about your project before you get too far into it. Here's a couple of ways I found helpful: Sketches and a written statment of what I'm doing Do some rough sketches of what you'd like as a final result Make some decisions about how you want to do the job and what you think you'll need to learn along the way. Describe the whole project in as few words as possible.

When you've got a workable concept, you'll be able to briefly explain what you are doing to someone else. If you've done it right, a listener will come away with a clear understanding of what you want to do, what the end result will be and will definitely not have the impression that you are absolutely nuts. A few clear sentences will do the job. Write them.

Starting the project as a whole still involves working at the summary level, but you also work in the next levels of detail. The summary step can also include preliminary design work in the form of hand drawn rough sketches that you may or may not use as the basis of your actual design. In the case of a flight simulator, this includes a survey of the kinds of switches, gauges, instruments, radios and flight controls found in the aircraft you choose. To start, you want to break the project down by groups of items and in some cases individual items, but not the complete details of their parts and construction. In the starting phase of the project you divide up the whole of what's to be built, but you don't worry about how these items will be built or what their parts are. At this point rough sketches of the whole project and some of its parts are useful. A good start is to have a summary of the items to be built and a notion of what activities you'll need to get them done. At the start is a good time to look at what others have done that is similar or relevant. You can examine others detail solutions and get an idea of what the coming activities are going to be. You man engage in some education, training or exploration of parts that might be useful in actual construction, but you are not making any final decisions about them. You can gather documentation at the starting stage that will later be weeded out to focus solely on what is actually used.

Note that you can proceed to Early Design and Early Prototyping while doing the work needed to "start" your project. You don't have to wait. You can get your hands dirty.

See C172P Cockpit Project/Starting


The purpose of documentation during a project is to help you get the job done. Keep only what you need for that. You might want to use documentation to keep track of the status of major activities at startup. Later you may only be interested in the status of activities for each "work product" Us a status report as motivation or as a way to decide what to do next. Don't even do one if you don't absolutely need one to keep things moving or communicate with any of your team. (you do have a team don't you?)

See C172P Cockpit Project/Documentation


Design is where you figure out exactly what to produce and exactly how to do it. It doesn't have to be a formal exercise. Depending on what you are working on you may need a little or a lot of detailed data. I'd like to do just enough design to get the job done. If a sketch with dimensions is enough, then that's what's done. If a CAD drawing is done its probably going to be drive a 3d Printer, 3d Router or a Mill. CAD drawings might also be needed for things that need to assemble accurately.

Design of a work product should cover every applicable aspect of the product:

  • Materials
  • Measurements
  • Construction methods
  • Testing,
  • Assembly
  • Integration with other work product items

etc. Hang on to any design materials you produce. They may prove valuable to you or others later.

See C172P Cockpit Project/Design


Prototypes are basically little projects. Use the same concepts that you use on the larger project. Ask yourself why you are doing a prototype. Ask if the prototype is really necessary.

Prototyping can be considered part of the Design process. So moving between the two activities is to be expected. But later you may find yourself going back to design from Construction or Assembly. If that happens try to figure out why and how to prevent it in the future.

Prototyping is for asking questions and finding things out that influence designs. Questions may be about the design, about how to do the construction or about whether a specific idea will work or not.

If you've run out of questions, maybe its time to build something. Move on to Construction.

Prototypes need a small plan that outlines where the prototype fits in the overall project. Goals and questions to be answered need to be specific. The answers need have a known purpose. Parts lists should be included. Source code should be included in full or by reference when it becomes available. A list of tests and things to be examined and documented is needed. Results should be written. Pictures of the project in action will help document the results if that's desired.

See C172P Cockpit Prototypes and Prototypes not specific to an Aircraft


Construction may be an obvious step, or there may be unusual steps to take, special materials, special tool consideration or safety concerns. For documentation, just say what needs to be said and get on with it. When you finish, maybe write about how it went. or take and file a picture or two.

See C172P Cockpit Project/Construction


There may be different phases of assembly, starting with assembling individual items, installation in a panel or equipment bay or assembling the entire cockpit. You may want to document this for others, especially if you find surprises during final assembly.

See C172P Cockpit Project/Assembly


There may be tasks best left until after assembly. Keep track of them under this topic and ensure they get done if they're still needed.

Are we there yet? Can we fly? What's the next project?

How to put a Simulator Together

You can look at a simulator at several different levels: The simulator as a whole is a cabin. In the cabin are supporting structures. These structures support Panels and bays, Consoles and Controls like the Yoke and Pedals. Panels support sets of gauges and instruments. An equipment bay accepts an assembly containing all the radios. When we first worked on the concept, we may have drawn some preliminary sketches of these items. In the design stage, we make things more exact with specifications of measurements, materials, how things attach and possibly information about construction and final assembly. The breakdown for assembly is

  • The Cabin
  • Supporting Structures
  • Panels
  • Switches or Groups of Switches, gauges, instruments, radios, controls
  • Low level parts.

The design needs to address work product at each of these levels.

The Cabin

You're going to need some kind of cabin for your simulator. It could be just an area of a room with no sides or ceiling except the walls and ceiling of the room. Or it could also be a complete enclosure with doors, windows and ceiling exactly like the aircraft you're simulating. The cabin provides a place to install the working parts of the simulator, including any monitors.

Eventually You'll need to plan all the details for your enclosure but at the beginning, to begin, simple hand sketches with a few basic measurements will do. In C172 Cockpit Project/Early Sketches, you'll probably notice that there is no "enclosure". Its just the Instrument Panel, the center console, the foot well and some supports so it doesn't fall over. 1

For me the enclosure is just a section of my home office and computer room with two 24" monitors to display what's outside the plane. The simulator will take up 40" of the 10' built in desk in the office. I'll save on plywood or aluminum because there's no sides and top. You may want something more realistic.

Supporting Structures

You'll need to support the working parts of the simulator and its display in an arrangement that is similar to a real cockpit. Think about what's holding up everything from the pedals to the Control Panels and how things will be attached You and maybe a co-pilot are going to need to sit somewhere. Again a sketch with a few measurements will suffice. Behind the covers on your instrument panel may be several individual panels with a few instruments or gauges each mounted on them. The radio stack is usually treated as a separate section to support all the radios. Yokes are usually mounted behind the panels with the shaft positioned to travel between and through two of the separate panels.

In general you'll need a foot well, center console and individual panel sections. You'll need to have something immediately behind the panels to attach them to, leaving room for the instrument mechanisms. You'll need to make provisions for a radio bay so individual radios can be attached. You'll need to allow for the Yokes, their electronic sensors and connecting mechanisms if there are two of them. This should probably be done behind a firewall like structure at the rear. This will allow flexibility in arranging Linkages between the Pilot and Copilot Yokes and Pedals and Force Feedback Mechanisms if you choose to include that immediately or later. You also need to consider how the whole arrangement can be self supporting without risk of falling over. You will also want to consider how the cockpit can be serviced and how it can be broken into parts or otherwise secured for storage or transportation.

Make a draft sketch or sketches showing the individual panels you'll need. Label each panel by its position or contents. Names like Left Pilot, Sixpack, Radio Stack. etc. Around this sketch, you can add structural elements visible from the perspective you chose. They don't all have to be there in detail, but Notes and arrows indicating where things not visible will be located are good. Your sketch and notes should cover all the issues in the previous paragraph.

You can add notes on the sketches to cover the issues outlined above, but it does not have specify how everything will be done, nor does it have to show everything in detail. Scan these sketches to add to your project documentation file.

A few kinds of parts

While there are lots of parts in the complete simulator, the number of different kinds of parts needed is actually quite small.

You may be building from commercial simulation parts such as complete yokes, radios and instruments. In that case just make a shopping list and take out your credit card.

= Madness defined as The Making of Lists

You're going to make a few lists. The first ones will give you some clues to the size and overall complexity of your project. Later lists will help to specify specific measurements and the specific parts to acquire or make.

Open your flight simulation software and start up your type of aircraft. Make sure everything is illuminated. Take a screen shot of every part of the cabin and print them. That's where we'll start our Planning Spreadsheet. If you don't have a spreadsheet program available, grab a free copy of Libre Office or Open Office.

Make a list of every gauge, instrument, radio, clock, control, group of similar switches, group of circuit breakers and something to catalog its location. I've chosen to divide my instrument panel into sections the way the real aircraft does and I'll list items by panel. I'll include structural supports I think are necessary as well The C172 List has

Panel or Support Switch group, gauge, instrument, radio or Control
Mounts behind panels Pilot & Copilot Yoke & Pedals
Footwell Firewall

Pilot and Co-pilot Pedals

Left Pilot (L) Suction Gauge

Fuel and Oil Gauges
Electric Gauges

Sixpack (Rectangle) Airspeed

Attitude Indicator
Turn Coordinator
Heading Indicator
Vertical Speed Indicator

Right Pilot (reverse L) Egt Gauge

Adf <br/ Course Deviation Indicator (2)

Lower Panel Primer

Carb Heat
Flaps & Flaps Indicator
Circuit Breakers
Light Switches
Panel/Radio Light
Avionics Power
Cabin Heat
Cabin Air

Upper Right Copilot Hobbs Meter
Lower Right Copilot Empty
Right Wing Outside Air Temp
Trim Panel Trim Wheel and Trim Indicator
Fuel Selector Panel Fuel Selector Switch
Radio Stack

KMA20TSO Audio Panel & Marker Beacon Receiver
KX165 Nav/Comm Radio (2)
KAP140 Autopilot
KT76A Transponder

Start with the "Cockpit"

Simulation Hardware Parts

Take a information about Prototyping for the electrical and electronic devices you'll need to build your gauges, instruments, radios and controls.

Look in the Cockpit Building Category for other related projects

WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.

This page is currently a set of discussion points around the topic of design. No detailed information on how to do anything here, just things to think about.

Simulator Cockpit Design

When you build your own cockpit, there's a number of design choices to make.

  • You may want to make the individual parts usable before the whole cockpit is ready to assemble.
  • Perhaps cost or time is an important consideration
  • You may want to be able to disassemble the cockpit for storage or transportation
  • You may want to build it in the back of a truck
  • A certain level of reliability may be a design goal
  • Realism may be a priority or not. You may settle for components being in the right place, but looking somewhat different from the real articles.
  • Fast enough response to changes in the simulator and changes made by operating the hardware is likely to be desirable
  • Noise may be a factor
  • Fire, Electrical and Physical Safety should be considered during design, covering both construction of parts, assembly and afterwards during operation of the simulator.

Design - Putting it all together

In a cockpit there are numerous switches, gauges, instruments, radios and controls.

These components can be organized by "Panel". My version of the C172 has Left Pilot, Six Pack, Right Pilot, Radio Stack, Co-Pilot, Lower Panel, Trim Wheel and Fuel Selector panels. You can guess how those will fit together physically.

Lets call each individual gauge, instrument, radio, control or group of related switches a separate "component". Each panel has one or more components. Panels make physical assembly and disassembly easier. They can also simplify wiring if everything on each panel is routed through a small number of plugs and sockets. Some of these plugs and sockets might have quite a few pins.

There's another way to break things down though. You can categorize all the components regardless of what panel the appear in by the number, overall type and variety of parts they contain. Active Parts are small devices that do something to one and only one needle, dial, number, word, indicator or circuit within a component. Active parts include switches, air cores, steppers, servos, LEDs, rheostats, magnetic or rotary encoders, seven and sixteen segment displays. Parts are what make our gauges, instruments, radios and controls do what they do.

Some types of active parts will have more than one variety. Each variety may or may not need a special interface.

Here's a partial list of Panels, Components and Active Parts from the C172P project. [[ | (full list)

Component Active Part Part Variety
Airspeed Indicator Air Core Movement Return to Zero 1
Tachometer Air Core Movement Return to Zero 1
Altimeter Air Core Movement or Stepper Heavy Duty 1
KMA20TSO Audio/Marker Indicator LED Red, Orange, Blue 3
KMA20TSO Audio/Marker Indicator Switch 3 Position 1
KMA20TSO Audio/Marker Indicator Switch SPDT 9
Lights Switch SPST 6
Circuit Breakers Switch SPST 16
Circuit Breakers Solenoid 16

Some of our components are quite simple and have a single part that needs to be interfaced with only one path for a signal An on-off switch is one simple example. In a switch, the change is that the signal is passed through the switch or not. The tachometer made of an air core is another type of part. An air core's interface takes two signals, both sine waves of varying amplitude that are 90 degrees out of phase with each other.

These two signals are passed through separate coils, also oriented 90 degrees to each other. Although the signal is changed by passing through the two coils it's not the change in signal we care about. In an air coil we care about a physical effect due to currents flowing in the two coils. This effect is a magnetic field oriented in a specific direction corresponding to the proportion of the amplitudes of the two signals. Air cores are motors designed to move an enclosed magnet. If the magnet's position does not match the alignment of the magnetic field, it will move until it does. When it does match it remains in a fixed position. If the enclosed magnet is attached to a pointer, we have a device we can use in several of our gauges and instruments.

Other components may consist of several parts and have parts of different types. The Audio and Marker Beacon Radio in the C172P is a good example. It has nine of one type of switch, one of a second type of switch and 3 indicator lamps. Expand this to the whole cockpit and you have hundreds of Active Parts of a dozen types and varieties. These parts distributed among more than a dozen discrete components, some simple, some quite complex and we need at least one signal path for each one.

Design Approaches

There are different ways to drive signals all these parts. Design approaches differ in the type, number and placement of interfaces. In hardware, some interfaces are just physical connections between devices and the type of signal that passes through the connection. Other hardware interfaces inside a device may change the signal in some way by passing it through an active or passive device.

Interfaces in software are similar. In software, the connection and signal and signal modification concepts have an analog in a path for data to move from one part of the software to another, the type of data that is allowed to pass through a path, and the operations or methods that can be applied to change data traveling over one or more such paths.

The interface boundary between software and hardware occurs on a pin of either a main processor or an attached peripheral device configured by the main processor.

There are many ways to design the combination of hardware and software to bring the proper electrical signals to a disparate set of parts.

One approach calls for standalone components. Each component would have circuitry to drive each of its parts. The component would be responsible for any translation and calibration needed to run the parts and would accept and send data between itself and the flight simulation software using either its own connection and protocol, or communicating using a common protocol through some kind of message broker

The other approach drives the similar parts of multiple components from a central point. Software at the central point for a given type and variety of part is responsible for any translation and calibration needed to run the parts as well as communication with the flight simulation software either directly or through a message broker.

There is an advantage in the first approach. With everything done as discrete modules, failures might be isolated to a single component In the other imagine that all your radios would work, but you can't turn them on because of a failure in your switching system. In a simulator, that might be ok. In a real plane, not so much.

There is a third way that may be necessary in a real aircraft but not necessarily in a simulator. In a real plane, the ADF indicator and the ADF radio receiver are tightly integrated. There is separate circuitry that is responsible for brokering the information between the two devices. This circuitry may be placed in a separate device behind the panel, or it may be integrated in the Radio. The Course Deviation Indicators and Nav portions of the Nav/Comm radios have a similar arrangement. Hardware interfaces are defined for each part in the transaction.

In a simulator, whether to mimic these behind the scene connections or not is a design decision. This decision may be affected by characteristics of the available data in the Flight Simulation Software, or the decision may depend on other considerations such as communication response time..

A role for Software

So far, we've just considered hardware interfaces. At some point, the signals used by hardware parts need to be treated as data. This changeover occurs at the i/o pin of some kind of processor. The signal path and allowable signals of a hardware interface have analogs in software as specific paths for items of data and the types of data the specific item can represent on the path. In most software, changes to data along a path become important. It is this characteristic of software that makes it possible to drive many different kinds of devices from i/o pins directly or indirectly with minimal electronics. Complexity that formerly resided in static electronic circuits has migrated into dynamic software.

Status of this Howto

For information about where things stand with this Howto, click the discussion tab.

Some Detail

Links to similar efforts on the Flightgear wiki

Links to FlightGear mailing list and forum entries related to panels or cockpits

Cockpit and panel projects on the FlightGear Wiki

Other cockpit and panel projects

Callahanp (talk) 10:17, 6 November 2017 (EST)