This is currnetly a WIP This repo is my personal configuration repository for the Makerplane EFIS and documents the installation and setup of all the components.
This is not intended to be a tutorial so some details may be omitted.
But hopefully, if you plan to build something similar this will be enough to get you on your way to success.

I am building a Fisher Dakota Hawk and the Makerplane EFIS will be my primary flight display.
The system will consist of two 13" 1920x1080 touchscreen displays, each powered by a Raspberry PI 5. Each Pi will be connected, over seral port, to a CubeOrange Flight Controller that will be used as a source for AHRS data and an auto pilot. The Auto Pilot only controls trim tabs on the Alieron, Elevator and Rudder to ensure the pilot can always override the auto pilot should it malfunction. Stratux will be modified to get AHRS data from the FIX Gateway and also serve as a source for ADBS in. An instance of Android will run on the Raspberry PIs so I can run my favorite mapping application, iFLY EFB, directly inside the Makerplane EFIS. A plugin in the Fix Gateway will receive NMEA data from iFLY allowing the next waypoint to be sent to the auto pilot. iFLY's built in feature to share fight plan on the network will be quite handy to ensure both instances stay in sync.

I selected the GeekWorm X729 UPS to provide reliable power to the PIs. The UPS also makes it simple to cleanly shutdown the PIs with the flip of a switch and we do not need to worry about vlotage fluctuations such as when starting the engine. The Waveshare 2ch CAN FD Hat will be used to connect the various components. One channel will be used to collect engine data from the ECU while the other channel will be used to connect the MGL RDAC and other FIX Gateway components. The adafruit RP2040 CAN BUS Feather has been quite fun to use. I have already written some circuit python to deal with buttons and encoders.

To ensure a single point of failure does not leave me with no instrumentation building this a a fault tolerant system is important to me. To acheive this I created a quorum plugin for the FIX Gateway. This allows other FIX Gateway plugins to decide if they should perform some actions or not to ensure only one of them is making changes or sending commands. Imagine an audible warning plugin, having two gateways sending the same audio at nearly the same time would be a garbled mess. The same happens for data calculations. Only one system needs to do some things, but the other should take over should the first one fail.

I have documented the installation process here: Installation Process
Keeping track of what FIX ID does what and where it is used makes it easier to make changes when needed. That is documented here: FIX IDs