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!

All Sensors chips may have been heat damaged

Today I was messing with my probes to make a newer, sleeker design (stay tuned), and I noticed that the interior of Probe #2 looked like this:

If you zoom in on the photo, you can see that the black mounting ring is deformed completely out of shape. This indicates severe heat damage that approximated the softening point of the PLA plastic -- likely by sitting inside a car for too long. PLA melts at about 180 degrees C, so I'm not sure how hot this thing got, but it could easily have gotten above 100 degrees C.

I am therefore suspecting that the All Sensors pressure sensors that had particularly poor performance -- the ones in the working probes -- were heat damaged. This might explain things.

I'm therefore building up a new probe with fresh sensors that performed well in the recent testing, and will report back as to their performance.

Crucially, regardless of what sort of sensors I use, it is clear to me that I must have an autozero function if I am to get good performance at low dynamic pressure.

Friday, June 7, 2019

Testing accuracy of Honewell HSC series sensors

I have three Honeywell HSC series sensors, +/- 40 mBar differential (about +/- 16 in. H2O). I put them on my manometer test stand and modified my software a little bit to match the Honeywell I2C protocol. This is what the HSC sensor looks like in the test rig:

I produced the following results, which are also in our Git folder:

HSCDRRN040MD2A3 (11) [Honeywell Sensor]
-14.963 inH2O => -14.947 inH2O, min= -0.031 %fs, max= +0.046 %fs, err=  +0.050 %fs
-14.963 inH2O => -14.950 inH2O, min= -0.038 %fs, max= +0.053 %fs, err=  +0.042 %fs
 -9.976 inH2O =>  -9.953 inH2O, min= -0.038 %fs, max= +0.061 %fs, err=  +0.069 %fs
 -4.988 inH2O =>  -4.984 inH2O, min= -0.046 %fs, max= +0.061 %fs, err=  +0.011 %fs
 +0.000 inH2O =>  -0.034 inH2O, min= -0.038 %fs, max= +0.061 %fs, err=  -0.107 %fs
 +4.988 inH2O =>  +4.891 inH2O, min= -0.038 %fs, max= +0.038 %fs, err=  -0.301 %fs
 +9.976 inH2O =>  +9.872 inH2O, min= -0.031 %fs, max= +0.061 %fs, err=  -0.320 %fs
+14.963 inH2O => +14.834 inH2O, min= -0.038 %fs, max= +0.038 %fs, err=  -0.401 %fs
+14.963 inH2O => +14.827 inH2O, min= -0.038 %fs, max= +0.038 %fs, err=  -0.424 %fs
HSCDRRN040MD2A3 (12) [Honeywell Sensor]
-14.965 inH2O => -14.955 inH2O, min= -0.053 %fs, max= +0.061 %fs, err=  +0.032 %fs
 -9.977 inH2O => -10.056 inH2O, min= -0.046 %fs, max= +0.046 %fs, err=  -0.248 %fs
 -4.988 inH2O =>  -5.038 inH2O, min= -0.038 %fs, max= +0.053 %fs, err=  -0.155 %fs
 +0.000 inH2O =>  -0.027 inH2O, min= -0.046 %fs, max= +0.053 %fs, err=  -0.084 %fs
 +4.988 inH2O =>  +4.945 inH2O, min= -0.038 %fs, max= +0.046 %fs, err=  -0.135 %fs
 +9.977 inH2O =>  +9.941 inH2O, min= -0.046 %fs, max= +0.053 %fs, err=  -0.110 %fs
+14.965 inH2O => +14.886 inH2O, min= -0.046 %fs, max= +0.046 %fs, err=  -0.246 %fs
HSCDRRN040MD2A3 (12) [Honeywell Sensor]
-14.968 inH2O => -14.920 inH2O, min= -0.053 %fs, max= +0.061 %fs, err=  +0.150 %fs
-14.968 inH2O => -14.940 inH2O, min= -0.031 %fs, max= +0.061 %fs, err=  +0.089 %fs
 -9.979 inH2O => -10.029 inH2O, min= -0.046 %fs, max= +0.053 %fs, err=  -0.157 %fs
 -4.989 inH2O =>  -4.982 inH2O, min= -0.069 %fs, max= +0.061 %fs, err=  +0.024 %fs
 +0.000 inH2O =>  -0.029 inH2O, min= -0.031 %fs, max= +0.046 %fs, err=  -0.092 %fs
 +4.989 inH2O =>  +4.984 inH2O, min= -0.023 %fs, max= +0.046 %fs, err=  -0.017 %fs
 +9.979 inH2O =>  +9.895 inH2O, min= -0.031 %fs, max= +0.046 %fs, err=  -0.263 %fs
+14.968 inH2O => +14.849 inH2O, min= -0.069 %fs, max= +0.046 %fs, err=  -0.371 %fs
+14.968 inH2O => +14.842 inH2O, min= -0.237 %fs, max= +0.084 %fs, err=  -0.394 %fs

The errors are within half of the +/- 1% accuracy guaranteed by the manufacturer.

The manufacturer claims +/- 0.25% error from the Best Fit Straight Line, which I presume would require a per-sensor calibration. I'm not planning to calibrate each sensor so I won't be taking advantage of that spec.

In general, I see far greater consistency than the All Sensors products. However, this is a small sample size and I have not yet subjected these sensors to our operational environment. I will build up a probe with these sensors and start using it as soon as possible, and thereby better characterize their performance in the field.

Monday, June 3, 2019

Bench testing transmission delay

I set up a simple experiment: I taped the USB accelerometer to the probe, and recorded data for a long time. Every once in a while, I whapped one of the holes of the probe, thus creating a shock that should be simultaneous in pressure and acceleration. I plotted the results. Here is a typical result:

Clearly there is some sort of delay. It is not the 3 second delay we saw in the flight data, but it's definitely something suspicious. My next steps are to try different combinations of serial connections to the probe to see if that will change things.

I am tempted to just jack up the baud rate on the XBee, and indeed that should be the first thing I try, but at the moment I'm just trying to get a sense of the problem.

In both cases -- the accelerometer and the probe -- I am using the Boost asio::serial_port library to open the serial port on the Linux host.

As an aside, here is the sensor zero drift over a period of about 30 hours. The zero reading went from -132 Pa to about -92 Pa, a change of about 40 Pa. This is a +/- 30 in. H2O sensor, in other words, +/- 7473 Pa. The change of 40 Pa is 0.27% of sensor full scale. The total zero offset at the start, -123 Pa,  is about 0.88% of sensor full scale. This sensor is sensor ID 5 from the data in our Git repo.

We are sending approximately 50 bytes at 20 Hz, which comes to about 8000 bits per second. This is on link configured for 9600 baud. Clearly we are near the limit of our 9600 baud link. But the delay of 0.8 seconds implies there's a buffer of approximately (0.8 seconds * 50 bytes/msg * 20 msgs/second) = 800 bytes somewhere, and honestly nowhere in the transmitting side (ATMega chip or XBee) does there exist such a large buffer.

We need to do more testing, under more controlled conditions. Stay tuned.

Sunday, June 2, 2019

Flight to compare yaw and acceleration; data gremlins

I did another flight in N291DR to compare yaw and acceleration, this time with a sensitive and high quality accelerometer that I was able to borrow from a friend. The data is in this directory in our repo.

The setup was similar to what we've done before, except I also had a nice Jeremy-display installed and showing the data as well, in addition to the data logging PC strapped into the seat with an old bicycle innertube as a bungee cord (note patch where the tube was repaired, likely more than once):

The sad part is -- the data is not usable. It seems there is a pretty significant transmission delay in the data from the probe. (I am doing bench testing of this right now and will report back -- preliminary results are that the pain is real.)

Of course, delays in data transmission are a Big Deal [tm] for an instrument like ours, so now would be, like, not a bad time to figure them out. It's not just about data acquisition!

In the graph below, you can see the angle of yaw (beta) in blue, and the lateral acceleration in green. I'm sure you can agree there is no causal way that the angle of yaw can respond to a sideslip 3 seconds after the airplane has started accelerating sideways.... At least not in the physics I was taught, but then again that was a while ago....

Thursday, May 30, 2019

Testing pressure sensor performance

Introduction and purpose

We know -- anecdotally -- that any given one of our probes produces repeatable results. We are not sure about accuracy. Specifically, we have the following ongoing questions:
  1. Is our yaw (β) ensing consistent with lateral acceleration, given where and how we mount our probe?
  2. Does our probe geometry give us accurate output for the actual values of dynamic pressure, AoA, and yaw (Q, α, β)?
  3. Do different individual 3D prints of our probe produce the same pressures at the same values of (Q, α, β)?
  4. Do our pressure sensors reliably measure the pressures we present to them?
We are investigating #1 with the accelerometer. We can build an operational probe useable in a single aircraft without worrying about #2 or #3. As for #4, we need our sensors to be reliable and repeatable.

We have observed significant zero offsets in our sensors and so are worried that they may be flakey. We needed to do some testing to characterize their performance. We decided to do this with a series of static tests in the lab.


I build a water manometer to apply known pressures via measured water columns. My general idea was to use plastic tubing, 3D printed parts, and neodymium magnets to build something I could put up against a magnetic whiteboard and move around to adjust the water column. My first attempt involved 3D printed parts holding lengths of tubing, which were adhesive taped to the parts:

This turned out to be a suboptimal design for a few reasons. First, the tubing kept pulling away from the 3D printed parts, peeling off the adhesive tape. Second, the straight lengths were long enough to provide a measurement area, but if I didn't set things up perfectly, water would run out of them and into the tubing that led to the system being measured, and I would have to empty the whole thing and refill it. Finally -- interestingly -- the compressibility of the air was significant. When I applied pressure, the water column would move quite a bit on the pressurized side, and again if things were not perfect, water would move out of the vertical section and run out all over the rest of the tubing.

My next idea was to use lengths of rigid acrylic tubing for the measurement areas. To get the flexible tubing to fit tightly, I heated the ends of the tube and pulled them to get them to "neck down" a bit, then cut them cleanly with a saw and beveled the edges. This created a tight seal. I also redesigned the 3D printed holders. The result looked like this:

I made sure the ruler was vertical and clamped it into place, and moved the tubes up and down.

My next version of this apparatus would make both tubes even longer, since I still had some trouble with getting water running out of the vertical sections and getting into the tubing to the system under test.

The test system was an Arduino Uno with a breadboard slot for the pressure sensor, and a couple of hoses so I could hook up the sensor and then attach and detach the manometer without disturbing it:

My manometer only needed to apply positive pressure -- to test "negative" pressure differences on the differential pressure sensors, I simply switched which port I was applying pressure to.

Experimental accuracy

The main sources of error, and how I mitigated them, are:

Water meniscus shape: I made sure to align the tops of the meniscus with the tick on the ruler and could get that to within maybe 1/64".

Water level measurement. I made repeated measurements for some cases and found that my measurements were within 1/16" of each other in some cases; within a few thousandths of an inch in others. My suspected "worst" error in measurement, 1/16", is 0.3% of full scale for a ±10 in. H2O differential sensor. This means that I should not, without further study, attribute a ±0.3% error to the sensors themselves, but larger errors are likely due to the sensors.

Ruler expansion and contraction: Aluminum expands by 0.00048 in 20°C so not significant.

Water density: I used distilled water.

Water expansion and contraction: If the density of water at 4°C is 1.0, then at 20°C it is 0.99819. This is an 0.2% change and may be significant. Assuming the pressure sensors are calibrated for water at 4°C, I obtained a table of water density versus temperature from this site, measured the temperature during testing, and used linear interpolation to correct the results.

Sensor readings

I wrote a simple Arduino program to read the raw binary counts from the sensor via I2C and print them out. My program averaged 1024 sensor counts and printed the average, along with the minimum and maximum counts seen.

Sensors tested

The following is a view of the sensors inside our probe:

The dp0 sensor is a gage type, All Sensors DLHR-L10G or DLHR-L30G (0-10 in. H2O or 0-30 in. H2O depending on the probe). The dpα and dpβ sensors are differential type, All Sensors DLHR-L10D or DLHR-L30D (±10 in. H2O or ±30 in. H2O).

The DLHR sensors are described by the manufacturer in this data sheet.

We did not test the Baro sensor for this exercise -- at the moment, we use it for determining density altitude for computing true airspeed, and we are not worried about this aspect of the calculation. We have generally seen good correlations between our measured pressure altitude and the altitudes recorded on aircraft onboard altimeters.


The results are in the airball-data Git repo in this directory. This includes a JSON file containing the raw data, a Python program to produce a report, and a copy of the latest report from that data.

Our results indicate that the sensors operate generally adequately but some units have a large zero offset. Due to their linearity, we believe that an autozero operation can establish accurate results.

The results are in the file output.txt in the Git repo. Here is a guide to reading the results:

From the results, it appears that the dpβ sensors are in worse shape, having a rather significant zero offset. It's not clear why. For example, this is a good sensor showing good accuracy throughout its range:

DLHR-L30D E1BD-C NAV8 R16L14-46 (4) [Flying probe #1 dpA]
-14.982 inH2O => -15.006 inH2O, min= -0.014 %fs, max= +0.015 %fs, err=  -0.040 %fs
 -9.988 inH2O =>  -9.970 inH2O, min= -0.012 %fs, max= +0.010 %fs, err=  +0.030 %fs
 -4.994 inH2O =>  -5.046 inH2O, min= -0.009 %fs, max= +0.009 %fs, err=  -0.086 %fs
 +0.000 inH2O =>  -0.016 inH2O, min= -0.008 %fs, max= +0.009 %fs, err=  -0.026 %fs
 +4.994 inH2O =>  +4.958 inH2O, min= -0.012 %fs, max= +0.013 %fs, err=  -0.059 %fs
 +9.988 inH2O =>  +9.958 inH2O, min= -0.010 %fs, max= +0.010 %fs, err=  -0.049 %fs
+14.982 inH2O => +14.935 inH2O, min= -0.013 %fs, max= +0.011 %fs, err=  -0.078 %fs

This, on the other hand, shows significant and unexplained zero offset:

DLHR-L30D E1BD-C NAV8 R16L14-46 (9) [Flying probe #2 dpB] -14.982 inH2O => -14.190 inH2O, min= -0.010 %fs, max= +0.010 %fs, err= +1.319 %fs -9.988 inH2O => -9.286 inH2O, min= -0.011 %fs, max= +0.010 %fs, err= +1.169 %fs -4.994 inH2O => -4.274 inH2O, min= -0.013 %fs, max= +0.011 %fs, err= +1.201 %fs +0.000 inH2O => +0.741 inH2O, min= -0.011 %fs, max= +0.010 %fs, err= +1.235 %fs +4.994 inH2O => +5.711 inH2O, min= -0.013 %fs, max= +0.012 %fs, err= +1.195 %fs +9.988 inH2O => +10.677 inH2O, min= -0.014 %fs, max= +0.016 %fs, err= +1.149 %fs +14.982 inH2O => +15.671 inH2O, min= -0.013 %fs, max= +0.014 %fs, err= +1.149 %fs


1. Ensure we have a working auto-zero procedure on the probe.

2. Watch the sensor zero values as they progress. If it's possible to uniquely identify the sensors, then maintain a log of their zero drift.