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

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

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.

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.

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.

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.

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