Avionics goes live [5.0 hours]

My current plan is to get the airframe up on the gear so I can roll it in and out of the workshop to do the remaining fiberglass work outside. I decided to do a trial fit of the Avionics before doing this, just to make sure everything fitted properly after riveting together all of the sub-panel brackets.

The trial installation took about 3 hours, and no adjustments were required. I only did the minimal amount of wiring to get power to the panel, installing a single master switch controlling the primary (left) system master solenoid. Power came from a car battery on the floor next to the baggage door. I left out the Transponder/ADSB system, the Avidyne IFD didn’t have a GPS antenna, and of course with no engine there were no EMS sensors. I taped a COM Antenna, and the Dynon GPS puck, onto a chair outside the workshop. I ran the ADAHRS cable through one of the conduits and connected the primary ADAHRS only, sitting on a shelf in the rear. Didn’t worry about the harness cables much, just crammed them in – a real installation will take a lot longer when it happens.

It all worked at first turn-on, apart from warnings associated with the pieces that were left out / not connected. Nothing calibrated but I was able to use the COMM’s, enter flight plans, wobble the ADAHRS and see the screens update correctly etc. It was a useful exercise and helped firm up how I was going to route some of the wiring.

Now I get to take it all out again (which won’t take long) and get back to the plan – up on the gear and a month or so back in fiberglass hell.

Trial installation of Avionics


Avionics [2.0 hours]

Last October I decided to use Advanced Flight Systems for the Avionics. They were great to work with and were able to take my hand written sketches, various CAD drawings and models, E-mails, and verbal descriptions and turn it into a coherent package of avionics and panel insert designs.

I signed off on all the drawings after about a month of dialog and more or less forgot about the whole thing until a wooden crate arrived here today containing the panel and avionics. AFS did a great job of packing it all up properly and everything arrived in pristine condition.

With all the avionics now in hand, I can finally work out where to mount the various boxes behind the panel, and do the necessary sub-panel cutouts and reinforcement. Between all the avionics and the SDSEFI equipment, there’s quite a lot to pack in behind the panel.

Apart from checking that everything arrived OK, I temporarily mounted the TFT display bezel on top of the LH panel insert. It took quite a bit of CAD work last year to ensure this bezel would squeeze in above the AF5600T EFIS, and match the contour of the panel insert. It fitted perfectly. I need to buy some black S/S #6 screws, so that the four mounting screws melt into the background rather than shine in my face.

  • f39f
    f39f
    Panel crate arriving
  • f39a
    f39a
    Ready to open
  • f39b
    f39b
    Well packed
  • f39c
    f39c
    Working through the layers
  • f39d
    f39d
    Panel out of the box
  • f39e
    f39e
    All this has to fit behind the panel
  • f39g
    f39g
    TFT Bezel fits
  • f39h
    f39h
    TFT Bezel fits
  • f39i
    f39i
    TFT Bezel

Annunciation with “attitude” [15.0 hours]

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)

Front side of the bezel
Inside of the bezel
GTT38A module (badly overexposed) and 3D printed bezel
Position of TFT module on the left hand panel insert

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.