Sunday, September 1, 2019

Data smoothing in the Airball UX

Today I made a bunch of additions to the source code that smoothed the Airball display. But we also retain the instantaneous data that shows the range of turbulence being encountered. Here's how we do it. We will demonstrate by running the UI using some previously stored flight data.

First the takeoff:

Notice how the ball is stabilized, but there is a much fainter "trail" of the instantaneous data (we are showing the past 20 instantaneous data values, with brightness diminishing from 3/8 of the full brightness down to zero based on recency). Here's the landing:

The point here again is to show a stable value that you can "fly with" in turbulence, but also show the span of the wiggles.

Sunday, August 25, 2019

A successful data gathering flight at last...

Yesterday I made a small contraption to put the Airball display in the panel of N291DR, with a hole for a USB wire and a RAM EZY-Mount:

As you can see, the location of the display allowed me to compare the inclinometer and the Airball airdata-derived yaw quite easily.

The probe was mounted as usual, using our 3D printed mounts on the strut, extending near the leading edge. And this probe has an autozero function built into the firmware.

The system worked pretty well, actually.

The first thing to notice is that airdata derived yaw was well correlated with the inclinometer. Yay! Obviously we need more data but this is really good news. I am ready to say that our yaw errors were basically zero offset problems that are solved by a simple startup autozero.

Secondly, airdata derived yaw was more sensitive than the inclinometer. We expected that, hoping that Airball would act as a "digital yaw string". It appears to do so.

Here is a bouncy phone video of Airball in some bumpy air:

I believe there is a "phase lag" caused by a delay which is in turn caused by our inadequate baud rate from probe to display -- I didn't have time to fix that yet.

Here is a nice shot of Airball showing the magenta TAS ring, and some yaw:

I tried calibrating VFE and VNO and found that the indication on my "installed" IAS is quite different from that measured by Airball. It was possible, however, to just set the bars to match what the installed IAS was saying, and from that point on things were very consistent. It was quite useful to be able to see VFE directly on the Airball.

Here are the next steps:

1. Increase baud rate. This is a no-brainer.

2. Increase digital filter time constant. The ball needs to be more "stable" so we can read it better.

3. Add a "shadow" ball with less filtering. To show the effects of turbulence consistent with the "digital yaw string" application, we can have a "shadow" ball that bounces around showing the instantaneous position. This allows the pilot to judge turbulence.

4. The ball should always be on-screen. In a full rudder deflection slip, the ball would often be off the screen. We need some visual that keeps it on the screen. For example, if the ball is past the right edge of the screen, the screen could look like this:

If we do that, we will have something that's close enough to be demo'able to third-party flight instructors. Stay tuned.

Tuesday, August 13, 2019

Sensor board V6, we'll see if this works....

I updated Jeremy's design for the Sensor Board, revving it to Version 6. Important changes are:

  1. Honeywell sensors are now standard
  2. Barometry with a commodity Bosch BMP388 chip
  3. Added a LIS3DH accelerometer
  4. Removed the on-board OAT which we were not using
I got my circuits and stencil from PCBWay and am hoping to build up a few copies as soon as the components and solder paste come in. Wish me luck -- that BMP388 (2mm square LGA-10) is super small! :)

Sunday, August 4, 2019

Once more unto the breach, yet fear the failwhale

Armed with the hypothesis that my failure of yesterday was due to heat, I took flight this morn in my trusty steed N291DR with my trusty equipment, for to secure data:

Yet alack, 'twas not to be. The data recording cut off during or soon after takeoff, again. And when I unplugged the probe and plugged it back in again just after landing, it worked, so it's not the heat; it's probably the vibrations. And in fact, here is a trace from one of the pressure sensors:

This sad song has been sung before. It's I2C bus flakiness caused by bad wiring somewhere. And indeed, as we know all too well, it locks up boards.

It is generally true that I have never had any luck flying kludgeboards. There is something about the flight environment that just kills connections, no matter how carefully done. Unless something is truly rock freaking solid, there will be some intermittent thing somewhere, and you'll find it as soon as you take off. And note that the bar for a "kludgeboard" here is not excessively high. The stuff I was trying to fly is basic hobby breadboarded electronics stuff.

I'm not sure what has been going flakey, but it may be a bad solder joint, or it might be that the 0.1" header connectors are for some reason not as secure as I'd like to believe they are.

So what's to do? Well ok, let's review the three issues we wanted to test by flying this experiment, and discuss whether we can back off in some interesting way.

1) What is the difference between the static probe "stick" and the 3D printed probe nose holes? This relates to the mechanical design of the probe and we can iterate on that separately as we need to. All we need is some pressure measuring board (we have plenty) and a test rig, and we need to measure a couple of pressures (including the difference between "static" pressure as measured by each of the different static source geometries). This can be done as a standalone experiment and need not block anything.

2) How does the aero derived beta signal differ from lateral acceleration? Adding an accelerometer to our board is cheap, and we need to rev our board anyway, so why don't we just add the accelerometer and call it a day? Later we can decide on the relative accuracy of each source, and anyway, we're planning to make the choice of lateral position (ay/Q or aero derived β) a user choice in the UI, so why worry?

3) How do the Honeywell sensors perform in a probe? We know others have used the Honeywell sensors and they work fine. Let's just rev up a board using them, and take the hit. It will cost less time, and perhaps even less money, than MacGyvering up a bunch of "test" boards and wasting time.

Saturday, August 3, 2019

Heat shrinkage of PLA

Today's flight may have been the victim of excess heat. In any case, it seems the PLA probe nose shrank enough to be a loose fit where it was a tight fit last night. We need a new 3D printing medium; ABS is on order....

Frustrating data gathering flight

Today I did a data gathering flight to answer the following questions:

1) What is the difference between the static probe "stick" and the 3D printed probe nose holes?

2) How does the aero derived beta signal differ from lateral acceleration?

3) How do the Honeywell sensors perform in a probe?

To do this, I made up a bit of a MacGyvered experiment probe. Pictures below.

Unfortunately, data acquisition stopped as soon as I was taking off, so the flight was a dud. Need to fly again, perhaps after figuring out what caused things to lock up.

Wednesday, June 26, 2019

Parts in the mail

A few more parts came in today --

  • Adafruit LIS3DH accelerometer breakout. I'm hoping this will be a reliable accelerometer to add to the probe, so we can choose between using aerodynamics or acceleration for yaw detection. The breakout boards are only for the LIS3DH, but we would use the LIS3DSH if we were stuffing an SMT board from scratch since it has better resolution.
  • Adafruit BMP280 barometer breakout. This is (one of the) latest Bosch barometers, and we can use that along with a 3D printed "cap" to create a cheap ported barometric pressure measurement. For our own SMT board, we might want to use a BMP388 since we seem more suited to its target market. (I should get some of the BMP388 breakout boards too.)
  • Sparkfun Pro Micro 3.3V. This will be the brains of our "breakout board" probe. You may recall we had trouble with the Sparkfun Fio V3 due to how it wires the battery to a pin on the microcontroller. This way we can avoid this issue.
  • Sparkfun LiPo charger plus. A separate battery charger.
Laying out all the required parts on a 1.5" x 5.5" grid (which is the size of our standard Airball probe board), it looks like we can fit it all with 0.1" thru-hole soldering without too much trouble. Note we are using both sides of the board, but the interference between the signals should be pretty minimal:

Of course, eventually, we'll want to put all this on an integrated SMT board, but for now this should get us started.

Initial testing with the accelerometer seems to show decent results; we'll see how it does when it's actually mounted and flown.

Our first test will not be with a complete probe but rather with just 3 pressure sensors and the accelerometer, as a focused experiment to correlate aerodynamic yaw and lateral acceleration. Stay tuned for the report of this within the next few days (I hope).

Saturday, June 22, 2019

Low cost ported barometer

You may notice that we have been using ported barometer sensors for compatibility with our dynamic pressure sensors. All of the cheap barometric sensors out there are board mounted and do not have ports. But is there a way we can avoid using a "special" part? This is the subject of today's investigation.

I happened to have an Adafruit BMP180 breakout board, which looks like this:

The Bosch BMP180 sensor is obsolete, but its successors are available on similar breakouts from Adafruit and Sparkfun -- and a variety of other sources online -- very easily for about $10 each. To add a port, I decided to design a 3D printed "cap" for the sensor --

This was the 3D printed part, when complete:

I drilled out the side hole to 3/32" cleanly:

I then cut a piece of 3/32" diameter brass tube, cleaned it with alcohol, and inserted it with a drop of CA glue to hold it in place:

The next steps were to add a tiny bead of CA glue around the edge and press the breakout board int0o the tight fit with the 3D printed part, then add 2 self-tapping screws to hold the assembly together:

I then tried blowing into it underwater to see how well sealed it is. It turns out the largest source of leakage is the porosity of the 3D printed parts themselves:

I think that, for barometric pressure measurement, a micro-leak is unlikely to change the measured pressure appreciably, so this is okay. I then put this in a breadboard and ran the Adafruit demo program for the BMP180, and verified that sucking on the tube increases the measured altitude:

The main problem with this setup is that, to solder it to a board, it would get pretty hot and would probably melt the 3D printed parts! So a next version should probably involve soldering the breakout board to a host PCB first, then adding the little 3D printed "cap".

In any case, for $10 plus change, this is a pretty useful way to make a ported sensor! ;)

Sunday, June 16, 2019

Drift stability of Honeywell HSC sensors

I arranged a simple experimental setup to measure the long-term (i.e., over a day or so) drift of the Honeywell HSC sensors. This was the apparatus:

Basically, I breadboarded three HCSDRRN040MD2A3 differential sensors and took data from them for a day, and plotted it all out. The sensors should, of course, read zero for the entire time. The results look like this:

The worst-case drift is 8 Pa. The sensors are +/- 40 mBar range, or +/- 4000 Pa. The full scale span is therefore 8000 Pa, making the drift (8 / 8000 * 100) = 0.1% of full scale.

The maximum zero error (without autozero) is about 17 Pa, which is about 0.2% of full scale.

By comparison, when we tested an All Sensors chip in this blog post, we found that the maximum drift was about 0.27% of full scale, and the maximum zero error was 0.88% of full scale.

Saturday, June 8, 2019

Building a sleeker new probe

I finally decided that I am going to steer away from "reliable" altimetry (i.e. altimetry that you can use for separation between aircraft, or report to ATC, or whatever). At least, we can put that aside for now. This means our barometry need be only good enough for estimating true air speed. Which means we can use a more convenient method of getting the static pressure than the messy aluminum tube that sticks out.

Again, one day we may reconsider, but for now, I think this is the sweet spot to make progress.

To that end, I redesigned the probe nose to have a series of radial holes part way down, judging that these would give an adequate estimate of static pressure. I then assembled that into a probe. Here are the steps.

First, we scuff a piece of 3/32" diameter brass tubing with sandpaper to give it a good gluing surface:

We then cut it into six 3/4" lengths, and clean up the cut ends:

We put them in alcohol to clean them, and take them out and dry on a clean paper towel without touching:

We then sandpaper and clean out the holes and edges in the new probe nose and a mounting ring:

One by one, we pick up each little brass tube with pliers, dab with a drop of CA glue, and insert it into each of the six holes in the nose so about 1/4" is showing:

We then screw and glue, with CA glue, the mounting ring onto the back of the nose. First we screw it down with a tiny gap, put glue into the gap, then close the gap by tightening the screws:

We then thread the tubing, this time using the brass tubes as "nipples" in the probe nose. This is an improvement over the previous system, where we had to glue the tubing directly into the nose. Note one hole is too close to the XBee -- we will fix that in a new rev. :)


This is the completed probe, and a comparison with the previous one. Stay tuned for reports!