Howto:C172P Cockpit Project/Miscellaneous notes
Specifications - General
Software and Hardware Requirements for Cessna C172P Flight Simulation Hardware
While each instrument, radio, and control may be handled as a separate item in confuguration, the actual implementation may group similar hardware aspects of multiple devices together. The groups are switches, encoders, rheostats, dial movements, digits, letters and led indicators.
The low level hardware consists of 144 switches, 37 rheostats or encoders, 27 Meter and Dial Movements, 60 digits, 10 letters, and 38 LED indicators. Each of which is driven by or produces signals that need to be processed and communicated in a timely manner.
Configuration information for the hardware and software elements could be centralized and stored in a database. The amount of configuration information needed will vary depending on how the design is approached.
There are at least two design approaches to a system:
1. Discrete components with hardware details hidden from the user and configured internally by hardwiring or internal software unique to each components
2. A more monolithic design where every circuit interface is exposed and hardware is divided not by instrument or radio, but by hardware function. For example, a switch is a switch, regardless of where it is found in the cockpit. Everything from the starter switch to the power switches on radios is handled using a couple of integrated circuits.
The simulation might benefit from a combination of these two techniques. The primary tradeoff is flexibility and easy replacement of whole components vs lower cost and simpler circuitry.
With the advent of very low cost microprocessors and even low cost single board computers, the discrete component approach may not be that much more expensive than the monolithic approach.
The monolithic approach might serve better for prototyping, with actual implementation as fully discrete components or a combination of the monolithic and discrete component approaches.
Since this is a hobby project, and each component is being built from scratch, mass production is not a consideration. This might be an argument for the monolithic approach.
Next Steps:
Consider the types of inputs and outputs in the simulation and the number of each type of input and output needed for the controls, instruments and indicators found in the C172P
Then consider some electronic and mechanical designs for each type
Designs:
1. Switch Matrix for up to 256 on/off switches
Every kind of switch in the aircraft can be modeled using one or more on/off switches. I am considering using a pair of 16 bit port extenders and up to 256 diodes to create a matrix of switches. the switches. The switches can be addressed, 16 at a time, using a switch bank approach driven by a simple polling cycle, or by interrupts if faster response is needed. Polling speed might need to be increased by using a dedicated processor. interrupts would increase the complexity of the circuit, but would give immediate attention to any switch that changes state.
If 8 Bit port extenders are used, the switch bank would be limited to 64 switches. Unused switches are not a problem. They are just jumpered as always off or alwoays on, whichever uses less current.
2. Rheostats for volume controls
Simple rheostats can be used in any volume control application. These are standard electronic components and are not costly. They can be had with integrated on/off switches and in dual control configurations. This seems the best choice for the volume controls on radios where adjustments are not frequent and an on/off switch is needed. An ADC channel would be needed for each one.
3. Discrete Rotary Encoders for Frequency Changes
Single rotary encoders are a cheap way to record continuous rotational movement that results in incremental changes in frequency. Although the discrete type is not appropriate for instrument adjustments, it's perfect for frequency adjustment. Since dual encoders are much more expensive, there's a mechanical problem to solve to link two such encoders to a dual shaft, at the same time providing for pull switches. Either a specialized decoder circuit or 2 gpio pins would be needed for each rotary encoder.
4. Magnetic Rotary Encoders for Instrument Adjustment and flight controls.
Flight controls have been implemented using rheostats, but these tend to wear out over time, resulting in jumpy or sticky controls. The Magnetic or Optical Encoders do not suffer from this limitation and will always provide smooth action for controls.
Flight controls and instrument adjustment need a finer grain than what a discrete rotary encoder can provide. Magnetic Encoders are fairly cheap chips that can be combined with a cheap magnet to provide fine grained adjustment not limited to 360 degrees. These are available with SPI and I2C interfaces and might require calibration tables to provide accurate results. Addressing considerations might limit the number of magnetic encoder SPI devices attached to a single SPI line, but this could be addressed with an 8 or 16 bit port expander for the CC line.
5. Lighted indicators
Lighted indicators, like switches are simple to implement. A large bank of them could be provided using port expanders with latching logic for each indicator. A simpler approach would be to drive each indicator from a GPIO pin.
6. Numbers and Letters
There are specialized chips that can drive LED based 7, 14 and 16 segment displays to provide letters and numbers. These are available with SPI and I2C interfaces. A driver circuit consisting of a single transistor may be needed for each digit or letter to provide adequate current. 7. Controls
Basic controls are fairly simple. Mechanical linkages to magnetic encoders provide linear and rotational amounts. We saved the challenging bits for last. Force Feedback on the Yoke and Pedals is likely to require some work in order to be accurate. In addition to our friend electromagnetism, find an actual pilot or instructor to help with force feedback design.
8. Instrument Dials, Meters, and Needles
Instruments vary from simple meter movements indicating such things as fuel level or voltage to complex mechanical devices like the attitude indicator. Some have rotating faces for compass direction or barometric pressure, some have rotating needles that must move continuously, some have multiple needles on the same axis like a clock, others have multiple needles like the VOR indicators. Instruments have built in illumination.
Electromagnetism is our friend here. PWM outputs can be used to drive coils that cause rotational or linear movement. A device called an “air coil” can be purchased for between $6 and $22 usd (depending on quantity) or built by hand for very little money. Meter movements can also be purchased for a few dollars. The micro stepper movements used in automobile dashboards for tachometers, speedometers and gauges, available for a few dollars each.
Some programming and auxiliary circuits will be needed to provide the signals needed. Typically two PWM outputs and an H Bridge of some kind are used for driving air coils and micro steppers.
Mechanical linkages and displays expected to be tricky: The Attitude Indicator' turns as a unit while the pitch indicator moves up and down relative to the rotated instrument. The Turn Coordinator ball needs to roll smoothly and accurately. The Compass heading faces, Altimeter Barometer and Altimeter proximity indicator needs to rotate smoothly and match what the simulator is showing.
9. Realism
The appearance of the simulated instruments and controls is important. We want to build something that is visually and mechanically as close to a real airplane as possible.
When I was a kid, we pretended the cupola of our barn was a Mercury Space Capsule. We put in a floor with a trap door, and wired up an intercom to the attic command center in the attached house 30 feet away. I think the simulator should be a bit more accurate.
Remember: “There are no mice in a cockpit”
Something like this, but not on a computer monitor.
Specifications - System Overview
The C172 Instrument Panel Hardware runs under the control of a web and gpio service running on a small server. The services' main responsibility is to act as a communications bridge between the flight simulator program and a set of lower level hardware that makes up the gauges, instruments, radios, switches and flight controls.
The services' responsibilities include:
- Serving configuration pages to the user
- Configuring, starting and managing ongoing data exchanges with the flight simulation software
- Configuring lower level microprocessors and peripherals
- Running tests of
- configured lower level microprocessors and peripherals
- configured connections with flight simulation software
- Monitoring and logging end to end communications between the simulator software and the cockpit hardware.
- Exchanging data with lower level microprocessors and peripherals
- Evaluating if data changes are significant and need to be communicated
- Prioritizing data exchanges
- Ensuring timely delivery of data to the simulator and the lower level cockpit hardware
The server is written in Javascript and runs under Node.js. The server as written should run on any processor provided the processor and its operating system
- has the necessary gpio pins or other interfaces to communicate with the lower level processors and peripherals
- can run a node server
- has a version of node that can access the appropriate communications bus from within the node server process,
The C172 Panel Project being built by Pat Callahan will use a Raspberry PI3 as the Node Server under the Raspberian Operating System
Callahanp (talk) 10:00, 7 December 2016 (EST)
Specifications - Cockpit Server Process
The server will need to regularly poll both the Flight Simulation software and the lower level hardware. To do this the server will manage a rolling schedule of tasks with higher priority tasks given control more frequently than lower level ones. The schedule of tasks is set up from configuration data. Weighting for priority is also done using configuration data. The server can also be set up to respond to interrupts generated by the lower level processors and peripherals.
Individual tasks will consist of an exchange of data either between the server and the simulator program or between the server and the controllers and peripherals.
During initialization, several arrays created
- an array of property paths
- one or more arrays of data
- an array of priority weightings
- an array of scheduled data transfer tasks
- an array of interrupt tasks
- an array of verify tasks
Also during configuration, the server can send configuration data to lower level controllers. Low level controllers may be a version of the raspberry pi or other devices capable of running a node server. In this case, the server running on the lower level controller will get any configuration data it needs from the Cockpit server process.
At configuration time, an array of data can be given values using configuration data or by reading data from the simulator or the cockpit hardware. A second data array will contain previous data values.
Exchanged data can be any of the following types:
- Boolean
- Integer
- Float
- String
Within the schedule, the interrupt tasks and verify task arrays, simulator and cockpit hardware data exchanges are represented in the same data structure.
- Byte 1
- Destination: bit 7
- Data Direction Read: bit 6
- Data Direction Write: bit 5
- Data Type Boolean: bit4
- Data Type Integer: bit3
- Data Type Float: bit2
- Data Type String: bit1
- Verify Writes: bit 0
- Bytes 2-5
- PropertyPathId: Integer
- Bytes 6-9
- DataId:Integer
- Byte 10
- Priority: Unsigned Integer
In communicating with lower level drivers, the server will use the configured property path to select interfaces and issue commands to drive low level chips directly, or more likely will pass the appropriate data and commands to an attached microprocessor via a specified interface. The format of the microprocessor path is an array containing a sequence of commands:
Interface: SPI0, SPI1, I2C0,I2C1, GPIO Pins, Ethernet, WWW or USB Read/Write: R, W Device Address: Device Pin: DataId: integer
Unless the data id of the property path matches the data id of the transfer task, the data is either not needed or is fixed data needed to set up a read or write.
Specifications - Cockpit Server Process
The server will need to regularly poll both the Flight Simulation software and the lower level hardware. To do this the server will manage a rolling schedule of tasks with higher priority tasks given control more frequently than lower level ones. The schedule of tasks is set up from configuration data. Weighting for priority is also done using configuration data. The server can also be set up to respond to interrupts generated by the lower level processors and peripherals.
Individual tasks will consist of an exchange of data either between the server and the simulator program or between the server and the controllers and peripherals.
During initialization, several arrays created
- an array of property paths
- one or more arrays of data
- an array of priority weightings
- an array of scheduled data transfer tasks
- an array of interrupt tasks
- an array of verify tasks
Also during configuration, the server can send configuration data to lower level controllers. Low level controllers may be a version of the raspberry pi or other devices capable of running a node server. In this case, the server running on the lower level controller will get any configuration data it needs from the Cockpit server process.
At configuration time, an array of data can be given values using configuration data or by reading data from the simulator or the cockpit hardware. A second data array will contain previous data values.
Exchanged data can be any of the following types:
- Boolean
- Integer
- Float
- String
Within the schedule, the interrupt tasks and verify task arrays, simulator and cockpit hardware data exchanges are represented in the same data structure.
- Byte 1
- Destination: bit 7
- Data Direction Read: bit 6
- Data Direction Write: bit 5
- Data Type Boolean: bit4
- Data Type Integer: bit3
- Data Type Float: bit2
- Data Type String: bit1
- Verify Writes: bit 0
- Bytes 2-5
- PropertyPathId: Integer
- Bytes 6-9
- DataId:Integer
- Byte 10
- Priority: Unsigned Integer
In communicating with lower level drivers, the server will use the configured property path to select interfaces and issue commands to drive low level chips directly, or more likely will pass the appropriate data and commands to an attached microprocessor via a specified interface. The format of the microprocessor path is an array containing a sequence of commands:
Interface: SPI0, SPI1, I2C0,I2C1, GPIO Pins, Ethernet, WWW or USB Read/Write: R, W Device Address: Device Pin: DataId: integer
Unless the data id of the property path matches the data id of the transfer task, the data is either not needed or is fixed data needed to set up a read or write.
Server Level Drivers
In order to use the various interfaces, the server will need drivers specific to that interface in order to transfer data.
SPI
Although SPI is a bi-directional protocol that transmits and receives data in the same clock cycle, we are going to mostly treat it as if it were a read only or write only protocol. In dealing directly with spi only devices, there is frequently opportunity to do multi-byte transfers, speeding up the process when using spi in this way. If however we are using spi as a communications method between processors, we'll need to leave time for the processing of a byte after each transfer and may have to have some way to indicate to the master that the writing process can continue with the next byte. We'll have to look into this further.
I2C
No use of I2c is anticipated at this time
USB
IN order to get data in and out of the Flight Simulator via USB, a new or existing driver would have to be used. While that's possible, no use of USB for server communciation is anticipated at this time.
GPIO Pins
A routine to read or write GPIO pins and possibly keep track of the current read/write and pull-up status of the pins will be helpful.
Ethernet
No direct use of Etherent, other than it's use as a transport for the WWW protocol communications.
Specifications - Simulation Program Interface
- Need a description of the communication between the Simulation Hardware Server and the Simulator works for each Flight Simulation Product.
Flightgear
Flightgear's protocol is quite simple. An HTTP server on a selected port will respond to requests to read and write data from the flightgear property tree. All that's needed is a list of the properties and the appropriate path. The Flightgear protocol driver can issue the appropriate http requests, using or returning data as needed.
XPlane
Prepare3D
=MicrosoftFlightSimulatorX
Specifications - Low Level Hardware and Controllers
Controllers
- Need a list of each type of Low Level Hardware and processors used as controllers.
Lower Level Hardware
- Need a list of Low Level Hardware Device types
- Need documentation on each type of Low Level Hardware Device
- Need a description of the lowest level of software that processes data from each type of physical device
Lower Level Data Protocols
- Need a description of the data required for each type of lower level processor or peripheral
Low Level Drivers
- Need a description of the lowest level of software that accepts data from each type of physical device
Low Level Processing
- Need a description of the lowest level of software that processes data from each type of physical device and communicates a processed result to the server.
Specifications - Gauges, Instruments, Radios, Switches & Flight Controls
Gauges
| Guage & Description | Specifications |
|---|---|
| Suction - vacuum system |
|
| Tachometer - Engine RPM | |
| Fuel Left | Preliminary Specification
|
| Fuel Right | |
| Oil Temperature | |
| Oil Pressure | |
| Voltage | |
| Current | |
| EGT - Exhaust Gas Temperature |
Instruments
- general description of Instruments
Radios
- general description of Radios
Switches
- general description of Switches
Flight Controls
- general description of Flight Controls
Specifications -System wide Data Flows
- Need a list of each type of data flow between the Flight Simulation Software and the Low Level Hardware in the Instrument Panel
- Need a complete description of each type of data flow with examples