Thursday, January 18, 2018

High-altitude help to prepare for low-altitude* testing

Hi there, Airball fans. Jeremy, here.

This is my "F1RST!!1!one" post on the Airball blog. I recently reached out to Ihab to offer him my help with the Airball project, and he enthusiastically accepted. I am an ex-Googler, currently on the tail-end of a year long sabbatical, mainly teaching kids robotics and working on personal projects. I am an instrument-rated private pilot and I own a DA40. Being an ex-Googler, I learned of Ihab's crazy and awesome project through internal channels, and I have been following it here since. Being an electronics hobbyist, some aspects of it caught my eye, and I've provided bits of advice (and consolation) to Ihab here and there for the past year or so.

I offered to help in whatever ways my skills and experience (or even my dogged determination to blunder my way through things) could be put to use. My first projects are all related to getting a flight-test capable Airball sensor probe up and running; reliably providing (non-glitchy) data for Ihab to continue proving the idea, evaluating designs, and building the Airball display unit. So, enough about me, onwards!

Working through some gremlins...

My first order of business was to understand the hardware Ihab had built so far, the code he had written, and help him work through some gremlins he had been experiencing with the custom circuit boards he had designed and assembled. In our discussions back and forth, I made repeated requests to Ihab for more and more specific zoomed-in steady-hands pictures of his work (and even a flatbed-scanned picture of his boards). It became clear to me that something was "just not right" with the solder mask on the boards he had been having trouble with.

I sent Ihab back this annotated picture of his board where I've called out some problems (manufactured by OSHPark – open for the larger version to make it easier to see):


The problem here is that the solder mask apertures are mis-aligned to the copper layer below it, which is exposing wispy (or substantial) little edges of the copper ground plane next to many (well, nearly all) of the SMD pads and plated through holes. This combined with Ihab's less than steady 😅 hand-soldering mean that it was exceedingly easy to bridge pretty much any connection to ground accidentally. And, so it happened. A few times. This fully explained why a previously-working board could suddenly stop working by the simple addition of an unpopulated socket – the act of soldering it in had bridged some pins to ground.

There were some other issues with the board's design that I had identified (and others that Ihab had run into earlier) so I knew I'd need to re-spin a custom board for the probe. In the meantime, though Ihab built a drive-test capable probe-on-a-stick which I wanted to make sure he could get good data back from.

Building my own breadboard rig for software development

In order to get Ihab up and running with reliable data, I planned to re-write the Arduino code powering his current hardware (and his new probe-on-a-stick), so I first ordered a few parts and built out a compatible hardware rig on a breadboard:


Once I got that up and running I could run Ihab's existing code, and started in re-writing it from scratch, based on a properly modularized codebase for the pressure sensors and the bus multiplexer. To that end, I wrote Open Source-licensed Arduino libraries (now available right in the Arduino IDE!) for the AllSensors DLHR-series pressure sensors and the Texas Instruments TCA9548A I²C multiplexer.

I was then able to make the actual Airball code much smaller, simpler, and easier to follow. I also made the measurement interrupt-driven by a timer so that the data coming from it could be sent at a much more reliable frequency (currently 20 Hz, or sending data every 50 ms). Ihab was able to get this new code up and running on his probe-on-a-stick immediately!

A new custom circuit board for the Airball probe

Once I completed the new code I got started on a redesign of the custom circuit board that goes inside the Airball probe – and hopefully hangs out on a wing soon, sipping some delicious in-flight air.

The previous board had a number of problems which we were looking to address (aside from the manufacturing problems), so the following changes were made:
  • Several mistaken connections (e.g. bridging the unused SCL and SDA pins on the multiplexer) were removed.
  • Some layout improvements were needed to help in assembly; all SMD components were moved to the top side, so that a solder paste stencil could be used, and the parts could be easily hot-air reflowed.
  • Many inconsistencies and errors were fixed in the custom-designed library parts so that the schematics and board designs are easier to work with, and look better.
  • Many more labels were added to the board and the layout was made more consistent overall.
  • The USB micro-B connector was replaced with one for which we have an actual part available, instead of the random footprint that was used previously.
  • The SDA and SCL for the I²C bus lines were re-routed so as to not be parallel to avoid crosstalk (which was actually visible on some oscilloscope captures during debugging).
  • The vias were tented (covered with with solder mask) so that they aren't exposed, the silkscreened text isn't broken, and so that the board looks nicer.
  • The corners were rounded, because all "pro" circuit boards have rounded corners. 😏
The new board however is drop-in compatible with the current design in order to allow Ihab to more quickly move on with physical integration in a flight-ready probe. Future designs will likely adjust the design more (such as integrating the ATmega32u4 microcontroller and other relevant components from the Sparkfun Fio v3 rather than placing it in a socket).

The new design still looks pretty familiar in EAGLE...

Top:


Bottom:


I got the boards in yesterday (manufactured by PCBWay) – Ihab made me choose a color scheme, so I went with white solder mask and black silkscreen text, and they look great:



I'll get a few boards assembled and tested soon – more to come on that!


* I live at 5,825 feet elevation, in the Virginia Range mountains southeast of Reno, Nevada. I suspect that most of the Airball flight testing will be done at 2000-3000 feet over the Central Valley, so I'll claim it's "low altitude testing". 😎

Friday, January 12, 2018

More miscellaneous meanderings

Various progress notes as things go ahead --

Jeremy has reproduced my setup, gotten a far better Arduino program than mine working, and is re-designing the PCB! Impressive progress!

I have been busy with my day job but have been noodling around with a 3D printed version of the Citabria mount. This is the form that's out to the printers right now:


Stay tuned for more progress. I got some test prints in ABS (white) and PLA (black) that are teaching me the limits of what to expect for tolerances in commodity 3D printing:




Furthermore, I've been slowly acquiring some new antennas for more testing down the line. I expect I will be able to handle low-wing airplanes by building a "spike" that puts the antenna ahead of the leading edge so it can be seen from the cockpit. This is for later but I have these antennas and U.FL extension cables to try out:



And finally, I continue to have trouble getting my Dynamixel servos to talk to my computer, after having gotten a dud USB2AX and having to get another one sent to me. Still trying....

Sunday, January 7, 2018

Mounting options

I'm re-examining my probe mounting options.

I tried putting the probe where it would be under the wing of a low-wing metal aircraft, just to see how the wireless stuff works. But with the 60 mW XBee, and the small Taoglas self-adhesive antennas I'm using, I do not have reliable enough connectivity.

So it's back to high-wing airplanes. And I was not happy with the way my Cessna strut mounting worked out so I'm considering going to a Citabria. I tried the wireless with a Citabria and it was just fine.

The great thing about Citabrias is that they have 2 struts, giving me the option of a 2-point support rather than just having to clamp really hard on just one strut. So I'm messing around with a design for a "twin vee block" mount for these.

I'm also trying out OnShape, and finding it mostly ok but different enough from SolidWorks that it's a fair learning curve. But with OnShape, I can easily share designs online! So here is a link to my design, and this is what it looks like:



I just figured out how to use the OnShape "Mass Properties" tool and the above weighs 0.5 pounds, assuming the vee blocks are made from hard maple.

Stay tuned!

Sunday, December 31, 2017

Simple data filtering

I looked through some of yesterday's data using GNU Octave with a goal of understanding how digital filtering can be used to smooth it a bit. I've been thinking of Kalman filters, but am realizing that I really don't have a predictive model of my system -- it's not like I can do some sort of dead reckoning from my current state to a new one. So for now I'm considering simple lowpass filters.

The main tradeoff from my viewpoint is the phase delay of the filters -- roughly speaking, the more smoothing, the more delay in the response of the smoothed output. This is rather bad for an instrument that attempts to give the pilot an "instant" view of their airdata.

On the other hand, I do think, from my earlier tuft experiments, that the airflow in my road testing is really horribly turbulent. I look forward to flight tests where I can quantify what things really look like off an airplane wing.

For now, I'm going with the assumption that if I can do a little bit of filtering to eliminate much of the jitter, that will be good preparation for any future contingency. And it's easy to implement a filter on the display side, and just as easy to disable it if I find I don't need it.

With that in mind, I used Octave's FIR filter design tools to come up with a grid of filtering options, with filter order ranging from N = 5 to 40 taps, and lowpass cutoff frequency ranging from f = 0.4 to 1.0 Hz. Here are the time domain results. Note that this is a very high-resolution image -- you can click on it and zoom as you wish.
The striking thing is that the most important criterion is filter order, not cutoff frequency. That has the most effect on time domain qualitative "smoothness" and phase delay. And it appears that at N = 5, our delay is less than 1/4 of a second or so, which seems reasonable for an aircraft instrument.

On this basis, I think a simple digital filter in the display along the lines of the above is a good idea, and I'll be adding it and reporting back as to the results.

Saturday, December 30, 2017

Data from probe on a stick

We did a road test with the POaS today:


This is the set of all data traces for one "loop", showing reasonable data quality:


Now a couple of interesting things.

First, I know that my peak speed on this run was 75 mph. Converted to a dynamic pressure, this would be 674 Pa. Here is a zoomed-in region of the delta P 0 measurement at the peak:


Lots of noise, but the data is believably close to the right value.

Second, there still are some single-sample "spikes" as visible in this zoomed-in region of delta P 0. This is specifically visible when the readings are low -- meaning that these spikes are otherwise dwarfed by other sources of noise:


Note that the baseline reading is only 4 Pa, and the spikes go down to -35 Pa. These are pretty low numbers overall. My suspicion is that these are either vibrations of the car, or actual noise. In other words, at about 20 Hz, the pressure sensors are acting as microphones and picking up things like the car doors slamming. This is worth testing more systematically at some point in the future.

Update: Looking at the last plot, these are not single-sample spikes! Many of them span multiple samples, meaning they are much more likely due to some physical phenomenon and not just noise in the digital lines in the probe. What phenomenon exactly -- and why the spikes occur exclusively in the negative-pressure direction rather than positive -- is a question for the ages.

Probe on a stick is done

The PO[a]S is done and sending data. Stay tuned for road tests!




Probe on a stick

Given the issues with the PCBs, I'm building a really simple "probe on a stick" that I can use to take data and de-risk other portions of the project. I don't think this is a valid flight test article but at least it can allow me to try road tests at various angles and see what results I get, and experiment with digital filtering of my signals.


On some level, the road tests did their job -- they acted as enough of a shakeout of the probe that they uncovered underlying reliability problems without the expense of flight testing. But it sure is a bitter pill to swallow....

I get exactly 5 minutes of crying in the corner ... but then I must press onward regardless.