Introduction

In June  2004, Damian Hall reported a couple of flights on the RDAS mailing list of a Hypertek Hybrid (J330, 835cc tank, FX grain) that experienced extremely early deployment. Damian suspected that the early deployment was a result of aliasing effects in the flight computer (RDAS) that he was using as Damian had  set the RDAS sampling rate to 50 Hz instead of it's normal 200 Hz. Damian also had two RDAS’s onboard. One had the early apogee detection anomaly and the other did not. I did a quick FFT of Damian's data but didn't see anything that looked like obvious aliasing, just what looked to me like a high level of vibration. A closer look in the time domain showed that indeed, aliasing was the culprit. Below is an explanation of what I believe happened. I also developed a MS Excel  spreadsheet (2MB. See the notes below) that shows the analysis and let's you interactively see the effects of aliasing.

An Example of Aliasing

Here’s an example of the RDAS data from a normal hybrid flight with the RDAS set to sample at 200 Hz, the maximum RDAS sample rate.

Here’s the data from the RDAS that experienced early deployment because of aliasing in the RDAS due to the sample rate being set too low (50 Hz).

Plotting the early deployment case in GnuPlot shows that the RDAS saw zero velocity, and initiated drogue deployment, at just over one second- right about at motor burn-out!

The second RDAS experienced late deployment, again due to aliasing in the RDAS because the sample rate was set too low (50 Hz). Remember, both of these flight computers were on the same rocket.

Apogee for the late deployment case is detected at 18 seconds when in reality apogee was at 5 seconds. How can setting the sample rate too low cause apogee detection errors like these? The short answer is aliasing. Aliasing is the “folding back” of higher frequency harmonics into a lower frequency. I don’t want to get into a detailed discussion of the theory of aliasing here as there are many good websites on the subject. I can recommend a great book on the subject though: “Understanding Digital Signal Processing” by Richard G. Lyons. Lyons book will give you the unavoidable mathematical details followed up by a more commonsense explanation. This is one of the most readable engineering texts I have ever come across. Quite a feat when the subject is DSP.

An Aliasing Experiment

First, lets look at the FFT of the normal flight with data sampled at 200 Hz shown above (Normal RDAS Flight). All of the data shown for the three examples were from the same Hypertek setup of a J330, 835 cc tank, and FX grain so that it can be easily compared (thanks Damian!). Notice how the the spectrum has significant spectral content all the way out to the Nyquist bandwidth of 100 Hz. The Nyquist bandwidth is the maximum bandwidth a sampled signal can have to avoid aliasing and is equal to one-half the sampling rate. The fact that there is spectral content at 100 Hz (one half of the 200 Hz sampling rate) kind of suggests that the original signal had a bandwidth greater than 100 Hz and there is probably already at least some aliasing in this plot. A good argument for using a low-pass filter on hybrid flights.

For comparison, here’s an FFT of an AP J motor. Notice how much less frequency content there is.

To try and make a direct comparison, instead of using the data from the other, bad flights, I resampled the 200 Hz data to 50 Hz to try and recreate a bad flight profile. This is an FFT of the resampled 200 Hz data at 50 Hz which gives a Nyquist bandwidth of 25 Hz. The old 200 Hz sampling rate data is superimposed in blue on top of the 50 Hz data in red. Resampling is a standard digital signal processing technique and when the new sample rate is lower than the original sample rate it is technically know as decimation. Notice how much more spiky the 50 Hz sampled data is. That is all due to aliasing and is what I originally overlooked. When I had run an FFT of one of the data sets from the failed flight, I had seen similar spikiness but had thought that it was perhaps vibration. Those densely packed small frequency spikes will have a big effect when they are all integrated to get the velocity data used to determine apogee. The RDAS determines apogee by integrating the acceleration data to calculate velocity. When the calculated velocity goes to zero it is assumed that apogee has been reached and the apogee charge is fired. In the aliased, resampled (red) data above, those small acceleration spikes have to get integrated to calculate the velocity. When aliased acceleration data is integrated it has a big effect on the calculated velocity as we shall soon see.

Early and Late Apogee Detection

This time domain plot shows the original acceleration and velocity data in blue, and the resampled acceleration and velocity data in red. It shows that the aliased data, ie the resampled acceleration data, gives a maximum velocity slightly lower, and a slightly earlier time for apogee (12 versus 14 seconds) than the original 200 Hz data. RDAS does not explain how they calculate velocity so I had to guess. I tried three standard numerical integration approaches: forward euler, backward euler, and trapezoidal. I built my algorithms in MS Excel (as was everything shown here) and checked it using MatLab. There really was no difference between the three integration algorithms I used and they all matched both MatLab and the RDAS GnuPlot. The spreadsheet uses the forward euler integration method.

Sensitivity to Launch Detection

Now lets add one more variable, the initial time step. The resampled data assumes that launch is detected at exactly the same time as the original data and the point at which launch is detected is the point at which we start integrating acceleration to get velocity. But what happens if launch is detected a bit earlier or a bit later? I have set up the spreadsheet so that you can try different "launch detect" scenarios. Go to the "RDAS-2-3 Data tab which has all of the data. The left hand side of the spreadsheet is the original data and the right hand side has the resampled data. Both sides have a cell at the top labeled "Initial Time Step" (cell E11 for the resampled data). That cell sets a "launch detect" offset from the original time. For instance a initial time step of zero means launch was detected at exactly the same time (the default case). The graph above shows an initial time step of 2 (2 steps at a 200 Hz sampling rate, or 5 milliseconds per step, means 10 milliseconds). In other words, what if launch is detected 10 milliseconds late? Now look at the Time Domain plot above. Yow! Apogee is now detected after only 7.3 seconds when the rocket is actually going 70 m/s (156 MPH). There goes that parachute. I love the balloon popping sound parachutes make when they deploy at high speed. In any case, by changing the initial time step you can make apogee be detected either early or late (try an initial time step of -1 in the spreadsheet). This explains why Damian had one flight computer with early apogee detection and one flight with late apogee detection under identical launch conditions. This is because the two computers detected launch and started calculating velocity (by integrating acceleration) at slightly different times. Download the spreadsheet and try changing the launch detect time with the original data using cell E10 on the left hand side of the spreadsheet. Because the data is not aliased (or at least not severely aliased) the velocity is much less sensitive to launch detect and hardly moves as the initial time point is manipulated.

A note on the spreadsheet. You have to have the MS Excel Data Analysis add-in installed for the FFT pages to display and for the file (MS Excel 2002 format) to open without getting an error/warning message. To install the Data Analysis add-in, go to Tools--Add-Ins and check the box for Analysis ToolPak. It will automatically install (you may have to insert one of your original MS Office CD's but you will be prompted is this is necessary). The Analysis ToolPak is included with every copy of MS Excel but is not installed by default. You can still see the aliasing errors without the Analysis ToolPak, but not the FFT plots.

Conclusions

The conclusions I get out of all of this are:

1. 50Hz (and probably 200Hz) is way too low a sampling rate for a hybrid rocket. 200Hz is probably OK for an AP motor, but it would be a good idea to have some filtering in the signal path.
2. Once acceleration data becomes aliased, the velocity calculated by integrating it is very sensitive to the launch detection time. Depending on when launch is actually detected apogee may be detected early or late.
3. An aliasing filter should be used between the accelerometer and the ADC. To avoid having to build a really complicated filter, a simple 2-pole filter can be used in conjunction with an ADC that samples at a much higher rate than the filtered signal bandwidth. This technique is called oversampling. To reduce the amount of data that is stored the oversampled data can be digitally low-pass filtered and then resampled (decimated) at the lower Nyquist rate.