Wednesday, June 20, 2018

Insanely bright new display by Jeremy

Jeremy just sent me a couple of inflight photos of the new display prototype in full sunlight under a Diamond DA40 canopy over the California in the middle of the day. Behold the brightness:



It's brighter than his Garmin G1000. This is crucial since it allows our instrument to be a reliable situational awareness aid regardless of the conditions.

Monday, June 18, 2018

Airball vlog by Robert Sogomonian

Jeremy's and my friend Robert Sogomonian made a vlog of an interview and flight test with Airball! Check it out here:

https://www.youtube.com/watch?v=eUM8t8AWpxs

Friday, June 15, 2018

Stick and Rudder available online

The book Stick and Rudder, by William Langewiesche, is now out of copyright and available online! Check it out here:

https://archive.org/details/StickAndRudderAnExplanationOfTheArtOfFlying

We at Airball are huge fans! [*]

I believe that, if you cannot explain what you do to a smart 6th grader, you probably have no idea what you are doing. This has informed all my work, on the Airball project and elsewhere.

In Stick and Rudder, I believe we have the best application of that ethos to aviation. Mr Langewiesche manages to describe the phenomenon of flight correctly, but with nary an equation or unnecessary fancy term. In Chapter 7, "What the Airplane Wants to Do", starting on page 109, this is particularly evident -- he boils down what engineers model via differential equations into step-by-step explanations, pretending that time is broken up into tiny "slices" and imagining what happens at each slice and how it affects the next slice. This is technically acceptable at all levels -- it also happens to be the finite difference method for solving differential equations on a computer. But you would not see such needless name-dropping in the book. It's all focused on building intuition.

We believe that, if Mr Langewiesche were alive today, and based on illustrations like these in his book, he would be excited about Airball.




[*] -- The book, being a product of the 1940s, is rather condescending towards women pilots. We are most definitely not fans of that aspect of it.

Monday, June 11, 2018

How far Airball has come, and looking to the future

Way back in 2015, Ihab had already been thinking about measuring air data cheaply and accurately and had substantially designed the Airball probe as we have built it today.

In April 2015, he described his idea in An Inexpensive Operational Airdata Probe, laying out the basic probe design, and–more importantly–the math behind it. While the probe in that paper is assumed to be plumbed to its electronics sitting somewhere else (rather than sitting inside the probe as they do today), the basic design of the nose of the probe was exactly the same as our current Airball probes:



In June 2016, Ihab submitted his winning Airball entry for the 2015-2016 EAA Founder's Innovation Prize. In that entry, he built upon his 2015 design and included a proposed design for a (now somewhat ancient-looking "yellow submarine") probe, as well as his innovative "airball" method of displaying the air data. He also included a mock-up for pretty much what the display unit looks like today:


In December 2017, I joined Ihab to collaborate on making this thing an attached-to-wings reality. Together, we've continued to prove, improve, and build upon Ihab's original basic design to produce our current generation of air data probe (built by myself) combined with a prototype display unit (built by Ihab), which no longer need to be renderings because they actually exist and work in real life:



After several weeks of busy "crunch" time for Ihab and myself, reviewing and revising and writing about our efforts, we are proud to announce having submitted Airball again for this year's EAA Founder's Innovation Prize. In our new entry, we describe the technical improvements we've made, our ongoing development efforts, and the in-flight validation we've done. We also describe our plans for the future and where Airball can go from here.

Take a moment to read our Airball entry for the 2017-2018 EAA Founder's Innovation Prize – and let us know what you think!

We look forward to hopefully seeing many of you at EAA AirVenture Oshkosh next month!

Monday, May 28, 2018

Building a display

Here I'm going to show you the steps to building one of our latest displays. This is just commodity Raspberry Pi hardware in a 3D printed enclosure, but it may be interesting to readers to see what goes into the device. We start with all the components laid out:


There's a 4.3" HDMI LCD display; a Raspberry Pi 3; an XBee breakout board; an actual XBee with a u.FL to RP-SMA connector and a 2.4 GHz antenna; a pushbutton encoder; a 3D printed enclosure with standoffs and screws; and a RAM mount base with screws. We have already wired the XBee breakout board and the encoder to the solder pads on the LCD display, which are wired into the Raspberry Pi.

Next we assemble the XBee into its socket. We mate the Raspberry Pi to the LCD circuit, and attach the (clumsy, I know, I know...) HDMI connector:


We then insert this into the back of our case:


And then we add our screws and standoffs to secure the LCD into the case (this also holds in the Raspberry Pi):


We then insert the encoder into its matched slot in the case:


And tighten the panel nut on the opposite side:


We then attach the u.FL to RP-SMA wire in the case panel mount slot, and attach the u.FL connector to the XBee:


Meanwhile, we screw the RAM ball to the case back. Note that it has a grid of #8 holes allowing the base to be positioned as you need it:


We then put some 3M VHB tape on the back of the XBee breakout and mount it to the case back:


Finally, we screw on the case back from behind:


We then attach the antenna and press the knob onto the encoder shaft:


This also works with a stubby antenna, depending on how far your probe is from your display and what's between them. Here is Linux booting up:



And here is an Airball display showing strong wireless signal (the battery status monitor is not yet working):



Friday, May 25, 2018

Airball system #2 is alive

A couple of days ago, I unboxed two new probes from Jeremy:



Isn't that sweet looking? Wouldn't you love to get that in the mail after ordering it from Sporty's? Well ... maybe soon. :) Anyway, this evening I got the second complete Airball system up and running:


The probe portion consists of:
  • Jeremy's V4 probe board (with the Atmel microcontroller directly on the board -- no more Arduino breakout boards!)
  • An actual temperature sensor probe exposed to the air
  • A probe housing built by Jeremy, duplicating the 3D printed designs I made in my garage (we both have essentially the same 3D printer)
  • Improvements by Jeremy to the probe housing as detailed in his last blog post
The display portion is:
  • A Raspberry Pi
  • A 4.3" 480x272 LCD display (still the kind with the clunky HDMI connector)
  • A 3D printed case
The display dimensions and resolution are now the same as what we're planning for the more long-term, compact display that Jeremy is working on at the moment.

Note the wireless signal meter and battery gauge. The battery portion isn't quite working right yet, probably due to a software problem on my part, but the wireless signal meter seems to be doing a good job. Jeremy's new probe firmware sends battery status, and he prototyped some code to read the signal strength (RSSI) from the XBee that I incorporated into the display.

A local CFI has our first system and is trying it out with his students. Now we can have 2 more systems. So I need to build up a second display just like the above, and we'll have that!

Exciting times. Stay tuned!

Wednesday, May 23, 2018

Airball takes a 30-hour trip to Houston and back

In addition to working on Airball, I also volunteer with FIRST as a mentor for an FTC middle-school robotics team. Although our team did not make it to the World Championship this year, I decided to go anyway to watch, learn, and meet people. I live in Reno, and the event was in Houston – what better reason to fly my DA40 cross-country?

It's about 15 hours of flying time each way, and I planned to do it over two days each way – with Airball attached, of course!

Attaching an Airball probe to a DA40 tiedown point

The first problem to tackle was how to attach an Airball probe to my DA40 reliably and have it be easily removed, easily reinstalled, and not in the way of anything important. My previous flight with Airball used the tiedown point, but required replacing the tiedown eye bolt with a RAM ball mount. For the cross-country, I wanted to ensure the tiedown eye bolt was still usable even with Airball installed, so I redesigned the mounting system.

I decided on an Aluminum plate (3/8" 6061) shaped in an aesthetically-pleasing way with two holes drilled and tapped 1/4"-20 threads for RAM ball mounts, and a third through hole for the tiedown eye bolt:

A custom mount for DA40 wing tip tiedown bolts.

This mount allows up to two RAM ball mounted devices per wing tip tiedown, so Airball and a GoPro can co-exist as well.

Waterproofing my Airball probe

In building and collecting data from the Airball probe designs up to this point we had not been terribly concerned with waterproofing the probe, because our data collection flights were generally on really nice days. I put some thought into how to (at least nominally) waterproof my probe so that I would not have to worry about whether or not to attach the probe on any given flight, and wouldn't have to worry about it if I ended up IFR in some clouds.

There were a few things I could identify and pretty easily fix or modify on the probe to ensure it didn't get any substantial amount of water in it:
  • The nose and the part that attaches it to the acrylic tube (which are 3D printed in two separate parts due to their geometry) are attached to each other with small screws, but I also glued them together with CA glue.
  • I added rubber gaskets for the RAM quick attachment mounting hardware between the "saddle" part and the tube and between the "saddle" and the RAM mount.
  • I 3D printed custom hexagonal-shaped plugs for RAM bracket's screw/nut holes to limit any water ingress which could then get around the screw. (These could be glued in for more permanency and perfect waterproofing of that path, but I opted just to press-fit them into the holes as I don't expect any forced water ingress anyway and a drop or two of water won't hurt anything.)
  • I glued the static probe into its hole with CA glue, and plugged its set screw hole with foam which was also CA-glued in.
  • I sealed the gaps between the tube and the 3D-printed mount parts with kapton tape, so that they could still be disassembled if needed.
  • Finally, the tail part has a slot which allows charging the probe and turning it on and off so it could not be permanently or even semi-permanently sealed, but I opted to just cover it with electrical tape and see how it did in flight. It was fine!
These are the rubber gaskets on the RAM mount parts:

The Airball probe's mount "saddle" got some gaskets.

The full probe, ready for flight (I also added a nice information card inside the clear tube, with contact information in case the probe was lost for any reason):

A ready-to-fly Airball probe (after returning from the trip).

It worked well! We didn't get to fully test the waterproofing of the probe as there wasn't really any significant rain anywhere on our flight legs, but we went through a few clouds and got the probe misted pretty good, and it was rock solid.

A portable data logger

In order to collect data from about 30 hours of flying, I needed to get the Airball display into some sort of shape to be taken along in the plane without getting in the way. Unfortunately I ran out of time to get the actual Airball software up and running nicely, and given some recent software changes my probe wasn't talking to the Airball display software. However, I could run some logging software so that I could collect and log all of the flight data (which I can then compare to the data my Garmin G1000 logs, for comparison and validation purposes).

I needed to do a few things:

  • Get everything to fit in a small package. I made some 3D printed parts to hold the display and all the guts into a "sandwich" form factor that could be compact and sturdy enough to survive the plane trip intact.
  • The Raspberry Pi doesn't have a typical PC's battery-backed real-time clock, so I added a Maxim DS3231 added RTC module so that it could keep time between flights without internet access to do an NTP sync at every boot.
  • I added a radio antenna and mount which would, I hoped, maintain constant signal from the probe.

This is the prototype display that I ended up with (missing the antenna and RTC module, but otherwise complete and totally functional):

The prototype display's "sandwich" form factor.


I didn't have sufficient hardware or space to mount the display on the panel anywhere, so instead I tossed it into the back seat on top of my flight bag:

My prototype Airball display "lovingly" placed in the back seat.

The flight went well overall, and I look forward to sharing some of the data I collected!

We made a fuel and lunch stop in Sedona, where I captured this shot of the plane parked on the ramp – Airball is so small you can barely even see that it's attached, but there it is on the left wing:

My DA40 parked on the ramp at Sedona (KSEZ).

Monday, April 23, 2018

It happened, the moment...

As I blogged previously, last weekend, I did a couple of test flights with CFIs. On the last one, we were returning to the airport when the following happened --
  • I am not used to the C172's glide (I usually fly an Evektor SportStar) so I was too high on approach and had to cut power and burn altitude to get to pattern altitude.
  • The pattern was very busy.
  • The controller told us to make right traffic for runway 31 right, which seemed ok.
  • He also told us we were #3 behind a Citabria on 3 mile final.
  • And finally, to extend downwind, and he would call our base.
  • The CFI pointed out to me a water tower that was a 3 mile landmark out at our airport.
  • I squinted desperately wondering, which of these is the bloody water tower?
  • And I squinted some more wondering, where in the heck is the bloody Citabria?
  • We flew on and on, and I started wondering if the controller had forgotten about us.
  • I transmitted "Tower, Cessna 123, sequence" and hoped for the best.
  • I was (if I recall correctly) asked to remain on downwind.
  • I continued wondering where in the heck the bloody Citabria was.
  • Now we were approaching rather uncomfortably close to some hills, and the CFI pointed out that maybe it would be best not to fly straight into them, so perhaps I'd better turn base.
  • I started my turn right as the controller asked me to turn base.
  • And in so doing, the controller asked me to switch to runway 31 left.
  • I puttered along trying to make the turn, expecting the kind of performance I get from my usual Evektor SportStar.
  • I overshot base to final.
  • I had plenty of distance (I extended downwind halfway to the next county, if you recall), but I still needed to be careful to do it right.
Within all this commotion -- I think during my downwind to base turn -- I asked myself the quintessential question:

How am I flying the airplane?

And I glanced at the Airball on the panel and right there was my answer. Indicated airspeed where I expect it to be, AoA where I need it, and coordinated. One glance.

A couple of test flights

Over the past week, I did two test flights with two different CFI friends in Cessna 172s. The goal was to use the Airball system (V3 board, Raspberry Pi display) in a "real" flight setting and see what the CFIs reaction was, and how they thought it would help them teach.

CFI #1

This CFI was like, ok, this is great but what does it do? :) He noted that he usually teaches attitude flying. I replied, well, think of all the times when your attitude is not a good indication of your AoA. This lit a fire in his brain.....

The first thing he did was to completely botch a stall recovery, where he pointed the nose down at the ground, "panicked" that he ground was coming up at him, then pulled up again. And there we were, with the nose pointed down towards terra firma yet the AoA was right down in the stall region. Hah!

Next he proceeded to do a steep turn. And this was definitely within utility category limits and non-aerobatic, but it was steep. My jowls felt like they were going to sag down into my lap. And lo and behold, a "fat" airball that "sagged" down to a high AoA, which if we were not careful could lead to an accelerated stall. Hah!

He also tried some more commercial maneuvers including wingovers (half of a lazy-8) and noted that it was interesting to see the yaw in the maneuver very clearly displayed, without having to look down at the laggy, slow inclinometer ball.

We also did some more regular things like slow flight and stalls, and observed how the ball changed position.

CFI #2

This CFI is all about teaching AoA, and was quite happy to finally have an instrument that visualizes it. Thus enthused, we launched for a jaunt.

We spent a long time trying stuff out with the AoA monitor. He came up with the idea of using the ╬▒REF marker (the split circle) to mark a given flight condition, then try variations from that. This was brilliant and allowed us to figure out, for example, how the AoA changed when flaps were deployed, or observe the phugoid oscillation of the airplane if we pulled up flaps without trimming. We spent a long time messing around with the flaps and observing their effect on AoA and theorizing about what was going on.

Overall, he was excited about the possibilities and planned to try it out with some of his students.

On our return from this flight, something happened that is worthy of its own blog posting. Stay tuned....

Tuesday, April 3, 2018

Airball Probe v4 is alive – and flying!

A new version of the Airball Sensor Board

In Oopsie – but it's alive! back in January, I described the process of producing the Airball Sensor Board v3 (and the "oopsie" in the short-lived v2), which made a number of improvements from Ihab's initial design (retroactively named v1).

While Ihab has been busy testing the v3 boards, I've now produced Airball Sensor Board v4, which made a handful of important improvements and made the boards a LOT better:

  1. Integrated all necessary components from the Sparkfun Fio v3 which we were carrying on the previous boards in a socket. This allows us to reduce the size of the overall board stackup quite a bit and allows us to fix a number of issues with the Fio, and gives us more flexibility in laying out the board as well.
  2. Relocated the pressure sensors and re-arranged them.
  3. Replaced the (very tiny) TI TMP102 outside air temperature sensor with a bigger and more manageable TI TMP275.
  4. Integrated all battery charging and voltage regulation on the board (instead of the Fio) and added a new battery monitor chip to provide accurate voltage and charge/discharge rate from the LiPo battery, which I wrote about recently in Validating air data probe battery life – with data.
This is what the new boards look like when populated:


It takes a number of parts to assemble one:


When assembled with the new mechanical parts, it looks pretty nice! I hope you'll agree:


The internal plumbing is quite clean with the new design:

Flying my DA40 with my new Airball probe!

I took my DA40 up for a short flight to validate the probe (and the probe mount) that I built, to test radio reception, and to see if I couldn't collect some data to add to our growing data set and provide some new insights through analysis.

Here's a close up mounted to the plane:


And a glamor shot of the first Airball-equipped DA40 (at Carson City Airport):


Onwards and upwards!

Friday, March 23, 2018

Validating air data probe battery life – with data

Hello, world!

I've been hard at work on several aspects of Airball's air data sensor probe as well as the in-cockpit display unit. I recently received circuit boards for version 4 of the sensor probe. This new board fixes a lot of things, and adds several new bits of functionality... which I'll cover in another post. One of the things it adds, though, is a battery monitor chip (the Maxim DS2782), so we can now monitor the probe's battery status in real time.

Since I am now able to easily get high resolution battery voltage and current, it seemed like a good time to do a battery "rundown" test, and collect useful data. I wanted to validate a few things:
  1. The total useful runtime from a full charge. I had some ideas about what it ought to be, but I wanted to confirm that the math is not too far off base.
  2. How the probe behaves as the battery voltage drops.
  3. Whether the probe will safely cut off at any point, or just keep running and potentially damage the battery.
  4. Whether the battery monitor chip is working and sane.
The test went well, overall! For this test, I was using a 1 Ah LiPo battery from SparkFun and a XBee Pro 60 mW 802.15.4 radio. Here is the data collected:



Using this combination of battery and radio yielded at least 12 hours of usable runtime on a full charge – quite acceptable! And, the battery discharge curve looks exactly like it should for a LiPo battery. So I must be doing something right...

A few things still require follow-up, of course:

  • The runtime was actually longer than expected (we expected ~7.5h, but ran for about double that). The battery discharge rates (in both mA and mW) we saw aligned reasonably well with our predictions, but the battery capacity seemed to be much higher. I am not sure whether that is due to the battery cell having a higher capacity than advertised (maybe?!), or some other problem with the test setup, but more validation is needed.
  • Neither the battery itself nor any other component cut off the module at a safe low voltage level. (The battery should have a low voltage cutoff at 2.75V, but despite allowing it to discharge to 2.6V, it never cut off...) I will add some additional protection mechanisms (both software and hardware) to avoid over-discharge of the cell.
More to come soon about these air data probe improvements, and some brand new design work on the display unit!

Tuesday, March 13, 2018

Yaw consistency in flight test

Here we will analyze the yaw consistency of the flight test in this directory:

https://github.com/airball-aero/airball-embedded/tree/master/data/2018-03-09-01

Recall that we observed the positions of the Airball yaw indication, with the inclinometer centered, at the following locations:


The display is 480 px wide, so half of it is 240 px. We know the pixel sizes of the decorations -- they are laid out on a 20-pixel grid. And we know that full scale beta was +/- 15 degrees. So we can approximate the yaw angles that our probe computed at these conditions as:

cruise: (2.75 * 20) / 240 * 15 = 3.4 degrees
climb: (2.5 * 20) / 240 * 15 = 3.1 degrees
slow flight: (1 * 20) / 240 * 15 = 1.3 degrees

The total variation in yaw between cruise and slow flight is therefore (3.4 - 1.3) = 2.1 degrees.

Assuming that we did indeed center the ball properly in all conditions, this means we should expect, at that mounting location, to read about 2 degrees of yaw error as a result of speed variation.

Recall that this is with a "bad" mounting location that is really pretty close to the prop slipstream -- in fact, closer to the slipstream than the factory Pitot tube itself:


So for the Nth time, the question we're trying to answer here is: Is it a good idea for Airball to measure the angle of yaw directly, or is the flow near the airplane too disturbed, and should we instead settle for something like lateral acceleration normalized by our best guess of the free stream dynamic pressure?

My conclusion from this data is that we don't yet know. :) We should:

1. Try another test with the probe mounted farther outboard -- perhaps mounted a little distance vertically below the intersection of the strut and the wing.

2. In flight, play with the relative sensitivity of the Airball yaw measurement compared to the inclinometer ball, since theory says that, with reduced dynamic pressure, the inclinometer should get "mushy". Verify that the yaw deviation seen at slow flight is real.

3. Acquire some data where we correlate the probe inputs with a signal from an accelerometer. This should eliminate the pilot technique issues of trying to center the inclinometer then read the Airball location.

This should give us a bit more information to either validate our direct yaw measurement, or nudge us to do it indirectly instead.

Second flight test

We conducted a second flight test, in a Cessna 172M. The data folder is here, with lab notes included. We will be adding some blog posts about the interpretation of the data soon.

https://github.com/airball-aero/airball-embedded/tree/master/data/2018-03-09-01

Friday, March 9, 2018

Open Source!

We've been busy with this and that since our test flight, but we haven't blogged much. Rest assured, more news is on the way. We're hard at work on new probe mechanical parts and electronics, a new display, and a more powerful wireless connection.

But we do have a HUGE milestone for you: Our code is now officially Open Source under the MIT License! Check it out here:

https://github.com/airball-aero/

We are not yet quite sure of the best way to release our mechanical designs -- these are scattered around in SolidWorks, OnShape and Autodesk Fusion 360. But we're working on that. Otherwise, everything else about Airball, including Eagle files for our circuit designs, is in the repo!

Sunday, February 11, 2018

Yaw bias due to asymmetric mounting

One of the things we noticed when we flew yesterday is that the ball was consistently deflected left (i.e. showing the airplane yawed to the right) throughout the flight.

The probe was mounted on the right hand side of the plane. We can imagine the airflow probably looks something like this:



It's not surprising, therefore, that the probe "sees" an airflow that tends to come from the left.

The problem, though, is whether this "yaw bias" is consistent across flight conditions. If it is consistent, then for a given probe mounting position, on a given airplane, all we need do is add an offset in the display software, and we're done. If it's not consistent, then we need to do something more fancy.

We do have fancy tricks we can pull out, where we "fake out" a good-enough yaw reading using an accelerometer and scaling to the current IAS, but we'd rather not play these games. The closer we are to a simple glider yaw string, the better.

Now a word about estimating angle of yaw. It turns out (we describe this in our original 2016 paper) that the ratio of pressure difference between left and right holes and the pressure difference between center hole and static is a nondimensional quantity that, according to potential flow theory, is a predictor of yaw. (The same is true for upper and lower holes, and AoA.) It also turns out that the relationship to angle is very nearly linear, with a scaling factor of about 11.5 degrees for each unit of ratio difference. With that, we can do a very rough computation of angle of yaw based on our pressures, and this is what we'll be using here.

Our intention is to get a general clue as to whether we have a project, given our current setup, or whether we need to seriously go back to the drawing board.

My conclusion at the moment is that we still have a project. Let me show you the data. First, here is the center hole dynamic pressure plotted at the top, and rough-calculated angle of yaw below, for the entire test:


What a mess, right? When we're sitting on the ground, the data is all over the place. Notice though that, halfway into the first flight, we do some maneuvers, including slowing down (this is when we tried stalls). Zooming into this maneuvering period, we have:


This looks more like data, and you can see the near-constant offset of the yaw signal. If I had to guess, I'd say it's about negative 2.5 degrees or so. The question is how this yaw signal varied with conditions. We can zoom into the area near the left of the plot where we are slowing down graduallyin preparation for the stall to see more:


There is a trend towards the right-yaw signal correcting to the left towards the low end of the speed region -- but is that real yaw that happened as we slowed down?

Finally, for this section of the data, we can plot center hole dynamic pressure versus yaw to see if there's a correlation:
Clearly there is some sort of correlation. It seems to go from a rough average of about -3.2 degrees at high speed to -2 degrees at low speed, a difference of 1.2 degrees. Again, I have no idea if this is a variation in actual yaw or the "fake" yaw due to our mounting.


In the big picture, we are building an operational instrument for pilots, not a flight test instrument. The gold standard for a flight-test-worthy airdata probe is a large boom that sticks out in front of the airplane. We can't tell every pilot to install one of those. So what's good enough for piloting?

While this question remains open, we certainly can do more data acquisition to study this issue. There are various avenues, at least a few of which are:

  • Trying out various installation locations on the same airplane;
  • Trying maneuvers with an experienced pilot remaining coordinated, and looking for correlations in that data; and
  • Acquiring data from an accelerometer and correlating with our yaw signal.
One more thing that's worth mentioning is that the standard inclinometer ball is already "wrong". For  a given angle of yaw, the ball is less sensitive at lower airspeeds (in fact its sensitivity should follow the square of the airspeed, so the difference is not trivial). Our yaw signal should be scaled properly at all airspeeds -- and it does not lose sensitivity at the low speeds when you need it most.

We hope to figure out what is the "best" yaw estimation method given convenient mounting on everyday airplanes. It might be our current aero-derived yaw, or it may be something else. Stay tuned!

Saturday, February 10, 2018

Successful first test flight

Well we did it! Thanks to my friend KC Budd who flew our hardware on his Cessna 172, N2720L, we have a successful first flight!

We flew KPAO KHAF, stopped for lunch, then returned KHAF KPAO. The air was pretty bumpy in places, over the hills and near the ground at KHAF. We did enough maneuvering to calibrate the fiducials on the Airball display, and observed how it performed in stalls.

Now the main goal of this test was to see if we have a project, or if we're barking up the wrong tree. I had no idea what the actual data would look like -- the AoA and yaw may be so bunched up on one end of the scale or the other that it would be useless. The airspeed feedback due to the ball size may be bogus. The whole concept may be bogus. Who knows until you've tried it, right? I have done some testing on the old Android app with my other friend's RV-9A, getting data from his Dynon avionics, but this was the first time with an actual probe -- and a homemade one at that. Would this be a complete dud and should we pursue something else, like quilting?

Well so KC's initial feedback is that, to a first approximation, we have a project. I concur, but then I'm obviously highly motivated. :) The AoA varied enough in all phases of flight to give useful feedback, and the airspeed feedback from the ball size helped situate us. Climbing at Vy with the AoA pegged on the Vy symbol was pretty cool. Cruise looked like cruise. Stalling looked like you'd expect.

There is still some human factors work to be done to determine if applying some nonlinear transform to the vertical scale a little bit would make it more information-dense, but for now, this thing looks like data rather than nonsense. May it continue to be so.

There are videos, which I'll link to as soon as they are uploaded from my phone.

This is our route (outbound and return). You can see the wiggling we did outbound, which was when we were testing stalls and calibrating the display:


This is what the data for the whole flight looks like. About 2/3 of the way through you can see a sudden vertical drop in temperature; this is when we switched the system off at KHAF and went to eat lunch, then came back, switched it on, and flew home:


I will be analyzing this data and posting updates as I go. One thing that was interesting is that there was a yaw "bias" in the instrument, which caused us to always be off-center. My assumption is that this was due to a combination of the flow field around the fuselage, and the mounting of the probe. It was therefore hard to try out the slip indication. One important question will be whether a constant offset can indeed correct for this bias, or if it's nontrivially related to airspeed, power setting and other factors.

Here is the back of my car as I got all my stuff together:


Eventually I got the probe mounted. You might recognize the mount from the renderings I posted yesterday. This mount worked really well and was very rigid. I'm going to make a couple of improvements to it then post the design here, and the 3D printed parts on Thingiverse, since it might be useful to some people in its own right:






We mounted the display on the windshield with a Ram suction mount:


And here we are flying (note the yaw bias):


Here is the probe flying over the ocean:


It also works over mountains:


And it can even work near the coastline, in between ocean and mountains:


which surely you must agree makes it a very versatile probe indeed! :)

More soon; stay tuned!