Saturday, April 11, 2020

Display form factor and electronics investigations

The state of the art for our displays remains Jeremy's new and improved, fully custom, and very compact Airball display. This design has everything we need -- bright screen; real-time clock; enough processing power and memory; the works.

As we have used our system in regular flight, however, we have discovered that the Airball use case does not require frequent manipulation of a control knob. This is not a GPS where you constantly need to pan and zoom and enter waypoints. Aside from initial calibration, there are two functions that are done regularly:
  1. Change screen brightness; and
  2. Change the altimeter setting.
It's perfectly okay to have "up/down" buttons for each of these, rather than a nice ergonomic encoder knob. And with that, it's possible to save some valuable front-panel space.

The culmination of this thinking is the following rough mockup:




Note we have a row of 5 buttons across the top, which take hardly any space at all. The remainder is just barely larger than the LCD display itself. There remains plenty of space on the PCB for our Raspberry Pi Compute Module 3, and any other electronics we might need. And without the knobs adding thickness, we can make the whole assembly very thin.

So -- this may seem like a step "back" in ergonomic goodness, losing the nice chunky aviation-feeling knob, but we feel it's a step forward in general usability in a cramped cockpit.

*  *  *

Now as for the innards, these will have to change somewhat. We are now going to need to use Wi-Fi rather than the XBee modules. The Raspberry Pi Compute Module 3 does not contain on-board Wi-Fi. We have two options, actually, which differ somewhat subtly....

The first option is to add to the board some sort of embedded processor that is Wi-Fi capable and which lets us grab the data we need. For example, we could embed an ESP32-WROOM-32U and have the Raspberry Pi "program" it on the fly using a USB connection, and somehow use it to grab the Airball data. This is completely possible and will definitely work.

But a second, better option is to add a Wi-Fi processor that the Linux distro and device drivers on the Raspberry Pi can recognize as a generic Wi-Fi adapter and use natively. That way the Wi-Fi connection could be better for general purpose use. Including uses that we might not ever have thought of -- I mean, if other folks can use this display for their own projects, for whatever reason, this just adds to our own economy of scale and makes the world a better place. Right?

So this second direction has us looking at stuff like a TI WiLink adapter connected to the Raspberry Pi Compute Module 3 via its SDIO interface. If we can get that working, it would be far preferable. The one problem with the TI WiLink modules is that they do not have an on-board u.FL connector for the RF -- they break that out as a pad on the module, and you must build your own antenna. I think that this still means we can consider our system to be "pre-certified", and it's not rocket surgery to create a tiny trace leading to a u.FL connector on the board we design ... but it's something we need to think carefully about.

*  *  *

While on the topic of display electronics, we thought somewhat about whether we should try to go with a BeagleBoard Black base rather than our current Raspberry Pi. The BBB has many advantages. For one thing, it breaks out "raw" LCD panel outputs from the board itself, whereas the Raspberry Pi (even the Compute Module 3) produce HDMI outputs, and we need an HDMI decoder to turn that into raw LCD signals. Also, at some point, we can simply embed the Octavo OSD335x System-in-Package in our system, which would contain pretty much everything we need and would be super compact!

We did some early comparisons of the performance of a BBB and a Raspberry Pi 3+.

This is a video of the BBB showing about 14 frames per second drawing Airball in an X11 environment. For comparison, this is a video of a Raspberry Pi 3+ showing about 23 frames per second on the same task. So the Pi gets about 164% of the performance of the BBB given these constraints. That's one data point.

We tried to run our Airball software with the Linux framebuffer on our BBB, but it locked up. We were not able to get it to run at all. We had that trouble a couple years ago, and things have apparently not changed. We are not doing anything "weird" in our software, so strike one against the BBB, from a viewpoint of just amorphous technical risk if nothing else.

Finally, we ran our Raspberry Pi 3+ with the framebuffer, with an 800x600 screen. Note that this will be slow than our regular 480x272 display, because even if we are not painting the whole 800x600 buffer, we still have to ship it in an out of display memory. But that was the test setup we had, in any case, and this is a video of it running at 16.5 frames per second.

Now recall that we are sending data from our probe at 20 Hz, and we really don't want to go below 20 frames per second so as to maintain the illusion of a smooth "analog" instrument. We therefore conclude that:
  1. We are not confident that the BBB / Octavo 335x will give us adequate performance;
  2. As best we can tell, we are probably pushing the display performance with our application anyway, so we can't afford to slack off;
  3. The BBB / Octavo 335x has shown nontrivial technical risk due to framebuffer crashes;
  4. The Raspberry Pi is updated constantly with new models, whereas the BBB has stagnated somewhat;
  5. The Raspberry Pi is more popular in the usual hobby circles, and in particular in aviation hacking (note the "Stratux" ADS/B receiver, for example); but mainly
  6. We already have a super performant and super compact Raspberry Pi Compute Module 3 design that Jeremy created, and any modifications we need to make to it are minor.
Our decision therefore is to continue to pursue the Raspberry Pi Compute Module 3 design. Maybe there will be a time when we need a super lightweight, super small Airball display, and we can revisit the possibility of using some other processor. But for now, we believe we have done our due diligence and should proceed as previous with the excellent design that Jeremy created.

*  *  *

One of the thoughts we have is, what about other output modalities? Folks are working on giving air data information to the pilot using haptics, sound, and any of a number of other things we haven't even thought of yet. Can we support these use cases? If so, then how?

The easiest way we can do that is to provide a series of GPIO pinouts in our new display board, arranged so that they can be populated with 0.1" screw terminal blocks or any other kind of connection that someone might like to think of. It's not yet 100% clear where or how, but basically, if there is a convenient I/O from the Raspberry Pi Compute Module 3, and we are not already using it, we should consider making it accessible as a simple pinout.

Probe mechanical form factor investigations

Recall from our posting Ideas for a next-generation probe that we were thinking of going to a 1-inch diameter tube for our new probe, since the new ESP32 hardware is compact enough to let us get away with it. We have done a lot of thinking about this, and we'll share some of it.

We have been sheltering in place from COVID-19, and so our planned test flight schedule has been severely curtailed. This kind of work -- thinking and prototyping at home -- is still possible, though.

The quick summary is that this geometry imposes some difficult constraints that would be just fine if we were building some production device in a factory, but may conflict with our goal of making a probe design that anyone can easily reproduce from first principles in their home workshop. And so, this being still early in our development of Airball, we have rejected it in favor of our 2-inch diameter geometry. But we have some cool ideas for that, which you might find exciting. So read on.

It is important to understand our design constraints. We can build "anything" if we assume we have a factory producing stuff in volume, with injection molding and custom metal stampings and what not. But we don't. Our self-imposed constraints are:
  1. Our design can be built from scratch using a commodity 3D printer and readily available parts. The builder will need to order a 2-layer PCB, perhaps with a paste stencil, and do a surface-mount assembly of the components.
  2. Our design can be built from a kit by a hobbyist using screwdrivers, small wrenches, pliers, a commodity electric drill, sandpaper, and possibly CA glue ("Super glue"). The kit builder must not be required to do any soldering.
  3. Our kit can be constructed via a farm of commodity 3D printers, and PCBs ordered pre-stuffed from a small volume assembly shop, with possible lightweight post-production operations like soldering on headers, connectors, or large-tolerance surface-mounted parts.

*  *  *

Recall that our new 1-inch probe started out with this idea:

This is all well and fine, but it required electronics in front of the battery (the sensors connected to the front nose) as well as electronics behind the battery (the connections for USB and the on/off switch, and perhaps also the temperature probe). How to hook all that up was up in the air.

Building ad hoc soldered wires between components like jacks and switches is always hard. And wires fatigue where they are joined to things, and eventually break. So really, we were talking about having two designs, which we will discuss in sequence. The first is to have two circuit boards, one in front of the battery and one behind it, connected via something like an FPC cable. (Standard ribbon connectors are way too bulky.)

This is the state of the art of where that design ended up. Note the 3D printed supports for the forward and rear circuit boards. Note how the battery is suspended inside the tube, and there is room for an FPC inter-board cable to slip into a slot beside it. Note also the fact that the rear board projects out of the housing and carries at its tip a tiny temperature sensor chip (e.g. a TI TMP102) so that we an do away with all random wiring. The rear board also contains the on/off switch and the USB connection. The printed circuit board can be single-sided from the factory to save money; the pressure sensors are easy to solder onto the second side and can be done as a separate step.



We fabricated some parts of this design and put them together briefly, and the parts looked like this:



Mechanically, everything worked out fine. There were two problems, though.

The first was the inter-board connection. We spent a bunch of time looking at FPC cables and connectors, and thinking through how this might actually work out. It's a bit of a finicky business, but it is not insurmountable. The number of connections to the rear board would actually be nontrivial; we would need:
  • Power: GND, USB VIN
  • USB data: D+, D-
  • Power switch: A, B
  • Temperature sensor I2C: SDA, SCL
This is 8 signals, meaning we'd end up with a 10-conductor FPC cable. It would all fit, but it would be finicky and customized. We could not see an easy way that the front or rear board could be "re-used" in a different design; at least not without some crazy hackery. So anyway.

The next thought was to try to consolidate the boards, and instead of sneaking electric signals past the battery, to instead sneek pneumatic connections past it. This caused us to investigate a whole family of designs that looked somewhat like this:




In these, the battery is pushed off to one side of the tube to make room for the six plastic hoses needed to get the six independent pressure signals to the (now, unitary) PCB on the back. We prototyped this, and it looked something like this:


 


Using 1/8" diameter plastic tubes, the fit was very tight. Not impossible, mind you, but tight. As a solution, we could go to a smaller tube, e.g., this 3/32" diameter Tygon tubing.

We investigated using the 3D printed parts themselves as conduits for the pressures, by building long channels into them:


In the end, the conclusion is that this is all possible, but it requires a bunch of engineering and testing to get it to work right. It is definitely an optimization.

Now as to the electrical connections to the battery. Clearly we cannot fit a simple 18650 battery holder into the tube. We must solder to the battery, or devise some sort of spring-loaded contact of our own. Soldering wires directly to the battery is possible, but it invites fatigue at the solder joints. 18650 batteries come with solder tabs, but we'd have to figure out how to finagle these into our overall design with the appropriate clearances. We'd also need to make sure we are not relying on a single boutique design of 18650 battery with tabs that are just so, and which could kill our design if it were discontinued.

Based on all of this, we decided (and it's a difficult decision, believe me!) to set aside our 1 inch diameter probe ambitions for the time being. This does not mean never. But our first kits will be built around our 2 inch "caliber".

*  *  *

To that end, we've returned to thinking about how we'd make things work. This is a very early snapshot of our arrangement:


Now we have lots of room for a standard 18650 battery carrier on one side of the board, and plenty of room for getting tubes to the sensors on the other side. This looks much more like a design that anyone can put together easily, without being too error-prone, and which is more likely to succeed at its mission rather than try to achieve premature optimality.

In this design, the circuit board length is bounded by the length of the battery and its carrier, which means the circuit board is 3.5 inches long. We end up with something still much more compact than what our earlier prototypes.

Again note how we have extended a little proboscis from our main PCB to carry our temperature sensor. We may or may not continue this trend. The thing is, with more space on the PCB, and more room in the probe overall, we can afford to have more "generic" connection options for I2C or 1Wire temperature sensors. We may even be able to use a standard Sparkfun TMP102 Breakout as our temperature sensor daughterboard, building strain relief and housings for it as appropriate in the 3D printed parts. Simple and easy is better than complex and hard at the moment.

*  *  *

With the decision to go with a 2 inch "caliber" probe, we now have a stubbier probe. This means that our bulky snap-off mounting that we've been using is going to be very close to the probe nose, and might disturb the airflow. Without doing wind-tunnel testing, we know that less disturbance is better than more. So if we can get our mounting behind the probe, away from the nose, this is likely to make things better, or at worst be neutral.

Our basic requirement from our mounting is what firearms people call a "return to zero" mount -- when put back together, it should maintain its original direction. It can move forwards and backwards along that direction a little bit, but the direction is what's important. This led us to think of some sort of Picatinny rail along with a quick release Pic rail mount. There are even plans for a 3D printed Pic rail quick release out there! We thought about building a back cover for the probe that incorporates a Pic rail shape:


Ultimately, though, this all seemed like lots of work. The sweet spot would be for the Pic rail to be mounted on top of the probe tube, but we already decided we don't want that because it interferes with the airflow. So we decided to set aside the Pic rail options for a while, regardless of how nice it would have been to somehow unify the aviation and firearms universes for a brief moment.

Our current best guess is screws on the back, and a slotted back plate that carries a RAM mount ball:






A screw with a 3D printed thumb knob goes into the bottom hole to secure and tighten up the arrangement.

This basically precludes sticking things like a temperature sensor "proboscis" out the back of the probe. This is okay. Our current idea is that we will embed our temperature sensor stuff, whatever that is, into some 3D printed parts that form part of the probe nose. It should be easy to make the nose half an inch longer and make a "pocket" of some sort within it so that air can circulate around a temperature sensor, yet not interrupt the outside radius of the probe as a whole. With the new-found flexibility in space that the 2 inch "caliber" gives us, we believe we can make this happen.

*  *  *

In the process of redesigning the nose, we are again looking into "design for kit-ability". Our current direction is to move away from extremely complicated 3D printed holes in the nose, and towards holes that have fewer kinks and can therefore easily be cleared of debris by a hobbyist using a pin or wire or some other simple manner. This means that we may be going to a "stacked manifold" design as we reported in our blog post from 2 years ago, Probe nose progress. The advantage of these kinds of designs is that they can also easily be machined or injection molded -- they do not rely for their feasibility on the ability to 3D print "impossible to machine" shapes.

Stay tuned for more progress on our designs!

Saturday, March 28, 2020

ESP32 probe ongoing programming

After some digging around, I decided to change the ESP32 probe's protocol to TCP rather than UDP, at least for this initial stage, to ensure that we got a reliable stream of messages, and any unreliability would be more correlated with something in the probe itself. As usual, check out our code in the airball_probe_es32 directory in our repo.

The innards of the probe are now on a piece of plywood, and they look like the below. Given that what you see is all we need, this should all be quite easy to integrate into the 1-inch diameter new probe form factor.


The Wi-Fi RF performance seems excellent. I put this stuff all the way across my yard and behind the house, covered with a large metal garden dustpan, and I still got really good quality reception from my computer's Wi-Fi. That's very encouraging.

In other good news, if the battery monitor is to be believed, we draw about 170 mA when operating normally. With a 3400 mAH battery, that's about 20 hours of life. If we de-rate this to protect the battery, we still can expect a safe 12 hour battery life, which is my metric for, basically, "all day long". This means that a pilot or CFI can plop the probe onto their plane in the morning, fly around without paying any attention to it, and pull it out and put it on the charger in the evening.

Less encouraging is that, for some reason, I now seem to be having power supply issues, which cause flakey performance of the sensors and the Wi-Fi. Now it worked previously just fine, so I assume my wiring is crappy or I need decoupling caps, or some combination. But in any case, before we call the circuit done, I need to make sure these gremlins are no longer there, and learn what mitigations, if any, I need.

Sunday, March 22, 2020

ESP32 probe code complete

Yesterday, I got the ESP32 version of the probe up and running with the following setup:

The code is in the firmware/airball_probe_esp32/ directory of our repo. This verifies that we can connect to our SPI and I2C sensors and get battery statistics over I2C, and broadcast the results by establishing a WiFi base station and broadcasting UDP packets on a well-known port.

The ESP32-DevKitC bundles a lot of the USB and power regulation machinery together, and uses an obsolete USB part, so I am hoping to bench-test a more stripped-down setup before spinning up a custom PCB. To that end, I need access to the individual pinouts of a raw ESP32-WROOM-32U module, and so this is what I made:


I will be reporting more on the following --
  1. Verifying data rates and reliability with the UDP transport.
  2. Battery charge time and battery life with the new battery.
  3. Results of trying out the more stripped-down ESP32 setup.

If this all checks out, then we are well on our way to a really compact, and relatively low-cost, version of our probe electronics. Stay tuned!

Sunday, March 15, 2020

Calibration curves in the ESP32

Given that I'm planning a transition to the ESP32-WROOM-32U, I'm going to have way more memory to play with than I had before. That means I can embed calibration surfaces (see the last blog post...) directly into the probe, without having to come up with a fancy curve-fit to save memory!

This weekend, holed up in the house due to COVID-19 and grounded due to rainy and cloudy weather, I have been doing just that. The results (ongoing) live in the airball-probe-esp32 directory of our Github repo. Just one function call that does 3 table interpolations is enough to turn the three pressures, (dp0, dpa, dpb), into the three airdata parameters, (α, β, q).

The calibration tables are currently generated based on potential flow formulae, in Python. Of course a future, and better, implementation would be to derive these from wind-tunnel data. But the beauty of this is that we will have verified the entire stack, execution speed, memory usage, etc., and will just swap in some numbers in place of others.

Stay tuned for some hardware prototyping with the ESP32-WROOM-32U next!

Saturday, March 7, 2020

Quick flow math for new probe nose

Per my previous post, I have been thinking about getting rid of the static pressure tube just using an extra hole in the front "ball" nose. The following is some simple back-of-the-envelope math to see if that is likely to work.

First let's describe our setting. We plan to add a 6th hole 90 degrees from the centerline, at the bottom of the probe, as follows:



You can see that we measure pressures dpα and dpβ as usual, but dp0 is now between the center hole and our new 6th hole in the 90-degree position.

Using the standard potential flow formula for a sphere, we came up with the expected pressure ratios, to see if we are likely to get good data or if we'll have nasty singularities. The good news is that all seems promising.

We will plot various values for a range of α and β of ± 25 degrees. The color in the following plots is a measure of total angular distance from the centerline, to help with visualizing the surfaces.

First, let us plot the actual pressure differences measured by the sensors, in relation to the free stream dynamic pressure q. We plot (dp0 / q), (dpα / q) and (dpβ / q):



The ratios are all reasonable and there are no surprises. (dp0 / q) is around [1.0, 2.5], and (dpα / q) and (dpβ / q) are both in the range [-1.5, 1.5]. In particular, (dp0 / q) is a reasonably solid value and will not be close to a divide-by-zero

Now we plot our pressure ratios that we will use to calculate α and β, (dpα / dp0) and (dpβ / dp0), to see if there is a clear signal:


The range in both cases is about [-1.5, 1.5] and approximately linear. That is very good.

We conclude that this probe nose design is well worth pursuing. The pesky static pressure rod is a pain in the neck to mount, and it makes our probes a lot more bulky. It would be awesome to get rid of it!

Sunday, February 16, 2020

Ideas for a next-generation probe

Losing the static probe

I have a friend who is an aeronautical engineer at nearby NASA Ames, at Moffett Field. He's been a great resource in helping me think about my probe. He has designed 5-hole and 9-hole alpha/beta probes for the NASA Orion spacecraft, so this sort of thing is not new to him.

Based on his feedback and my flight test data, it's clear I'll likely need to do some sort of calibration of the probe, based either on CFD simulations or wind-tunnel data, or a combination of both. Luckily, my Reynolds number range is not huge, so I should be able to get some pressure ratio calibration that will work for my entire range of dynamic pressures.

He has pointed out to me that, since I'm all in on calibration anyway, I don't technically need this bulky static pressure probe sticking out. I could measure any additional pressure between any of the holes on the ball nose. All I need is 3 pressures, to determine 3 unknowns (α, β, q). Once I determine q, I can subtract that from whatever the barometer reading is, from whichever probe hole I choose to connect it to, and get a "true" barometric reading.

Discovering the ESP32-WROOM-32U

While I was living under a rock, the world has gone all in on ESP8266 processors and Wi-Fi "Internet of Things" modules. The next step from there on is the ESP32-WROOM-32U which has lots of memory, can be programmed via the Arduino IDE, and comes with all the Wi-Fi I need. And it costs $4.50 per part. Yes, you read that right.

With all that memory, I can afford to embed the calibration tables in the probe itself, meaning that anyone can grab the probe, connect to Wi-Fi, and receive data sentences at 20 Hz in the form:

$AR,α,β,q,p,T

where:

α = angle of attack
β = angle of yaw
q = dynamic pressure
p = barometric pressure
T = temperature

This means that people don't need to use "my" host Raspberry Pi software to get immediate, useable airdata.

A smaller form factor

Given all the above, it should be possible to fit the whole thing into a 1 inch diameter by about 8+ inch long housing, still with the transparent polycarbonate tube that is our trademark. :) If we add a USB interface, it should be possible for someone to get a probe, put it together, and then program it with the Arduino IDE themselves without having to take it back apart!

Recall we got ~ 12 hours of battery life with a 1 Ah LiPo battery. With a 3.2 Ah 18650 battery, regardless of how much power the ESP32 consumes to transmit on WiFi, it is very likely we could get similar if not better battery life.

The installation flexibility of such a small package would be awesome! You could simply zip-tie it to any sort of "curved" mounting ... we would not need to add any screw holes.


Wired installation

To install this in a wired fashion, we have an ongoing to-do item to prototype an RS-485 driver. With that and a standard R/C airplane "battery eliminator circuit" to step down the ship 12VDC to something near 5V, which we could then down-regulate to 3.3V, we'd have a wired system with the comms going over a single twisted pair. More on our experiments with that soon.

Of course you might ask: But the wired probe will not need Wi-Fi. Will you use a different microprocessor so that you don't waste all that Wi-Fi functionality? To which I answer: $4.50. I can afford to standardize on the part with the integrated Wi-Fi and just ignore the Wi-Fi, and it's still cheaper than most of my alternatives.

New "V block" mount in progress

One of the contributions of the Airballs to the universe is ways of mounting reasonably lightweight, compact junk to your plane in a secure but "tool free" manner. Our mounts so far have been 3D printed to the exact contours of the struts. We have versions for a Citabria, Super Decathlon, C172, and RANS S-6S.

This arrangement is very secure, but leads to a rather bulky 3D printed chunk though, and may not be universally applicable. This has led us to consider a more generic "V block" shape, where we augment the 3D printed parts with a piece of aluminum angle and add some padding. This is what we have so far. It seems just as secure as the custom-contoured version. Stay tuned for more details.





The "pitch string"

Yesterday I tried out this idea I've had for a while -- the "pitch string":


I attached a piece of fishing line vertically down the airplane's centerline, with tiny beads on it every 2 inches. Now this may not be the case for everyone, but for me, if I focus on the horizon, I see two equally clear images of the string (due to parallax). My aiming point is halfway in between them. So I can use these to watch the movement of the nose as I bank into turns, and keep track of the pitch of the airplane relative to the horizon.

My contention is that something like the pitch string, plus Airball, is the ideal setup for VFR flight instruction.

Already, even after all these hours of flight (well -- I mean, 300 hours is not a lot, but it's something), it helped me notice how I need to raise the nose in turns, and be more aware of adverse yaw. My CFIs always told me to pick a point on the nose or windshield and use it as a reference. However, without specific instruction as to which point to pick, I think my eyes tend to wander and I become more heads-down. Something that gives me a specific thing to focus on is super helpful.

An improvement may be that, instead of equally spaced beads, it should have just one "bead" that the pilot can move up and down to act as a reference. For training airplanes used by many people, I can imagine a "ruler" aligned edgewise so it doesn't obscure the view, but with graduations on it so each pilot can reset the "bead" to their preferred location, might be a useful thing.

Saturday, February 15, 2020

New probe is very consistent with existing ones

Today I did a flight with one of our new probes. Compare the "new" one (top) with the "old" one (bottom) here:



You can see that the new one has a bit of a longer static tube, but is otherwise quite similar to the old one. The readings are super consistent with what we had before. This graph shows the data from the old probe in two separate experiments, versus the new probe:


So basically, anyone can build a probe according to our specs with their 3D printer and some electronic muckery, plop it on their plane, and without any additional messing around, get consistent results. This is HUGE. :)

The next step is calibration, of course. More on that soon.

Sunday, February 9, 2020

Sunday, February 2, 2020

Two more systems!

As of last night, after diverse trials and tribulations, we have two more Airball systems:


Apart from the various noodling around we've been doing with verifying the airdata on the plane, the problems with this particular build-up is that we seem to have gotten a bad batch of TCA9548A I2C mux chips, and messing with that issue wasted a bunch of time. But we're back on track, and newly confident that, if we assemble our things right, they actually do work properly. Yay.

The first system we hope to give to a friend who has a background in aeronautical human factors, and it looks something like this:


You can see the probe and display, obviously, and our current prototype for our "V block" shaped strut clamp that should be compatible with a large variety of airplanes.

Stay tuned for more news!

Monday, January 20, 2020

Integration test using water manometer

If you follow this blog, you know that we've done extensive water manometer testing of our system, especially the pressure sensors. However, in our quest to knock off hypotheses about the IAS discrepancy in N291DR (and as a way to, coincidentally, also build confidence in the components of our system), we decided to do a quick water manometer test of the whole system. Sort of like an integration test. Never hurts.

Sorry that we don't have pictures for this one ;) but what we did is apply pressure to the dp0 sensor of the probe, in inches of water, and read off the IAS from the cockpit display. This tests the whole thing -- end to end. If we convert applied pressure to IAS in knots, and compare to the reading on the instrument, we conclude that the full system is working correctly.

Probe position is not responsible for IAS problem

Continuing our experimentation, I decided to mount the probe on the end of a 3/4" fiberglass pole securely fastened to the struts of N291DR. Here are a few pictures of the mounting:








The result is that, while our AoA numbers near stall decreased (expected since the probe is relatively free from upwash effects), our IAS readings remained consistent. This is a graph of the results:


Note that, at low IAS, we report numbers higher than the N291DR instrument. This is to be expected. We are compensating for AoA and yaw angle, whereas N291DR's instrument is just a simple tube sticking out into the wind. At high angles, N291DR's instrument will read low.

The mystery continues. The next thing is to do a proper calibration using a quadrangle course with ground speeds and record the results. At this point we're just knocking hypotheses off the list, and some may argue we should have done that before doing the probe on the long pole experiment, but this yielded interesting results in and of itself. It taught us that, while the AoA values change, the IAS numbers remain pretty consistent regardless of where we stick our probe.

We did capture a video of the approach to a stall, which you might find interesting. Check it out here.