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.