Friday, December 15, 2017

Poor filtering is poor

I noodled around with the data from the road test, passing it though a 25-tap lowpass FIR filter. Here are the results -- purple is original, and green is filtered. The X axis is in seconds:

Looking more closely, we have:

Notice the 1 second delay, and the DC bias. Clearly this is not okay.

Now it's true that I studied signal processing at some point in my life, but that was literally 30 years ago. :) So I have a big ramp-up I need to do, and clearly I need to learn about, and implement, a proper Kalman filter.

The data above is nominally at 20 Hz, but because I have had trouble getting timers to work on my Arduino, what this really means is that I acquire data with a 50 millisecond delay in between. This is no way to acquire data. :)

And finally, it's possible that the road environment has more turbulence than flight, so it may be that the filtering requirements for flight are less stringent, which would mean I could defer the fancy filtering until later.

Therefore what I've learned here is:
  1. I need to move to flight testing sooner;
  2. This means I need to figure out my airplane mounting again -- the mount I bought was a bit wobbly, and maybe I should move to using a Citabria that has 2 struts for more stability;
  3. For this testing I need to buckle up and add my 2 other sensors to my probe and hope I don't fry them;
  4. I also need to get Arduino timers working so my data is at a consistent sampling rate (no sense paying for a flight test then using crappy sampling); and
  5. Meanwhile, I need to start learning about Kalman filtering.
That should keep me busy.

Sunday, December 10, 2017

First road test, Pitot only

Today I ran my first road test of the actual probe, using only one sensor, the gage sensor for the center hole relative to the static pressure probe. In that configuration, it was just a fancy Pitot tube. Here is the sensor mounted on the mast:

And here is the Airball display unit in the car, along with an XBee receiver connected via USB to my laptop acquiring the data for analysis:

I drove the car while my wife rode shotgun acting as Test Range Safety Officer [tm]. Her job was to look out for stupid stuff, and indeed she did catch some possible snafus with low-lying telephone wires and trees, and kept situational awareness on the general road environment.

Here is a video of a portion of our trip:

We set the cruise control for 80 mph and read off approximately 66 kias on the probe. We are at sea level and as you can see we were at approximately 64 degrees F or about 17.7 degrees C so conditions were close to standard. 80 mph means we should be reading 69.5 kias, which means our error is more or less acceptable for now. The data is not filtered, and the reading was estimated simply by changing the IAS scaling until the ball more or less filled the screen then reading off full scale, so there's lots of error there.

The following is the plot of Q (in Pascals) versus sample number. Our sample rate is approximately 20 Hz -- approximate because I'm still trying to figure out how to get timer interrupts to work on the Arduino.

Here is a 40-second expanded section:

And this shows a bit more clearly what is noise (due to turbulence -- the sensor by itself on the bench is very quiet to within +/- 1 Pascal) and what is speed variation as we navigate the busy Bay Area traffic.

As before, my expectation is that we need some digital filtering.

The probe survived the experience and, so far (knock on wood), with good anti-ESD practices and clean power-down and discharging of the electronics prior to making any changes to the circuit, the parts have survived. If this continues, I will be encouraged to commit more of my precious, expensive pressure sensors to testing. For now, I remain with one sensor in the "fancy Pitot tube" mode.

Thursday, December 7, 2017

Water manometer verification of sensor

I built up a new sensor board and, after a whole lot of pain with previous sensor damage, I am taking it slowly. I only installed one of the pressure sensors: the gage sensor for measuring dynamic pressure in the center hole of the probe.

To figure out whether the readings it's giving me are even remotely related to reality, I made a very simple water manometer and connected it to my sensor:

Meanwhile, I set up my PC with an XBee to receive the serial data:

I then applied a measured water column:

and 4.94 in. H2O should be 1229 Pa. My sensor board reports its data in SI units, so looking at the numbers coming off it:

the reported 1224 Pa is close enough for me. This was not an attempt to calibrate the sensor, or to determine its accuracy, but rather simply to figure out if I had a serious math error or mis-configuration somewhere. We are good to go now.

Next up, installing the sensor on the Toyota mast and getting some "flight" data. As I mentioned before I'm probably going to have to make a foray in to digital filtering. Expect more soon.

Sunday, November 19, 2017

New sensor board in the making

I'm trying to be far more careful now about how I build up and qualify my boards. I got 6 boards made from Osh Park and fully stuffed one of them yesterday. Today, I'm doing a step by step qualification to make sure everything works well.

I attached a Fio V3 to the board with a temporary header and rubber bands (someone should make Cleco fasteners for 0.1 inch headers!!) and used a Sparkfun TMP102 breakout board I had lying around as a generic I2C device to test the pressure sensor slots (so I don't risk my actual, expensive pressure sensors).

First, I learned that unless I de-populated the pullup resistors and decoupling cap on the TMP102 breakout, the bus did not work properly. I suspect it was the pullups that were overwhelming the bus, given that my board already has pullups.

With that fixed, I was able to verify that each of the pressure sensor slots were interrogated correctly by my bus scanner and that the TMP102 showed up where I expected it to.

Here is a picture of my test setup, followed by a picture of the signals as digital and analog traces on the scope. You can see how each of my 4 I2C buses is lit up in sequence by my bus scanner program.

Turbulence at the top of my mast

I installed a little tuft to estimate the amount of turbulence at the top of my mast:

As you can see, it is in view of my video camera. The result of a test run on the freeway is here (and note also impact with a tree branch ... happily no harm done).

Here are some things I noticed:

1. The piece of copper wire holding the tuft in place is a little bit wiggly, which could be exaggerating the movement of the tuft.

2. That said, even when there were few road bumps and the wire was staying put, the tuft was wiggling around quite a bit.

3. It seems difficult to estimate the frequency of the oscillations but I'm going to suspect it's just broad spectrum noise.

4. If this is any indication of what things look like on a crowded runway, I'll have to do some serious digital filtering to basically reject everything except the bandwidth of interest, which is probably no faster than 0.5 Hz or so.

With that in mind, then, the following is my plan of attack:

1. Build up and qualify a reliable new probe.

2. Test it with the 60 mW XBee modules, pushing the sampling rate as high as I possibly can while still getting reliable comms.

3. Thus oversampled, now add a simple lowpass filter on the display.

4. Give myself a TODO item to learn about Kalman filters and implement a more proper filtering strategy later.

Sunday, November 12, 2017

Furl the staysails!

I made a mast to fit on my 2006 Toyota Prius to permit further testing. The mast is an 8 foot section of aluminum tubing; at that height, if there is any turbulence, then it is likely to also occur at takeoff and landing and should probably be digitally filtered. In any case, it's a cheap way to do tests.

The mast is made of an 8-foot length of 1" square 1/16" wall aluminum tubing. At the bottom, it is riveted to a large T-strap hinge which is attached to a piece of plywood which is in turn held onto the car's roof rack bar with a pair of U-bolts. I have some ropes with carbiner hooks attached to the four jacking points under the bumpers, and from these and the roof rack I have 4 stays made of paracord. The lines come off and the mast folds down for transport. I don't deploy it unless I know I'm on a stretch of road where I'll have clearance.

Here it is, stowed and deployed:

I drove the rig around today on a 45mph road and on the freeway, with a camera attached, to determine how it held up. Stability seemed good. I'm generally not worried about excessive vibrations.

Here is the 45mph run:

And, after gaining some confidence, this is the run on the freeway:

For a subsequent test, I'd like to make a dead-simple wind vane and stick it up in view of the camera to get a baseline for how turbulent the flow is up there and how that is affected by vehicles ahead of me on the freeway.

Sunday, October 29, 2017

My board eats chips

After a very frustrating time spent with the innards of Probey, I have come to a disturbing conclusion: My circuit board eats chips.

By which I mean, for some reason, the circuit I designed and built has been destroying the ($50 each, thank you very much ... did I mention nothing in aviation is cheap?) pressure sensor chips. Right under my very own eyes, one chip that was doing just fine and answering as it should at I2C address 0x29, after being plugged into the board to test the various sockets, just stopped working and did not respond to I2C messages at all.

I am ensuring the board is powered off prior to connecting and disconnecting things. BUT it may well be that the Fio V3 is not really powering off the buses when it's turned "off" so long as it has a battery connected, and perhaps the resulting discharge when parts are connected and disconnected causes them to fail. I am trusting the Fio to turn itself off while I swap chips with the battery connected. Maybe I should disconnect the battery before swapping chips.

Perhaps also the All Sensors chips are particularly sensitive to power transients and ESD? I don't know.

I put together an independent breadboard test rig to test the chips away from any other weird circuitry:

This rig is my determinant of whether a chip has been eaten or not. And in fact, again, a "good" chip showed up on 0x29 in the test rig and in the probe, then stopped responding in the probe, and back in the test rig was also not responding. So the probe board eats chips. Simple as that.