openFSB

[JackZ]

If using RJ45 connectors for this project is a good idea, (these connectors are sturdy, widely available and with the proper crimping tool, one can build its own cable), I strongly advise you to stick to the standard Ethernet cabling scheme, if able in your project, especially if you want to use the POE power over Ethernet feature.

Because plenty of people will use « off the shelf » Ethernet cables (hopefully not the XCrossed ones), and there might be voltage/current or signal issues if it is not the case, even with clear instructions and warnings

My 10 cents

Jacques

[SimPassion]

Totally agree with this
the more simple, the more reliable on user side

Gilles

[drnicolas]

CAN-Bus is a good option in real world. Priority, error handling - anything is done by CAN itself. And all nodes (or instruments) can get the necessray information.
I am using 250Kb/s and it seems defintiely enough.
AFAIK ARINC429 already has a kind of identifiers which tell you what kond of information is in the message and form where it came - just like CAN-Bus

[SimPassion]

And what is the proposed wiring cable and connectors design ? Which cost ?

Gilles

[Sling]

AFAIK ARINC429 already has a kind of identifiers which tell you what kond of information is in the message and form where it came - just like CAN-Bus

Arinc 429 uses octal labels to identify the type of information and format and unit id’s to identify the source. It runs at 2 speeds low and high. High is still only 100kb/s. Most modern avionics still have A429 ports to support legacy installations but most of the newer stuff is talking to each other via aviation forms of Ethernet. Such as HSDB and AFDX.

[WillemijnL]

The wiring scheme of the powered CAN connection. This is not Ethernet although the numbering and coloring is the same as Ethernet (T568A or T568B on both sides of the cable).

openFSB CAN connection wiring scheme.png (11.18 KiB) Viewed 4096 times

A part of the CAN transceiver prototype board as shown at the FSWeekend. The connector behind the RJ45 breakout: white/yellow: CAN-L/CAN-H, red/black: 5V/GND, I've used colored cable and same color marking on the RJ45 connector. There is also a screw connector which can be used instead of the RJ45 connector.

Next weekend I have another event (in dutch: Houten Digitaal). I will take a picture of the whole demo panel then and post it here. That will make things more clear. At the FSWeekend there was not enough light to take a good picture.

[SimPassion]

Hello @WillemijnL

have you any pictures to show and detailed report on how it goes ?
will be nice to see a already working solution

Gilles

[WillemijnL]

Hi Gilles,

You are asking me at the right time, because I had scheduled to give an update right after christmas holyday. I have no working solution yet, but that was not planned for this moment. In the last two monthes I had two other events after the FSWeekend which took time. But a lot of work is already done behind the scenes and is still going on:

• Setup of version control on Github.

• Setup of a documentation website which is automatically updated from Github.

• Started to create a new website to replace the temporary static website so news can be published.

• Creating a library with a set of rock solid debounced controls turning every button, (multi)switch and rotary encoder into a high class control. Published version 0.1 yesterday with the debouncer and a button class (see Github). Version 0.2 with a very good rotary encoder class will be published in a few days. The rotary encoder class has also error detection and correction in case of missed pulses. Now testing it with already very good results and documentation has to be made. I need these controls to create good and reliable testscripts and testpanels. You can use the library in your cockpit when you are creating your own sketches with the Air Manager message port. More info to come when version 0.2 is published.

• Almost finished the general software design of connectors. A connector will have data objects, a communication object and composers and parsers and will be flexible to support different flight simulators (and of course Air Manager). Only needed objects will be compiled to get a small binary that will fit on the MCU. Second half of january I expect to finish the design and start coding and testing an Air Manager connector which will also support X-Plane, Prepar3d and FSX through Air Manager. Later on I will create the openFSB CAN client, but the CAN client is optional, so that has a lower priority. Connectors are required for stand-alone controllers and CAN gateways so connectors have to be created first.

• Have had contact with the organizer of the FSWeekend about the possibility and conditions to have our own free openFSB booth at next FSWeekend (7/8 november 2020). It is no problem to have one because it is a noncommercial open source project.

• Made appointments with the Flightgear development team to look at openFSB integration in Flightgear in spring. With an Air Manager connector and a Flightgear connector possibly a bridge between Flightgear and Air Manager can be made.

I have started developing with Micropython/Python, but switched to C++ instead. Most of you will be familiar with C++. Coding in Micropython is much faster, but the disadvantage of Micropython is that they use a standard set of pin numbers for each IO module. These pin numbers are based on the Pyboard, the reference board of Micropython. To use Ethernet and/or CAN gives pin conflicts on most boards. That's why Ethernet and/or CAN are excluded by default for most boards. 32-bit MCU's also have alternative pin numbers. To get it working you have to change/add pin numbers in the board definition file, turn on the modules and compile and install the new Micropython firmware. An other problem is that on some boards saving Micropython scripts on the board is not always working out of the box. Micropython is evolving fast, but has too many problems at the moment to be used by everyone. With C++ the modules/libraries are compiled together with the sketch and will work on all boards without modified firmware. Saving on the board is no problem when using the Arduino IDE or PlatformIO. Later on there will be a (Micro)python version so openFSB can be used on Micropython boards and also on the Raspberry Pi.

I hope the first version of the Air Manager connector is working at the beginning of March to be demonstrated on the Dutch national HCC Knowledge Day at 7 March 2020 (HCC = (Dutch) Hobby Computer Club).

I will finish this long story with a picture of the panel used to demonstrate openFSB at the events. Only the top left controller was working with a quick and dirty Micropython script. I had only two weeks to create the panel so this was all I could get working. But one picture tells more than a lot of words.

The yellow cables are network (Ethernet) and the pink ones are the CAN bus including power. The gateway (including the display) and the controllers connected to the CAN bus are powered from one power adapter on the back of the panel (the black power connector is on the top of the panel). Nice detail: the monitor is connected to a Raspberry Pi on the back of the panel running Air Player. You see well known instruments at the bottom. The running presentation on top is also an Air Manager instrument.

Willemijn

[SimPassion]

Thanks @WillemijnL for this very detailed and clever explanation
that bring to us a great overview of the capabilities of the CAN solution working with Air Manager together
and also the nice work you are doing along the way, to promote this new approach including during flight simulation shows. I've observed the clean quality of your presentation design
Nice to see the opportunity to check if C++ will keep its promises for such project
Further, I'm wondering if the power could be delivered through, available POE switch if we already have one and Ethernet splitted cable. Surely a question you've already answered and discarded ?
Thanks, again, I will follow your results with attention and I'll check forward

Gilles

[WillemijnL]

CAN itself has no power or a specification for cables to use like i.e. USB has. CAN uses only two wires for CAN high and CAN low signals and you can connect devices to the CAN bus your own way. In the demo I am using ethernet cables with have eight wires. Two of them are used for CAN, the others for power which is no part of CAN. In some cases such a wiring solution can be handy but is not necessary. In my cockpit it will be handy. With a PoE ethernet switch you can connect stand-alone controllers with Ethernet like the top left controller in the picture of the demo. You than need a board or Ethernet adapter with PoE support. CAN is not needed in that situation.