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.

No comments :

Post a Comment