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

PART FIVE

This is a direct continuation of PART FOUR, picking up where I left off, with the design and fabrication of a suitable enclosure for the flight unit.

Enclosure design

Sketchup

Using the Sketchup web package (free online here) I designed the enclosure to house the SSL, see Figure 1.

Fabrication

3D Printer

I procured a Flashforge Creator 3 Pro 3D printer to fabricate the enclosure. This choice was driven by the desire to print in polycarbonate (filament type “PC”) — for strength — as well as polylactic acid (filament type “PLA”) — for prototyping. The printer is shown in Figure 2.

Printing the enclosure components

Given the complexity of the structure — with its various cutaways, internal shelves, etc — it turned out to be difficult to print the enclosure as a single monolithic structure. After a few failed attempts, I opted instead to split the job into multiple components which could then be assembled together later. Figure 3 shows the collection of individually printed components, pre-assembly.

Figure 3. 3D printed components for the SSL enclosure. For this prototype, I’ve selected PLA filament (a final production version will be printed in polycarbonate for added strength). The design incorporates hexagonal inserts with steel nuts glued-in for final assembly.

Assembly

Figure 4 shows the enclosure partially assembled with the internal SSL components visible.

Figure 4. SSL enclosure partially assembled, showing the internal mounting of the SSL components.

Figure 5 shows the fully-assembled SSL with the enclosure components bonded together using epoxy resin. For comparison, the legacy fatigue meter is displayed on the right..

Figure 5. Fully-assembled SSL enclosure (with the internal SSL components installed), alongside the legacy fatigue meter.

Installation

Figure 6 shows the SSL installed in the Bulldog aircraft in the location where the legacy fatigue meter is ordinarily installed. The new instrument is a plug-and-play replacement of the legacy instrument. No changes whatsoever are required on the aircraft.

Next steps

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

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

Bulldog, Flying

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

Bulldog, Flying

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)

Bulldog, Flying

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

PART TWO

This is a direct continuation of PART ONE, picking up where I left off. I start with the next major step being Source the uninterruptible power supply (UPS). I work through the integration of this into the device including the implementation of appropriate power and data modes. I next present the installation of the device within a suitable test enclosure mounted in the Bulldog cockpit in parallel with the legacy fatigue meter, including suitable power connectors. Finally, I present the results from the initial flight test.

PiJuice HAT

There are various options available for choice of UPS for the Raspberry Pi . I’ve selected the PiJuice HAT (Figure 1) which is a full-featured UPS with multiple technical benefits in addition to meeting the key requirement of providing battery backup power whenever the mains power is interrupted e.g., when the airspeed switch temporarily cuts the power.

Realtime Clock (RTC)

An RTC is required to ensure that the system date & time are maintained whenever the Raspberry Pi is in the shutdown state. This timekeeping is not essential for the fundamental functionality of the Fatigue Meter but is handy for display and for ordering the stored records in chronological order.

To this end, the PiJuice actually incorporates an RTC powered by its lithium-ion battery. However, this means that the PiJuice RTC may only keep running for a few days if the system happens to have been powered-down with the PiJuice battery in a low-charge state. This could be inconvenient, with the clock running out of power (and hence losing all sense of time) whenever the aircraft is idle in the hangar for days or weeks. So, I opted to install a separate RTC (Figure 2), independent of the PiJuice, which has its own button cell battery lasting many years.

Figure 2 A Realtime Clock (RTC) for the Raspberry Pi, independent of the PiJuice, with its own button cell battery lasting years. The unit I chose is the Adafruit DS3231 Precision RTC, costing USD 14 (GBP 10).

Hardware and software integration

Figure 3 shows the SSL Fatigue Meter prototype flight unit, modified from PART ONE, to incorporate the PiJuice HAT and the RTC.

Figure 3. Prototype SSL Fatigue Meter flight unit modified from PART ONE to incorporate the PiJuice UPS and the separate RTC. The various components are mounted within a modular frame which, in turn, will (eventually) be contained within a suitable protective enclosure. Visible at the top of the image are cables & connectors which will eventually be routed to the outside of the enclosure. These include (i) two leds to display system status; (ii) a push button (blue plastic button, upper left in image) to manually switch the unit on and off — which can be used to override the automated switching controlled via the Bulldog airspeed switch; and (iii) a micro usb connector to provide a separate source of mains power (e.g., via a phone charger etc) i.e., in addition to the mains power from the Bulldog airspeed switch circuit. I incorporated a diode to allow both the micro usb power supply and the airspeed switch mains power supply to connect to the PiJuice micro usb power supply in parallel (so there is no need to take care to disconnect either of the mains power supplies whilst the other is in use).

GPIO configuration for PiJuice

In order for the PiJuice HAT to correctly operate alongside the accelerometer and the separate RTC, over the shared i2c bus, it must be configured as shown in Figure 4.

Figure 4. Correct configuration of the PiJuice HAT in order for it to function correctly over the i2c bus which is shared with the accelerometer and the separate RTC. The EEPROM address has been changed from the default value of 50 to 52 (and EEPROM Write unprotect checked to enable the change to stick). The RTC address 68 for the clock built-in to the PiJuice is left “as is”. This clock is not used and is disabled by ensuring that the corresponding kernel is not loaded. Instead, the separate clock — which also resides at address 68 — is enabled by loading the appropriate kernel via the /boot/config.txt file, as shown in Figure 5.

Figure 5. The /boot/config.txt file must be edited as shown to load the appropriate kernel for the separate RTC. The i2c addresses are then correctly assigned, as shown in Figure 6.

Figure 6. When correctly configured, the i2cdetect command yields the result shown above. The accelerometer is assigned address 19, the PiJuice address 14, and the separate RTC address 68, replaced instead by UU which signifies that the clock kernel has been successfully loaded.

Auto-start via PiJuice

The PiJuice has been configured to enable the unit to automatically power-up whenever mains power is supplied. Fundamentally, this is to facilitate incorporation of the fatigue meter within the Bulldog airspeed switch circuit, exactly like the legacy fatigue meter. This auto-start behaviour was achieved as follows (essentially from trail-and-error because the documentation for the PiJuice in combination with Raspberry Pi 4 is incomplete):

Ensure that mains power is supplied only via the PiJuice micro usb connector, and not the Raspberry Pi usb-C connector.
Ensure that the PiJuice is configured as shown in Figure 7.

Figure 7. Correct configuration of PiJuice HAT “System Task” tab to enable auto-start of Raspberry Pi 4 whenever mains power is connected. The mains power must be supplied to the PiJuice micro usb connector and *not* to the Raspberry Pi usb-C connector.

RTC synchronisation

The RTC can be conveniently synchronised to the correct time by connecting the Raspberry Pi to the internet (via the ethernet cable). This only needs to be done once. Thereafter, the RTC will keep time as long as its button cell battery has charge, i.e., for many years of nominal use (when the battery eventually needs replacing, the time can be set manually via mobile phone connected to the Raspberry Pi WiFi hotspot, i.e., without the need for an internet connection).

The RTC is now the basis of timekeeping. In order for the Raspberry Pi to adopt the time from the RTC each time it boots up, the /etc/rc.local file needs to be edited as shown in Figure 8.

Figure 8. In order for the Raspberry Pi to synchronise its system clock with the RTC each time it boots up, the /etc/rc.local file needs to be edited as shown.

POWER and DATA modes

I’ve extended the python code (whose primarily function is to gather data from the accelerometer) described in PART ONE to provide the following modes of operation:

POWER MODES

AIRSPEED SWITCH MODE — this is the nominal mode of operation. The system is automatically powered on when the airspeed switch engages. If the airspeed switch then disengages temporarily, system continues to run on battery. If/when the airspeed switch re-engages, the system runs on mains again whilst the battery charges. If the period of running continuously on battery (i.e., when airspeed switch is disengaged) exceeds 30 minutes, or if the battery charge state falls below 5%, the system automatically shuts down.
MAINS BYPASS MODE — if power is provided via the micro usb adapter (e.g., from a phone charger etc), the system is automatically powered on and remains on until the power supply is removed and then the system automatically shuts down after 30 minutes running continuously on battery or if the battery charge state falls below 5%. All triggering from the airspeed switch is ignored when the micro usb power is connected. Therefore this mode should only be used for testing, or for charging the battery when parked, or for downloading meter readings to a mobile device when parked. Otherwise, erroneous readings will be recorded (e.g., due to taxying over bumps etc) which would nominally be ignored via the airspeed triggering.
BATTERY MODE — when no mains power is available via the airspeed switch circuit or the micro usb connector, the system can be powered up and run on battery alone. This is achieved by pressing (and quickly releasing) the externally-routed push button switch (visible in Figure 3). The system automatically shuts down after 30 minutes running continuously on battery or if the battery charge state falls below 5%. Alternatively, the system can be shut down manually by pressing and holding the push button switch for 10 seconds. Note: this manual shutdown can be used irrespective of whether the system is running on battery or mains: but if mains power remains connected, the system will automatically re-start after 60 seconds.

DATA MODES

NOMINAL DATA MODE — this is the nominal mode of operation used in combination with AIRSPEED SWITCH MODE for power. Whenever the mains power is engaged via the airspeed switch, the accelerometer readings are recorded and counted. In this state, the BLUE LED is lit and the RED LED is unlit. Whenever the mains power is dis-engaged via the airspeed switch, the accelerometer reading (and counting) are temporarily suspended, emulating the behaviour of the legacy fatigue meter. In this state, both the BLUE LED and the RED LED are lit. Also, whenever the mains power is dis-engaged continuously for 5 minutes, the currently running data gathering session is terminated, the acceleration counts logged for that session, and a new session started.
TEST DATA MODE — this is a special mode available for testing, and must be configured by editing the system configuration file stored on the device then rebooting. When running in TEST DATA MODE, the power settings are ignored (i.e., mains or battery treated identically), and the accelerometer readings are recorded and counted as long as the system is powered up. In this mode, the acceleration measurements can be tested in any power mode. For example, without any connection to the aircraft power (i.e., in MAINS BYPASS MODE or in BATTERY MODE). When data gathering in this TEST DATA MODE, the BLUE LED is lit and the RED LED is unlit. Using this mode, I was able to perform some basic functional tests of the accelerometer readout and bin counting whilst running on BATTERY MODE in my car, before testing in the aircraft (see later).

Battery health self-test

I’ve also incorporated self-tests of the PiJuice battery and power system and included these in the overall system health diagnostic report (described in PART ONE). If there is an fault in the battery or power system, the entire instrument is deemed to be unhealthy.

Test drive

To perform basic tests of the instrument, I took it for a test drive in my car (Figures 9 & 10). This enabled me to test the power modes which don’t require connection to the Bulldog airspeed circuit i.e., the MAINS BYPASS MODE and BATTERY MODE as well as the TEST DATA MODE. I was also able to functionally test the NOMINAL DATA MODE by emulating the action of the airspeed switch by manually connecting and disconnecting the mains bypass micro usb power cable.

Figure 9 Testing the basic functionality of the power and data modes in my car using a temporary enclosure (cardboard box!) for now. In the scenario depicted, the system is running in BATTERY MODE (no power cable connected) and TEST DATA MODE (blue led top-right of image).

Figure 10 Box closed, instrument fully self-contained, running on battery, with the accelerometer measuring bumps in the road.

Test flight

Temporary enclosure

In preparation for the first test flight, I graduated from the cardboard box of the road tests and built a temporary enclosure using foam-board in order to secure the instrument in the Bulldog cockpit. Eventually I will create a durable enclosure using, for example, an acrylic box, once the design of the instrument is stabilised. Figure 11 shows the foam-board enclosure (with the instrument inside), mounted in the same location in the Bulldog where the legacy fatigue meter is usually located (I temporarily removed the legacy meter in order to check that the new instrument would fit properly).

Figure 11. PSSL fatigue meter inside a temporary foam-board enclosure, mounted in the same location the legacy meter is usually located in the Bulldog cockpit i.e., under the fibre-glass cover (removed, not shown) situated behind the glovebox between the seats.

Figure 12 demonstrates that the SSL fits neatly in the Bulldog cockpit, and is visible through the perspex window in the glovebox, the same window which is ordinarily used for taking readings from the legacy fatigue meter. With the new instrument, the readings are uploaded to a mobile phone via WiFi, so there are no readings to be taken as such. Instead, the window is useful for observing the status leds on the new instrument, visible via plastic windows inserted in the foam-board enclosure front plate.

Figure 12. SSL fatigue meter mounted as in Figure 11, but now with the fibre-glass cover in place, viewed through the perspex window in the back of the Bulldog cockpit glovebox, the same window ordinarily used for taking readings from the legacy instrument. The perspex window is convenient for observing the status leds on the new instrument (illustrated here in the powered-on state). The meter readings for the new instrument are uploaded via WiFi to a mobile phone, replacing the need to take physical readings through the window.

Figure 13 shows a WiFi signal strength diagnostic measurement taken on a mobile phone when seated in the Bulldog cockpit. The signal strength from the instrument WiFi hotspot is wholly sufficient to establish network communication with the device. As long as the eventual permanent enclosure (e.g., fabricated from acryclic) has similar transparency to WiFi, network communication should be fine. Note: this need for WiFi transparency is a reason not to build the eventual enclosure from metal.

Figure 13. Strong WiFi signal from the SSL hotspot (“FlyLogicalSSLWiFi”) broadcast from within its foam-board enclosure located underneath the fibre-glass glovebox cover in the Bulldog cockpit.

Power connectors

For convenience, the power connection to the SSL should use the same connector as the legacy fatigue meter. It turns out that although the original (“Plessey”) connectors are no longer available they can be made to order via Lane Electronics (www.fclane.com). Figure 14 shows a male-female pair of connectors obtained from Lane Electronics.

Figure 15 shows a “splitter” harness I constructed using these connectors, enabling the 28 V power cable from the Bulldog airspeed switch to be used for powering both the legacy fatigue meter and the SSL fatigue meter in parallel.

Figure 15. A “splitter” harness constructed using the connectors in Figure 14 to provide power simultaneously to the old and new fatigue meters via the existing Bulldog power supply cable (fed from the airspeed switch).

Figure 16 shows the harness connected to the old and new fatigue meters (on the bench).

Figure 16 showing the harness from Figure 15 connected to both the old and new fatigue meters in parallel. The existing plug (situated in the Bulldog cockpit, just behind the passenger seat) which ordinarily connects to the legacy fatigue meter, will connect to the adapter shown at the bottom of the image.

Figure 17 shows both fatigue meters installed in the Bulldog, with the harness connected. This parallel arrangement is necessary in order to test the new instrument against the old. The eventual goal is for the new device to wholly replace the old, when it would then be mounted in the legacy location as in Figures 11 & 12. But for now, until approved, the legacy device must remain installed and operational, with the new device in a suitable location, running in parallel.

Figure 17 Both the old and new fatigue meters installed in situ in the Bulldog cockpit. The legacy instrument (not visible) is installed in its usual place behind the glovebox, under the fibre-glass shroud. The new instrument is attached (using velcro pads) to the armrest immediately above the location of the legacy device. The harness from Figure 16 is connected to both. The existing plug (lower-right in the image) which ordinarily connects to the legacy fatigue meter is now connected to the adapter, thereby providing power to both fatigue meters in parallel.

Telemetry monitoring mode

To assist with testing and debugging, I’ve created a mode of operation whereby the telemetry from the SSL can be monitored in real-time on a mobile phone via the WiFi hotspot. Specifically, I access the Raspberry Pi via the RaspController mobile app and run the fatigue meter software kernel inside a console window.

Pre-flight sense check

As an example of the use of telemetry, Figure 18 shows the accelerometer readouts and the bin-count values as they change during a “roll” manoeuvre as displayed in Figure 19. During this manoeuvre, the vertical acceleration measured by the accelerometer goes from +1g to – 1g and back again. This entire manoeuvre represents a single loading cycle (even though it comprises two passes — out and back — through each g level). If my understanding of how the legacy fatigue meter functions is correct (as discussed in PART ONE), this cycle should trigger an increment of 1 in each of the +0.25g bin and the -0.5g bin counts. This is indeed the case, as verified in the observed telemetry in Figure 18, implying that the computation has been correctly programmed in accordance with the assumed algorithm. However, if the underlying assumptions prove to be incorrect and the legacy instrument counts transitions through acceleration levels differently — and this will become apparent when testing the SSL alongside the legacy meter — I will need to modify the programming logic accordingly. But at least such software changes are straightforward once the algorithm is known.

This sense-check exercise represents a simple but effective end-to-end test of the SSL fatigue meter (albeit by activating only two of the g bins), in preparation for actual flight tests.

Figure 18. Mobile phone screenshot video capturing real-time telemetry from the SSL for test and debugging purposes. As the video progresses, observe how the bin_counts increase by 1 (for each of the -0.5 g and the +0.25 g bins) when executing the “roll” manoeuvre displayed in Figure 19.

Figure 19. Executing a “roll” manoeuvre (actually, a “half-roll” then back again due to practicality of holding the SSL in one hand and the camera-phone in the other) with the SSL operating wholly self-contained (i.e., in BATTERY MODE and TEST DATA MODE).

The maiden flight

I performed the maiden flight on 18 March 2022 from Ronaldsway Airport, Isle of Man (EGNS), with both the legacy fatigue meter and the SSL prototype installed as in Figure 17. The SSL was configured in AIRPSEED SWITCH MODE and NOMINAL DATA MODE. The flight comprised a standard take-off and climb-out to the local area, some “lightweight” general-handling (i.e., not a full aerobatics sortie) in order to exercise the accelerometer bin-counts in the non-extreme acceleration ranges, then return to base with a few circuits before a full-stop landing.

Observations during the flight

I made the the following observations during the 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 flight

After the flight, I downloaded the meter-readings archive from the SSL (via its WiFi hotspot to my mobile phone). These are displayed in Figure 20. Comparison with the delta readings from the legacy device are contained in Table 1. It can be seen that the SSL and legacy meters have been activated in the same acceleration thresholds (“bins”) as one another (which is good), but that the SSL counts are generally higher than the legacy counts, suggesting that the counting algorithm may have to be amended to bring the SSL measurements into alignment with the legacy measurements. Further flight tests are required to establish precisely what modifications are required.

Figure 20. Readings from the SSL fatigue meter following the maiden flight on 18 March 2022. Before the flight, the SSL had been reset to “zero” so the displayed session counts are the same as the total counts (and the delta counts). Table 1 shows these delta counts per bin for the SSL and the legacy fatigue meter.

	-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

Table 1. Fatigue meter delta readings from both the SSL and the legacy fatigue meters following the maiden flight of the SSL.

As well as the acceleration bin count readings, the SSL software has been modified to record the maximum and minimum accelerations from the flight (i.e., the “maxG” and “minG” values in Figure 20). These are seen to be +3.42g and -0.36g, respectively. Figure 21 shows the corresponding readings from the analogue G-Meter in the Bulldog cockpit panel, which are seen to be approximately +2.6g and +0.3g, respectively. The SSL values suggest wider extremes than the analogue instrument. Without independent calibration of both, it is not certain which is correct!

Figure 21. G-meter reading after maiden test flight on 18 March 2022, suggesting a maximum value of approximately +2.6g and a minimum value of approximately +0.3g. The corresponding readings from the SSL are are +3.42g and -0.36g, respectively (from Figure 20).

Next steps

I’m encouraged that the SSL worked end-to-end in-flight as expected and that the fatigue meter readings it generates are directionally correct compared with the legacy fatigue meter. The detail of the counting algorithm needs to be investigated through further tests and calibration, and I’ll report my findings in a future post. In summary, the following steps remain from the original list in PART ONE:

Select a suitable housing box and mount the SSL components within it (i.e., beyond the current prototype foam-board enclosure)
Make any final adjustments to the hardware and software based on the flight tests
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)

I’m also encouraged to discover that I’m not the only one using a Raspberry Pi in a “production grade” aerospace application: here is a project which uses a Raspberry Pi for the first time ever as a spacecraft flight computer.