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....