Boom Integration Part Deux
I made the first flight with the boom attached on New Year’s Day—a good way to start 2020. The boom itself is a really nifty piece of kit built by Andrew Angellotti and the folks at Spin Garage in Mojave California. They specialize in building accurate, light-weight, portable flight test equipment. It transmits wirelessly to the cockpit, and data is recorded on the SD card in the ONSPEED AOA box. Post-flight, I download all of the data wirelessly in a (big!) single file that we can open with Excel or MATLAB for analysis. The file integrates data from the EFIS, boom and Gen 2 V3 using GPS time as a primary reference. The boom functions as a calibrated control for our experimental data, and while flight test and analysis show that we’ve got an accurate system; we can nail that down by using calibrated boom data for comparison. The boom also allows us to quantify lag rates and damping performance.
Any time you attach an external store to an airplane, the first order of business is to validate the installation; i.e., make sure it doesn’t fall off. We (Lenny, actually) built a set of boom mounts that is more robust, lower drag and more quickly installed than the Spin Garage system and optimized for RV’s. It allows us to mount on either wing, but most importantly, reduces installation and removal time to about 5 minutes and six screws. Conceptually, it works the same as a heavy-duty camera mounts that utilizes the #6 screws used to hold the RV fiberglass wing tip in place. The mount is static tested to 9G’s longitudinally, and 6G’s laterally using a digital fish scale, readily available in the flight test equipment isle at the local WalMart.
Andrew provides a nice set of illustrated installation and removal instructions for their temporary mounting system, which could be used on any airplane. All up weight for the boom is only 250 grams. It’s powered by a small lithium battery and has a bright LED I can monitor from the cockpit to ensure it’s on and transmitting properly. In addition to alpha (AOA) and beta (sideslip) vanes that are accurate through ± 20 degrees, the boom is equipped with an accurate pitot/static source called a Keil probe that is specifically designed for flight test work. This provides an accurate CAS source independent of the airplane and measured in the free stream well ahead of the leading edge of the wing. At low offset angles, the airspeed measurement error is essentially zero, and known for higher angles, so we can do any math required during analysis.
Published limits for the boom using the Spin Garage mounts are ± 4 G’s and 155 KIAS. Since I’m a knuckle-dragger that tries to fly with ham hands; we designed our mounts for aircraft limits: 6 G’s and 182.5 KTAS. During the first test flight, I validated the boom envelope to 4 G’s and 183 KTAS. It didn’t fall off, which is good, because it was expensive. We’ll eventually open up the boom envelope with the heavy-duty mounts to full aircraft limits and once we mount it on a -7 or -8 open up the TAS limit as well. Since we haven’t done extensive data analysis yet; we don’t know what the effect of G will be on boom performance; but we’ll find out.
3D Audio, Round One
Evolution has made the human meat-computer brain remarkably good at figuring out what angle a sound is coming from. We experimented with this in the military, since it’s uber handy to know what direction a potential threat is coming from. We decided to try an experiment with our tone to see if we could effectively mimic the function and performance of the slip/skid ball in the inclinometer to use the tone to provide a yaw cue to the pilot when you are flying at AOA’s above L/Dmax (i.e., slower speed where you want the ball centered up for the most part).
The way this works, the tone “slides” left or right in the stereo sound field based on input from the lateral accelerometer on the IMU chip (i.e., it works just like the synthetic ball does on your EFIS if you have one or the mechanical ball in the inclinometer). Since we are experimenting with the ergonomics, we are simply sliding the tone with the ball. There is a change in volume and gain based on the amount the ball is out of the race—further out = more gain down on the opposite channel and volume increase on the channel the ball is "sliding" into. You “step on the tone” the same way to “step on the ball” to center it up. We chose a logarithmic algorithm for this based on the way our ear perceives relative volume.
This 3D audio logic will work with a stereo intercom. We know that this is relatively new technology and many airplanes don’t have stereo intercoms or wiring; so, we will also experiment using the Bluetooth functionality in the box that is currently un-tapped to transmit directly to a Bluetooth stereo headset to provide the yaw cues. There will be software controls to turn this feature on or off; and, obviously, it won’t work in a purely monoaural system.
The basis for this is that any truly effective technology designed to mitigate loss of control risk has to convey AOA, sideslip and energy information to the pilot. If he or she insists on ignoring that information, then some type of auto-recovery in addition to cuing would be just about an optimal solution…think “hey, you’re screwing up your control inputs, fix it” followed by “I’ve got the airplane!” We aren’t actively pursuing auto-recovery with our project; but we are trying to address items 1-3 on this list. Kind of like flying with an IP every "sortie."
Real-time WiFi Settings Interface for Flight Test
Our learning curve with Gen 2 has been steep and fast. Until we move into beta test, we are a mostly one man/one airplane developmental flight test department, with Lenny typing as fast as he can to eradicate software bugs. I’m generating sorties (Air Force slang [from the original French] for “flights”) as fast as time and “science in progress” permit. The good news is that I’m also the least common denominator when it comes to making computers go; so, if I can stumble through software changes and settings, anyone with a solid sixth grade education can likely do better. At present, if I want to make a change, I have to land and re-program the V3 box.
Because we’ve been at this experiment for four years and the fact that I’m pretty familiar with the mighty RV-4 test bed, we decided to develop a wifi interface that will allow us to change software settings in flight to help expedite flight test and eliminate the need to re-program for every change. This is no mean feat, and the jury’s out on whether or not we’ll be able to pull it off effectively. There is some pretty intense coding work that is required to make this happen.
The primary purpose of this interface is to change damping settings and latency real-time to ascertain effects in real world ops; and a secondary benefit is to easily adjust set points during a “hard tune” calibration. We realize there are some human-factors considerations with changing settings real-time and only intend to use this interface for flight test work. I'm sure I'll find a way to screw it up in an operational environment.
A Plethora of Harnesses…
Phil has been graciously plugging away at fabricating the 25 V3 boxes and associated harnesses that we’ll use for beta testing. The harnesses are color-coded, and continuity checked with an 8’ pigtail. We’ll provide one with each box to our beta testers to help simplify installation. Pneumatic connections are made by teeing off existing pitot, AOA and (for experimental airplanes) static lines.
We are still designing the experiments we want to perform during beta; but when we’re ready we’ll post on the VAF safety page to figure out what the fate of these 25 systems will be! If you've got experience with design of experiment to optimize use of resources, we'd love to hear from you--we are always interested in collaboration to make sure we are staying on track.
Send Cash!
We are also validating the modern internet model of everything for free/death-by-advertising/good luck with donations model (i.e., it doesn't work). Our little 501(c)3 non-profit has been averaging 0.1% (that's 1/10th of one percent) donations vs expenditures. Slightly higher than the odds of a shark bite here on the Gulf Coast, but not much. We don't have any expectation that we'll be able to sustain this effort on a donation model over time; and we'll continue to plug away regardless mostly because I'm not smart enough to quit. Hopefully there is some value in the flight test results, hardware design, software and training materials (including the RV Transition Training Syllabus) for our EAB community. There's a PayPal donation button on our home page if you're so inclined--we sure appreciate it. All of our flight test work is paid for out of pocket by volunteers, and we are averaging north of 40 man-hours per week of volunteer work in addition to flight test. 100% of our operating budget (such as it is) goes towards procuring equipment and internet expenses. We'll be providing hardware, software and support to our beta testers for free (unless, of course, they are inclined to donate to the cause!).