FG Interface

FG Interface (FGInt) aims to make it easier to build real cockpit environment that can communicate with FlightGear. FG Interface has 2 distinct parts. Hardware and Software.
Interface hardware is build around a Raspberry Pi Nano computer.
Interface software is written in Python 3

The Story

At the beginning I wished to see if it was possible to communicate with the sim. Quickly, with a simple telnet client and the built in server it became easy to write the first scripts in Python. Python language have been chosen because telnet class was available in Flightgear sources. The first script was written , leading to automate some action, But I was not able at that moment to use switches or other to act on the simulator.

In the same time, big red & white old man bring me a wonderful thing, a new Nano computer generation, able to carry a full Linux version, mono core cpu, the RPi was a small guy ..., 512 MB RAM. .... and a full duplex TCP/IP RJ45 100 Mb/s.

Few time later, marriage was celebrated. It was easy to setup, all hardware drivers was already existed, even some very powerful, and most of time low level library was existing too. Quickly the possibilities offered by raspberry went well beyond my expectations. The first tests showed how easy it was to configure and implement cockpit instruments. But to be easy to use, it was necessary to write a few libraries to offer a simple and powerful tool.

One year later, after doing some shopping and spending time between soldering iron, electronics and learning python language, I was able to build the first FG interface, a real prototype with 256 outputs and 128 inputs . Meanwhile, Raspberry Generation 2 was available, with 1 Gb ram.

Today, after 3 years working on this project, i am very close to release the first public version. Lot's of work have been done since i was playing with the properties tree over a simple telnet client. Each element of the cockpit that you implement is represented in the interface by a virtual object manipulable at the breasts of the interface. Depending on the type of object [switch, indicator, display ...] this gives access to a different methods allowing the management of the object.

For example, in a display object you ll have access to functions such as :

• WriteDisplay(value), a function that will display value you send on the display object
• WriteDigitDisplay(value, digit), a function that will allow to manage a display digit

For a switch, a function like getSwitchState() will return the state of the physical switch.

All the background stuff is managed by the interface. There are only objects to manage and all the information needed will have to be setup in configuration files. This mean that the main script still need to be written, calling methods of an object to manage and process information coming from FG.

On the communication side, the server is build around the socketsever module, bringing a very powerful tool to create and setup network communication. A library is also available inside the interface package.

Electronic schema and PCB board are on the road and i am actually finishing verify process.

FG Interface in it actual state, look like more a tool box, than a full finish product. But it make the job. It need some rudimentary coding notion to create to main loop script.

I plan to release a tool helping to generate the main loop system with a more friendly GUI in future version, that will need a more accurate comunication system (TCP side)

Raspberry PI, the system heart

The Raspberry Pi is a series of small single-board computers developed in the United Kingdom by the Raspberry Pi Foundation.

https://en.wikipedia.org/wiki/Raspberry_Pi

A full linux support computer with input / output capabilities.

First generation release in 2013 was built around ARM V6 32 bits CPU at 700 Mhz and 512 MB RAM (version B1+). I was able to create lot's of instrument and i never have been blocked by hardware resources.

Today, the latest generation (V4), with a quad core at 1.5 Ghz CPU, with 4 USB port (2 of them USB 3), up to 4 Gb RAM and RJ 45 Port (version 4B). There is actually one limitation that cannot be cross. Major problem is linked to the hardware itself and the addressing system on I2C device. That will be discuss later.

In addition, the RaspberryPi is provided with a 40 pin connector, opening to the world all the input, output and power buses of the computer.

The FG Interface is built around the I2C bus. On generation 3, Raspberry PI has 2 I2C buses, but one is reserved for the camera connector and is difficult to access.

I2C Bus

I²C (Inter-Integrated Circuit), pronounced I-squared-C or I-two-C, is a multi-master, multi-slave, packet switched, single-ended, serial computer bus invented by Philips Semiconductor (now NXP Semiconductors).

I2C Bus

Why this bus ?

• 1°) Well, i didn't start coding the interface before having a look on what hardware was available. And fact is that most hardware drivers are all using I2C. Or more simply, all device and devices drivers needed to manage a full cockpit can be found with an I2C port.
• 2°) All standard hardware devices have their own low level library available, most of them can be found for example on adafruit

I2C Devices & Limitation

As has already been said, there is a material limitation which can not correspond to the actual state of development. On the I2C buses, each driver device (chip) is known by its address. A standard device available on all electronic component websites for I / O (chip MCP23016) has 16 I / O and a physical address coded on 3 bits ..... Consequently, there can be only 8 device if this type on the bus. The range of address for the MCP23017 ranges from 0x20 to 0x27, which brings us to a maximum of 128 input or output or even an input / output mix, but the maximum will always be 128 with this type of driver. I talked earlier about the 256 output, because I use in the interface another driver device, the HT16K33, which is perfect for managing LEDs or display segments. The HT16K33 has a different range of I2C addresses, between 0x70 and 0x77 so it can be on the same I2C buss as the 8 MCP23017 chips. The same applies to the pilot device for the servo motor, this type of element has its own control device on ranges with different address than the others

Python

Python is a widely used high-level programming language for general-purpose programming, created by Guido van Rossum and first released in 1991. An interpreted language, Python has a design philosophy which emphasizes code readability (notably using white space indentation to delimit code blocks rather than curly brackets or keywords), and a syntax which allows programmers to express concepts in fewer lines of code than possible in languages such as C++ or Java.[22][23] The language provides constructs intended to enable writing clear programs on both a small and large scale.

https://en.wikipedia.org/wiki/Python_(programming_language)

Why Python?

• 1°) Well, when looking at how i could communicate with the sim, i found the python telnet class in the Flightgear sources.
• 2°) Python is the official programming language on Raspberry, and lot's of device driver lib are available in this language.

On other language more 'pro', as like C or C++, libraries are existing too, but it was not in my knowlegde ... maybe some day i will port te interface in theese languages.

Communication

At first I was playing with the telnet client and the properties tree via a TCP / IP connection. Raspberry has an RJ 45 port. It quickly appears that the telnet protocol was not fast enough to handle a large amount of data.
By further examining Flightgear, I finally found the section of the Generic Protocol, and how to set up an appropriate communication system on the flightgear side. A server or client, based on the communication header, is created on the Flightgear side.

So one of the main part of the FG Interface is a full TCP client / server system dedicated to communicate with flightgear. This mean it's possible to have more than one interface connected to the same simulator instance, so if generic I/O are limited on one interface, with more interface, you will have more capabilities

At the actual project state, inter communication between interfaces is not available

Project Status

System

• Format Configuration File Done
• I2C Protocol low layer wrapper library Done
• I2C MCP23017 low layer wrapper library Done
• I2C HT16K33 low layer wrapper library Done
• FGInt TCP Server

Library

• Switches Library (Multi switches type class) Done
• Switches Light Library Done
• Segment Displays Library Done
• Rotary Encoder Library Done
• Servo library

add-on

• A320 / 330 Airbus FCU add on Done

Hardware

• Schemas Done
• PCB

Documentation

• Wiki FG
• FGInt Pending