Saturday, November 16, 2019

Two more display modules

Today I finished two more display modules.

One of them uses one of the new XBee 3 wireless modules. It initially didn't work with the XBee 2 that I had, until I realized I needed to install the 802.14 firmware. Once I did that, it was plug-and-play compatible with both hardware and software.

The most crufty part of the build is the tiny resistor network which provides reliable pullup and pulldown voltages for the quadrature encoder knob. I tried using the internal Raspberry Pi GPIO pullups for that purpose, but they don't seem to push enough current to produce reliable results when turning the knob quickly. So resistor network we must have. If I were to make this design in any quantity, I would spin up a PCB for that tiny thing -- but right now the protoboard is adequate. I am not sure the brightness of these displays is where I need it to be anyway, so I hesitate to "standardize" on this design.

Here are some build photos for your enjoyment.










Saturday, November 9, 2019

Cold solder is cold

After a CAD session during which vibration isolating versions of the probe board mounting areas were designed, I looked at the miserable board to see if I could determine the cause of failure. Well, it turns out I had a cold solder joint for the GND connection to the power and battery management daughterboard.

This is the solder joint in question, in the PCB hole pointed to by the screwdriver:



I did not allow for enough heating when applying the solder, and must have done a poor job of inspecting the board because, in hindsight, the joint in the photo looks pretty bad -- it's obviously just a bleb of solder sitting there.

In the same orientation, this is the hole in the PCB layout. You can see that it is properly joined to the ground plane by thermals, to alleviate exactly this problem:


So we're back on track -- but, if I can, I will change to the vibration isolated version of my mounting, just in case. If it's not too much more trouble, it should be really helpful.

Vibration damage in avionics is a thing (who knew?)

The Airball probe stopped working a few days ago while I was taxiing N291DR along the gopher-hole-pitted grass runway at the Monterey Bay Academy airport (CA66).

If you don't know this, the Monterey Bay Academy is a Seventh Day Adventist boarding high school in our region. They have an airport (of course! which self-respecting boarding high school doesn't?). And they have for years very generously made it available to the flying community, so long as you respect their rules -- mainly, refraining from landing during the Sabbath. They are awesome folks.

I have been working up to landing at their strip, which is sort of a "bush flying kindergarten". A few days ago, accompanied by my wife (and Airball Product Marketing Manager) Melissa Blum, I landed there as PIC for the first time ever!

Airball worked fine, until we did the long back-taxi down the bumpy runway. Then it stopped sending data. It's been a few days since I had the chance to pull it off the airplane and debug, but now I think I know what happened.

In this video, you will see that merely by wiggling the Pro Micro Arduino daughterboard, I can get it to turn off and on. So basically, the power supply solder connections or circuit board traces were mechanically damaged by the bumpy taxi!!

I found this out when I was poking around the circuit with my test probes and just happened to notice that the act of poking with the probes itself got the thing to light up and start flickering and sending data. Here is the video:


So the realization du jour is: Vibration in avionics is a thing.



Clearly I need to redesign my probe somewhat to add rubber vibration isolators to the board mount. This is a bit of a pain in the neck as I had hoped to be done with futzing with the probe mechanical design, to be perfectly honest. But I have to do what I have to do.

I hope I can manage to get some sort of isolation mount for the rear of the board. As you can see in the video, that area is already pretty "busy" and is not designed with any sort of simple mounting holes. 

Monday, October 28, 2019

Inventory time

Apart from what's in N291DR at the moment, I hope to build 2 more Airball systems. This the inventory of components I have so far for the two probes and displays:



Stay tuned as these get built up. It should be possible, I think, to show the work being "kitted up" much more clearly this time now that we have been around this block a few times.

Saturday, October 26, 2019

Successful test flight, good performance

Today I flew the latest Airball hardware on N291DR, and it worked beautifully!!! In particular, as I was calibrating the airspeeds, I noted that I was getting VFE = 70 kias at exactly the same point as the airplane's built-in airspeed indicator. Stall was predictable, yaw was consistent with the inclinometer, there was no "lag", and overall things were peachy!

Unfortunately we are using a commodity LCD panel which is not as bright as some others we've tried, so I can't show you any video! It washed out completely! Maybe I'll share a video of me flying with it just for fun though.

Here are some photos of the installation.





Saturday, October 19, 2019

New "maker" display is complete

Today I put together the first complete prototype of the "maker" style display -- one which uses commodity parts. There is a small resistor network for the encoder knob, which I made on a piece of breadboard -- that can be a tiny custom PCB at some point. Otherwise, this is built around a standard Raspberry Pi and a 4.3" HDMI LCD panel that's inexpensive and available everywhere. The result looks like this:



We still have a few software improvements / bugs before we get a test flight, but in the meantime, check out the assembly pictures!

















Wednesday, October 9, 2019

New probe has 12h battery life as previous

Just confirmed the new probe has a 12 hour battery life, comparable to our previous design. This is not surprising, given that it's just a recasting of the same hardware, but it's still good to know. Here is the probe sitting on my desk at work today. The LED blinks on or off per data cycle, so it is blinking at 10 Hz and the data is going out at 20 Hz:


Friday, October 4, 2019

New probe design

It's been a while since we posted, and it's not for lack of activity.

We have switched to using Honeywell pressure sensors, since they are (as best we can tell) more reliable. And since they are not as easily available in different types, we decided to use a Bosch BMP388 barometer instead of a high-zoot ported pressure sensor. This meant we were up for a big board rev.

In the meantime, we re-evaluated and decided we could get by with a less custom sensor board, using a few "breakout board" components to simplify our buildup for prototyping.

The result is our "maker style" probe, which we just got together:






Notice the following:

* Compute module is a SparkFun Pro Micro 3.3V.

* Power is provided by a SparkFun Battery Babysitter.

* Barometric sensor is an Adafruit BMP388 breakout board with a 3D printed "cap" to provide a port for redirecting the static probe pressure to the sensor.

* The static probe is now attached via a 3D printed pylon to avoid having to bend tubing, and it is made of a piece of regular hobby store brass tubing.

* Various changes have been made to the mechanical parts to make them easier to assemble.

We will be trying this probe out in flight and also, as we build more copies, showing more details of how it's put together. We're still trying to iron out some of the bugs.

Stay tuned!!!

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! :)