I’ve been derelict in my duty posting project updates. The crux of our work has been two-fold since spring: first, developing and testing parser code that works with MGL avionics; and second replacing our original on-board IMU with one that is less temperature sensitive. The first has been a challenge since MGL uses a binary output with a variable message size to save CPU cycles. Improved IMU performance is required for auto cal in airplanes that aren’t EFFS-equipped and the MGL parser was required to support the EAA’s One Week Wonder program at Oshkosh—a Sonex Waiex-B powered by a Rotax 912iS that was assembled by a team of incredibly hard-working volunteers over the week of the show. The ONSPEED system now has the capability of interfacing with Garmin, Dynon and MGL systems for both data recording and automatic calibration. Our one shortfall is GRT. We do not yet have software to support those systems.
Pubs
We finally have a set of “how to” publications available for system support on our GitHub site. The pubs are available in two versions: one that is abbreviated in checklist format for users that know their way around a computer and one that is much more “insert tab B into slot A” for folks that are casual computer users. Unfortunately, for all of its capability, the Arduino Integrated Development Environment isn’t easy to use for the typical pilot. Whatever the next version of the system is, we will definitely be stepping away from this system—it’s simply too complicated (and easy to make a fatal error) for the average non-engineering user.
As always, I request any feedback from folks that use the pubs, since I’m exactly one man deep in the tech writing department and often lose sight of the forest with all of the trees in the way…
Unobtainium!
It seems that the PRJC Teensy 3.6 that we are using in V3 hardware is pretty much made of “unobtanium” these days. We’ve shared any bench stock that we have and are currently “bingo” (i.e., we have none left). The folks that make the 3.6 report: “Teensy 3.2, 3.5, 3.6 are only temporarily out of stock, due to chip shortage. Chips have been ordered (they were actually ordered just slightly over 1 year ago, in January 2021). These boards will be made again when those chips arrive. But they've been delayed by several months due to the global chip shortage. Best estimate is looking like July 2022 for Teensy 3.2, possibly later in 2022 for 3.5 & 3.6.” The Mighty Google says it's anyone’s guess when more will be in stock.
The V3 configuration will remain our through-hole, “Heathkit” configuration; but as we make progress, we’ll be moving on to a fourth version (cleverly referred to as “V4”) that will be a more productionized reference design. Our standard “all volunteer, get the physics right” timeline applies to that project 😊 so I won’t hazard a guess what sort of timeline applies to that effort.
The ”One Week Wonder” Project
Cecil Jones did some excellent work getting a V3 system installed in the EAA’s One Week Wonder. A couple of late nights, missed air shows, gnashing of teeth and a bonus day in Oshkosh to pull that off—Thanks Tron! Through a series of minor miracles, the airplane taxied on the last day of the show and flew shortly thereafter.
Since we were moving at light speed to git ‘er done, I managed to trip over my clown shoes getting everything squared away in time, including not testing a box before bolting it into the airplane only to discover a bad power supply. First time that happened, turns out we nicked something important when modifying the IMU…no excuse. We swapped in a back-up box at Oshkosh. A subsequent trip by yours truly to the Sonex factory in Oshkosh to install a box with the new IMU and current software undid that mistake. Big thanks also to Chris Jones and Bob Baggerman for developing an MGL (EFIS) parser. No mean feat, since MGL uses a binary data output with variable message size. This is different from the other manufacturer’s which use a fixed-length serial data stream. At least that’s the stick monkey’s summary—I’m sure the engineers will correct me if I’m wrong. All I know is it was hard and took twice as long as anticipated. Standard!
I also want to thank Chris Hepburn for help designing a new pitot/static system for the airplane. The basic Sonex solution is an inexpensive under-wing pitot static system similar to the “dirt cheap” AOA probe we tested in the spring. After some debate, we settled on the Dynon pitot/AOA probe (known commodity) and added conventional static ports on the aft fuselage (unknown commodity at this point). In addition to AOA calibration, we’ll work with the folks at EAA and Sonex to dial in the new system and measure static source pressure error.
Dirt Cheap Probe in the Wild
We are working on our first “round dial” installation. This will be our first non-EFIS airplane, which means we are counting on the 20-buck chuck IMU for calibration. For the record, we don’t think we have the IMU filtered well enough with current software for general use without an EFIS for calibration; but we want to “fast track” an installation for experimentation in something besides an RV. Worst-case scenario: if we can’t achieve a sufficiently good auto cal, we can always fly some trim shots and calibrate the old-fashioned way…the owner of the airplane flew F-4’s in the Air Force and is well versed with the AOA tone.
You may notice we are using the “dirt cheap” probe we tested last spring on the RV-4. Because the installation is in a certified airplane, the probe is mounted on an inspection plate, and the system is separate from the primary pitot/static system. We think this simple probe configuration will be adequate for the speed band of the airplane. Since the probe itself is noiser than a standard Dynon or Garmin tube, we’ll have to deal with the compound problem of a slightly noisy signal being calibrated using a slightly noisy gyro! More to follow as we finish the installation and do some testing.
And, speaking of “dirt cheap” probes, we’ve concluded that while it’s practical to use two bent tubes to provide a differential pressure source, the right “dirt cheap” answer is a spherical head probe with multiple ports. This is Lenny’s department. The cool thing is that we can quickly print different configurations for testing. The current challenge is orifice configuration. Auto calibration requires an accurate dynamic pressure source. It also looks like we’ll be using a different math technique for deriving coefficient of pressure with that configuration. The immediate priority is taming the IMU; so, the advanced probe is currently on the back burner.
The cutting edge of first generation EFIS tech
For the past couple of years, I’ve had some new avionics on the shelf for installation in the mighty RV-4. Because I’m not much of a tinkerer, and hate change (like any good pilot!) I’ve always been hesitant to ground the airplane for modification. I never know when Lenny is going to have a moment of inspiration and have new software ready to test; so I want the airplane flyable. As I get to my fourth year of delaying modification; I’ve finally concluded that what I’ve got is good enough until we finish this project, no matter how long that takes. Unfortunately, both of my older D-10A EFIS decided to act up simultaneously, so they are both out for overhaul. We can still test in the interim, day VFR. Cudos to Dynon Avionics for supporting these old systems! One tactical advantage of these old tubes (besides the simplicity of use and redundancy they provide), is the high serial data transmission rate (64Hz vs the more common 5-10Hz that more modern avionics use). To be kind to the CPU, in the mighty RV-4 we record EFIS data in the secondary wing-mounted system and fuse the data post flight with the primary system that is tasked with recording VN-300 GNSS/INS and air data boom data. Turns out the biggest challenge of this decision (to keep the old EFISs) is finding a serviceable HS-34 control panel...they are rare as hen's teeth! If you've got a horizontal one laying around from an avionics upgrade, drop me a line.
Anatomy of an Auto Calibration
Like any complex project, we figure we are 90% done, 90% left to go (i.e., the same math used to ascertain 90% of the pilots are in the top 10% 😊). We know that we’ve got the ability to automatically calibrate using the EFIS and even basic capability using the IMU; but what we don’t yet know is how well this ability will work in the wild, nor do we fully understand the accuracy of the various calibration techniques we’ve used (yet). When we initially developed the concept of capturing the entire pressure vs AOA curve using a single deceleration run it seemed intuitive this should be relatively simple to do: Just accelerate to Vmax, pull the throttle back, slow down and stall. Well, it turns out, not all deceleration runs are created equal. I was excited to get feedback from other pilots, but the results surprised me. An auto calibration run is a single, smooth AOA increase as the airplane approaches stall. You can see this in Figure 1.
The system uses the on-board IMU to determine angle of attack: it’s the difference between flight path angle and pitch. This is plotted in Figure 2 for the same auto calibration run:
The advanced piloting technique I’m using to auto calibrate is simply looking out the window. Exact deceleration rate or altitude control isn’t important. Notice that the aircraft pitch increase isn’t nearly as smooth as the AOA curve. This is a result of changing flight path. Since all I’m doing is looking at the nose of the airplane (the EFISs were removed from the airplane for maintenance), I’m instinctively adjusting pitch and pitch rate to keep a stable “nose rising” picture. In other words, a good auto calibration is achieved when the nose is continually tracking up into the stall. The run in Figures 1 and 2 produced the calibration curve in Figure 3. Notice the smooth coefficient of pressure vs alpha curve, evidenced by the high R2 value. Also notice the increased pressure variability as angle of attack increases. These data are from the RV-4 primary system using the Dynon probe. Due to the broad speed band (ratio of maximum speed to stall), and low drag of the Catto fixed pitch propeller on the RV-4, this run from Vno to stall required 68 seconds.
If the pilot rapidly increases pitch and then stabilizes the picture, i.e. quick smooth pull to X degrees nose up and then maintain that pitch angle allowing AOA to “catch up,” the quality of the calibration suffers. We designed the logic to work at 1kt/sec deceleration; but the exact rate isn’t important—what’s important is the smoothness of the control application. If the pilot increases pitch to rapidly or tries to “chase” the deceleration display, it’s difficult to achieve a good calibration. Figure 4 is an auto cal run in an RV-8 equipped with MGL avionics flown by one of our beta testers. It shows AOA, pitch and deceleration rate. This RV-8 is equipped with an O-360 engine and two blade, metal Hartzell constant speed propeller. This run was started at a speed below VNO and with the high drag prop only took 36 seconds.
In this example, the pilot smoothly increases pitch to about 15 degrees and simply holds the attitude, allowing AOA to catch up. It does, albeit not smoothly. This resulted in the calibration curve shown in Figure 5. Note the relatively noisy data and low R2 value. This calibration is usable, but below the desired .98 R2 minimum value.
From this, we can derive that the quality of the calibration is related to the handling technique the pilot uses during the deceleration run. In other words, it appears as though auto calibration is not pilot proof. We may have complicated things by designing to a nominal 1 knot per second deceleration rate (a number that comes from standard flight test and certification standards) and developing a display to show that. Result? Folks are trying to nail the deceleration rate. This is not possible at all in the first quarter-third of the speed band and takes some judicious altitude/flight path angle trade-off to accomplish in the second 2/3d’s of the run. Smoothly increasing AOA also requires the pilot to vary the rate at which back stick/pressure is applied during the deceleration run. At first, little or no pressure is required, but as the airplane decelerates, increasing back pressure is required; and the RATE at which the pilot pulls back needs to increase as the stall is approached.
Here's a video that explains auto calibration: https://youtu.be/4ZN5XmLhtl0