Tying it all together [31.0 hours]

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.

  • f60a
    Custom R-Pi Hat, hand assembled
  • f60b
    Prototype CPU Assembly
  • f60c
    Prototype CPU assembly
  • f60d
    Prototype CPU assembly in place under LH seat
  • f60e
    Prototype CPU assembly, on the bench in test

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.

Smoke in the cabin! [19.0 hours]

Not really. But it poses a question in a 2 battery + 2 alternator electrical system. What do you do? There is only really one action plausible, which is “Both Masters OFF”.

When I did the Avionics, I figured I didn’t need a backup battery, because I had something better – a complete second battery/alternator system. That’s like a backup battery, but better … it can basically last forever. As an upside, it removes the weight and wiring associated with the backup battery. It was only when I went to do the complete wiring schematics that I asked myself the above question, and in so doing I realized that I did, in fact, need a backup battery. How else can I run a set of minimal Avionics after a “smoke in the cabin” event requires me to turn both electrical systems off. I couldn’t write an emergency procedure that said something like “turn one system off, wait a while to see if the smoke clears, turn the other off if it makes no change”, that would be silly.

So, I have to include the backup battery, to run a minimal set of Avionics in an emergency. However, there are many conditions where I would prefer to use the right electrical system as the backup, since it is far more capable. If the left electrical system went down for any reason, the right electrical system should be used as the backup. I didn’t want to start adding switches to manually select these choices, because:

  • In any emergency situation, a pilot will tend to suffer a large drop in IQ. Adding switches and actions to deal with the emergency situation is just asking for trouble.
  • Any sort of manual changeover could bring about a situation where the Avionics power went off, then back on, requiring the EFIS’s to reboot. This takes time – the last thing you need when an emergency occurs.

Therefore, what I need is some kind of automatic changeover. If the right electrical supply is present, then it should be selected as the backup source. If the right electrical supply is absent, then the battery should be selected as the backup source. Power diodes? No thanks, don’t like them. A non-latching relay would work, but then I’d need a switch or something in order to test the battery on startup. It’s starting to get a bit complex. There’s also circuit protection, and the need for a charging path to charge the battery. What I really want is a system that does the automatic changeover, with no energy loss when operating off the battery (no diodes, no relay coil current), and that yields good visibility to the condition of the battery, charging state etc. With this in mind, I designed a small board to manage the backup battery requirements.

The schematic for the board can be viewed here.

Over on the right, a latching relay is used to switch “Backup Power” between the right battery/alternator system and the backup battery. The FAN3240 and associated components drive this relay. In the center left, a small Arduino board controls everything. This needs a tiny amount of 5 volt power, whenever either the battery or right system is present. Up on the top left, protected by polyfuses, these two power sources are diode OR’d to provide 12V for relay power and a small linear regulator provides 5V for the Arduino board. On the bottom left, a level translator provides an RS232 serial port for remote monitoring. Finally, the “headset power” for Bose etc. headsets is tapped off a convenient point that has power if either the battery or right system is alive. In an emergency, the (trivial) power for ANL headsets will still be provided by the TCW battery – this isn’t a bad idea, in an emergency with minimal avionics, we would be better off hearing any VHF traffic clearly, right?

The Arduino controller has scaled analog inputs to sense battery voltage and right supply voltage, as well as the sense and “low voltage” outputs of the TCW IBBS. Two outputs from the controller are used to set or reset the latching relay. The code is trivial and simply selects the right system in preference to the battery, if it is present. A remote communications protocol allows a host system to determine the status at any given time, including measured voltages and the direct IBBS outputs, and to force the system one way or another for testing.

A modified backup battery harness is required to use this system with the AFS ACM. Page 155 of the ACM manual (v6.5) shows the standard harness from the TCW IBBS backup battery to the AFS control module. Here is a link to the actual harness I made to accommodate the new battery backup board.

I mounted the TCW IBBS on the back of the sub-panel, behind the AFS ACM. That makes it a bit hard to get to, unfortunately, but I didn’t have much choice by this point because all of the front sub-panel space was used up. The battery backup board is mounted near the ACM, I didn’t bother putting it in a case, there’s no reason to do so. Here’s a not-very-good picture of the first, hand assembled, prototype sitting in position on the sub-panel, ready for test. There’s one panel switch – the standard low-power one required by the TCW IBBS to enable the backup battery. Apart from this, everything else including test is handled remotely and can be viewed/controlled if need be from the small TFT display I’m using on the front panel for annunciation and monitoring of the EFI redundant power system.

Prototype battery backup controller