IAS accuracy testing

I am still searching for the elusive accurate IAS, or at least, a root cause.

First I checked a pressure sensor with a water manometer to be sure all was well, and my numbers came out accurate to within 0.1 inch of H2O, which is good:

Position 1: I set up a standard "UAV" Pitot tube with one of our pressure sensors and put it on the usual strut mount:

Position 2: I mounted the probe on a boom on the wingtip. This album shows more details of the process for installing the boom:

The results compared to the built-in IAS were as follows:

Built-in ASI (kias)	Probe Pitot Position 1 (kias)	Probe Pitot Position 2 (kias)
40	46	46
50	50	52
60	58	60
70	67	68
80	72	75
90	76	80
100	86	90

You can see that the second and third columns are very similar. So moving to a different position did not affect the readings very much. However, the readings remain quite a bit different from the built-in ASI.

I then did a quadrangle course comparing the built-in ASI to GPS speed. The data are as follows. The headings are not "real" but they are more or less 90 degrees to one another:

• Approximate altitude: 5400 feet
• Local static pressure: 84267 pascals
• Local outside air temperature: 13.4 degrees C

Heading	IAS (kias)	GPS ground speed (kt)
000	80	79
090	80	90
180	80	89
270	80	77

Taking the average of the 4 ground speeds:

(79 + 90 + 89 + 77) / 4 = 83.75

Therefore our TAS was 83.75 ktas or 43.08 m/s.

At the given barometric information, air density is 1.0197 kg/m^3.

Dynamic pressure = 0.5 * 1.0197 * (43.08^2) = 946 Pa.

This corresponds to sqrt(2 * 946 / 1.225) = 39.3 m/s indicated = 76.4 kcas.

So at 76.4 knots calibrated airspeed, we have:

• Built in ASI: 80 kias
• Airball Pitot position 1: 72 kias
• Airball Pitot position 2: 75 kias

It looks like the built-in ASI is way off. The Airball Pitot under-reads in Position 1 but shows improvement due to movement from Position 1 to Position 2.

So is that the answer then? Move the Airball to the wingtip and trust it, and know that the built-in ASI is super inaccurate? We need to do a bit more testing before we're sure. Specifically, at each of these airspeeds, from 40 to 100 kias (according to the built-in gage), we should do a full quadrangle. Stay tuned.

Probe nose testing at Wichita State

Airball collaborator Matthew Schmid at Wichita State University did some new testing of two probe nose concepts. Here are some quick videos of the testing in progress:

The experiment is best described in the Github repo, so please first check out the following:

https://github.com/airball-aero/airball-tunnel/blob/master/data/2021-09/README.md

First let's analyze the "2-hole" head. This is a plot of the pressure coefficients from all the holes, for the 5 psf test:

First, all 5 holes from the probe nose show really good correspondence of the data (orange dots) with theory (blue dots). There is some difference, which is proportionate. This is great.

Notice, however, how the static pressure signal is really poor. It is highly asymmetric and does not seem consistent. The "2-hole" concept relies on having two controlled orifices, on the left and the right, feeding pressure into a common plenum and thus averaging out the pressure in a predictable manner. But in our setup, we just plumbed 1/16" passages through windy 3D printed matter, with a right angle somewhere there, creating an unknown and inconsistent resistance to cross-flow.

If we want to try again, we should probably consider creating two, precisely drilled, tiny "orifice plates" out of metal to create the two side holes, and connecting them with a large plenum. Not unsurprisingly, this setup sounds very much like the static source on the side of an actual airplane!

Having basically dismissed the 2-hole static source as currently implemented, let's take a look at the case with the explicit static tube. Here again is the 5 psf test:

There the static pressure signal looks very symmetrical and useable. There is one interesting factor though. Look at the way it varies with alpha:

At positive alpha, the static probe is "shadowed" behind the probe nose, and so it reads a lower pressure. We decided to put the static probe tube above the nose so as not to interfere with the angle of attack reading -- but now we realize that the nose interferes with it! This is okay. We can use this calibration to get a reasonable system.

If we combine the static probe head data for 5 psf and 20 psf, we can see the effect of Reynolds number on our results. At least in the range tested, the pressure coefficients are consistent (not an outlier row of data around beta = 24 degrees, which we will eliminate).

The next steps are to reproduce the static probe geometry in a manufacturable and durable manner. In particular, the problem we were having is that the probe tube would rotate freely in the 3D printed nose, and just adding a set screw was not enough to constrain it. Our current approach is to use stainless steel capillary tubing and silver-solder on a small mounting "foot" to constrain it better.

Stay tuned for details.

Software updates ongoing

Often my Airball posts are about building hardware. This one is about pure software -- but it has deep hardware implications.

You may recall that the Airball displays have a knob and/or buttons to adjust parameters. Well, we only need adjustment very infrequently. In particular, we only "need" on-device interactors for:

1. Entering the barometer setting, if the altimeter is being used; and
2. Changing the screen brightness.

My current test strategy is to hold off on the altimeter for a while and get feedback about the basic device, and the cheap commodity RasPi displays often don't allow software control of brightness and are inadequately bright anyway!

The new scheme is to host a Web app on the device, which will allow the user to edit parameters from their phone or tablet. The user will connect to the Wi-Fi network of the probe and display, go to a well-known IP address, and edit to their heart's content. Since I can use React or Flutter or whatever I want to build this app, I can create a "real" UI.

The first step is the wiring on the device. I changed the code so the airball-settings.json file is in engineering units (not button counts like I had before), and also made a lot of display parameters (like width, height, and whether various widgets are shown) variable at runtime. I added code to use inotify to listen for changes in the settings file, and created a simple CGI script in Python using Apache2 to handle POSTs to change the file.

The result is a super-simple Wi-Fi enabled settings UI, which I'm demonstrating here by editing the file and POSTing it via curl to the device:

I am using a UCTRONICS 3.5 inch display as opposed to the 4.3 inch displays I was using previously -- in an attempt to create a somewhat more compact unit. We'll see what feedback we get from users.

Next up is to create the Web app -- React and Flutter are the main competitors, and I'm leaning towards Flutter just because I want to learn it!

Congratulations to FlyONSPEED

The FlyONSPEED team are the Grand Champions of the EAA Founder's Innovation Award competition! Congratulations to the whole team, lead by "Vac" Vaccaro, an all-around crazy and super swell dude. See the EAA news report here:

FlyONSPEED Wins Founder’s Innovation Prize Grand Championship

Airball was honored to come in second behind Vac's team.

Coming in third were Mike and Ian Foale (a father/son team) with Solar Pilot Guard, a really cool solar-powered suite of sensors and notification.

Also in the finals were Ed Wischmeyer with Expanded Envelope Exercises, which seek to familiarize pilots with flight outside their "comfort zone" so they don't panic when they have to do that; and Ray Kwong of Epic Optix who showed us how HUDs can enhance safety and situational awareness.

At some point the photographers asked Vac and his team to pose with their grand prize trophy, but he insisted that the rest of us (2nd and 3rd place winners) pose with him too. This is just the kind of guy he is. So here we all are, one big happy family:

The most delightful thing about the event was the "back room" discussions. We all supported one another and were excited to collaborate in whatever way we can. We all cheered one another on. We checked out one another's tech (for those of us dorks who traveled to Oshkosh with piles of geeky junk -- I'm looking at you Vac and Ihab).

Expect, in particular, that Airball and FlyONSPEED will be working really closely together. The killer system is one that has both visuals and sound. We're excited to make aviation better and more fun, and we hope you enjoy watching the journey.

And again -- congratulations Vac and team! Stupendous job!!!!

HuVVer-AVI testing

I just got a HuVVer-AVI from a friend at Oshkosh (event recap to follow; this is just a quick technical note). It seems like a dandy little instrument platform that could be super useful. It is ESP32 based, and has no graphics acceleration or anti-aliasing of any sort. But it seems rather capable for what it is.

I messed with the code, and eventually got myself this very simple static demo of an "Airball" like display painting to the screen:

The loop() time for each paint iteration was 74 milliseconds. It is possible that the many arcs were taking lots of time to paint. By contrast, the following, which is one of the standard screens but with the colors flipped because I was messing with it:

takes 63 milliseconds to paint.

Currently, Airball operates at a 20fps update rate with time to spare, including saving and painting the last N raw "ball" images in fading color. It is clear to me that the HuVVer-AVI cannot maintain that kind of "instant feedback" feeling. It is an instrument, not a "virtual windsock" that flutters instantly with every little twitch.

But of course: is that important? It is to some people, and not to others. Is it important to our project? How does that compare to the fact that the HuVVer-AVI is very small, and is ready to use, made by someone else? I honestly don't know.

Wired probe mockup

In preparation for Oshkosh, I've been making some prototypes / mockups to discuss with people. The latest is a mockup of a wired probe -- using aluminum tubing (since we don't need WiFi to the probe). Here are a few photos. It's pretty amazingly lightweight, but I'm not going to weigh it till I get some .035 wall aluminum for the boom.

More mount design thoughts

The latest version of the adjustable strut mount seems to work fine but it has a tendency to be a bit wobbly and have some "hysteresis" in its alignment. First, here are some photos:

Now the hysteresis. Note in this video how the rear does not quite return to the exact same position when disturbed. This may be rectified partly by making the front part more rigid, but probably not quite. Now I'm thinking about solutions involving two items that "hug" the strut at 2 locations, with the variable structure in between them. Stay tuned.

One other thought is of course to just "give up" and add a hinge right behind the probe. I've been resisting this because it just re-iterates the problem of creating a reliable and stiff hinge, and it is not quite as easy to "boresight". But maybe this would indeed be the best....

Mount design is whupping my a**

In previous posts I've discussed trying to come up with a more rigid alternative strut mount -- one that does not rely on the RAM mount balls. This is because the RAM ball mounts can and do "slip" under load. They are good and useful and I plan to keep them as an option, but I'd like a more rigid alternative.

The design process has been truly a horror. Most difficult has been the angular adjustment. Making it out of 3D printed material is surprisingly hard, especially since the PETG I'm using these days has a really low friction coefficient, so any sort of frictional clamping, for example, the design below, seems doomed to failure:

Undaunted, I came up with a design that used a lot of interesting parts from McMaster, including a rod end bolt (https://www.mcmaster.com/2434K488/), binding barrels (https://www.mcmaster.com/99637A560/), and leveling washers (https://www.mcmaster.com/91944A027/). All told, this came to a hardware BOM only of about $75 per unit. Eek! This is what it looked like, just so you can behold it and then move on:

So then I decided to improvise with standard machine screws and washers and what not, to make the equivalent mechanism using "hardware store" parts. This was a mitigated success. This is what the design looks like:

This is what it looks like on the inside:

But now the problem is finding a way to clamp the tube into the forward area without crushing the plastic and without creating sharp protrusions that will cut into the bungee cords that hold the whole thing together. This is what the latest prototype looks like:

And just in case you're wondering, here's my scrap pile:

Wish me luck! :)

Spelling Bee

Sent to me by a friend today. See you all at Oshkosh!

Pew, pew, pew!

Just when you thought matters chez Airball could not get any more ridiculous, there's this:

So let's back up a little. On the front, there's the thru-bolt style probe prototype that we've been working on. Nothing new there. But the things with the spirit level are way weird, and the mounting stuff in the back is just zany. Let's take it one by one. First the mounting.

*  *  *

The RAM ball mounting is very versatile and strong. But, if you apply pressure to a RAM mount, it will slip and move to a new position before it breaks. For a mount for an iPad or something, that's a a feature. But for something where alignment is important, I'd actually rather the mount break first, to make it clear that it's been misaligned!

To that end, I've been thinking of making a more rigid mount. Because many wing struts are not necessarily perpendicular to the direction of airflow, I need at least 2 degrees of freedom to adjust, which I have chosen to be: rotating around the axis of the probe, and rotating side to side. The result is this mounting:

The verdict: Way too wobbly. The design needs to be more rigid. But the idea seems sound, and we'll keep plugging at it.

*  *  *f

Next, there's the matter of the gunsights. This is part of a procedure to boresight the probe. First, we sight down the fuselage of the aircraft at a distant object:

Then we look down the sights, which are arranged somewhat similarly to a tang sight (as popularized on the Sharps rifle) and are to be attached temporarily with rubber bands and aligned with the keel line of the probe:

We level the probe with the bubble level, and align it with the distant object. The slit design of the sights allows us to move our line of sight up and down as needed:

The result is that the probe is aligned in a vertical plane parallel to the centerline of the fuselage:

If things are reasonable, it should also be aligned along the angle-of-attack axis in a reasonable direction. It need not be perfectly "horizontal" relative to the wing because -- well -- there is not such thing really (what do you pick? zero-lift line? chord line? ...?). From that point on, we do a test flight to calibrate the important AoA points, like stall, best climb, best glide, etc.

*  *  *

Stay tuned as we work out the kinks from the mount design. We will likely maintain our RAM mount adapters because they are so darned convenient. But the more rigid mounts are, in our view, also promising.

And of course, with the probe mounted on the end of a "tube", for experimental airplanes, we can use Adel clamps to clamp the tube to the wingtip screws, as shown in this schematic:

And that is of course a bridge to a permanent, wired-in solution for experimental airplanes!

Progress with probe kit build

It's been a while since I've posted an update. Rest assured we've been working massively hard. :) For now, here's a bit of news about work I've done to -- hopefully ;) -- improve the way the probe is built and make it easier to put together.

The "new" design is a throwback to some of our earlier work, using four thru-bolts to hold the whole assembly together. The bolts are #4-40; previously we were using #6-32, which is honestly way too big. This solves a number of problems with previous designs --

1. Building 3D printed parts to axially locate the internals made these parts complicated.
2. Relying on the outer polycarbonate tube to hold things together meant that, during assembly, everything flopped around.
3. Drilling holes in the polycarbonate tube is nontrivial -- easy for a well-equipped shop, but not something that's easy for a kit builder to do.

The result is as you see. Meanwhile, notice that our new material of choice is translucent blue PETG, which has proven to be extremely good at reproducing detail. We have high hopes for this stuff.

These renderings show the probe from the outside, from the "top" and "bottom" (the battery is now on the bottom):

You can see how we have preserved the previous method of attaching to the mount, with the two screws with standoffs coming off the back -- except now, these screws are part of the continuous thru-bolt assembly going the entire length of the probe. Next, here is a detail of the temperature sensor board, which sandwiches in the 3D printed parts and will now be wired to a screw header terminal:

The pressure sensors are pretty much as before. Note that we are relying heavily on the plastic threaded and barbed connectors you may have seen us using previously:

The sharp-eyed among you might notice we only have 5 holes in the probe nose now; no "static" hole or static probe. This is a new result and one which we hope to talk more about soon. For the moment, we note that this is a really promising direction.

The assembly sequence is shown in the below photo album. Note how, once the thru bolts are assembled, the entire circuitry and plumbing are exposed to be worked on, after which the outer tube can be installed.

Assembly photo album