A new Fatigue Meter for the Bulldog aircraft (Part 3)

PART THREE

This is a direct continuation of PART TWO, picking up where I left off, with the continuation of flight tests and comparing the SSL fatigue meter readouts with the legacy fatigue meter readouts, and adjusting the SSL software as necessary.

Flight tests

Flight profiles #1 (maiden flight), #2, #3

As with the maiden flight, I performed two further tests with both the legacy fatigue meter and the SSL prototype installed, configured in AIRPSEED SWITCH MODE and NOMINAL DATA MODE, but with no changes to the SSL from the maiden flight. Likewise, each follow-up flight comprised a standard take-off and climb-out to the local area, some “lightweight” general-handling (i.e., not full aerobatics sorties), then return to base with a few circuits before a full-stop landing.

Observations during the flights

As with the maiden flight, I made the following observations during each follow-up flight:

• From the status leds on the SSL, it was seen to successfully power-up on activation of the airspeed switch just after take-off once airspeed exceeded 75kts, and remain on mains power for the duration of the flight (except for during the circuits, see below).
• The “Fatigue Meter” circuit-breaker remained “in” (i.e., did not pop) for the duration of the flight, verifying that the electrical demand combined from the SLL and the legacy fatigue meter remained within the 2 Amp limit of the circuit-breaker.
• During the circuits, the status leds alternated between mains and battery power, verifying that the SSL was correctly responding to the airspeed switch actions, i.e., switching to battery power (and suspending data recording) whenever the airspeed dropped below 65kts i.e., just before touchdown, and reverting back to mains power (and re-commencing data recording) whenever the airspeed exceeded 75kts again i.e., in the climb-out just after take-off.

Observations after the flights

After each flight, I downloaded the meter-readings archive from the SSL and compared with the delta readings from the legacy device. The results are contained in Table 1, including those for the maiden flight (#1, for completeness, already reported in PART TWO). It can be seen that the SSL and legacy meters have generally been activated in the same acceleration thresholds (“bins”) as one another (which is good), but that the SSL counts are higher than the legacy counts when there are multiple triggers in a given bin. This is particularly obvious when looking at the +1.75g bin which has the most counts since it is the one most often triggered in “lightweight” general-handling flying.

Flight #1	-1.5g	-0.5g	+0.25g	+1.75g	+2.5g	+3.5g	+5.0g	+6.0g
SSL	0	0	8	49	23	0	0	0
Legacy	0	0	5	21	16	0	0	0
% Error			60%	133%	44%
Flight #2
SSL	0	0	1	8	0	0	0	0
Legacy	0	0	1	3	1	0	0	0
% Error			0%	167%	-100%
Flight #3
SSL	0	0	1	13	1	1	0	0
Legacy	0	0	1	2	1	0	0	0
% Error			0%	550%	0%	100%

Table 1. Comparison of the SSL and legacy fatigue meter delta readings for each of the first three test flights. SSL highlighted green when readings are identical to legacy, orange when above legacy, and red when below legacy. Ideally all should be green, but if not, orange is better than red since then the SSL is overestimating the acceleration counts i.e., erring on the side of caution. The rows labelled ‘% Error’ show the difference between SSL readings and legacy readings, per bin, expressed as a percentage of the legacy readings. These are seen to be numerically large, suggesting an over-counting by the SSL versus the legacy.

Low-pass filtering

Given that the SSL readings are generally triggered at the correct threshold levels but are over-counting compared with the legacy, and assuming that the counting algorithm is correct i.e., incrementing when a threshold is passed in the outward direction (but not in the return direction), this suggests that perhaps the SSL pre-count acceleration signal is fluctuating (up and down) more than the legacy pre-count acceleration signal, and that these fluctuations are being duly counted, leading to higher counts for the SSL than for the legacy. The fluctuations could be genuine or due to noise in the system, or a combination of both. No matter the cause, the standard signal-processing solution under such circumstances is to apply a low-pass filter operation to the signal before passing it through the counting algorithm.

Filter design in MATLAB

Since the signal from the SSL accelerometer is already digitised, a digital filter is appropriate, implemented in software (i.e., rather than an analogue filter implemented in circuitry). The design parameters I used are contained in Figure 1.

Figure 1. Digital low-pass filter design using MATLAB (which has a convenient graphical-user-interface for filter design). The sample rate (Fs) of the data retrieved from the accelerometer is 10 Hz (as described in PART ONE). I’ve specified the filter low-pass cut-off frequency (Fc) to be 1.5 Hz since I don’t imagine that the Bulldog would be flown in such a manner as to manoeuvre through the g-levels at a higher rate than this. The other settings specify the type of filter structure. I’ve chosen a 5th order Butterworth design due to the efficiency of IIR filters for real-time computation.

Filter implementation in Python

The very same filter design implemented in MATLAB (Figure 1) can be carried out in Python (using the Scipy package) using the following line of code, where 5 is the desired filter order, and 0.3 is the desired low-pass cut-off frequency specified as a multiple of half-the-sample-rate (the Nyquist frequency) (so we get 1.5 Hz/ (0.5 * 10 Hz) i.e., 0.3):

sos=signal.butter(5,0.3,output='sos')

The resulting filter can then be applied to the raw signal on a batch-by-batch basis via the following line of code in Python:

zf=signal.sosfiltfilt(sos,z)

where z represents a batch of raw acceleration values (in Python Numpy format), sos specifies the filter (from above), and zf represents the filtered acceleration values. Note that I’ve used the filtfilt mechanism which applies the filter forward and backward through the batch in order to eliminate phase offsets — not strictly necessary, but tidy.

Figure 2 shows the results of the low-pass filtering applied to a sample trace from the SSL accelerometer. The raw signal is a sample trace captured from the SSL accelerometer (along the Z-axis i.e., the local vertical). The filtered signal is the output from the digital low-pass filter when applied to the raw signal. It can be seen that the raw signal is indeed noisy as suspected– which is likely the cause of the over-counting of the acceleration threshold-crossings — and that the filter is effective in reducing the noise. It is hoped that by sending the filtered signal (rather than the raw signal) through the acceleration threshold-crossings algorithm, the SSL fatigue meter bin counts come into alignment with the legacy fatigue meter results.

Figure 2. Effect of low-pass filtering on the SSL accelerometer readout.

Post-modification test flight

Table 2 shows the delta readings from a flight test (#4) conducted after the incorporation of the digital filter within the SSL flight software to pre-process the acceleration measurements before being passed through the bin-counting algorithm. In order to trigger more of the bins than in previous flights, the flight profile comprised some aerobatic manoeuvres: two inside loops, two slow rolls, plus a few steep turns. It can be seen that the low-pass filter seems to have largely corrected the issue of over-counting. The SSL readings are now either identical or numerically very similar to the legacy readings across the wide range of bins covered in the flight (a more aggressive aerobatic sequence would be required to trigger all the bins!).

Flight #4	-1.5g	-0.5g	+0.25g	+1.75g	+2.5g	+3.5g	+5.0g	+6.0g
SSL	0	2	3	11	6	3	0	0
Legacy	0	2	3	9	7	3	0	0
% Error		0%	0%	22%	-17%	0%

Table 2. Comparison of the SSL and legacy fatigue meter delta readings for the fourth test flight, an aerobatics sortie, following the implementation of the low-pass filter. Colour-coding and ‘% Error’ definitions as per Table 1. The errors are seen to be numerically much smaller than before the implementation of the low-pass filter (Table 1), suggesting that the low-pass filter has been largely successful in addressing the issue of over-counting.

G-meter comparison

The SSL outputs for max-g and min-g for this aerobatic sortie were +4.64g and -1.02g, respectively. Figure 3 shows the corresponding readings from the analogue G-Meter in the Bulldog cockpit panel, which are seen to be approximately +3g and -0.45g, respectively. Given that we know that the negative-g must be at least as low as -1g on account of the fact that the sortie involved slow rolls with the aircraft being held in the fully-inverted orientation for a few seconds each time, it strongly suggests that the SSL readout for the negative-g should be trusted more than the G-meter which seems to underestimate the negative-g. Likewise, given that both the SSL and legacy fatigue meters registered three counts in the +3.5g bin, this suggests that the SSL positive-g reading of +4.64g should be trusted more than the G-meter value of +3g which again seems to be an underestimation.

Figure 3. G-meter reading after test flight #4, suggesting a maximum value of approximately +3g and a minimum value of approximately -0.45g which underestimate the actual extrema g-values when compared with the flight profile (fully inverted -1g, etc). The corresponding readings from the SSL are are +4.64g and -1.02g, respectively, which seem to be more trustworthy.

Further improvement

I’m encouraged that the SSL fatigue meter readings are now rather close to the legacy readings with the incorporation of a low-pass filter in the SSL software. My goal is to achieve complete alignment. There are two areas where fine-tuning can be pursued to this end: (i) adjusting the low-pass filter characteristics; and (ii) adjusting the bin thresholds.

Bin threshold adjustments

Rather than using a single numerical value per bin threshold i.e., -1.5g, -0.5g, +0.25g, +1.75g, +2.5g, +3.5g, +5.0g, +6.0g, each bin has a “buffer zone”, bounded by the “Outbound” and “Inbound” values contained in Table 3. For each bin, the count is incremented whenever the acceleration enters the buffer zone in the outbound direction. The bin-counting for the given bin is then deactivated until the acceleration re-enters the buffer zone from the inbound direction, re-arming for the next count for that bin.

Bin	-1.5g	-0.5g	+0.25g	+1.75g	+2.5g	+3.5g	+5.0g	+6.0g
Outbound	-1.47g	-0.47g	+0.28g	+1.72g	+2.47g	+3.47g	+4.97g	+5.97g
Inbound	-1.53g	-0.53g	+0.21g	+1.78g	+2.53g	+3.53g	+5.03g	+6.03g

Table 3. Bin thresholds used in the counting algorithm. These can be adjusted to fine-tune the counting.

Next steps

Given that the SSL readings are now converging on the legacy readings across the dynamic envelope, this confirms that the counting algorithm is in principle the correct one. I’ll continue to test and fine-tune via adjustments to the low-pass filter design and to the bin buffer zone values in order to bring the SSL readings into complete alignment with the legacy readings.

In summary, the following steps remain from the original list in PART ONE:

• Create a suitable housing box and mount the SSL components within it (i.e., beyond the current prototype foam-board enclosure). I’m now considering the use of a 3D printer for this.
• Make any final adjustments to the software based on further flight tests in order to achieve complete alignment between SSL and legacy readings across the dynamic envelope.
• If it proves to perform with the required accuracy and reliability, submit for mod approval via the LAA for installation on my Permit-to-fly Bulldog.
• Calibrate the SSL via the ground-test company (if required for the mod approval process)