The last two posts described what I’m doing for redundant SDSEFI power, and backup power for Avionics. To complete the picture, I need a small TFT display for status monitoring on the panel, and a general purpose embedded computer to handle communications, housekeeping and logging for the entire system. I could have built more capability into the EFI redundant power board, but that would have meant more I/O and features that weren’t relevant to its primary purpose of providing redundant power, and I didn’t want to dilute its purpose in this manner.
TFT touch display
I bought a small TFT display module a few years ago, to evaluate its capabilities. This was described in a previous post, here. The display fitted in the panel above the PFD just fine, and I had a 3D printed bezel made for it. There was a problem with graphical/plot performance, which I reported to the manufacturer on their Forum. While they acknowledged the problem, they didn’t do anything to address the issue and it’s obvious the product is headed towards end-of-life in the coming years. Visually, plot updates at a rate of around once every few seconds just doesn’t cut it for me. I can gather plot data from the EFI redundant power module in around 1 msec, so obviously I could display it in pseudo-real time if the display module were up to the task.
I resigned myself to the fact that I had to find a different display module. There aren’t many options in such a small form factor, and I eventually ended up with a module from the same manufacturer based on the Bridgetek chip. This means I had to completely rewrite the test software to evaluate the module, but I wasn’t sorry to throw out all the old code because it really didn’t hang together very well. I looked at the screen design products Bridgetek offers, but these didn’t offer any plotting widgets and if I have to grow my own I may as well just write enough from the ground up to do the very limited job I needed. The three main uses for the TFT display are:
- To use as / replace discrete door annunciators
- To aid with the SDSEFI specific checklist items, reducing switch count
- To visually plot injector, coilpack and fuel pump data as an adjunct to the standard EFIS engine monitoring
The first two are simple tasks, so the main job was to write enough software to produce simple visual plots. To get the USB based link to the display working, I used the d2xx library and MPSSE libraries FTDI provides. In the latter case, I had to compile the sources since FTDI don’t provide prebuilt libraries for Linux. It didn’t compile out of the box, no surprise, which caused me to actually look at the source code. That was unfortunate because it made me realize what an absolute shambles it is inside. Same code base they use for Windoze, so it gets a lot of use, but it’s simply … rubbish. There is an open source alternative for the d2xx library, and another for the basic mpsse-spi interfaces which hasn’t been maintained since 2013 and is broken. One day I’ll look into why and fix it up, in the meantime I’m using the patched up FTDI code base, and will live within its defects/limitations.
Armed with the programmer’s reference and a few examples for the Bridgetek display, I wrote enough code to produce the displays I needed, and for the touch interface so as to be able to swipe between screens and operate interfaces. I’m quite happy with the results, and for injector etc. plot data I was able to achieve update rates in the range of 12 – 20 updates per second. That’s good enough to call it a (pseudo) real time display. I can’t take screenshots right now, due to one of the defects in the FTDI mpsse library, so for this post I’m going to include a crude video taken with a hand held phone. The video uses simulated data (originating in the EFI redundant power board), but the displays and response are essentially identical to those when I have real data from the engine emulator clacking away on the bench. I’ve superimposed noise over the data, it’s simply a development aid to get a subjective visual impression of the update rate. The real data isn’t this noisy of course. It’s hard to take good video of a live screen, the colors are wrong, it’s out of focus on each side etc., the real display looks far better than this, but for what it’s worth, here it is:
Yes, there’s really a security code on this aircraft. No ignition key, if you don’t know the 4 digit code to use, the engine won’t start. In normal operation, you won’t get past the door status page unless all the doors are closed, the checklist items that are operated from the display are in the same order they will be for the physical checklist etc. The two “data plot” pages, will most likely be the one(s) in normal use during a flight, I’ll probably make a mode where they’re off (or very dim) but the relevant display will be pushed and returned to normal brightness if a fault occurs. It’s possible to highlight an individual item, and effectively “reset” an individual electronic circuit breaker. I’m not sure this is a good idea in flight but the capability is there, unless I suppress it.
The plots don’t look as bad as the video shows, here’s a photo taken in a lighter room, but again the out-of-focus left/right stuff is the silly phone camera, not the display:
The display module itself is physically different enough from the previous one that it requires a new bezel. I updated the existing bezel design to accommodate the new display, and have sent off an order to have one 3D printed in UV tolerant black PA12 material.
General purpose computer
I need a small general purpose computer to tie this scheme together. It requires:
- USB interfaces for the TFT display and EFI redundant power system
- RS232 ports for the Battery Backup controller and A/C controller
- Digital I/O for the door switches and a few other items
- Analog and PWM I/O for the O2 sensor and some other items
- Enough storage for logging engine data from the EFI power system
- Networking of some kind so I can download logs on the ground
- Low power consumption
- Extensibility, in that it should be replaceable in future years with newer technology, without much rework
Inherent in this scheme is the fact that with the exception of the redundant power system, none of the auxiliary elements – the display, and certainly not the computer – are required for flight safety/continuation. Some elements are required for runup/checklist items – which all happen on the ground – but apart from these an in flight failure won’t matter.
With this in mind, I decided to use off-the-shelf parts to the extent I could, rather than launch into a ground up board design for what is basically a commodity item. In addition, I wanted the system to run a standard version of a *nix kernel, most likely Linux. It had to be open source, nothing hidden, so that any problems I could always diagnose as deeply as required without relying on any third parties for a resolution. I wound up using the following parts:
- A Raspberry Pi 4B computer module. It’s hard to admit I’m using something like this.
- A Monarco hat add on board to provide the required industrial grade digital and analog I/O.
- A custom hat (another add on board) that I designed and built, to provide the remaining required features
The resulting assembly easily fits into the space under the pilot’s seat. I made a copy of the F-1067B seat floor cover, using 0.032″ Alclad, and bolted a plate underneath it, to which the boards are mounted. Cutouts in the new F-1067B allow a HDMI port, RJ45 (Ethernet) port, and a pair of USB-C ports. These can be accessed by simply sliding the seat back to the rear stop. One of the USB-C ports could, for example, be used for a USB flash drive to store log data that can be recovered post flight.
The following photos show the prototype. I’m actually going to make a new F-1067B replacement, which moves the connectors and assembly further aft, to provide more clearance from the flight controls. I’ll also be changing the plate spacers to screws with locknuts, and adding some safety ties to the assembly so that, in the highly unlikely event that some or all of the board retaining screws/nuts or associated connectors come loose, no part of the assembly could fall “forward” and interfere with the flight controls. I may even design and 3D print a case for the entire thing that is safety wired so as to not ever be able to fall in the direction of the flight controls. The integrity of the entire system will of course form part of the annual maintenance procedures.
Custom HAT
The custom hat schematic may be viewed here. Top left is the standard 40 pin header for expansion board connections to the Raspberry Pi. The I/O used here is carefully selected so as to not conflict with that used by the Monarco Hat. To the right are two RS232 transceivers, one for each port, to translate from the internal levels to that required for RS232 interfaces. On the right again is an RJ12 which may be used for an SPI connection to external devices.
On the bottom left is a timer circuit. I wanted the computer system and TFT display to come alive when the pilot side door is opened, without any switch activation, and stay alive as long as the door is open. Once the door is closed, I wanted the system to stay alive for, say, 5 minutes, by which time the pilot should have turned on at least one master switch. If either the left or right electrical systems are on, then the system should stay on. In order to bring about the door magic I’ve added an extra reed switch to the front of the pilot side door, which will be OPEN when the door is closed. Once the door is opened, this reed switch will close, which turns on an opto-coupler, which in turn brings up power (via Q4) and initializes a timer circuit. Upon closing the door, the system will continue to be powered (via Q3) until the timer expires, by which time either or both of the switched power systems should be up, allowing power to stay up even after the timer expires. The standby leakage current for this system, when the door is closed and all other power sources are off, is only a few uA, this is supplied directly from the “right/secondary” battery via a fuse. If at any time I have the door open all day (e.g. for maintenance) and don’t want the computer system to stay alive, I’ll simply insert a dummy pin/magnet assembly into the front door hole, or pull the fuse on the baggage bulkhead to take away the “always on” power source.
Across the bottom center of the schematic is a DB25 male connector, for connections to/from the various systems. To the right again is a FET switch, operated from a gpio pin, to allow power to the TFT display to be switched on or off by the CPU. On the bottom right is an RS485 transceiver, which is not normally stuffed. At one point, this type of interface may have been used for a previous type of TFT display, but it is no longer required.
Physically, I avoided using anything smaller than 0603 components, and the board is easy to hand assemble in under two hours. I don’t plan on doing a production run at an outside facility, the CPU system is not flight critical and the hand assembled board is unlikely to be a reliability problem.
Since the entire CPU assembly is so low in cost, small and light, I’ll be carrying a spare on any cross country trips, it’ll be around a 15 minute job to change it over and most of that time is removing and reinstalling the seat and F-1067B cover screws.
