My winter non-activity at the Hangar continued through July/August due to a bout of illness followed by an ankle fracture. 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):
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.
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.
Logging
The logging requirement specification is simple:
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.
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.
The presence of active logging is not to compromise the features, quality or refresh rate of the LCD display.
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.
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.
Sorry about the knee....
EFI power board, with temporary wiring out to engine emulator
The last two posts described what I’m doing for redundant SDSEFI power, and backup power for Avionics. To complete the picture, I need a small TFT display for status monitoring on the panel, and a general purpose embedded computer to handle communications, housekeeping and logging for the entire system. I could have built more capability into the EFI redundant power board, but that would have meant more I/O and features that weren’t relevant to its primary purpose of providing redundant power, and I didn’t want to dilute its purpose in this manner.
TFT touch display
I bought a small TFT display module a few years ago, to evaluate its capabilities. This was described in a previous post, here. The display fitted in the panel above the PFD just fine, and I had a 3D printed bezel made for it. There was a problem with graphical/plot performance, which I reported to the manufacturer on their Forum. While they acknowledged the problem, they didn’t do anything to address the issue and it’s obvious the product is headed towards end-of-life in the coming years. Visually, plot updates at a rate of around once every few seconds just doesn’t cut it for me. I can gather plot data from the EFI redundant power module in around 1 msec, so obviously I could display it in pseudo-real time if the display module were up to the task.
I resigned myself to the fact that I had to find a different display module. There aren’t many options in such a small form factor, and I eventually ended up with a module from the same manufacturer based on the Bridgetek chip. This means I had to completely rewrite the test software to evaluate the module, but I wasn’t sorry to throw out all the old code because it really didn’t hang together very well. I looked at the screen design products Bridgetek offers, but these didn’t offer any plotting widgets and if I have to grow my own I may as well just write enough from the ground up to do the very limited job I needed. The three main uses for the TFT display are:
To use as / replace discrete door annunciators
To aid with the SDSEFI specific checklist items, reducing switch count
To visually plot injector, coilpack and fuel pump data as an adjunct to the standard EFIS engine monitoring
The first two are simple tasks, so the main job was to write enough software to produce simple visual plots. To get the USB based link to the display working, I used the d2xx library and MPSSE libraries FTDI provides. In the latter case, I had to compile the sources since FTDI don’t provide prebuilt libraries for Linux. It didn’t compile out of the box, no surprise, which caused me to actually look at the source code. That was unfortunate because it made me realize what an absolute shambles it is inside. Same code base they use for Windoze, so it gets a lot of use, but it’s simply … rubbish. There is an open source alternative for the d2xx library, and another for the basic mpsse-spi interfaces which hasn’t been maintained since 2013 and is broken. One day I’ll look into why and fix it up, in the meantime I’m using the patched up FTDI code base, and will live within its defects/limitations.
Armed with the programmer’s reference and a few examples for the Bridgetek display, I wrote enough code to produce the displays I needed, and for the touch interface so as to be able to swipe between screens and operate interfaces. I’m quite happy with the results, and for injector etc. plot data I was able to achieve update rates in the range of 12 – 20 updates per second. That’s good enough to call it a (pseudo) real time display. I can’t take screenshots right now, due to one of the defects in the FTDI mpsse library, so for this post I’m going to include a crude video taken with a hand held phone. The video uses simulated data (originating in the EFI redundant power board), but the displays and response are essentially identical to those when I have real data from the engine emulator clacking away on the bench. I’ve superimposed noise over the data, it’s simply a development aid to get a subjective visual impression of the update rate. The real data isn’t this noisy of course. It’s hard to take good video of a live screen, the colors are wrong, it’s out of focus on each side etc., the real display looks far better than this, but for what it’s worth, here it is:
Yes, there’s really a security code on this aircraft. No ignition key, if you don’t know the 4 digit code to use, the engine won’t start. In normal operation, you won’t get past the door status page unless all the doors are closed, the checklist items that are operated from the display are in the same order they will be for the physical checklist etc. The two “data plot” pages, will most likely be the one(s) in normal use during a flight, I’ll probably make a mode where they’re off (or very dim) but the relevant display will be pushed and returned to normal brightness if a fault occurs. It’s possible to highlight an individual item, and effectively “reset” an individual electronic circuit breaker. I’m not sure this is a good idea in flight but the capability is there, unless I suppress it.
The plots don’t look as bad as the video shows, here’s a photo taken in a lighter room, but again the out-of-focus left/right stuff is the silly phone camera, not the display:
The display module itself is physically different enough from the previous one that it requires a new bezel. I updated the existing bezel design to accommodate the new display, and have sent off an order to have one 3D printed in UV tolerant black PA12 material.
General purpose computer
I need a small general purpose computer to tie this scheme together. It requires:
USB interfaces for the TFT display and EFI redundant power system
RS232 ports for the Battery Backup controller and A/C controller
Digital I/O for the door switches and a few other items
Analog and PWM I/O for the O2 sensor and some other items
Enough storage for logging engine data from the EFI power system
Networking of some kind so I can download logs on the ground
Low power consumption
Extensibility, in that it should be replaceable in future years with newer technology, without much rework
Inherent in this scheme is the fact that with the exception of the redundant power system, none of the auxiliary elements – the display, and certainly not the computer – are required for flight safety/continuation. Some elements are required for runup/checklist items – which all happen on the ground – but apart from these an in flight failure won’t matter.
With this in mind, I decided to use off-the-shelf parts to the extent I could, rather than launch into a ground up board design for what is basically a commodity item. In addition, I wanted the system to run a standard version of a *nix kernel, most likely Linux. It had to be open source, nothing hidden, so that any problems I could always diagnose as deeply as required without relying on any third parties for a resolution. I wound up using the following parts:
A Raspberry Pi 4B computer module. It’s hard to admit I’m using something like this.
A Monarco hat add on board to provide the required industrial grade digital and analog I/O.
A custom hat (another add on board) that I designed and built, to provide the remaining required features
The resulting assembly easily fits into the space under the pilot’s seat. I made a copy of the F-1067B seat floor cover, using 0.032″ Alclad, and bolted a plate underneath it, to which the boards are mounted. Cutouts in the new F-1067B allow a HDMI port, RJ45 (Ethernet) port, and a pair of USB-C ports. These can be accessed by simply sliding the seat back to the rear stop. One of the USB-C ports could, for example, be used for a USB flash drive to store log data that can be recovered post flight.
The following photos show the prototype. I’m actually going to make a new F-1067B replacement, which moves the connectors and assembly further aft, to provide more clearance from the flight controls. I’ll also be changing the plate spacers to screws with locknuts, and adding some safety ties to the assembly so that, in the highly unlikely event that some or all of the board retaining screws/nuts or associated connectors come loose, no part of the assembly could fall “forward” and interfere with the flight controls. I may even design and 3D print a case for the entire thing that is safety wired so as to not ever be able to fall in the direction of the flight controls. The integrity of the entire system will of course form part of the annual maintenance procedures.
Custom R-Pi Hat, hand assembled
Prototype CPU Assembly
Prototype CPU assembly
Prototype CPU assembly in place under LH seat
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.
Some time ago I decided to use the SDSEFI system for the IO-540 engine in this aircraft. This article is not about that decision, but rather the various implications of having an electrically dependent engine and how I am dealing with them.
Disclaimers:
No representation or warranty as to the suitability of anything described here is given, for any purpose.
Nothing described here is endorsed by any manufacturer, in particular SDS/Racetech.
SDSEFI Component Redundancy
There are various physically separate, redundant systems involved in the SDSEFI system:
Two separate ECU’s, with mostly independent/duplicate sensors
Two separate Hall sensors
Two separate ignition systems, with two spark plugs per cylinder
Power system redundancy
There are all sorts of debates, which can be viewed on VAF and elsewhere, about the “best” way to deploy a single engine aircraft electrical scheme for electrically dependent systems. I won’t fill a post repeating all this material. The bottom line for me, after a few too many decades in semiconductor, hardware and software engineering, is this:
True redundancy means having two physically independent systems
Physically independent means these two systems do not come anywhere near each other. This includes wiring and conduit runs.
Anywhere that physical independence is not possible, circuit protection must be employed to ensure that no single point of failure can bring down both independent systems.
The aircraft must stay fully available for IFR operations, for as long as fuel is available, in the event either one of these physically independent electrical systems goes down.
(3) above comes about because there is only one fuel injector per cylinder, unlike everything else with the SDSEFI system there are no redundant injectors.
(4) above comes about because Australia is a big country, with large regions that contain nothing. Hitting “Nearest” on the GPS would rarely provide the kind of options that the same button does in the USA.
Implications
The only system that complies with the above requirements is a 2 battery + 2 alternator system. A dual SDSEFI system for an IO-540 typically draws 14 +/- Amps, so relying on a Battery alone with no alternator would not yield much flying time, given this load plus a minimal set of essential avionics. While a single battery / dual alternator arrangement is a fine implementation for many situations, it doesn’t really fit the bill for me.
Given two physically independent electrical systems, the question becomes how to arrange for reliable injector power. The classic “essential bus” arrangement with large power diodes doesn’t really fit my mindset, the “essential bus” itself is, as far as I’m concerned, a single point of failure for the entire system. The dominant failure mode for power diodes is to fail as a short. This may well go unnoticed – until it matters – or it may lead to a cascade of other failures that compromise both power systems.
My primary goal is to provide the required power redundancy for the injectors, and electrically dependent engine systems as necessary, but in a manner that distributes circuit protection such that no single failure can bring the system down. This activity led me down a very long path, encompassing the entire electronic, electrical and electro-mechanical aspects of providing and monitoring power for the SDSEFI based system. After several discarded prototypes, I’ve settled on the system and am describing it in this post.
A secondary goal is to simplify the startup procedure, while enforcing the necessary checklist actions, for engine start and ground checking the various redundant SDSEFI systems. This issue has been discussed in a VAF thread, I wanted to avoid having a bewildering array of switches. I do not, however, subscribe to the school of thought that any pilot should be able to jump into the aircraft I’m building and take off, as far as I’m concerned transition training is required for any new aircraft and that encompasses the entire set of aircraft systems. It’s inconceivable to me that this training would not include a comprehensive understanding of the SDSEFI system, and associated electrical system.
A further secondary goal is to allow monitoring the various injector, ignition and fuel systems, to the extent that the use of electronic circuit protection allows such observation. We’re all used to having advanced engine monitors as part of EFIS based avionics these days, but current day monitoring systems do not cater for monitoring the components that make up the SDSEFI system – electrical fuel injectors, coil packs and fuel pumps. There’s a wealth of information hidden in these systems, and the goal is to expose it in a manner that (i) does not distract the pilot, but (ii) allows in-flight observation/confirmation of a failure and (iii) allows early observation and/or notification of a component which may be on its way to failing, before an in-flight failure occurs.
About complexity…
A likely comment about the following description is that it is all too complex. That is a fair criticism, the system I’ve built is certainly not for everyone. Of course, the insides of just about every one of these magic electronic aviation boxes in common use today is complex, but much of that complexity is hidden from the user. I can’t think of many projects across my own years of design experience that were not internally complex, even for products that on the outside appeared relatively simple.
System Overview
There are three main components associated with the redundant power system. These are:
A redundant power board, mounted behind the panel, that contains electronic circuit protection and redundancy for the fuel injectors, electronic circuit protection for the coilpacks and fuel pumps, and monitoring of all circuits. The power board contains completely autonomous hardware for redundancy and circuit protection.
A small TFT touch display, mounted on the panel, that allows monitoring and control of the power system
An embedded CPU, mounted under the pilot’s seat, that communicates with both the power board and the display. The CPU handles many items that are essential for ground runups, but there is no in-flight requirement for either the CPU or the associated touch display, these items can fail and have no impact on safety or continuation of an IFR flight.
I’m not going to describe the CPU or touch display here, instead this post will focus exclusively on the power board.
Redundant Power Board
This is the key component for power redundancy to the injectors. I’ve burned through a lot of time and several prototype cycles evaluating various technologies and arrangements before settling on the final configuration. Over April I hand built a full prototype board, and tested it against my engine emulator (more on that later). Based on this testing and some final modifications, I’ve this week released a new board design and, for the first time, I’m getting these prototype PCB blanks produced as they would be for a production run, rather than in a cheap version used purely for prototypes. I’ll hand stuff one of these samples when the blanks arrive in a few weeks time, and repeat/continue testing. Eventually, of course, I’ll have to do a small production run at a board assembly facility in order to ensure adequate build quality for use in the air. I would never fly on a hand assembled prototype!
Here’s a picture of the most recent prototype:
March 2021 redundant power board prototype
This is the afore-mentioned place where the two separate power systems – unfortunately – have to come “near each other” so that, in the event one of the electrical systems goes down, power will still be applied to the injectors from the other bus. Rather than having a single “essential bus” using large power diodes, this board handles redundancy for the injectors in a distributed manner, with each injector power system isolated and protected from the other injectors.
Here is a link to the schematics for the current revision of this board. These schematics come with no warranty as to correctness or suitability for any application whatsoever.
Per-injector supplies
There are 6 identical redundant/isolated supplies, one per injector. Sheet 2 of the schematics contains the supply for injector 0 (cylinder #1). For the injector supplies, I’m using TPS1HB35 devices for circuit protection and current monitoring. These are rugged devices with internal over-current and over-temperature protection, low ON resistance and a sense output for monitoring current, junction temperature and fault conditions. Current limit is set to 5 Amps, and the device may be set up to either retry about every 2 msec in the event of a fault condition, or latch the fault condition (if the latch input is high), requiring external intervention. This device operates from the primary (left) bus, corresponding to the main alternator. A fuse (or PTC) on the left side of the schematic protects the left supply from board level failures at this point, it will not blow in the event of an injector wiring failure – the TPS1HB35’s protections will kick in first.
On the right side of the schematic, providing redundant switchover in the event of a failure of the primary supply, is an old fashioned electro-mechanical relay. In the open “unpowered” position, the injector supply will come from the secondary (right) bus, via a protective fuse. I entertained all sorts of electronic arrangements for providing this redundancy, but ultimately decided on the complete isolation this scheme gives. These are hermetically sealed relays with contacts that are rated at 5 Amps continuous current. The relay is non-latching, with a coil current of only 11.4 mA, with a functional vibration resistance of 20G. Since the relay is non-latching, if the left supply fails for any reason, the relay will be un-powered and go to the open state, switching the injector to the secondary (right) supply.
The sense output is set up to track output current, 1 volt of sense output per amp of output current. There is a micro-controller on the board which runs a bunch of ADC’s sampling sense currents from each injector, with firmware that looks for pulses. The board contains both USB-C and RS232 connectors, allowing remote systems to ask for and receive more-or-less real time data from the current sensing, and here is an actual screenshot from the little TFT display for the injector waveforms derived from a live test running six pulsed fuel injectors powered from the prototype board:
The little “blip” on the rising edge of the waveforms corresponds to the opening of the injector pintle, as it causes a back-emf that results in a momentary reversal of the injector current. The TPS1HB35’s have low on-resistance and run cool, with measured junction temperatures only a few degrees above ambient. Shorting an injector is a non-event, with the associated TPS1HB35 going into fault mode. In “automatic” fault mode, retrying about every 2 msec, the TPS1HB35 junction temperature rises by just a few more degrees.
There’s obviously a lot that can be done with the software/display systems to highlight faults or unusual behaviors, as well as the firmware, there’s ample room to do signature or other analysis, an FFT on the pulse etc., but for the time being the main point is to exercise the redundant power system hardware/firmware and test it under real world conditions. I have a lot of data, not presented here, which has made me comfortable with the design and performance.
Coilpacks and Fuelpumps
Originally, I prototyped the power board for injectors only. I thought about doing a separate board/box, for a coilpack/fuelpump pair, so there would be one for the primary/left and one for the secondary/right systems. The aircraft wiring associated with such an arrangement started to take on a life of its own, the more wire segments and connections in a system, the more prone to failure it is. A few years ago I worked on a hashing chip design that had core power requirements of 1.2 Volts at 600 Amps. The package exposed bare die, with a water cooler clamped directly to the silicon. The board power supply design to support this amount of current was a wild ride, but eventually worked out just fine in 3oz copper.
I did some calculations and decided that with 2oz copper I could easily support the required currents for the coilpacks and fuel pump circuits, even under short-circuit conditions, and that a single board to support all devices would minimize the amount of electrical wiring while still being able to maintain complete isolation between the left and right supplies. As a bonus, the same micro-controller could be used to sense coilpack and fuelpump currents, requiring just a single communication connection to the host CPU system.
Sheet 10 (thru 13) of the schematics show the circuit protection arrangement for the coilpacks and fuel pumps. These are dedicated electronic protection circuits for each of the four devices, two each on the respective left and right supplies. There is no notion of electrical “redundancy” since the devices are physically redundant themselves.
Here I use a higher current device in the same family, a TPS1HB08B high side switch. Trip current is around 19 Amps, which sounds like a lot but has to be high enough to allow for (a) the rate-of-change of current for the coilpack circuits, since the TPS1HB08B protection looks at rate-of-change as well as absolute level, and (b) the turn on inrush current for the fuel pumps, which I measured at 13 Amps for the sample pump I’ve used for testing. There is no separate fuse, apart from the master 30A fuse next to each battery, the TPS1HB08B is the fuse. The “left” and “right” coilpack/fuelpump pairs are physically separated on the board, by quite a large distance.
There is a “disable” input for each device, primarily to allow coilpacks to be disabled during ground runup checks. Again, sense outputs allow real time output current measurements to be made, and faults to be detected. The microcontroller firmware again looks for pulses for the coilpack circuits, or samples continuously for the fuelpump circuits. Here’s a TFT display screenshot, from real time data collection, with an identical coilpack to that used for SDSEFI driven by a pulse system, with spark plug loads. The fuel pump in this case was a purely resistive load:
In this case the coilpack dwell time was too long, the current limiting that is occurring was protection from the coilpack drivers I used. A more reasonable dwell time would result in a simple triangular waveform. To test the fuelpump circuit, I bought a cheap Ch*nese fuel pump from EBay for next to nothing. The fuelpump current is sampled continuously and the resulting waveform represents commutator action. I placed this fuel pump in a bucket of water, recirculating the outlet, and within a few days the thing showed clear commutator degradation. This was an excellent test of the sampling and display system, here is a screenshot:
I was wondering how to find a broken fuel pump to test how the small display system could show degrading performance, but it turns out all I had to do was buy a cheap pump on EBay and make it pump water. Here’s the same waveform on the scope, as measured directly from the board’s sense line. A more reasonable pump would have a fairly constant commutator ripple rather than the one shown here:
Seeing this poor knockoff pump struggle within days of first operation has made me feel better about the time I’ve spent going to the trouble of allowing the design to monitor and sample data from these circuit redundancy/protection systems. A fuel pump showing the above behavior may well pump adequately to maintain fuel pressure, but it is clearly on the way out and it would be far better to know about this and replace the pump on the ground, rather than wait for an unexpected in-flight failure.
Coilpack and Fuelpump circuit operating and fault conditions
These coilpack and fuelpump circuits have necessarily quite high fault current settings. We’re normally blind to this, where (say) a 15 Amp slow-blow fuse would provide the necessary protection and the impact of a failure event, as brutal as it may be on the electrical system, is limited to the time it takes the fuse to blow. Even under normal operating conditions, these circuits are far from pure. Consider for example the coilpacks.
Coilpack dwell time is nominally around 3.5 msec in the SDSEFI system, during this time the coilpack current will rise fairly linearly from zero to up to around 7 Amps, and then rapidly drop back to zero. In the RV-10, with batteries behind the baggage bulkhead, there is several meters of wire supplying power to the coilpacks. The resistance of this wire, together with the effective internal resistance of the battery/alternator system, causes a measurable drop in the supply line at the redundant power board. Here is a measurement, the trace shows the approx. 14.4 Volt supply rail dipping by around 0.25 volts during the 3.5 msec coil dwell time, followed by an approx 1.5 Volt inductive spike when the load collapses. Equivalent engine RPM is 2700, so these are frequent, ongoing events:
In the case of a coilpack/fuelpump device or wiring short circuit, the TPS will either turn off and latch the fault condition, or keep retrying around every 2 msec if the “latch” input is low. Retrying under short circuit conditions, with the high fault current setting required for these devices, is a safe but nonetheless violent condition. Here is an example where the TPS turns on the output after a fault, detects the circuit still in fault, and turns off again. The purple trace is the 14.4V supply rail, which can be seen to dip by around 2 volts as the short-circuit current ramps up across around 20 microseconds, before bouncing back after the TPS re-enters fault mode and turns the output off again. Under continuous fault retry conditions, I measured a junction temperature rise of 60 degrees C above ambient for the corresponding device. The system took it OK, even when hit with a heat gun to raise the ambient temperature further, but it’s probably not a situation I would allow to continue indefinitely.
Since I have firmware control over the state of the “latch” input to each TPS individually, I can decide down the road a bit whether to allow the automatic retry thing to go on or whether, for these circuits, to latch the fault and allow some sort of an in-flight option (through the TFT display) to retry the circuit. Think of it as a normal circuit breaker, but controlled through the touch display. Given that there are two physically separate coilpacks and two fuelpumps, there is a good argument for simply latching a fault and not distracting the pilot by trying to do anything about it in-flight. The main point at present is to nail down the power board flexibility I need to build in so I can change these sort of behaviors at a future date purely through firmware/software changes.
While on these sorts of pictures, here is a fuel pump turn-on event, showing a rapid starting current rise to about 13 Amps, settling down to the operating current of around 4 Amps after 75 milliseconds:
Micro-controller
Sheet 7 of the schematics shows the micro-controller circuitry. This is a conventional STM32 based system, with both RS232 and USB external interfaces. There are five ADC’s in the STM32G4, these sample 10 analog inputs corresponding to the six injectors, two coilpacks and two fuel pumps. These ADC’s sample continuously, with 4X oversampling and a total conversion time of 4.82 usec that alternates between the two inputs. Across a coilpack dwell time of 3.5 msec, this gives 300 samples which is more than enough to yield a good representation of the waveform. DMA controllers map ADC output directly to main memory, and as mentioned previously firmware goes hunting through the blocks of ADC data looking for pulses, which are then normalized and centered in buffers ready for acquisition by an external host through a communications port.
There is no dependence on the micro-controller for in-flight operations. If the micro-controller fails in any way, it cannot effect circuit protection or the integrity of the redundant systems. There are some unusual things on the right hand side of this sheet to ensure this. The “disable” signals used for checklist items during ground runups do cause real actions with the circuit protection devices, and if these were permanently wired to the micro-controller outputs, then a micro-controller or board failure which drove these signals could potentially turn off a power circuit. To ensure this cannot happen in-flight, a set of relays disconnect these “disable” signals from their respective destinations. The relays themselves can only be energized by a charge pump circuit, that will only turn the relays on when a micro-controller output is pulsed at a rate of around 5 KHz. A failure of this output, to either high or low or open, cannot close the relays, thereby protecting the system from faults in the micro-controller section.
Engine load emulator
To debug and test this system, I needed a load emulator that looked the same as the engine does. For this, I bought a coilpack, six plugs, harness, six cheap high impedence fuel injectors etc., all from EBay, and mounted them on an Alclad plate (in fact the standard VAN’s RV-10 panel which I had no further need for). I did a board with FET’s and coil drivers, and used an STM32 evaluation board I had on hand to drive it all. This allowed me to drive injectors and coilpacks with pulses, controlled remotely via a USB connection to a host based testing system. As noted earlier, I also have a fuel pump in a water tub. I have resistive loads that I can switch over to for the injectors and the fuel pump, because it’s hard to think while a bunch of fuel injectors are clacking away, they make a surprisingly annoying sound. Here is a short video of the load system in operation, with all injectors and coilpack points in operation (there’s foil around the spark plugs because the EMI was crashing a nearby open computer):
It’s really aggravating in operation, which is why I can switch things over to resistive loads for certain testing. I don’t think the fuel injectors will live for long with no fuel flow for cooling, and I made a bit of a mess of the load board design so some things recently blew up. The load system has proven to be very useful though, so I’m going to spin a better load board design, install a second coilpack etc. so I can more closely emulate the complete IO-540 engine configuration. I’ll use this for first bringup of the system once installed in the aircraft, by hanging wires through the passenger side door and in behind the panel.
I need to do a lot more testing with the next prototype board, and with manufactured boards. Thermal testing with the power board in operation inside an oven at elevated temperature, etc. so the engine emulator will see a lot of service before first start of the real engine.
Redundant power board physical considerations
Obviously with both the right and left coilpack/fuelpump systems, and the entire fuel injector power system, on the redundant power board it is a critical part of the aircraft electrical system. To this end, there are various design considerations that have gone into how connections are made, and the physical / mounting aspects of the board. Here in no particular order are some of these considerations.
It is only a 2 layer board. There are no internal layers. There is no doubt that, with a couple of internal layers, the board could be quieter, and the ADC measurement points could be routed in a much nicer/controlled manner. However, I didn’t want the added complexity of a 4 layer board, or any power plane other than a bottom ground plane.
The board is 2 mm thick, which is a bit thicker and more resilient than a regular PCB. I may make it thicker still.
Copper weight is 2oz, which gives plenty of margin for the higher current traces
Power and ground connections to the board are all made with M4 screw terminals. I didn’t want to use anything other than ring terminals for these critical connections. There are two ground terminals – left and right – which go to their respective ground bolts on the firewall.
Injector, Coilpack and Fuelpump power connections to the board use high reliability Harwin M80 connectors. These connectors have screw/nut retainers both to the board and between connectors. They’re expensive but this is a critical application, which warrants the extra expense.
Not noted above is that power for the ECU’s, and for the injector relay box, comes from additional pins on the Harwin connectors used for the left/right coilpack+fuelpump harnesses. On board circuit protection for the ECU’s is included for these outputs, further reducing the need for extra aircraft wiring for these points.
The power output connection for the SDS injector relay changeover box is active if either left or right power busses are available. I note that later versions of the SDS injector relay changeover box have two power inputs, but mine has only one.
About checklists
As noted earlier, checklists are imperative for so-called “advanced” aircraft systems. Some aspects of the redundant power system design, such as the ability to disable supplies, were done to aid in ground checklist items that would normally require switches, but that could be done electronically given the capabilities of the touch display and the redundant power board. Without further explanation, here is a copy of a worksheet I’ve used to confirm the required capabilities are present, this data will eventually contribute to the relevant printed checklists for the aircraft. Thanks go to a spreadsheet generously shared by another RV builder, John B., who provided the basis for this layout.
Maintenance
There won’t be much in the way of maintenance requirements for the board, apart from the usual annual checks of the wiring connections. I’ll have spares on hand since I will have to do a small manufacturing run, and the board doesn’t really weigh anything so there’s no reason I couldn’t carry one as part of the aircraft spares kit on a longer cross country journey. For the on-board fuses, I considered replaceable fuses in small cartridge carriers, but discounted this, since they add mechanical connections and associated reliability concerns. I considered PTC’s as well, and have the option in various cases to decide which at a later time since the footprint is the same, but by and large I prefer the rugged reliability of surface mount fuses, and if one blows there will be an external reason which has to be addressed anyway.
Conclusion
If you want to build quickly and get your RV-10 in the air as soon as possible, use magnetos and mechanical fuel injection. Proven, reliable technology.
If you decide to use electronic ignition, or ignition and fuel injection, so that you have an electrically dependent engine, then you need to think through the mission parameters and design a robust electrical system that will satisfy the mission requirements. This can often lead to a significant commitment in time and resources. I hate to think of the time I’ve invested so far, as a result I’ve decided to log zero hours for this activity.
Bone pile of EFI power board designs that didn’t make it
I got an E-mail from someone wondering why I stopped posting.
I’ve been steadily working the project, but having reached the “90% done, 90% to go” stage, it’s been hard to progress many tasks through to completion. Winter down in Tassie was long and cold as usual, and the short days tend to slow down workshop hours. Thankfully that’s now behind me for the year.
The inlet plenum 3D printing work reached a stalemate. After many Covid delays, I received the second prototype and it was damaged in transit due to poor packing. I worked with the vendor and insurance to have it replaced, and after yet more Covid delays the replacement arrived, also smashed in shipment. I was able to tape together enough pieces from the two parts to decide that the shape was going to be correct; however, I lost faith in the high temperature epoxy material – it was clearly too brittle. The correct material is ASA, but the quality of the first prototype was not good enough. In order to compete in online 3D printing services you need the lowest price, and there’s a big difference between how this first prototype was printed and how I would want it done. I talked to a few vendors in Australia, and it was clear that the cost would rapidly escalate into the thousands of dollars, for each printing, and I might want to do more adjustments yet. I decided to shelve the work, and ordered a commercial grade large form 3D printer. After months of delays, some again due to Covid-19, this thing will arrive here next week. The only problem is it arrives in 8 boxes and I have to assemble it. Once I get it up and running, I’ll be able to print the plenum as many times as I care to, with the quality I want, before calling it right.
I designed all the overhead panels, some auxiliary panels for headset connections etc, and settled on the replacement lower panel arrangement for the Aerosport 310, which was previously incorrect. I worked with AFS to get these designs finalized and the panels are being cut and printed at this time. In the meantime, I made some cardboard replicas and used these to do most of the overhead wiring. I’m not willing to post a photo of that.
I’ve been doing the wiring, which is a big job for an RV-10 made bigger by my choice of 2 batteries, 2 alternators, a 3 screen panel, A/C and SDS EFI. The wiring is about half done overall, and currently looks like a disaster. I started out wanting to simply do the wiring behind the baggage bulkhead and through the overhead, so that I could finish up the tail and put the final skin on. This plan rapidly devolved into an acceptance that I had to do all of the wiring, there are too many interactions to lock up one part before all parts of the puzzle are solved.
Associated with the wiring are some custom electronics. These pieces are:
Backup EFIS power. The backup EFIS power nominally comes from the second battery/alternator supply. However, what is the action in the case of an electrical fire and smoke starting to fill the cabin? It has to be “both masters off”, there’s no time to figure out which system is the problem. The engine will keep running because the EFI system is separately powered, but in order to keep minimal EFIS functionality, the regular backup battery must be used. So, I designed a board which will supply backup power to the AFS system, which will come from the secondary battery/alternator system if it is running, otherwise will come from a backup battery. Changeover is automatic, and the functions are ground tested as part of the runups.
SDS EFI power. Although the ignition systems, the two fuel pumps and the two ECU’s are on physically redundant battery+alternator systems, there is only one set of injectors so I needed what some would call an “essential bus” to run the fuel injectors. Any place physically redundant systems have to come together is a problem so I’ve applied some effort to this which I’ll post more about in a few months time.
Monitoring and logging. Between the extra TFT display on the panel, the EFI power system, the battery backup system and the A/C there are various sensors and data monitoring that I wanted brought back to a central non-essential point. A small embedded computer system sits under the pilot’s seat and has various communication methods to collect data and present information on the extra TFT display. This may eventually be a last resort backup EFIS, but not initially. I needed a set of interfaces for this embedded system that went beyond what is commercially available, so I’ve done a board for that as well. The prototype worked OK with a couple of jumpers and I’m re-spinning the board now.
In between all these activities, I found I was missing various miscellaneous/low-cost parts, which I’ve procured on a slow track with a few consolidated shipments from the US, again affected somewhat by Covid delays.
Reading through all of the above, it’s clear that I’ve done quite a bit over the past few months, but haven’t managed to actually finish anything. When I finally do manage to finish something, I’ll put up a celebratory post that will include some photos.
I have no idea how many hours I’ve spent on the above over winter – quite a lot – but I’m just going to log 100 hours because I really haven’t kept track of it all.
In order to use SDS EFI &/or ignition products, it is necessary to modify the ring gear to insert magnets for timing sense. This is a straightforward procedure, but not commonly done for dual pulley ring gear as used when an A/C compressor is fitted to the engine.
My ring gear (flywheel) was supplied by Airflow Systems as part of the A/C kit, and uses a serpentine belt for the A/C compressor drive. The magnet insertion points wind up in the middle of the serpentine belt area, which changes how things need to be done compared with the standard procedure published by SDS. Here’s what I did.
My flywheel had timing marks on the front side only. This confused me for a long time because the timing marks didn’t line up with the tooling holes as described in the SDS procedure. It turns out this was all because of my ignorance about Lycoming engines. When timing marks are on the front side of the flywheel, the TDC #1 mark lines up with the small hole at about the 2 o’clock position (viewed from the front) of the starter motor. When timing marks are on the aft side of the flywheel, the TDC #1 mark lines up with the vertical split at the top of the casing. So, with the flywheel lined up at TDC #1 (which I confirmed by looking at the #1 piston through the top plug hole), I marked the rear TDC #1 mark, and the tooling holes then matched up as described in the SDS instructions.
There is a difference though – the tooling holes in the Airflow Systems flywheel are 3/16″, whereas those in the standard flywheel are 1/4″. Ross at SDS kindly made me a drilling jig to suite the flywheel I have.
I then went ahead and drilled the flywheel exactly as per the SDS instructions, using a new #29 cobalt split point drill and plenty of cutting fluid. By sheer good luck, the holes wind up exactly centered in one of the grooves for the serpentine belt – see the pictures. This is lucky because it means it isn’t necessary to rebuild the “crest” of the grooves on the flywheel, just fill in material that has been removed inside the groove.
I tapped the holes #8-32, again as per the standard instructions, and carefully de-burred the sides of the holes in the micro-V groove using needle files, sandpaper and a magnifier. I then cleaned out the holes thoroughly with acetone. At this point though, it is necessary to deviate from the SDS procedure.
There isn’t enough depth to insert two grub screws as well as the magnet, only one grub screw will fit. Here’s what I did:
Each hole contains the magnet, and one grub screw. I soaked the grub screws in acetone to remove any grease or oil, then set the four grub screws aside on a clean, dry tray.
For each hole, I picked up a grub screw with an Allen key, applied red loctite (these aren’t ever coming out) to the grub screw threads, and inserted the grub screw to a bit short of the right position from the outside, leaving the Allen key still in place.
I then mixed up some 5 minute epoxy, filled the hole per the standard instructions (the plastic shaft of a Q-tip with the head cut off works well for this), and inserted the magnet from the inside. The magnet gets pulled in and smacks against the grub screw.
Now carefully wind the grub screw further in, until the magnet is at the desired position, just inside the inner surface of the flywheel. Remove the Allen key. Wipe off the excess epoxy with some acetone on a clean rag.
Clean off the red loctite from the serpentine pulley groove with acetone. I used a piece of paper towel with acetone, and a clean feeler gauge to get right down to the bottom of the groove. Then I used a Q-tip dipped in Acetone to get down and clean the loctite out of the threads in the hole, above the grub screw, while holding the flywheel so that the acetone would run out of the hole rather than down around the grub screw – so as not to displace any loctite around the threads.
Do one hole at a time – go back and repeat steps 2-5 another three times, making sure to get the magnet orientation right. Then set everything aside for a few hours or overnight for the epoxy and loctite to cure.
Now it is necessary to “rebuild” the damaged groove. I used a product called Devcon Titanium Putty to do this. It’s an expensive product and you only need a small amount, I was able to borrow some from a friend that is a commercial user. There are other metal repair products around that would also be suitable.
Mix a small amount and force it down each hole so that there is a continuous layer of putty around the top of the grub screw out to the bottom of the groove, and use a fine knife to roughly shape the two sides of the groove, ensuring the threaded hole is fully filled up to the top of each side of the groove. I then let the Titanium putty cure for 3 hours. Don’t let it go much longer – after about 6 hours it gets a lot harder to work.
Three hours after applying, I used a combination of tiny needle files and various fine grades of sandpaper to rebuild the groove in each of the four hole positions. I started with the files, then switched to 120 grit paper to get each position nearly done. I wore a magnifying headset to do this, so that I had good vision for this micro-surgery. When I got close to the final result, I set the flywheel aside for another few hours for the putty to harden a bit more.
After about five hours total, I did some further sanding using 240, 400 and finally 800 grit paper to polish each side and the rim of the groove to complete the rebuild. The Titanium putty is well secured by the threads of each hole – see the final picture. The job is done when each side of the groove is smooth and flat, and you can run your fingers across the top of the groove with your eyes closed and not be able to tell when you run across where the hole was.
#29 hole drilled in Airflow Systems dual ring gear
