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

PART FOUR

This is a direct continuation of PART THREE, 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.

Test Flight #5

Flight profile: aerobatics

I performed another aerobatic sortie test with both the legacy fatigue meter and the SSL prototype installed, configured in AIRSPEED SWITCH MODE and NOMINAL DATA MODE, with the same software configuration as at the end of PART THREE (low-pass filter, etc), but with the inclusion of an archive function whereby the entire acceleration history was stored on the SSL and retrieved later for offline processing.

SSL versus legacy fatigue meter readings

After the 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. As with the Flight #4 in PART THREE, 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.

Flight #5	-1.5g	-0.5g	+0.25g	+1.75g	+2.5g	+3.5g	+5.0g	+6.0g
SSL	0	5	20	32	20	4	0	0
Legacy	0	5	19	36	22	4	0	0
% Error		0%	5%	-11%	-9%	0%

Table 1. Comparison of the SSL and legacy fatigue meter delta readings for Test Flight #5, an aerobatics sortie, using the same software configuration as in PART THREE. Colour-coding and ‘% Error’ definitions as per PART THREE. The errors are seen to be numerically small, requiring only minor fine-tuning to achieve exact alignment. The average accuracy [defined as 100-average(abs(%Error))] is 95%.

Acceleration histories

In order to fine-tune the counting algorithm to obtain precise alignment between the SSL and legacy readings, I’ve downloaded the entire acceleration history from the sorties with which to perform offline tuning and testing of the algorithm. Figure 1 shows the acceleration history for the entire mission. For interest’s sake, Figure 2 is zoomed-in on a segment containing an inner loop and a slow roll, and Figure 3 is zoomed-in further to illustrate the effect of the low-pass filtering (described in in PART THREE).

Figure 1. Z-axis acceleration measured by the SSL every 0.1 seconds over the entire Flight #5. The spikes coincide with aerobatic manoeuvres. See Figure 2 for detail.

Figure 2. Segment of the z-axis acceleration trace from Figure 1, zoomed-in on a segment containing an inner loop and a slow roll aerobatic manoeuvres.

Figure 3. Z-axis acceleration trace from Figure 1, zoomed-in to show the effect of the low-pass filtering (described in PART THREE). The filtered signal (red curve) is used in the SSL fatigue meter bin counting calculations rather than the raw signal (blue curve) which leads to an over-counting compared with the legacy readings.

Algorithm parameter adjustments via numerical optimisation

Rather than attempting to further adjust the bin-counting parameters by manual trial-and-error, I used numerical optimisation. Specifically, by treating the low-pass filter cut-off frequency and filter-order as two adjustable parameters, and the Outbound and Inbound bin threshold parameters as a further ten adjustable parameters (ignoring the threshold parameters for -1.5g, +5.0g, and +6.0g since I have no data for those levels as yet), I ran an optimisation algorithm (in MATLAB using the fminsearchbnd algorithm) to search for the set of 12 parameter values which minimise the difference between the SSL readings and the legacy readings when applied to the raw acceleration trace for Flight #5 (as depicted by the blue curve in Figure 1).

The results of the optimisation are contained in Table2.

Low-pass Filter Parameter	Value
Cut-off frequency (Hz)	1.85
Filter order	9

Bin	-1.5g	-0.5g	+0.25g	+1.75g	+2.5g	+3.5g	+5.0g	+6.0g
Outbound	-1.47g	-0.47g	+0.19g	+1.73g	+2.45g	+3.4g	+4.97g	+5.97g
Inbound	-1.53g	-0.53g	+0.19g	+1.91g	+2.45g	+3.55g	+5.03g	+6.03g

Table 2. Adjusted low-pass filter parameters and bin thresholds resulting from numerical optimisation performed on the fatigue meter readings from Flight #5. Note: the italicised values are hard-coded, i.e., were not included in the optimisation since no relevant data exists.

Applying the bin-counting algorithm with the parameters from Table 2 to the raw acceleration data from Flight #5 gives the results shown in Table 3 where the average performance with the optimised parameters is now 98% compared with 95% from before (Table 1).

Flight #5	-1.5g	-0.5g	+0.25g	+1.75g	+2.5g	+3.5g	+5.0g	+6.0g
SSL (optimised)	0	5	19	32	22	4	0	0
Legacy	0	5	19	36	22	4	0	0
% Error		0%	0%	-11%	0%	0%

Table 3. Comparison of the SSL and legacy fatigue meter delta readings for Test Flight #5 using the optimised software configuration parameters in Table 2. The average accuracy [defined as 100-average(abs(%Error))] is now 98%.

G-meter comparison

The SSL outputs for max-g and min-g for this aerobatic sortie (Flight #5) were +4.5g and -1.2g, respectively. Figure 4 shows the corresponding readings from the analogue G-Meter in the Bulldog cockpit panel, which are seen to be approximately +3g and -0.51g, respectively. As with Flight #4 in PART THREE, 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.5g 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 #5, suggesting a maximum value of approximately +3g and a minimum value of approximately -0.51g 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.5g and -1.2g, respectively, which seem to be more trustworthy.

Test Flight #6

Flight profile: aerobatics

I performed another aerobatic sortie test with both the legacy fatigue meter and the SSL prototype installed, configured in AIRSPEED SWITCH MODE and NOMINAL DATA MODE, with the optimised parameters from Table 2 deployed in the SSL software. The acceleration trace for this sortie is shown in Figure 4.

Figure 4. Z-axis acceleration measured by the SSL every 0.1 seconds over the entire Flight #6. The spikes coincide with aerobatic manoeuvres. The sortie has a similar dynamic profile to the previous flight (Figure 1).

SSL versus legacy fatigue meter readings

After the 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 4. As with the Flight #5, 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, with an average accuracy of 97%.

Flight #6	-1.5g	-0.5g	+0.25g	+1.75g	+2.5g	+3.5g	+5.0g	+6.0g
SSL (optimised)	0	5	17	46	27	4	0	0
Legacy	0	5	18	46	25	4	0	0
% Error		0%	6%	0%	8%	0%

Table 4. Comparison of the SSL and legacy fatigue meter delta readings for Test Flight #6, an aerobatics sortie, using the optimised software configuration parameters in Table 2. The average accuracy [defined as 100-average(abs(%Error))] is 97%.

Simulated extreme bins

Since the flight tests didn’t extend to the very extremes of the dynamic envelope, it is helpful to check that at least the counting algorithm works correctly on the extreme bins by simulating the levels in software and applying the algorithm accordingly. Figure 5 contains the same raw acceleration trace from Figure 4, but with values of +6g and -1.5g artificially injected in place of the existing extremal values.

Figure 5. Artificially modified raw acceleration trace from Figure 4. The modifications extend the envelope to the extremes of the fatigue meter range i.e., +6g and -1.5g in order to test the bin-counting algorithm at these extremes.

Applying the bin-counting algorithm with the parameters in Table 2 to this modified trace gives the results contained in Table 5. It is seen that the algorithm correctly registers the unit increments in the +6g, +5g, and -1.5g bins (highlighted in cyan in the table).

Flight #6 (modified)	-1.5g	-0.5g	+0.25g	+1.75g	+2.5g	+3.5g	+5.0g	+6.0g
SSL algorithm	1	5	17	46	27	4	1	1

Table 5. SSL bin-counting algorithm using the software configuration parameters in Table 2 applied to the artificially modified Test Flight #6 trace from Figure 5.

Test Flights #6 and #7

Flight profile: aerobatics

I performed two more aerobatic sortie tests with both the legacy fatigue meter and the SSL prototype installed, configured in AIRSPEED SWITCH MODE and NOMINAL DATA MODE and recorded the acceleration traces for these sorties, as shown in Figures 6 & 7.

Figure 6. Z-axis acceleration measured by the SSL every 0.1 seconds over the entire Flight #7. The spikes coincide with aerobatic manoeuvres. The sortie has a similar dynamic profile to the previous aerobatic flights.

Figure 7. Z-axis acceleration measured by the SSL every 0.1 seconds over the entire Flight #8. The spikes coincide with aerobatic manoeuvres. The sortie has a more aggressive dynamic profile compared with the previous aerobatic flights.

Further optimisation

Multiple flights combined

Given that the goal of the SSL fatigue meter is to replicate the legacy fatigue meter bin counts over all flights taken together, it makes sense to optimise the SSL algorithm using the data spanning multiple flights rather than from a single flight at a time. To this end, Figure 8 shows the SSL raw acceleration traces from Flights #5,#6,#7, & #8 concatenated together into a single trace.

Figure 8. Composite raw Z-axis acceleration trace obtained by concatenating the individual traces from Flights #5,#6,#7,#8.

Separate optimisations per bin

As well as utilising the data from multiple flights in the optimisation process, I’ve provided additional degrees-of-freedom by enabling a separate lowpass filter design per acceleration bin, and by running the optimisation algorithm on each bin separately. The resulting optimal parameters are contained in Table 6.

Bin	-1.5g	-0.5g	+0.25g	+1.75g	+2.5g	+3.5g	+5.0g	+6.0g
Low-pass cut-off frequency (Hz)	1.85	1.075	1.6145	1.30	1.5668	1.075	1.85	1.85
Low-pass filter order	9	6	5	5	8	6	9	9
Outbound threshold	-1.47g	-0.455g	+0.1897g	+1.8355g	+2.45g	+3.4g	+4.97g	+5.97g
Inbound threshold	-1.53g	-0.54g	+0.1927g	+1.9156g	+2.4748g	+3.5g	+5.03g	+6.03g

Table 6. Adjusted low-pass filter parameters and bin thresholds resulting from numerical optimisation performed per bin on the concatenated raw fatigue meter readings from Flights #5,#6,#7,#8 (displayed in Figure 8). Note: the italicised values are hard-coded, i.e., were not included in the optimisation since no relevant data exists.

Deploying the optimal parameters from Table 6 into the SSL bin-counting algorithm and applying to each of the traces for Flights #5, #6, #7, #8, and also to the combined trace from all four flights together, gives the results shown in Table 7 alongside the corresponding legacy delta readings.

Flight #5	-1.5g	-0.5g	+0.25g	+1.75g	+2.5g	+3.5g	+5.0g	+6.0g
SSL	0	6	20	32	21	4	0	0
Legacy	0	5	19	36	22	4	0	0
% Error		20%	5%	-11%	-5%	0%

Flight #6	-1.5g	-0.5g	+0.25g	+1.75g	+2.5g	+3.5g	+5.0g	+6.0g
SSL	0	5	17	47	23	4	0	0
Legacy	0	5	18	46	25	4	0	0
% Error		0%	-6%	2%	-8%	0%

Flight #7	-1.5g	-0.5g	+0.25g	+1.75g	+2.5g	+3.5g	+5.0g	+6.0g
SSL	0	3	10	26	14	3	0	0
Legacy	0	3	11	26	14	4	0	0
% Error		0%	-1%	0%	-5%	-25%

Flight #8	-1.5g	-0.5g	+0.25g	+1.75g	+2.5g	+3.5g	+5.0g	+6.0g
SSL	0	6	17	53	35	13	0	0
Legacy	0	7	16	50	32	12	0	0
% Error		-14%	6%	6%	9%	8%

Combined #5,#6,#7,#8	-1.5g	-0.5g	+0.25g	+1.75g	+2.5g	+3.5g	+5.0g	+6.0g
SSL	0	20	64	158	93	24	0	0
Legacy	0	20	64	158	93	24	0	0
% Error		0%	0%	0%	0%	0%

Table 7. Comparison of the SSL and legacy fatigue meter delta readings for Test Flights #5, #6, #7, #8 and the combination of all four, using the further-optimised software configuration parameters in Table 6. The average accuracy [defined as 100-average(abs(%Error))] for each individual trace is now 92% (Flight #5), 96% (Flight #6), 97% (Flight #7), 92% (Flight #8), and 100% (combination of Flights #5, #6, #7, #8) .

The results are very encouraging because these further optimisations have resulted in 100% accuracy between the SSL and legacy counts when the four flights are considered together (and better than 94% on average for the individual flights).

Next steps

The convergence between the SSL and the legacy readings across the dynamic envelope, confirms that the SSL is in principle working correctly and that the optimised parameters effectively represent an accurate “reverse-engineering” of the dynamic response of the legacy fatigue meter. That said, I’ll continue to test across future test flights (and fine-tune the parameters as necessary). Also, I’ve not yet achieved flight loads lower than -1.2g and higher than 4.5g (I can’t push or pull hard enough!) so have been unable to test the acceleration sensitivity at the extreme ranges of the fatigue meter, though as noted above, from simulated data, the bin-counting algorithm at least is found to perform as expected at these extremes.

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’ve procured a 3D printer for this and will report on progress in my next post.
• Make any final adjustments to the software based on further flight tests — ideally across the full dynamic envelope of the fatigue meter (+6g, -1.5g) and against different legacy instruments (i.e., rather than just the single instrument used in all tests so far).
• If the SSL continues to perform accurately and reliably, 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). This may be required to reach the extreme ranges (+6g, -1.5g) if unable to achieve those in flight.