Engine ground runs [1.0 hours]

After several months spent finishing the engine installation, on May 3, 2024 I finally attempted some engine ground runs.

In preparation for this, I tried to pre-oil the engine by removing plugs and cranking with the starter motor, as is commonly done. After four 15 second cranks, I still didn’t have any indication of oil pressure. I tested the sensor, EFIS display, and the oil sensor restrictor fitting on the engine, they were all OK. It may have come good with continued cranking, but I felt this was simply the oil pump being totally dry (=> unprimed) after years of storage – with air gaps between the teeth and pump walls instead of retained oil held in place by surface tension – so I decided to give it some help. Not having a pressure pre-oiler, I removed the oil filter (which is on a 90 degree B&C adapter), and with a cheap new oil can and extension tubing, squirted engine oil into the filter inlet gallery until it filled up. I then had a helper gently wind the prop backwards, one blade at a time, and kept refilling the space with oil. This sucked oil back into the oil pump, and coated all 360 degrees of the gears.  With the oil filter re-installed, I then cranked the engine for 15 seconds, with still no indication of oil pressure. That’s not surprising, the sensor pickup is at the end of a chain which would include filling the oil filter and galleries after the oil filter outlet with oil. Sure enough, about 5 seconds into a second 15 second crank, the oil pressure came up and by the time I was done indicated in excess of 30 psi. After that I reinstalled the plugs and prepared the engine for first start.

To do these engine runs, I had heavy rubber chocks on the main wheels, and tied the tail down (with weights). And of course I had my feet on the brakes. I also had two helpers on the ground, with fire extinguishers handy. In the videos you’ll see me talking, apart from checklist items I had a phone link open to one of the ground helpers in case they told me to stop!

The first run was simply to confirm the engine goes, get oil pumped throughout the engine, and test each ignition system without going above 1200 rpm. It took a fair bit of cranking to get started – I think I did not have it sufficiently primed – and I was about to give the starter motor a rest when it fired. After this the run went fine, for a total of around 3 minutes and the CHT’s never got above 220F. There was a normal RPM drop when I disabled the left ignition system, and one backfire when I disabled the right ignition system, but then a normal RPM drop so something to look into there. Here’s a shortened video of the start and finish of this run:

After inspecting for leaks etc. and taking a break, we did a second engine run. This second run was to get the governor and propeller pitch control going. These won’t work until oil has been forced through the governor and into the propeller hub, and that takes more time and some sustained oil pressure at higher rpm. To do this, after a short warmup I took the engine up to around 1900 rpm, pulled the propeller pitch control back to a course setting, and waited. It took around 35 seconds for the propeller pitch to kick in, but I must admit I was expecting it to take longer and was slow pushing the pitch control forward again. As a result the transition to course pitch was a bit more severe than one would normally do for a ground test. I followed this with two more propeller pitch tests, again at 1900 rpm, before pulling the throttle back and ending the run.

A day later I downloaded the EFIS log data, and came up with the following plot for this run. It shows how I did the ramp up to ~1900 RPM cautiously in a few steps. The oil pressure drops before each propeller pitch event (as the governor becomes an oil sink), and along with the RPM drop there is an accompanying increase in manifold pressure. These changes are all as expected. Also on this plot are the primary and secondary alternator currents. The primary alternator current peaks at its rated 60 Amps not long after startup, but the battery was fully charged to begin with so the primary alternator only had to replace capacity lost due to cranking, which it was clearly able to mostly do across the short duration of this engine run. The secondary (vacuum pad) mounted alternator did some work as well, mostly at higher RPM’s, this type of alternator tends to have poor output at low engine RPM.

At the end of the test, fuel pressure drops to zero because I turned the (SDSEFI) fuel pump off. The engine RPM increased momentarily before stopping. This happens because as the fuel pressure drops, the engine sees a leaner mixture. Leaning from a rich mixture, the flame front propagation speeds up – i.e. the mixture burns faster, efficiency improves, and RPM momentarily increases. At some point we cross best stoichiometry (ideal mixture) after which the RPM will drop, the remaining residual fuel runs out and the engine stops.

Very happy to get these tests completed, and to have some good data confirming the test results. A special thanks to my neighbor Dickie and wife Kerrie, for ground assistance and camera work.

There are a few things to tidy up in the engine and cowl installation, then I need to install all the seat belts, a few inside panels, etc. before doing the weight and balance measurements, some more ground and then taxi tests, avionics certification and paperwork leading up to approval to commence phase 1 flight testing.

Painting … done [1.0 hours]

It took me the remainder of 2023 to recover from injuries and regain enough facility to complete the paint work. Painting an RV-10 is a very large job and I’ve given up any notion of keeping track of hours. I painted the fuselage and doors in late December, took a break for a few weeks and then completed the cowls, rudder and VS in late January. As large as my blow-up booth was, I couldn’t do it all at once, apart from which applying paint masks and taping up between layers is such a time consuming job it would be impossible to do it on my own inside of the time limit to apply all colors.

Overall I’m happy with the paint job, it’s not up to professional standards but pretty good for an amateur effort and my out-of-pockets costs all up, including paint, were a small fraction of the numbers I’ve seen being spent on paint jobs. Most of the cost was paint – I used PPG CA7700 primer and CA8800 polyurethane paint. I compromised in a few areas where the paint design was a bit too ambitious. For instance, I was going to include a black surround across the window/door pillars as is commonly done with RV-10’s, but that was just more time and risk so when the time came, I omitted that step.

Since completing the paint job, I’ve been re-assembling everything, it has seemed strange to be fitting parts together that will not be disassembled again.

  • 20231124_104418
    Doors after painting the inside
  • 20231218_111109
    Spraying final coat of fill primer, prior to sanding
  • 20231220_141734
    Checking the final door gap
  • 20231224_115505
    Taped up seams/holes ready for acid etch
  • 20231219_164158
    Fuselage after acid etch, ready to prime
  • 20231226_123923
    Fuselage after priming
  • 20231222_144018
    Doors after priming
  • 20231226_195550
    Fuselage after painting white
  • 20231226_195702
    Doors after painting white
  • 20231227_102023
    Paint mask ready to apply
  • 20231227_102035
    Applying paint mask
  • 20231227_183319
    Masking up ready for blue
  • 20231227_224213
    Fuselage after shooting blue, taken through plastic window
  • 20231228_150404
    Fuselage, ready to shoot dark grey
  • 20231230_165621(1)
    Fuselage after painting
  • 20231230_170208(1)
    Hanging doors after painting
  • 20231230_165821
    Minor blunder, requiring a re-paint
  • 20240208_140254
    Rudder after acid etch, ready to prime
  • 20240208_182135
    Rudder after priming
  • 20240208_182124
    Lower cowl after priming
  • 20240209_175421
    Lower cowl ready to shoot blue
  • 20240210_094636
    Removing parts of paint mask between layers, VS
  • 20240211_123950
    VS and rudder after painting
  • 20240210_222256
    Lower cowl after painting
  • 20240210_222245
    Lower cowl after painting
  • 20240227_164630
    Wings on

Typing while down for maintenance [20.0 hours]

My winter non-activity at the Hangar continued through July/August due to a bout of illness followed by ankle and knee fractures. As such I have had a lot of time on my hands where the only thing I could really do was sit around and type. I have a lot of material for the Aircraft Flight Manual (POH) and it’s time to start collating it into a coherent document. Of course, there are a lot of performance numbers that can only be filled in after phase 1 flight test, but there are other, descriptive chapters that can be completed at this time.

The small TFT display is unique to this aircraft, and I completed a chapter describing its operation. I’ve put a lot of thought into the redundant power system, and how the data it can gather gets presented to the pilot in a way that is useful and informative, but not distracting. Here’s a link to the draft text for that chapter (only):

AFM Chapter 9


Winter 2023 (in)activity [100.0 hours]

It’s been a slow 5 months on the RV-10 front. Overseas and domestic trips and other commitments severely limited my time from March onwards, and by late April it became clear I could no longer paint in Tasmania’s cold conditions – since I don’t have a heated booth. I finished preparation of all remaining fiberglass components, painted the inside of the doors, and some other small pieces, but I simply couldn’t do any more primer/topcoat jobs because of my limited time and the cold weather. I resigned myself to this and won’t be able to resume painting until things warm up around here – October probably.

I have had some time across June and July to spend on other activities. I 3D printed a final model in cheap PLA for the inlet duct that wraps around the compressor, and it fits like a glove. I can now print a final version in a suitable material that can withstand temperatures inside the cowling.

EFI power board work

I released a version of the EFI redundant power PC board last November and had PC blanks fabricated. It included some design refinements and component changes brought about by some parts that were end-of-life’d by manufacturers during Covid. It is still the case that certain components are on very long lead times, but this situation should be resolved by early 2024, allowing me to get a small batch of boards assembled in a proper manufacturing facility. In the meantime, I have enough parts to hand build some more samples, so during the cold month of July I hand assembled two Rev 1.2 (Nov 2022) PC Blanks and tested them. There are 357 components per board, most of them the size of a flea, so doing two boards took me around 40 hours total under the microscope, spread across a week. The key to this kind of hand assembly is to never hurry, and stop when you start to tire. I was happy when both of the boards I assembled came up and checked out 100% functional. One of them will go into the aircraft, replacing the Rev 1.1 board currently in there, and one will stay on the bench for ongoing firmware/software development and test work. Here’s a photo of one of these new boards, sitting on the lab bench and connected up for test, wired to the engine emulator.

I’ve done away with the RS-232 DB9 connector, it’s too large and I use the USB-C interface which is much faster and needed for logging. I re-tested all normal operating modes, and fault modes across the two boards. In the process, I filled in a few pieces of firmware that I had left the last go-around, and addressed some other fault modes that I hadn’t previously dealt with.

When a fault is not a fault

A fault mode I hadn’t previously addressed is when there is a wiring or component problem that causes a resistive DC short to ground, resulting in a fixed current drain on a channel which should only ever pulse from a near zero-current state. In other words, the injectors and coilpacks. This type of fault could go un-noticed in a more typical installation, since it would not necessarily blow a fuse or circuit breaker, and the circuit in question might continue to operate – the injector could still open, and the coilpack could still fire, even in a degraded state. The engine operation might be a bit compromised, but the trouble would be hard to diagnose until it deteriorated into a hard failure. With the redundant power board, though, it is easy to sense these conditions, and I wanted to highlight them for the pilot.

I simulated this type of fault condition with the engine emulator and did the necessary firmware and software changes to capture the condition and highlight the fault. I settled on changing the normal display plot color from green to amber, and highlighting the fault information in the corresponding detailed display. Here’s an example of the displays for a coilpack that has a resistive fault to ground.

In this instance, the left coilpack has a resistive fault to ground. The right coilpack circuit is OK, and the normal pulse is shown with peak current (4.5 Amps), dwell time (3.5 msec) and implied engine RPM (500). However, for the left coilpack, there is a resistive fault to ground, and it’s not enough to trip the electronic circuit protection into fault mode. The display switches to Amber, and a sampled plot occurs along with an indication of average current. The pulse you can see is there because the coilpack is still there and operating. Since this occurs on top of a DC offset, the firmware doesn’t try to extract and analyse the pulse, so the pulse will move around on the display as updates occur. This is a simple resistive fault, but the steady DC baseline in this test could just as easily vary and it would appear on the sampled display as a noisy line instead of a purely horizontal one. Pressing the Coilpack-L channel will bring up the following detailed display:

In the detailed display, an indication of the DC offset problem appears in Red. There is no actionable item here, any wiring or coilpack problem will need to be diagnosed on the ground.

Fuel pump or fuel pressure regulator anomalies

There was a discussion on VAF a while ago about fuel filter contamination, and a suggestion that you could tell when fuel filter(s) needed cleaning by listening to the whine of the fuel pump(s). It struck me as odd that this is an acceptable diagnostic method in this day and age of engine monitors and sensors all over the place to monitor engine performance. So I did some more work on the firmware and software for the EFI redundant power board to monitor and log a bit more fuel pump data.

For the regular detailed fuel pump display, I derived and added a measurement of ripple current. This gives an objective, numeric indication of commutator action and noise, rather than the subjective indication I’ve had in the past.

Note the above display was using an air blower, not a regular fuel pump. Makes no difference for development work. Available in the new detailed display is a sampled plot of motor current showing commutator ripple, average current, start inrush current, ripple current, and fuel pump run time since the last start. In addition, a new button “Show start” has been added. The EFI redundant power firmware takes and stores a sample of the most recent start event for each fuel pump, and this can be displayed. The system captures 400 samples across the one second after a pump start is detected, and it is displayed as follows:

This display updates whenever a new start on the associated pump occurs, so if you didn’t like how a pump started, you could perform several pump restarts, and examine the start inrush characteristic for each event. The update occurs one second after the pump start begins, of course, since this is how long we collect data for. Any discontinuity in this plot could indicate a wiring error, or a developing fuelpump problem.

This sampling of fuelpump inrush current has also been added to the logging system. Every fuelpump start event is logged to flash memory, along with a timestamp as to when it happened. At the end of a flight, part of the log data processing consists of generating plots for each pump start event. The following is an example plot for a test run that involved seven pump starts. The inrush surge current follows a similar path for each separate start event. Any line that deviated from the “normal” characteristic would be cause for some further investigation.

This latest work closes out the EFI redundant power system design as far as I’m concerned. I’m happy with the features and stability, what remains at this point is to collate all of the operating information (some of which I’ve described in a few posts) into a chapter to be included in the POH.

Painting the wings [120.0 hours]

I haven’t posted for a long time, but have been pushing along various jobs including the baffles, wing root covers, fuel system and painting various small parts such as the flaps, ailerons etc. While the wings were still pinned on to the fuselage, I did a complete fuel system and tank test, by filling the wings with fuel and running the fuel pumps each side through the entire distribution system, except for the final lines to the injectors. No leaks, good fuel pressure, no weeping rivets. After this, I took the wings off to paint. Since this was a major activity I’m posting some details here.  If you’re not interested in the details, pictures are at the end of this post.

I thought about how to set the wings up for painting quite a bit, and finally decided to make a set of stands to hold the wing in place vertically, with the nose highest. I discounted more complex schemes such as rotisseries, RV-10 wings are quite large and a rotisserie would need to be quite robust. Apart from which, it is unnecessary. Painting the large wing surfaces vertically gives you the easiest access and optics to maintain a wet edge, and in an amateur setup without highly filtered air it exposes the minimum area for dust to “settle” while the paint is drying.

I was going to build a booth out of structural pine and plastic, but after pricing the required material I elected to save the hours and buy a cheap inflatable booth. It’s large – 10m x 5m – and the blower to keep it inflated is noisy, but it was easy to set up in the hangar and the filters were quite adequate.

I put a lot of thought into how the stand works, and then built it out of scrap material. There is a stand for the wing root (main spar), a stand for the outboard (light) end of the wing, and an intermediate piece of stand which allows me to support the wing after the white is painted, so the end stand can be temporarily removed and the wingtip fitted for taping. The two ends of the stand are tied together with a pair of 75x35mm pine pieces, 4 metres long, and the resulting “channel” can be lined with plastic to catch the water runoff from the acid etch and rinse operations. This was another reason for doing the wing vertically – I could do every operation from acid etch to final paint in the same stand, with no changes apart from the switch while the wingtip is temporarily put in place for taping.

I painted one wing at a time. Spraying takes next to no time at all, but taping off takes many hours and I didn’t want to have to do this for both wings at once. I did the left wing first, then after learning a few things did the right wing slightly differently. It took 3 (long) days to do the right wing, from start to finish, with four colours. Here’s the order of events:

  1. I scuffed the top side of the wings while they were on the plane, and the bottom side of the wings on a pair of workbenches after they were removed. I de-greased both sides at this point, so that they were “substantially” clean before moving the wing into the booth. I also taped up both ends, all the inspection plate holes, fuel drains etc. at this stage.
  2. Tape drop cloths to the floor of the booth. Tape builder’s plastic to the water channel, making sure it is pressed down inside the channel. Use minimum tape, because it has to be taken up again while the wing is in place.
  3. Move in the wing stand and screw each end to the channel pieces.
  4. Move in the wing. It’s a two man operation to lift the wing off a pair of workbenches and onto the stand. The poor guy holding the outboard end has to hold it while I secure the main spar. I inserted 3/8″ teflon tubing into the outermost 3/8″ holes on the spar connection, and used batton head screws with washers (and ample layers of masking tape) to secure the wing root in place. Then I move to the outboard end, hold the wing up, and the other guy can release the wing and insert the support for the far end of the wing, clamping it into the stand and screwing down a holding cap. The support piece has padded surfaces for the spar, two of them separated by about a 2 inch gap, for the outermost two bays of the wing. With this support in place, I can release the weight and the wing is fully supported, and moreover is fully exposed to be able to spray all surfaces.
  5. Do any remaining tape up for paint. Fuel cap holes, and a few other bits ‘n pieces.
  6. Fully degrease the wing. This is easy since it was mostly done before moving the wing into the booth. Don’t forget to pay special attention to the skin overlaps, where grease can stick to the edge.
  7. Tape up the seams so the acid etch doesn’t penetrate into the wing interior (much). Tape over the fuel cap holes, and the the inspection cover holes etc.
  8. Do the acid etch. I used cheap 2 litre and 5 litre garden sprayers, the type you pump up to spray. The 2 litre container was for Alumiprep 33 solution (about 50/50 with distilled water), and the 5 litre sprayer contained distilled water. Spray the acid at low pressure horizontally across the wing – it’ll all run downwards – and catch it with the 3 inch brush using horizontal strokes. Wear safety glasses. Work your way from the top to the bottom. I did half of the length of the wing at a time, front and back (spraying near the top oversprays to the other side), twice, allowing time for the acid to work, then rinsed it all off with the 5 litre sprayer, never allowing any of the surfaces to dry. The first acid you spray on will “break” and quickly run downwards in trickles, which is one reason you need to keep brushing horizontally to spread the acid around. Once it has had a chance to work, the water will not “break” much or at all. With one half of the wing done, front and back, I switched to the other half. I kept going back and spraying water over the first half, to keep it all wet (oxide won’t grow back under water). Once the wing was all done, the channel was full of acid + water runoff, the entire wing surface was wet, and there was also a bit of water lying around outside the channel (inevitable) but not much. In total I used about 1.5 litres of acid+water solution and 5-6 litres of rinse water (I had to refill the container once, a 10 litre sprayer would have been better). Now let it all dry.
  9. After 5-10 minutes, I removed all the wet tape and rinsed around the exposed areas where a bit of acid had penetrated in and around the tape, using a bit more distilled water in a small squirt bottle.
  10. Let the wing dry. I used some cleaning cloths to run along the bottom where the skins run behind the aft spar, since water tends to accumulate at this bottom (aft) edge and take a lot longer to dry. Heaters may be necessary if the weather is cold. Hot days are best, get the thing dry as quickly as possible because the oxide is growing back…
  11. As soon as the wing is dry, spray EAP-9 (or your adhesion promoter product of choice). You only need a very fine mist of the EAP-9 product. Allow to dry.
  12. Move in the wingtip. Spray the primer on both the wing and tip. I used PPG CA7700B primer, as part of the system I used. The primer only needs to be sprayed on as a very thin coat – almost translucent. Allow to dry.
  13. Remove the water. You can “roll” the plastic from the outboard direction, then using a small cup and a bucket, get all the water (and primer overspray, and acid) out of there. I did this later for the left wing, but it’s best to get it all out of there asap because it’s a mess. Be careful not to splash any of this toxic mixture on the wing.
  14. Wet down the floor (it contains a lot of primer overspray) and spray the main topcoat (in my case, white). I used PPG CA8800 paint. It’s expensive paint, but easy to use and will outlast me. I sprayed two coats using the CT2 thinner, 40 minutes apart. It took me 15 minutes to spray the entire wing and wingtip (I’m slow at this), so plenty of time between coats to clean the spray gun and mix up the next pot of paint (induction time is zero). The coats need to be thin, this isn’t a truck. Although it isn’t necessary to clean the entire gun between coats, I’ve always done so. Hint: After the first coat (only), as you finish cleaning each part with gun cleaner, rinse it in Acetone. This rinses off the gun cleaner, which can be a little slow to dry (in my case), and the Acetone will evaporate quickly. That way, when you reassemble the gun for the second coat about 20 minutes later, all the parts will be bone dry.
  15. As soon as the white topcoat is “dry to tape”, or a bit more, re-configure the stand so the wingtip can be temporarily fitted. This step can be skipped depending on your paint scheme. In my case I had fairly acute sweeping angles of grey accent paint crossing the wing-wingtip boundary, and I wasn’t confident of getting these right without taping up the entire shapes with the wingtip in place. The mid stand piece I made was secured to the bottom channels, the outer most flap support, the wing tie-down hole, and the aft spar near the inboard aileron hinge bracket. I’ve included pictures showing how this was all done. I used a piece of 3/8″ fuel line inserted into the flap bracket hole to protect it from the screw, with plenty of soft (baffle material actually) padding and washers to spread the load, and of course masking tape.
  16. Now is a good time to tape down some new drop cloths on top of the old ones, at least in the outboard half of the wing where you’ll be mostly working from now on. If you have a poor man’s spray booth like mine.
  17. I made some patterns out of brown paper (and tracing paper) for where the various colours go. It’s a lot easier to do these with the wing on the plane, or the bench, and without the time pressure of spraying paint. Using the patterns, I taped off near the boundary of each colour. I use 3M 233+ (green) tape for anywhere that tapes on to freshly painted surfaces, and cheaper tape anywhere I’m taping down onto the top of the green tape, or other covering material. Once the basic shapes are outlined in tape, carefully slice the tape with a sharp knife on the wing/tip split line, and remove the wingtip. Re-configure the stand back the way it was (to make it easier to cover the rest of the wing up for protection from overspray.
  18. Tape everything up. This is the part that I found takes a long time. Tape things up so you can easily remove tape covering successive colours, in the order you’ll spray them.
  19. Tape up the edge(s) you’re doing, in my case the second colour to spray was blue. I use 3M 471 vinyl tape for the edge work. It’s best to avoid crossing rivets or seam boundaries, but in some cases this is inevitable.
  20. Clean the exposed (white) surface with isopropyl alchohol. It’s best to avoid touching any surface at all, but I can’t manage the taping up wearing gloves so it’s inevitable to get a bit of a touch somewhere and this has to be cleaned up. Press all the blue edge tape in.
  21. Go mix the paint pot. Spray the colour (again, in my case, two light coats 40 minutes apart). the very last thing I do before spraying the colour is to re-press all edge tapes, with a gloved finger. A final wipe with a tack cloth is also a good idea.
  22. At the “correct” time, peel off the edge tape. It should be prepared so as to make it easy to peel off, and the direction should be correct (towards any point in the pattern). In my case I found 75 minutes after the second coat was about the right time, at 20-25 degrees ambient. Clean up any paint that (for example) ran around a rivet the edge crossed, using a Q-tip and thinners. It’s far better to deal with any artifact now with a Q tip than later with an air brush. In some cases the air brush will be inevitable.
  23. If there are more colors, once the paint is dry-to-tape, rearrange the taping and repeat the above process for the remaining colours. I was able to spray two colours per day, white+blue on day 1 and dark+light grey on day 2.

It was quite an effort to do all this for two wings, but I’m happy with the results. It’s an amateur job of course, but close enough to what a pro would do at a much cheaper cost in labour. The paint I used is buffable, if I want to work on any areas later. There is a buffable clear coat available for this paint system, but I elected not to spray the clear, due to the extra expense, weight and the fact that I’ve never successfully sprayed clear coat before and didn’t want to add more work to the job.

I’m having a break from the project for a few weeks, before getting on with preparing and painting the fuselage.

  • lw1
    Ready for acid etch, seams taped
  • lw2
    Acid and water runoff collected in channel
  • lw3
    Sprayed on EAP-9, ready for primer
  • lw4
    After spraying primer
  • lw5
    Wingtip primed
  • lw6
    White topcoat sprayed on wing and wingtip
  • lw7
    Middle support stand
  • lw8
    Middle stand detail - flap anchor screw
  • lw9
    Middle support stand detail - tie-down bolt
  • lw10
    Middle support stand - bottom support
  • lw11
    End support removed
  • lw12
    End support removed
  • lw13
    Wingtip fitted with a few temporary screws
  • lw14
    Pattern for blue
  • lw15
    Blue transition tape marker
  • lw16
    Tape markers for grey details
  • lw17
    Wing and wingtip seperated
  • lw18
    Masking off remainder of wing
  • lw19
    Blue painted, vinyl edge tape removed
  • left_wing_and_tip
  • lw20
    Left wing complete, back in wing stand
  • rw1
    Right wing completed (top)
  • rw2
    Right wing completed (bottom)
  • rw3
    Right wingtip completed
  • bw1
    Both wings finished, back in the wing cradle

Power System for SDSEFI – part 2, and logging

This post is a follow-on from the previous one on this subject – here.

I’ve never managed a board or chip development that didn’t benefit from test/field experience and subsequent revisions. Usually the revisions are to lower the cost and raise the performance, and a range of defect corrections and perhaps feature enhancements go along for the ride. Although I’m not flying yet, I’ve made a point of doing a lot of “ground testing” of the EFI power system, and to that end I have a complete duplicate system set up in my office/lab here, along with an engine/ECU emulator that behaves exactly like the real thing. This post describes a PCB spin I’ve done, and the addition of the one major piece of software that I previously skipped – logging.

Board Spin

I had a small punch list of changes to perform, and during the second half of May, with the aircraft in the Hangar and cold winter weather setting in, I spent some time (mainly on the really cold days) in my comfortable heated office doing a minor board revision, with the following changes:

  • Manufacturability corrections – bringing components and footprints into line to avoid unnecessary redundancy or duplication.
  • External filtering control – I noted that, with long dedicated wire runs from the batteries (located aft of the baggage compartment in the RV-10), IR drops during left coilpack events could have an observable impact on the captured waveforms for the injectors. As an option I could use some external large / high-reliability capacitors to smooth things out, but these need to be fused and they need inrush current limiting to keep things under control at turn-on. Some board level additions were made for this option.
  • Selection of all trip modes available on the board, controllable via the stuff list. I’ve experimented quite a bit with the various protection options of the TPS devices. I’ve decided that, for the injectors, I don’t want to use anything other than automatic over-current protection and retry, because I don’t want anything on the board that has a failure mode, regardless of how remote, which can disable an injector. For the coilpacks and fuelpumps, however, I’ll leave the ability to set the over-current protection to manual, because there are two completely independent sets of plugs and fuelpumps. As a result, (i) an extremely unlikely board level failure mode which can disable one of these supplies would not be catastrophic, and (ii) in the event of a real fault which causes over-current on one of these channels, in the case of a bad short circuit the retry trip current can be a 20 Amp spike every few msec, and although the power system is perfectly happy doing this it looks very ugly and probably over time takes a toll on the associated battery/alternator system. It might also lead to RF interference. As such, being able to disable the individual power circuit in-flight probably has some merit.

Once the new PCB’s arrived, I hand assembled one across a quite a few sessions which probably totaled about 16 hours of microscope time. The entire board came up fine on first power-on, and the new features were all good. After testing I’ve decided to do one last board change, which incorporates the one remaining and embarrassingly obvious feature enhancement:

  • Use a separate wire run from the common left EFI supply fuse for the injectors, so that the existing fuse which is right next to the left/primary battery has two separate wires running to behind the panel for the EFI power system. The existing wire is for the left coilpack and left fuelpump power. The new wire (same gauge) will be for the left injector power. This largely prevents the coilpack pulses and fuelpump current from impacting the measured fuel injector pulse data, and is a much better method of isolating these observations from each other than the use of external filter capacitors.

Here’s a picture of the Rev 1.1 board on the lab bench, a bit messy due to a bunch of test points and the debug interface. I’m no longer stuffing the RS-232 interface, the USB-C link is fast and reliable and that’s how the aircraft is wired.


The logging requirement specification is simple:

  1. I want to log every event that occurs with the power system loads, at the full resolution available from the underlying sampling system. That means every injector pulse, every coilpack pulse, the fuelpump ON/OFF state at the time of any change, and a regular sample of the fuelpump dynamic power characteristics (read: commutator noise). For the LCD display, this data is scaled and down-sampled in order to fit onto the display. For logging, I want to maintain the full 12 bit ADC accuracy of the measurements, and the full sampling resolution, which in the current hardware is one (4x over-sampled) measurement for each of the ten power channels (6 ignition + 2 coilpack + 2 fuelpump) every 52 micro-seconds.
  2. Logging data is to be dumped to a removable flash drive during flight (plugged in to the CPU under the pilot’s seat), so that this flash drive can be removed after flight (by sliding the seat back) and downloaded, or alternatively dumped across a wireless network.
  3. The presence of active logging is not to compromise the features, quality or refresh rate of the LCD display.
  4. Log data must include precise start/end timestamps, so that the entire log can be matched up with other engine log systems, such as data available from the SDSEFI ECU, and/or the EFIS related engine monitors.

I can’t simply log every sample. To do so would require a data link with bandwidth of at least 3.9 MB/sec, and the system would accrue log data at the rate of around 14 GB per flight hour. The main focus of the existing firmware is to locate and sample pulses (injectors, coilpacks) and on/off changes (fuelpumps), so it seemed logical enough to extend this functionality to include real time logging.

Long story short – with the addition of a few thousand lines of firmware code, communication protocol additions, and host software additions, the logging system is now fully operational. Pulses are timestamped and a simple lossless data compression scheme is used to reduce the data requirement. Log data is stored locally on the power board and periodically downloaded by the host system, at up to 20 times per second. Apart from various test modes, the usual method in place is that logging will start any time either fuel pump goes on (from both initially off), and stop once both fuel pumps are off and the backlog of log data has been downloaded. Each logging start event leads to a time stamped directory on the flash drive which contains all of the log data. A timestamp file from the host system provides high resolution start/finish times, which can be used to correct any slight inaccuracy/tolerance in the power board’s clock. Compressed log data accrues on the flash drive at a rate of approximately 300 MB per flight hour. I bought a 256GB USB-C flash drive for about $60, which will fit log data for over 800 flight hours before requiring some sort of intervention, that’ll do.

I’ve tested this system extensively on the bench and it is now rock solid, with no noticeable impact on LCD display response or refresh rate.

Viewing log data

This is an entirely different topic, and a complex one. A two hour flight leads to a large amount of log data. Viewing this “big data” efficiently, being able to rapidly zoom in to a point of interest to examine it in more detail etc. is a common and not very well addressed real-world problem in the IT industry. I didn’t want to devote much time to this right now, so for the time being I settled on being able to extract anything up to a 5 minute slice of log data from a larger database, and view this in a zoom-able graphical form with some Python code. Here’s a zoomed-in example (injector loads are resistive in this sample (keeps the lab quiet), and no fuel pumps were active in this test):

Log data isn’t primarily for “viewing”. I think where this will end up is with a set of heuristics, some applied in real time as log data is collected, and some performed by the host CPU after engine shut down, i.e. after each flight. Any anomaly found will lead to some sort of notification message, which on the ground can lead to an actual human examination of the log data and if necessary a maintenance action. Numerous issues come to mind, for instance:

  • An injector has started to go a bit sticky and occasionally not open – as determined by an (infrequent) lack of an inflection in the rising edge of the injector current.
  • A fuelpump has started to show signs that a commutator segment is failing
  • Ignition (coilpack) characteristics have changed, or intermittently change, indicating degradation of either the coilpack, drivers, or an ECU.

This sort of capability is a project for the future, after the aircraft is flying, where the necessary algorithms can be developed using actual flight logs. Where analysis in real time is possible, some of these heuristics can be migrated in to the real time logging system. The whole point is to provide early detection of impending failures, and to fix the associated problem before it becomes a hard failure, and before leading to a noticeable change in engine performance. For example, a fuel injector that previously worked every time now fails to open once every thousand or so cycles.

As usual with this activity, I’m logging zero hours, because it isn’t really a normal part of an RV-10 build.

Move to the Hangar, and subsequent works [100.0 hours]

In early May I moved the project to a Hangar at Hobart Airport. A kind neighbor donated his time, truck and float to perform the move. One wing missed out going when the loading plan went a bit astray, and we moved that on a different truck a few weeks later. It was a bit unnerving to see the project tied down on the float and being driven on gravel tracks out of here, but my neighbor’s 50+ years of experience in the trucking industry made it all seem easy.

I spent much of May into June moving the contents of the workshop to the Hangar and setting everything up there so I could continue with the build. The workshop at home looked like a war zone during this effort, it was certainly high time for a clean out. A resident rat had been living a comfortable life in a cluttered corner of the workshop, it was last seen running for cover under some bushes in the outside garden after being evicted.

I pinned the wings on, again with the help of several neighbors, and have since finished fitting the flaps, the wing root fairings, the wingtips, and the wing root fuel lines. With the flaps fully retracted in the reflex position, and the ailerons rigged to match the flaps (with elevator neutral), I split the rear edge of the wingtips with a fine hacksaw blade, set them in place to match the ailerons, final drilled the rivet holes for the wingtip ribs while being held in place, and re-glued the rear wingtip inner edge with epoxy. After this set, I removed the wingtips, stood them up and reinforced the rear edge with flox and a layer of fiberglass. Compared to the initial condition, I moved one wingtip down about 4mm and the other down around 7mm; they were out by enough to annoy me and fixing them was quite easy.

Winter has been brutal in that tin Hangar. Thermals and heated vests only go so far. After the workshop at home was cleaned up, I pitched a marquis tent inside it. I dismantled my old priming booth, and recovered the wire table to use for spray painting parts. With two electric oil heaters going, I was able to keep the environment inside the tent at a high enough temperature to spray paint some parts. I painted a few simple one-colour items – the horizontal stabilizer, elevators and some fiberglass parts to make a start on the daunting prospect of painting the aircraft. The transportable parts I’ll paint at home in the coming months, the wings and fuselage I’ll have to paint at the Hangar, this will have to wait until summer so I can get a reliable block of warm weather. I’ll build a temporary booth out of wood and plastic film at the Hangar to do this work, with filters and fans to provide some airflow for over-spray removal.

In the meantime, I continue to grind away at the never-ending list of things to do. Now winter is officially over, the days are getting longer and progress should pick up.

  • move1
    Loading up
  • move2
    On the move
  • Second wing delivery
    Second wing delivery
    Delivering the second wing and stand with my neighbor's classic flatbed truck
  • wing1
    Wings pinned on
  • flap1
    Fitting the left flap
  • flap2
    Fitting the left flap
  • wing_root_fairings
    Wing root fairings, and temporary anti-slip
  • tip1
    Fitting the wingtips
  • tip2
    Fitting the wingtips
  • tips3
    Fitting the right wing tip
  • tips4
    Re-gluing the right wingtip
  • paint_hs
    Painting the Horizontal Stabilizer
  • paint_elevators
    Painting the elevators and trim tabs
  • paint_ailerons
    Painting the ailerons
  • paint_rudder_fairing
    Painted bottom rudder fairing

On to the final lap [87.0 hours]

With the bulk of the Avionics, wiring and software work done, I’ve spent the past few months back on airframe and related work, pushing towards the point where I’m ready to take everything to the hangar. Lots of small to medium scale jobs, chipping away at the overall task. Here’s what I’ve done:

  • Wing wiring. I ran and labelled all wiring for both wings, and temporarily hooked up with wingtips, pitot, etc. and all connections to the fuselage, with the wings still sitting in the wing stand. I tested all functions, and found two minor issues – the landing and wigwag switches were reversed, and I had forgotten to run a wire from right to left side for the strobe synchronization. Apart from this, all good so I could now close up the wings.
  • Riveted bottom wing skins. This was a tedious job, which we did with each wing in turn laid flat on a pair of workbenches. The first wing took about 12 sessions across 4 days. Then we had a break for about a week, before tackling the second wing which took about the same number of sessions but stretched across a few extra days. Not many pictures of this, didn’t do much that deviated from the instructions, but due to the size of my forearms I found it impossible to reach down to the rear spar between the close-together ribs under the wing walk doubler. I made up a special long bucking bar, by taping a tungsten bar on the end of the RV-10 elevator bucking bar, which I could then hold in position. Not a great option, but good enough to get the job done cleanly.
  • Clear coat and install the centre console. This went in OK, as did the headset panels I previously designed and made up. Also included in this area are the throttle and pitch controls, fuel valve extensions etc. It’ll be a mild nuisance to take apart at each annual, but with the tunnel cover breaks I have in place won’t be too bad. The finished look is great.
  • Fitted the Matco brakes, brake lines, and filled the system with brake fluid. I replaced the standard O-rings in the Matco brakes with Viton rings, for high temperature stability, since I never need to worry about deep sub-zero conditions in Australia. I used Royco 782 brake fluid. No leaks, thankfully.
  • Wheel spats. Another tedious activity. I mostly followed the plans, except:
    • I used the RVbits leg intersection fairings, because the ones supplied in the kit are terrible.
    • I used a laser level for all the relevant measurements, much easier than plumb bobs etc.
    • I found my jacks crept down a bit over time, which is a problem for doing the spats because it takes a succession of fiberglass jobs over several days to do it all. I made up a wooden stand, that went under the main spar (with 3/16″ of hard rubber padding), used the jacks to raise it all, then lowered the stand onto wooden boards. A few Alclad shims under one side was enough to level the airframe in roll, and a tie-down on the tail was used to get the pitch into the cruise attitude. When it came time to do the nose wheel, I raised it higher by adding an extra board under each side and re-leveling.
    • I split the lower main wheel leg intersection fairings on each side, and fiber glassed the fairings into the respective front and rear spat halves. This is a bit more work to get right, but makes it simpler and easier to remove and reinstall the spats.
    • I painted the inside of the spats. I figure they’ll fill up with dirt and mud and require cleanout occasionally, and this seals up the fiberglass interior to make it easier to wash any accumulations away.
    • Since I’m using the Matco brakes, I had to cut out a section of the main wheel fairing brackets, to clear the brake line connection. I reinforced the area with some scrap Alclad to restore stability to this part.
    • The gaps between the front and rear spat halves, particularly on the nose gear fairings, were a bit irregular so I took the time to fix them up with micro.
  • Finalized everything behind the baggage bulkhead so that I can rivet on the final top skin.
  • All sorts of miscellaneous jobs, too numerous to list. These seem to be never-ending.

I’ve come to realize that if I don’t move everything to the hangar soon, it may become too wet and muddy around the workshop over the winter months to easily do the move. The mud around here is amazing – it can be like grease without too much rain at all. My current activities are aimed around doing this move in the coming weeks.

  • aaa_bottom_skins
    Riveting bottom wing skins
  • f61c
    Improvised bucking bar for rear spar rivets under wing walk area
  • aaa_wing_skins
    Inevitable side effect of riveting bottom wing skins
  • f61d
    Aligning the main leg fairings
  • f61e
    Work on the "split" bottom leg fairings
  • f61f
    Working on nose wheel fairing
  • f61m
    Fairing support bracket modified for Matco brakes
  • f61l
    Fairing support bracket modified for Matco brakes
  • f61k
    Right main fairings
  • f61i
    Left main wheel fairings
  • f61h
    Split leg fairing, left side
  • f61g
    Split leg fairing, right side
  • f61j
    Nose wheel, leg fairings
  • aaa_painting_spats
    Painting insides of spats etc.
  • f61a
    Centre console fitted
  • g1i
    Overhead panels in place

2021 Done [300.0 hours]

I spent most of the second half of 2021 slowly working on the aircraft wiring. It seemed like a never ending job but eventually it all came together and by December I was able to re-install the panel + avionics and make it all work. Here’s what I completed, among other things:

  • All tail wiring, including both batteries, avionics shelf fuse blocks, ADSB receiver, antennas
  • Pitch and trim servos
  • A/C evaporator wiring, sensors and controller board
  • All overhead wiring and overhead panels, lighting etc.
  • Flap motor, sensor, joysticks,
  • Door annunciation switches
  • 3 screen AFS system, IFD GPS, and all associated avionics/audio/radio wiring
  • Panel switches, and wiring for both B&C regulators
  • SDSEFI dual ECU system, MAP sensors and FWF wiring
  • Custom dual battery/dual alternator power board for redundant EFI power
  • Custom TFT display (front panel) and controller CPU (under pilot’s seat)
  • Pitch and aileron trim wiring
  • Wing, heated pitot, and emergency fuel transfer wiring
  • Engine monitor wiring
  • USB power for various panels
  • Headset connections x4 and USB power at the rear of the centre console

I used a dual 600W bench power supply to bring the system to life, it can provide up to 35 Amps of current to each of the right and left battery buses, but more importantly I was able to set lower current limits during the initial bring-up stages, and only increase those limits as more systems are brought online. More importantly, there continued to be no smoke. Using this bench supply also allowed me to run the entire system indefinitely, without worrying about having to charge the batteries (which are in place but disconnected).

I rebuilt my “engine simulator” with a bit more design thought this time, and included a second coilpack and set of drivers so that I have both the “left” and “right” ignition systems. I replaced the cheap ch*nese injectors, some of which previously melted, with another set of cheap ch*nese injectors, but with a new injector driver board design which is running much more reliably. I also put a slider pot on the throttle cable so that I can adjust rpm using the real throttle, which allows me to examine operation of the power system across the usual engine operating range without climbing out of the aircraft to make the adjustment. It’s also kind of cool to push the throttle forward and have something actually respond! My old test fuel pump seized up (since I used it in water), but that’s OK, I simply used a blower motor to emulate the actual fuel pump. This had the advantage of being able to blow air across the various load resistors which I use in place of the injectors most of the time, since the injectors are so noisy.

When it comes to electronics, there’s always a lot of effort required to get from a “working prototype” to a stable, production worthy design, and this is true in the case of the EFI redundant power board I previously described. Four months ago my wife’s latest 50kg puppy smashed me in the knee, and after hobbling around for a few months I got a scan and went in for knee surgery in late December. During the latter part of this time, and since, I haven’t been in a position to climb into and around the fuselage, so I took the opportunity to do a lot of sit down work to fill out the missing/broken pieces of firmware/software and refine the hardware to the point where it is approaching what I would call a production worthy design. The latest prototype is installed in the aircraft, and since completing the wiring I have been able to operate it in-place along with all the rest of the avionics, simply by replacing the connections to the injectors, ECU’s, coilpacks etc. with flying connections to the engine simulator sitting on an adjacent bench. I also made the “screensaver” functionality work, which allows me to write the rest of this post with actual images saved from the little custom display, rather than horrible camera photos.

The startup, door checks, checklist items etc. are more or less as I previously described them, so I’m going to show what the engine monitoring displays look like during normal as well as abnormal operations, where all “abnormal” operations are brought about by physically messing with the engine emulator, i.e. every abnormal condition is physically *real*. First, here’s the monitoring display for coilpacks and fuelpumps during what represents “normal” operation, with both ignition systems running and one fuelpump operating:

The Coilpack display show the current rise as each coil is driven. The linear current rise is controlled by the coilpack drivers, with a nominal 3.5 msec dwell time used in the emulator. The actual dwell time measured is 3.3 msec, and there is also an indication of the peak coil current – 5.2 Amps and 5.5 Amps respectively. Although the power board locates and measures every current pulse, the display is set up to update at a rate of 10 times per second.

The fuelpump display shows the run time of the pump (5.5 minutes), and the average pump current (5.5 Amps in this case, a bit higher than the actual fuel pumps). The graphical sample has a ripple because of the pump commutator action. This was a good quality blower pump and the commutator ripple is fairly consistent. To illustrate what a bad pump looks like, I connected a cheap auto-store 12V plug-in fan to the right pump position. The current draw is much lower than a fuel pump, the system self scales so ignore this, but look at how bad the commutator switching is:

If you saw this sort of ugly switching on an actual fuel pump, you would want to replace it. A more usual problem would be a commutator segment that started dropping out, this would be an early indication of trouble even though the fuel pump may still be achieving proper fuel pressure. Displaying this sort of information is just another tool to monitor equipment performance and provide early indication that there may be trouble on the way, just as we rely on engine monitors these days to display comprehensive EGT/CHT etc. information.

Switching to the fuel injector display, here’s what I was presented with when I brought up the new emulator system with my six new cheap Ch*nese injectors (idling at 500 rpm):

I have several scaling options to fit pulses into the display, in this and all cases described in this post the injector scaling is set up so that one, fixed scaling is used across all six injectors. This allows relative comparisons to be made between injectors without having the underlying software skew the results. All six injectors are opening, the little squiggle on the rising edge occurs when the pintle opens, but injectors 3 and 6 open later and reach a lower peak current for this short (3+ msec) firing interval. At low RPM (short injector opening duration), one could expect that cylinders 3 and 6 would run quite a bit leaner than the other cylinders. This might be otherwise observed as rough idling, but probably doesn’t matter in the overall scheme of things. At higher RPM, these injectors are open for slightly less duration than the others, but this might be compensated for with the usual individual cylinder AFR adjustment available in the SDS system. I’m hoping that, when I start up my real engine, the injectors supplied by SDS will show more uniformity than these injectors (bought on EBay).

I introduced various types of injector failures, to get the display system responding properly. Here’s a case where cylinder #3 injector has shorted turns in the solenoid, it is still managing to open but then goes into over-current fault during the latter part of the opening cycle (500 rpm):

The over-current fault level is set to 3.3 Amps, there is no way to determine how much in excess of this the actual fault current is, so I simply represent it with a red bar. Since the fault is in the injector itself, the fault only occurs during injector pulses. If you touch the display on the faulty item, it will bring up the detailed injector display as follows:

There isn’t really much more information here. The system defaults to “automatic” fault detection and retry. I have included the ability to latch faults and reset them, but I doubt this is the sort of activity you want to undertake in flight. Note, however, that since the fault is only occurring as the injector fires, the fault is clearly in the injector itself, and not in the wiring. Is the injector staying open? Since it did in fact open, the injector will likely stay open despite the fault condition during automatic retries, where the current is pulsed back on every few msec; however, there is no way to really know. There is a brute force means to live with this sort of fault in the air – disable the left supply, causing the injectors to switch over to the right supply only, with each injector having a 5 Amp slow blow fuse in place. Maybe the fuse would blow, maybe not. You would be a cavalier pilot to try this sort of thing mid flight, since it would also mean that the left ignition system would be down.

A wiring fault is detected by sensing continuous fault conditions for any duration in excess of 100 msec. Here’s the display presented in the case of a wiring fault (still 500 rpm):

The display updates in more-or-less real time to such events. To bring about this fault, I simply shorted (to ground) the 12V supply to cylinder #3 in the engine emulator, and by the time I looked up at the panel the above display was present. If you saw this in flight the engine would be running rough and you would want to throttle back and land ASAP.

Another type of fault is an open-circuit in the injector, or wiring to/from the injector. In this case, there simply won’t be any current at all. Here’s an open circuit fault in cylinder #6:

Yet another type of injector fault is one where either a poor electrical connection outside or within the injector, and/or a deteriorating injector coil, is causing the resistance of the overall injector circuit to increase, effectively decreasing the ability of the injector to open. The fault may be intermittent. The injector is mechanically OK, it just opens late and draws less current:

This engine would be idling a bit rough, but at higher RPM’s the problem would manifest itself as cylinder 6 running a bit lean. Notice how the injector opens late, but it still does open, and is open for perhaps 14 of the nominally 16 msec opening time:

Notice how the display self scales to fit the wider injector pulses into place. The purpose of the display is to present a comparative, qualitative, impression of how the injectors are behaving, not to present any sort of precise absolute measurement. I have toyed with some other options to keep showing the rising edge even when the opening time (pulse width) increases, but haven’t really settled on whether this is a useful mode or not. In any case, if you saw the above display during flight, you would ground the aircraft and replace the injector. Hopefully you would note this during run-ups and never get airborne in the first place. Here’s a more extreme case, of an injector/wiring situation where the injector is failing to open at all (500 rpm):

If you saw this after start, you wouldn’t bother going any further.

One type of failure I couldn’t emulate is a partially sticking pintle. I don’t have such a bad injector on hand, but I plan to try and acquire one by calling around some repair shops in the area. Based on what I’ve seen though, I think the display will show such a condition quite easily by noting the small current reversal coming and going, or moving around as the pintle sticks. This might be a use for the type of display that focuses only on the rising edge regardless of opening duration.

A few other displays. Here’s what happens if there is no communications with the EFI Power Board:

A few statistics displays, not very interesting inflight but useful for ground diagnostics:

This latter display is actual junction temperatures on the power board for each of the ten channels, on a day when ambient temperature was around 25 degrees C. Shorting any channel’s output to ground only raised that channel’s junction temperature by 7 degrees or less (with auto fault sensing/retry in place). I’ve operated the system with the power board enclosed and heated to around 60 degrees ambient, with no junction temp exceeding 75C. Since the TPS* devices used on the power board are rated up to 125 deg C junction temperature, there’s clearly plenty of margin here, and if the ambient temperature behind the panel is much beyond 60 degrees, I don’t think I’d be sitting in the aircraft anyway. I do have (defrost) fans on the top of the panel which weren’t operating during these tests, although no forced air cooling is required for the EFI power board. I also note there are no power diodes in any main current path soaking up energy or heating up the surrounds. The board runs cool.

Where to from here?

Now I can walk again, I can get back to the job of finishing the aircraft and entering phase 1 flight test. In terms of the EFI power board, when I started the project, the end game was simple – once the hardware/software design was complete and tested, I was going to do a small production run in a commercial facility that specialize in such things, so I can get a set of boards that have the required level of manufacturing quality built in. The supply chain crisis railroaded this idea for 2021, and I’ve already had to make a few substitutes for components on the BOM that have been end-of-life’d. The biggest problem is the main power switch semiconductors and the STM32 microcontroller used on the board. Everywhere is out of stock, and likely to be for the remainder of 2022. I have enough parts here to hand build a few more boards, but not enough to provide for (say) a 10 unit proto/production run. It takes me around 20 hours under the microscope to hand assemble a board, and I’m coming around to the notion that I may have to fly off phase 1, or at least part of it, with a hand assembled board that I’ve thoroughly tested, including temperature testing in an oven. The inherent redundancy built into the board and system design helps get my head over this hurdle.

There is only one other software item for this system remaining on my to-do list before first flight, and that is to implement logging. The system has ample bandwidth and storage to log all data, sampled at up to (say) 5 times per second, for the duration of a flight. Any anomalies noticed during flight can be re-examined by playing back the log data, perhaps in tandem with log data from the Dynon engine monitor. The log data can simply be copied onto a USB stick, plugged into one of the ports accessible with the pilot side seat slid back.

Here’s a short video, with the panel alive and the engine emulator going, pushing the throttle from idle up to 2700 rpm:

A note on A/C ducting

A long time ago I designed and 3D printed some bits to perform the A/C ducting on the evaporator. Along with the wiring behind the baggage bulkhead, and overhead (where the ventilation controls are), I sat all these ducting pieces in place since, with the overhead completed, I could see how much air I can blow through pressurization of the overhead. The evaporator outlet duct has extra 2″ outlets, for scat tubes down to the baggage bulkhead, if I needed more air outlet volume. The A/C evaporator has three scroll fan settings, call them low, medium and high. In addition, I added a 4 inch bilge blower to the outletpath, driven by a variable speed drive. The latter item turns out to be the most efficient way of moving air. With the evaporator ducting just sitting in place and leaking like a sieve, and the extra 2″ outlets taped off, I measured the various blower combinations available with all four overhead vents wide open. I measured vent outlet velocities from 0 through to 16 metres-per-second, fairly consistent across all outlets, depending on the various blower settings. Across the four vents, this corresponds to moving air at a maximum rate of 1,277 CFM. This is enough to completely move the air volume of the cabin several times per minute, so I don’t see the need for the extra ducts on the baggage bulkhead. I’ll either re-print the evaporator outlet part, or more likely print and glue on some caps to block the extra 2″ outlets.

I have to lower the evaporator shelf down to rivet the final skin on. It’s a bit of a jigsaw puzzle, but I can raise the shelf back into place and secure all the wiring/ducting with the skin on. Has to be that way, for future servicing. Final securing of the ducting in place will also prevent the leaks that occurred with it all just sitting there, which can only increase the measured vent air flow.

I’ve got enough sensors in place to have a future “AUTO” mode for the A/C and external air ducting, controlled by a small micro-controller that sits on the evaporator shelf, accessible with the baggage bulkhead removed.

Finally, here are some additional photos of items discussed in this post.

  • g1a
    Sorry about the knee....
  • g1b
    EFI power board, with temporary wiring out to engine emulator
  • g1c
    Centre console
  • g1d
    Rear seat headset connections and USB power
  • g1e
    Sneaky CPU board under pilot's seat
  • g1f
    Front seat headsets and USB power
  • g1n
    Dual bench supply powering the system
  • g1g
    Live panel. Note TFT display above pilot PFD.
  • g1h
    Overhead wiring in progress
  • g1i
    Overhead panels in place
  • g1j
    A/C evaporator ducting
  • g1k
    A/C evaporator, rear NACA vent ducting
  • g1l
    A/C evaporator ducting
  • g1m
    Measuring overhead air vent outlet velocity
  • g1_bridge
    RIP Bridget

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.