Howto:C172P Cockpit Project/Miscellaneous notes
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