There were quite a few early RV10 incidents with doors opening in flight. Most were due to doors not being properly latched in the first place. Van’s added a safety latch, but most builders choose to install the awesome Planearound safety latch. In addition, Vans supplies magnetic reed switches to sense each door pin being closed, together with panel lights to provide a visual “door open” indication. Some EFIS’s can also accept an input and provide a door indication.
When I did the panel layout, it was clear that space was at a premium. The door annunciator lights seemed like a single function waste of space, albeit an important one. I started looking at a TFT display to combine several annunciation functions, and narrowed the search down to a small TFT touch display module made by Matrix Orbital, the GTT38A. Readable in daylight, dimmable, and being a touch display, the possibilities multiply.
The fit was tight. I designed a bezel and verified the fit by printing prototypes on my (cheap, consumer) 3D printer. Checked the 3D model when integrated into the panel models. Finally, I had the bezel printed in black UV resistant epoxy, which cost me a total of $25.
The module sits above the pilot side EFIS and the bezel matches the shape of the panel insert in the Aerosport 310 panel. In order to minimize the depth, it is necessary to modify the GTT38A module, and remove most of the connectors. These will be simply be replaced with a few flying leads which go through the panel to a small connector. The module requires +5V power, ground, and a 4-wire RS-232 interface (TX,RX,CTS,RTS)
With the TFT touch module in position, it’s time to get creative and decide what what other useful tasks it can perform apart from replacement of the door annunciator lights. There’s an embedded CPU associated with the power system I’m designing for the SDS-EFI system, with plenty of spare capacity, access to some interesting sensor data, and the Internet if cellular service is available.
There’s a valid philosophy going around about modern aircraft panel design, that says any old pilot should be able to get in and fly the aircraft, i.e. what they are presented with should have the same look and feel of any old Cessna, to avoid safety issues associated with a lack of understanding about the modern avionics. I don’t have a problem with this approach, but I’m building this aircraft for myself, and my better half, and as such I don’t feel tied to having (for example) a legacy keyswitch with “LEFT/RIGHT” magneto positions, despite the fact that there are no magnetos.
The following images are actual screenshots from the GTT38A, driven by early software written to test out a few concepts and verify the functionality.
First thing is the startup screen. You climb in, and turn the masters on. This could be just about anything, including the time, a startup diagnostic report, whatever. For now, it’s just the aircraft callsign:
OK, so I’m now holding the checklist card, and I’m ready to start up. I need to move on from the above startup screen (whatever it ends up being), so I touch the GTT38A display, and I’m presented with the following:
That’s right, if you don’t know the security code in this aircraft, you won’t be going anywhere. I already have one key for the fuel locks and another key for the doors and baggage door. I didn’t want a third key for the ignition. There is no keyswitch in this aircraft. Without the code entered here, the engine start button won’t do anything, and there won’t be any power supplied to some essential parts of the SDS-EFI system.
There’s a design issue associated with this. It’s fine to disable mechanisms on the ground prior to startup, but once in the air, there must be no possibility that a fault in the electronics can disable essential systems. This includes faulty software design, electrical I/O signalling, or any other issue deep in the electronics itself. Suffice to say, once the correct code is entered and the engine is started, there are low-tech redundancy mechanisms in place to override the dis-engagement interfaces that the security lockout employs on the ground.
OK, so we enter the correct code. Here’s the next display:
This is the original purpose of the TFT display. The three “lights” on the right are for left door, right door, and baggage door. In the actual prototype, the lights flash if the doors are open, and the “UNLOCKED” text does as well. There is really no way to ignore or not notice it. When all the doors are closed and the pin sensors are all engaged, there will be “three greens” and at that point touching the display will move on to the next category. Until the doors are locked, touching the display will do nothing.
There’s an issue with such a hard nosed approach. What about wanting to do an engine run on the ground with a door open, for maintenance? The answer is to have multiple security codes, that allow different paths through the procedures. A maintenance code, which might require more digits as well, can be assigned to allow bypassing certain lockouts such as the door lock test.
Assuming we’re in normal operation, after the doors are locked, we will be going through the startup checklist. Most of these items will be covered by panel switches that are outside the scope of the TFT display, but there are a couple of items that are not, such as testing the Coil Packs. When I went through the electrical system design, one aspect was to consider everything I needed for the dual SDS-EFI system, and that included being able to test everything during runups. This exercise made it clear I needed a switch for each Coil pack, in order to test the Coil packs (akin to a magneto test). There was no need for these switches at any time other than during runups. The CPU which monitors the redundant power system has access to a mechanism to disable power to the coilpacks (same in-flight comments as before), so I chose to do these runup actions using the TFT display, saving two panel switches and associated wiring and mechanical connections in the process.
Checklist items that are initiated from the TFT display are simply a sequence of items, and you can sequence back and forth through the items with “NEXT” and “BACK” buttons. Here, for instance is the display for testing the Left Coilpack
With the engine at the selected runup speed, touch the large button to disable the Coilpack. The display will change to this:
In this mode, the Coilpack is disabled, and the “NEXT” and “BACK” switches are also disabled. You can’t go anywhere without re-enabling the Coilpack. The checklist item will call for the pilot to check engine RPM drop, probably 50RPM or less. Once the check is complete, the Coilpack can be re-enabled by touching the large centre button, and the display will revert to the previous state. Clicking the “NEXT” button will proceed to the next checklist item, which would in this case be the right Coilpack:
We go through the same procedure here.
There may be additional checklist items, if so they’ll be presented in the same simple form. The idea is not to take over the job of a printed checklist, and not to take over a checklist facility that the EFIS system might provide. The checklist items deployed by the TFT display are simply those that the associated controller has access to, and can’t be accessed elsewhere, i.e. items associated with the SDS-EFI system that are provided and controlled by the redundant power system.
After checklist items are completed, the TFT display will have a number of run-time options. These will probably be selected by swiping the display, to scroll between pages horizontally. The displays will generally be limited to those items not available elsewhere, the idea again is not to try and be another EFIS, but to do things the EFIS can’t do.
For example, current engine monitoring products aren’t set up to monitor electronic fuel injection operation. The power system I’m designing performs redundancy in a distributed manner, each fuel injector has individual power that is redundant and protected. Along with this comes current monitoring, but the injector current is dynamic. ADC’s sample the injector currents, and this data is available for presentation on the TFT display. A typical injector current display might look like this:
The display is deliberately simple. There are no scales, just cylinder numbers and graphs. The last thing a pilot needs is more complex displays flashing in his face. The above injector current data is sampled and will update around 10 times per second. The “shape” of these plots show the familiar “blip” on the leading edge, caused by the back EMF as the pintle opens on the injector.
We can do some simple heuristics on the injector current profile. In the highly unlikely event of an injector going open, wiring going open, or ECU driver failing, the display will look like this:
Obviously the next step would be to switch over the ECU. If the failure goes away, the ECU driver or wiring as far as the injector relay box is a problem. Regardless, the next step would be to land as soon as possible.
Other parameters can be considered – pulse width, presence or absence of the pintle “blip”, area under the curve etc. and measurements that fall outside of a particular range could be highlighted by changing the plot color to red. Again, indication only – no automated actions – and nothing too flashy, just an additional piece of easy-to-interpret data that may help to quickly diagnose a situation where the engine starts running poorly.
I’m sure there will be more applications for the little display, such as:
- Display Air/Fuel ratio from a wideband O2 sensor
- Display Coilpack dynamic current
- Display data from FWF thermal or pressure sensors, for future cooling efficiency testing.
In the meantime I get to delete two annunciators (doors) and two switches (coilpacks) from the panel so in that regard I’m already ahead.