If you’ve read about my first design, you know it was based on building special purpose IOCards, as done by opencockpits.com. In those days, IOCards were connected to the computer using the parallel printer port. By the time I started parallel ports started to disappear and USB was the way to go.
I left the idea of special purpose IO Cards. Building a cockpit with IOCards have inherently complex wiring. This is what I see as one of the disadvantages of the Opencockpits design.
Now the focus is on ‘Panel Units’. Most panel unit have switches, buttons, LEDs and displays. A panel unit houses some electronics to connect these via a serial (SPI) interface a processor card. The processor card connect to the computer using USB.
In a real cockpit you find many different panel units. Good example of panel units are: MCP, Radio/Comm panel, EFIS, Fuel panel, etc.
Switches and push buttons.
Most panel units have some switches, push buttons or rotary encoders. There can be several variations switches. Some have a number of contacts (positions), some are flip switches that take one of 2 positions and there are momentary actions switches (push buttons).
Inside the panel unit all these switches are connected to cheap electronic chips. We need one chip per 8 connections. Flip switches and pushbuttons take 1 input, rotary encoders take 2 inputs and position switches one input per position.
In my current design a panel unit can have 0 to (max 32) input chips, this gives max 256 inputs available.
E.g. The MCP panel unit has: 5 rotary encoders, 15 or 17 push buttons and 4 flip switches. In total we need 31 inputs, so the MCP will need 4 input chips.
Displays and LED indicators
Displays and LED indicaters connect to a chip that can drive 8 7-segment displays per chip. LED’s can connect to the same chip giving you 8 LEDs per 7-Segment display. Most displays do not use the DP, so the DP can be wired to an individual LED.
E.g. The MCP has: 23 7 segment numeric displays and 15 indicators. The numeric displays do not use the decimal point. With 3 display driver chips we can connect all 23 numeric digits, 22 LED.s from the decemal points (only the MACH needs DP) and 8 LED from the 24’th digit.
Input- and display chips are connected in series to an SPI (serial interface), see Panel Hardware.
Panel Units Chain
Panel units are chained to a Processor Card. The length of the chain is limited by the total number of switches, buttons, displays and LEDs on the chain.
- Each processor card can interface:
- 256 button, switch or rotary encoders (taking 2 switch connections)
- a combination of 128 7-Segment displays or 1024 LEDs (1 display= 8 LEDs)
- 6 Servo outputs
- 4 Relay outputs
- 6 Analog inputs
Below you see a diagram of typical panel units connected in chain to a processor card.
The MCP only takes 3 input chips and 3 display chips from the possible total 32 inputs and 8 display chips. This is why panel units are chained in series. The next panel unit, the EFIS has no indicators, 2 3-position switches, 11 push buttons and 4 position switches with total 18 postions. So for the EFIS we need 5 input chips.
As things stand today:
- One PC can have 8 USB processor cards.
I would need to make a few simple changes to the software to double or triple that. So without really do all the calculations, I think this is modular and expandable enough to fullfill all cockpit builders needs.
Moreover most full cockpit setups have multiple PCs, each PC can have 8 processor cards.
Yes, this may lead to a panel unit that does not need all the multiple of 8 inputs. A waste of 1-7 inputs. This is the price one needs to pay for less complex wiring!!
If a panel unit needs Servo, Analog input or relay – that is wired separately, not part of the chain.
We will discuss the hardware of a panel unit on this page: (Panel Hardware)
FSIO Software overview.
Part of the whole project is the software that connects all this end-to-end with our flight simulator. Communication with flight simulator, means getting information about many flight parameters, switch and instrument settings from the running FS program in to our panel hardware and vice-versa.
I could have used the MSFS Development kit to make a program to just do that. However this work has already be done by Peter Dawson http://www.schiratti.com/dowson.html.
I expect reader to be familiar with this products as it is used for almost every FS add-on, being soft- or hardware.
Next thing I need is some function that connects the hardware to a FSUIPC/FS variable.
e.g. One of the buttons of my hardware should set the gear-up, the signal from the hardware needs to be translated to the correct Flight Simulator variable and send to FSUIPC/FS
One very important goal I had is configuration data had to be in ONE PLACE, and ONE place only. When I was planning for this software, I found that what I was defining, to be already part of SIOC (one of the deliverables of opencockpits.com). SIOC connects the Opencockpits hardware and has a scripting engine. I do not use the part that connects to the hardware, but the IOCP server part and thus the scripting. Read SIOC user manual here.
This also means that, if you already have Opencockpits hardware, you can add FSIO hardware. The SIOC script is the central scripting and configuration base.
Download SIOC from SIOC download
SIOC has everything I defined I would need, so why write it myself?
- a configuration language to define hardware to FSUIPC/FS variables
- a scripting language to do some (logical) manipulation with variables
- SIOC acts as a server using a very simple protocol over TCP/IP
I use SIOC – SSI script as my SINGLE SOURCE of configuration within my project.
Now I need to connect my hardware to SIOC. I have played with the thought to add a TCP/IP stack to the PIC18F4550 and allow the hardware to connect direct to SIOC server. The amount of code I needed within the PIC for all that is far too heavy for this little fellow. Also the amount of memory that I would need is far beyond the capacity of the PIC.
So I stay with the PIC18F4550 and so I need to write a program that:
- communicates with the host over USB
- connects as client to SIOC
- translates SIOC variable sent into commands to the hardware with the proper addressing and data
- on reception of input from the hardware, translates hardware address of the input to SIOC script variable and send the proper command to SIOC
By lack of a better name I call this program IOControl.
Below you will find an overview of all software components of the FSIO system:
In the picture above you see all components of FSIO.
The SIOC script is, as already mentioned the SINGLE SOURCE of CONFIGURATION data within the project. (here)
The PMDG Data-Event Server component is not needed if you do not use PMDG. In fact this is an independent program that can be used without any other FSIO component. Read more about it here.
IOContol runs on any PC on the network where FSX/SIOC is. It is the interface between the hardware (processor card) on the USB and SIOC.
IOControl and the microcode in the PIC go hand-in-hand. The microcode does al the scanning and interfacing with the hardware (panel units). IOControl does all the other stuff, like: preparing values and protecting sending out of limit values to the microcode, rotary encoder acceleration etc. IOControl translates hardware input into SIOC variables.
IOControl does not need to be on the same system with SIOC or even flight simulator. IOcontrol connects as client to SIOC server. As long as it can read (a copy) of the current SIOC.SSI script file it can run on any PC in the network.
Function overview of IOControl
At startup IOControl will read the SIOC.SSI script file and collects all configuration data that deal with hardware input/output functions.
Next IOControl will connect to SIOC.
From the configuration file IOControl now knows what SIOC variables it needs to display on indicators, numeric displays, relays and servo’s. So, in its initialization message to SIOC IOContol request the variables it needs from FS/FSUIPC/SIOC.
Now SIOC now knows what variables we need. If any of the requested variables changes, SIOC will send the changed variable data to IOControl. IOcontrol will then send command to the microcode to display it (set the servo or relay).
When we push a switch or turn a rotary encoder, the microcode will send the event to IOControl over the USB connection. IOControl will then translate the hardware address of the switch to the SIOC variable and send the event to SIOC.
The two software components the PIC18F4550 microcode and IOControl make the system.
Today, IOControl can handle 8 USB processor cards.
- The microcode in ALL USB processor cards is the same version. No need to maintain serveral special purpose values of the microcode.
- At first use the processor cards is given a Logical Device number that is stored in EEprom.
In other chapters we will talk about:
- Panel Unit hardware
- Processor Card hardware
- configuration of hardware in SIOC
- switches & rotary encoders
- displays & LEDs
- non-chain hardware:
- analog input
- IOControl software inner working
All software and firmware that I talk about on this site can be downloaded (free). You will find download links on my forum about FSIO . Each first item of a forum will hold the appropriate dowload link. The forum is members only, so you need to register.