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.