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 - Simulation Program Interface

• Need a description of the communication between the Simulation Hardware Server and the Simulator works.

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

• general description of gauges

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