top of page

We Should Be at Oshkosh...

...drinking Spotted Cow. But because we can't (wisely under the circumstances), I thought I'd post a quick update:

Just Say No to Apple Catalina (For now, at least)

One of the fringe benefits of being the FlyONSPEED stick monkey, is that I’m generally the last person on the team to figure things out. This results in an overall lower level of stress, since all of my unknowns are generally unknown to me, most of the time. After a recent IT scare (as in I thought I accidentally fried my MacBook with all of the project flight test data on it) I figured it might be a good idea to get a back-up computer so we don’t go program Code 3 (i.e., hard broke) because I can’t interface with the boxes in the airplane, or worse: let the dog eat all of our homework.

Imagine my surprise when I tried to plug my brand new, uber MacBook into the airplane and, wait for it, I couldn’t open up the software we use to talk to the V2 box in the mighty RV-4. Didn’t take but a quick call to Lenny to find out that “yeah, our version of Arduino doesn’t run under Catalina…” Sigh. I’m still working on re-configuring the new computer to Mojave, Apple doesn’t make going backwards in operating systems easy. So, the lesson learned is if you are a Mac user—make sure the operating system is Mojave or older to use all of the current FlyONSPEED software. Anecdotally, I’m a Sequoia Benchmark user, and it too is challenged by newer versions of MAC OS. Bottom line: if you live in Apple world, tread lightly with the latest and greatest OS!

Programming for Pilots

And speaking of computers, I’m also a great software tester. Mostly because I don’t know my way around a computer the way the other guys on the team do, so once again, I perform "wedge" duty (the wedge is the simplest tool known to man). We currently have the most current version of the builder’s manual on GitHub. Software installation instructions are in there; but it can be a bit much for a neophyte—even for someone capable of soldering together a V3 box from scratch. Turns out there are mostly hardware folks and mostly software folks and a few rare individuals good at both (thankfully, that’s the rest of the ONSPEED team).

Even after you get everything programmed, you still have to work your way through the configuration process using the WiFi interface and a cell phone or tablet. So, I thought I’d provide the 30,000-foot overview of the software as well as were to get more “how to” information.

There are three pieces of “ONSPEED” software: the basic program itself, the WiFi firmware and the Arduino "libraries" required to compile the code.

Our basic interface with the box is the Arudino app. The “arduino” is a small development board that folks use to prototype systems or serve as a brain for a robot or other smart device. In the V3 box, the “teensy two” computer serves this function. It is similar to an Arduino and other development motherboards. The basic Arduino software interfaces with the Teensy when it is configured properly (i.e., has the correct settings). The Arduino software architecture uses “libraries.” I think of those as specialized sub-routines or off-the-shelf program add ons. In order for the ONSPEED software to run, the proper libraries must be loaded into the Arduino app and the proper settings selected. After the basic Arduino app is loaded and the libraries are configured on your laptop, you can load the basic ONSPEED software program. There are one or two user configurable settings in the basic software; but for the most part, other than occasionally updating you won’t interface with the basic code. This file is called “OnSpeedTeensy.ino” and is resident in an Arduino folder currently called “OnSpeedTeensy” along with a bunch of other Arduino files the stick monkey does not understand. The only file I ever click on in that folder is the OnSpeedTeensy.ino.

In addition to the Teensy, the V3 box also has a wifi board. Of course, it has its own firmware that has to be installed and configured properly. Presently, the first time you load the firmware, you do that with the computer plugged into the box using the basic Arduino interface. After the initial firmware load, future firmware updates can be done using WiFi. The wifi code is in a file named “OnSpeedWiFi.ino” in a folder named “OnSpeedWiFi.” In keeping with standard convention that anything worth doing is generally hard; after the intial firmware is installed, wifi updates use a file named “OnSpeedWiFi.ino.pico32.bin.” To really obfuscate, if you are on a Mac, this file shows up with a zip file icon. Clear as mud, no?

I’ve got a couple of checklists that I’ve developed to help me out with managing these processes (i.e., so I can mostly get it right on my own without having to bother the smart people for help). It’s also important not to drink too much Spotted Cow whilst you are programming or trying to set the system up, or you’ll likely come to regret that technique.

This is the checklist I use most often for daily operations (hyperlink RV-4 daily). This one is RV-4 specific and I only share it as an example. There are lots of moving pieces and even after 10 months and 50 or so test hops; I still use the checklist every time I fly because I usually manage to forget something. I’ve made a generic version of this checklist for everyone. The checklist mirrors the WiFi AOA Configuration and Sensor Configuration windows. It helps me when I work through the WiFi process when I fill in the information that I know before hand, and then program it. Eventually, we’ll get our configuration wizard to walk pilots thru the process; but for now this is how we’re making things work.

This is a more detailed document that I put together to help folks walk through the programming process. This isn’t designed to replace the information in the software installation guide—that was written by engineers way smarter than I am. This is purely a step-through written by a pilot that might help another pilot. I’ve learned that it’s usually something simple that fouls up the works. For example, a missing Arduino library, a transposed number in a setting, forgetting to hit SAVE after an input, etc. This list is actually a lot longer. I know. I’ve made all of the mistakes, multiple times. Occasionally I find an actual bug, so they’re not ALL my fault (say a good 2-3% or so).

Because I’m a pilot, I completely get “set it and forget it,” i.e., it just has to work with a simple interface. I want to turn it on and adjust the volume. The software pain is a one-time thing and we’ll make sure any boxes that we send out to folks for test will at least have baseline software and firmware versions, so that any update is fairly straight forward. If you are scratch building and need a vector, we are always an e-mail or message board query away to help. As I’ve said in the past, we appreciate posts on the message board so that we can share any corporate knowledge; but we are always happy to help out any way we can. Don't hesitate to drop a line.

The “ORD.”

Back in the late Paleozoic, we used to have an “operational requirements document” that spelled out the desired performance of any system that we bought for military use. This was where us users told a contractor what we wanted and how well we expected it to work. It was up to the engineers to figure out how to make that happen and the contracting and procurement folks to get it to us for testing. The first stage of testing is “developmental” or “does it work?” The second phase of testing is “operational,” or “how well does it work when exposed to an operational environment and how do we use it?” The “does it work” benchmark was spelled out in the ORD.

When we started this project, we piggy-backed on work done by Dr. Dave Rogers and the folks at Embry-Riddle on behalf of the FAA. This team developed a low-cost differential pressure AOA solution that was capable of measuring absolute AOA to within ¼ to ½ degree. We’ve always had that objective and want to expand the capability to any commercially available probe or even a home-made sensor. We also want the software to be easily adaptable, and any hardware to be inexpensive and easy to build for anyone with basic electronic skills (or easy to manufacture). Additionally, we want the system to perform under G, not because we want to bolt it into a fighter, but because performance under G translates to performance in challenging conditions: turbulence, gusty winds and wind shear. Our design objective is accurate response at G onset rates up to 4G’s per second, which is a de facto test limit with the mighty RV-4 and represents the limit of my ability to rapidly apply G and the aircraft's ability to respond in flight. And only when I’m having a good day. It remains to be seen if we'll be able to accurately hit this data point or not. Since each G is 32 feet/sec, the ability to handle 4G’s in a second translates to a gust load of 128 feet/sec. Enough capability to catch a wire on a dark and stormy night.

Depending on flight conditions, we can use pitch, pitch rate, vertical velocity, other IMU outputs, and dynamic pressure as well as the calibrated boom to assess performance. In addition to accurately computing AOA in a timely manner, the system has to present a usable, timely, damped signal to the pilot either in the form of a tone or suitable visual display. Oh, and we want the AOA corrected for any sideslip induced error, accurate overload warning and airspeed limit warnings to work well too. All of the stuff the pilot needs to know for how hard to “pull on the pole".

The SpinGarage LLC "Featherweight" test boom bolted to the left wing tip of the mighty RV-4.

Evaluating this performance is what we are currently working on in the flyONSPEED flight test department (such as it is!). Evaluating 1G performance in level, unaccelerated flight is fairly straightforward. Both pitch and calibrated boom data are available for comparison with V3 computed AOA. In a flaps 0 condition, we are averaging 0.209 deg error; 0.329 deg flaps 20 and 0.334 deg flaps 40 with the Dynon Probe (we don’t have these data for other types of probes yet). This meets the original design objective of less than .25 to .5 deg error. In more dynamic conditions, we are currently shifting our filtering technique from Gaussian to Savitzky-Golay smoothing. This will reduce latency and the digital to analog nature of the tone still works its own damping magic. Our current challenge is accurately assessing performance under G load. Lead and lag are minimal; but we’re not yet confident enough in our analysis to publish results under G. This is because we are still learning how to correct the boom for high pitch rate conditions under load. If anyone reading this has experience with this type of air data probe correction, we are all ears and will buy beer for any good inputs. We plan to test up to 4G's sustained.

The reason we want a high-performance system that’s been thoroughly flight tested is that we want pilots to have enough confidence in the system to use it as a primary reference for maneuvering flight, takeoff, approach and landing operations. We aren’t familiar with any commercially available angle of attack system (or energy cuing device) that stipulates performance parameters. Our objective is to demonstrate what is the art of the doable by setting the performance bar and sharing all of our work. We also understand that maneuvering by reference to an AOA cue is also a concept that hasn’t seen wide use outside of the fighter community, so the other part of our mission is education and familiarization.

Measure Twice, Don’t Cut Anything

For reasons unknown to me, two of my three kids are sailors. That’s probably because they grew up on an Air Force base and just wanted out. One is all blue (Coast Guard) and one bleeds haze grey (USN). A couple of weeks ago, #1 was home on leave. In our quest to figure out how the boom works under G, Anna Maria (Ensign, USCG, one each) helped me jack the airplane up, level it and conduct a few experiments on a day it was raining too hard to do much else. This drill put our collective “just about washed out of physics for engineers x 2 generations” to good use. Pouring water mostly. Sailors are intimately familiar with water--enough to live there. Working together, the two of us measured the boom bending under load and properly quantifed boom and EFIS (pitch) installation error so we can add those corrections to our analysis. I’m not sure if AM had as much fun as I did (measuring an air data boom isn’t quite up there with surfing or kite boarding), but she was a great sport about it.

Anna Maria and the fully-calibrated, high tech 2 x 4 measuring device.
Leveling the RV-4 laterally. The canopy rails are the fuselage reference line.
Checking angle of incidence in accordance with Van's drawings. The RV-4 as + 1/2 deg incidence.

Adjusting the boom so that the axis of the alpha vane is parallel to the horizon.
Measuring boom installation error: 0.3 deg nose down relative to the fuselage reference line.
EFIS is installed with 0.3 deg nose up error.

138 views0 comments

Recent Posts

See All


bottom of page