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

Also see (now published)

PART TWO

PART THREE

PART FOUR

PART FIVE

PART ONE

In a previous post from 8 years ago I present my musings on the Bulldog Fatigue Meter. A couple of (expensive) three-yearly overhaul cycles have passed since then, and the next one is coming up. So it got me thinking “surely there is a better way of doing this?”. In this post, I describe a prototype replacement device which I’m currently building. If it proves to perform as expected in terms of accuracy and reliability, the ultimate intent would be to get it approved as a suitable replacement for the old device (hereafter referred to as the “legacy” device). I call the new device the “FlyLogical Solid State Laboratory (SSL)” because the technological platform is versatile and extensible, and can potentially be used for more than just a fatigue meter. Also, the abbreviation “SSL” is a play on “Suitable System of Levers”, see that previous post for the explanation.

Design goals

The main design goals for the new Fatigue Meter are summarised as follows:

• Utilise a modern solid-state accelerometer with a digital readout i.e., no moving parts whatsoever in the device, eliminating the need for routine / periodic maintenance / overhaul
• Include an electronic self-test at boot-up so that the device can report its health on every use cycle. If it generates a healthy signal, the device is deemed serviceable. If it generates an unhealthy signal, it would be deemed unserviceable (and only then would require technical attention).
• Incorporate a wireless connection to a mobile phone to (i) facilitate convenient retrieval of the Fatigue Meter readings per flight (as well as the ability to download the entire stored archive); (ii) monitor the health of the device via an on-screen health diagnostic report
• Compatibility with the existing Bulldog Fatigue Meter power supply and airspeed switch for “plug-and-play” convenience when it comes to replacing the legacy device

Solution architecture

Solid-state accelerometer

There are many available on the market. I’ve chosen the LIS331 from STMicroelectronics on account of the following key features (see the datasheet for full list of features):

• Dynamically selectable range ±6g/±12g/±24g
• Embedded self-test
• Digital output interface
• Low cost (USD 13 / GBP 9)

Figure 1 The LIS331 solid state accelerometer (still in its packaging) in the palm of my hand, illustrating how tiny it is. The accelerometer is the integrated circuit (black chip) located at the centre of the red breakout board.

Raspberry Pi host platform

For interfacing to the accelerometer, I’ve chosen the Raspberry Pi host platform on account of the following key features:

• Flexible digital bus (the General Purpose Input/Output or GPIO bus) for interfacing to external devices such as the LIS331
• Built-in Wi-Fi capability (for facilitating the wireless connection to a mobile phone)
• Convenient to program using the Python language
• Small physical footprint, low-power consumption
• Low cost (USD 88 / GBP 65)

Building the prototype

Breadboard

Figure 2 shows the prototype SSL.

Figure 2 SSL “breadboard” prototype. The core of the instrument is the LIS331 accelerometer which can be seen dangling from its connecting wires, visible at the centre of the image (the red breakout board from Figure 1). For convenience when laying out the circuit design, the LIS331 is soldered to a GPIO “wedge” (the black T-shaped breakout board) which is in turn connected to the Raspberry Pi Model 4 B (top right of image) via the ribbon cable. As well as the accelerometer, I’ve incorporated a pair of LEDs and a beeper (plugged-in to the white breadboard) for conveying status information without the need to connect the mobile phone. This will allow the aircrew to instantly check the status of the fatigue meter whilst airborne without the distraction of the mobile phone. I’ve also wired-in a toggle button to emulate the effect of the airspeed switch. For now, this simply toggles the data collection process to test that the airspeed interrupts are managed correctly in software. It doesn’t actually cut power to the device. This will need to wait until I’ve sourced and incorporated the uninterruptible power supply (discussed later in the post). Bottom left in the image is the (“Splinktech”) voltage regulator which converts 28V dc down to 5V dc required by the Raspberry Pi. Top left in the image is a Hewlett Packard laboratory power supply, emulating the Bulldog 28V bus, providing power to the voltage regulator which in turn powers the Raspberry Pi via its standard USB-C power connector.

Software programming

There is a large active community of “makers” who implement hardware/software projects on the Raspberry Pi. As such, there is a great deal of information available online, including sample Python code. Utilising these resources, it was straightforward to write the software kernel to interface to the LIS331 accelerometer via the Raspberry Pi GPIO bus. The following video snippet shows a screenshot of the real-time capture of 3-axis accelerometer data from the LIS331 via the Raspberry Pi. Notice the Z-Axis value of (close to) +1g, obtained because the accelerometer Z-Axis happens to be aligned close to the local vertical. You might ask why the registered value is slightly above +1g when the maximum it should be is 1g when stationary on the Earth’s surface ? As noted in the datasheet for the device, taking the average from the two Z-axes measurements (i.e., the positive and the negative) should eliminate the bias (so turning the device upside down will result in a reading slightly less than 1g).

You can see from the code comments at the top of the screenshot that the code was adapted from open-source community contributions (many thanks to jenfoxbot for getting me started on this hardware/software combination).

Accelerometer real-time readouts from the benchtop prototype SSL

Acceleration threshold counting algorithm

The acceleration measurements need to be converted to counts within the “bins” [-1.5g, -0.5g, 0.25g, 1.75g, 2.5, 3.5g, 5.0g, 6.0g] as defined for the legacy device and the Bulldog fatigue index (FI) calculations. Without knowing the internal details of the legacy device’s gating and counting logic, I’m going to assume a simple “threshold” counting approach, summarised as follows:

• Only a single axis is used in the counting. This is the local vertical axis (which measures +1g in straight and level flight). By careful positioning of the accelerometer within its housing box, and careful alignment of the box in the aircraft, the local vertical will correspond to a singe axis of the three-axes accelerometer readouts
• Set the full-scale range of the accelerometer to ±12g from the possible values of ±6g/±12g/±24g thereby ensuring that the allowable loading envelope of the Bulldog is fully captured (-3g to +6g). Note, it may be acceptable to set the accelerometer to ±6g (which would prove higher resolution over the range of interest) but by choosing ±12g we can be sure that the upper bin +6g is fully covered.
• Set the intrinsic sample rate of the accelerometer to 50Hz (from the possible range of 0.5 Hz to 1kHz) and down-sample the readout via the GPIO bus to 10Hz, thereby providing a measurement every 0.1 seconds to the bin counter. Process the bin counts in batches of 100 samples which corresponds to 10 second chunks (at 10Hz). This combination should provide sufficient bandwidth to capture the dynamic load transient in flight, whilst not overly taxing the Raspberry Pi resources (CPU, data bus, etc).
• For those bins which record accelerations greater than 1g, the count for a given bin will be incremented by one each time the (single axis local vertical) acceleration passes through the given threshold (bin value) in an upward direction (downward passes will be ignored)
• For those bins which record accelerations less than 1g, the count for a given bin will be incremented by one each time the acceleration passes through the given threshold in a downward direction (upward passes will be ignored)

The threshold counting algorithm was straightforward to implement in software. Comparative testing (legacy and SSL, side-by-side) will determine if this simple approach is valid, or if a more complex algorithm is required.

Health self-check

As per the design goals, a key feature of the SSL is to eliminate the requirement for periodic overhaul (e.g., every three years for the legacy device), relying instead on internal health-check diagnostics before each flight. As per the datasheet, the LIS331 incorporates such a self-test functionality. It is triggered by sending a signal to the device to instruct it to (electrically) apply calibrated forces along each sensing axis. By checking that the resulting sensed values fall within the published expected range, the health of the accelerometer can be definitively verified. The sign (direction) of the calibrated forces can be flipped, allowing testing to be performed along both directions of each sensing axis. It was straightforward to implement the self-tests in Python in accordance with the datasheet, and incorporate them in the overall SSL software stack.

Wi-Fi, web-server & web-app

As per the design goals, the SSL should provide wireless communication with mobile phones to facilitate convenient transfer of the meter readings and health reports. The Raspberry Pi incorporates both Bluetooth and Wi-Fi for wireless connectivity. I decided to use Wi-Fi owing to its greater flexibility.

Configuring the Raspberry Pi as Wi-Fi hotspot

This is a common usage of the Raspberry Pi and is straight forward to configure. For the SSL, I have configured the Raspberry Pi as a private Wi-Fi hotspot i.e., reachable from connecting devices but with no public internet access. Figure 3 shows the SSL Wi-Fi network (named “FlyLogicalSSLWiFi”) available via my Android mobile phone (on iOS devices, the SSL hotspot similarly appears in the list of available networks).

Figure 3. SSL Wi-Fi hotspot. Simply connect to “FlyLogicalSSLWiFi” from any mobile device to establish a private wireless connection (i.e., without internet) between the SSL and the mobile device. This connection allows transfer of meter readings and health reports from the SSL to the mobile device.

Web-server & web-app

Having established a Wi-Fi connection, the next key question is how to communicate in software between the SSL and the mobile device. My first instinct was to create a traditional “mobile app”. However, that would entail writing separate code for each mobile platform (i.e., Android and iOS, etc). There are software technologies to assist with this (e.g., Xamarin, Flutter, ReactNative, Ionic, etc) which facilitate code-reuse between the mobile platforms. But in my experience with all of these technologies, none allow for 100% code re-use, so there is inevitably a need for “last mile” programming specific to each platform. Moreover, for iOS and Android, there is a need to interface with the respective App Stores which brings its own bureaucracy to the process.

So, I decided instead to build a web-app — which utilises a browser-based user-interface and a suite of web pages hosted on the device. This is effectively a universal solution since every modern smartphone incorporates a browser. Moreover, it means that any device with a Wi-Fi connection and a browser can access the SSL: not just an iOS or Android phone/tablet. For example, a Windows-, Mac-, or ChromeOS- laptop.

The only (minor) disadvantage of using a web-app as the user-interface between the SSL and the mobile device is the consequent need for the SSL to host a web-server in order to serve the web pages for consumption by the web-app. But this really is a minor disadvantage because it is a common use of the Raspberry Pi to host a web-server. As such, I have configured the SSL Raspberry Pi to run the Apache web-server (which along with nginx is one of the most popular web-servers in the world). A key benefit of using Apache is the ease of deployment of PHP-based web-apps. PHP remains one of the most popular web development languages. It is easy to program, so I’ve chosen it for the SSL web-app pages. Figures 4 & 5 show screenshots taken from my mobile phone of the prototype SSL web-app main page and system-health page, respectively. Figures 6 & 7 show screenshots of the downloaded meter readings archive and detailed health report, respectively.

Figure 4 Prototype SSL web-app main page as viewed from my Android phone via the SSL Wi-Fi connection. This page contains the meter readings and totals (accelerometer bin counts) pertaining to the most recent data-capture session (or flight, once in operation). The counts displayed here were created by manually shaking the SSL on the bench (!). The “click here for detailed Health Report” link leads to the page shown in Figure 5. The “Click here to download archived Meter Readings” link triggers a download (from the SSL to the mobile phone) of the meter readings archive, the contents of which are shown in Figure 6. The archive data file is physically stored on the Raspberry Pi micro-SD card and is therefore permanent (i.e., survives power recycles) and can be transferred from the SSL to the mobile phone during any Wi-Fi session.

Figure 5. Prototype SSL web-app system health page as viewed from my Android phone via the SSL Wi-Fi connection. This page contains details of all aspects of the SSL system health as of the latest boot-up, including the results from the accelerometer self-tests. The “_self_test_A” and “_self_test_B” pertain to switching the sign (direction) of the self-test calibrated forces. The “accelerometerIsHealthy” flag is set to “1” (pass) only if the self-test measurements fall within the published ranges from the LIS331 datasheet. The “click here to download Health Report” link triggers a download (from the SSL to the mobile phone) of the health report, the contents of which are shown in Figure 7.

Figure 6. Excerpt from the downloaded SSL meter readings archive which contains the chronological records of bin counts and totals for every data-capture session (aka flight, once in operation). The data is in json format for maximum portability.

Figure 7. The downloaded SSL health report (from Figure 5). Again, the data is in json format for maximum portability

Power supply considerations

SSL power consumption

Measuring the total power consumed using a power monitor plugged into the domestic mains plug which feeds the Raspberry Pi power supply suggests a nominal power consumption of 3W with the accelerometer, Wi-Fi hotspot, and web-server all operational (see Figure 8 ).

Figure 8. Measuring the total power consumed by the prototype SSL running on domestic mains power reveals a power consumption of 3W with all SSL functionality operational. Note this power number includes any power loss in the wall power supply unit (which is likely to be very low).

At a voltage of 5V feeding the Raspberry pi, this equates to a current of 0.6A which is well within the 2A circuit-breaker limit on the Bulldog fatigue meter power circuit. This implies that from an electrical load point-of-view, the SSL can be a plug-and-play replacement of the legacy unit. All that is required is a voltage regulator to convert the Bulldog nominal bus voltage of 28V down to the 5V input required by the Raspberry Pi. No re-cabling required (just a change in connectors).

Figure 9 shows a candidate voltage regulator which I’m testing.

Figure 9. An off-the-shelf dc-dc voltage regulator for converting the 28V from the Bulldog main bus down to the 5V required to power the SSL. The unit can be seen in Figure 2 (lower left in the image) where it is undergoing continuous testing, powering the prototype SSL . It generates no discernible heat (i.e., the unit is not warm to the touch, even after many days of continuous operation).

This is a compact, sealed unit (encased in resin, waterproof and contaminant-proof) which accepts a range of input voltage (12 to 28V dc) and generates a stabilised 5V dc output. Bench-testing with a dc power supply (emulating the Bulldog 28V bus) determines the output to be 5.25V, irrespective of fluctuations in the input voltage. With a current rating of 3.5 A this is more than adequate for the powering the SSL.

Airspeed switch

The most complex part of the power supply story is the need for a rechargeable battery pack to temporarily keep power flowing to the Raspberry Pi whenever the mains supply is cut. Such a power cut will be a routine occurrence. For example, whenever the crew selects “battery master switch off” or whenever the Bulldog airspeed switch detects a low airspeed and cuts power to the fatigue meter circuit. This is intentional behaviour to prevent the fatigue meter from recording the shock loads incurred when the aircraft lands. Likewise, the airspeed switch doesn’t provide any power to the circuit until the airspeed exceeds 73–76 kts (ref RAF Bulldog document AP-101B-3801-1), pertaining to being airborne. This is to prevent the fatigue meter from recording shock loads encountered during ground manoeuvres, taxying over bumpy ground, etc. This does raise the question about the airspeed switch cutting power whenever the airspeed falls below 65–68 kts when not intending to land. This can happen when practicing full stalls or aerobatic stall turns. In which case the fatigue meter would temporarily not be logging legitimate loads. But this is the case for the legacy device as well as the SSL (!)

The reason why interruptions in supply power need to be managed gracefully is that the Raspberry Pi, a fully-fledged computer in its own right, needs to be shutdown cleanly (just like a desktop PC). It is inappropriate — and could actually damage the system — if the power is simply cut without issuing the proper shutdown command to the operating system. By utilising a battery pack in the mode of an uninterruptible power supply (UPS), the power cycles can be managed properly.

I’m currently researching the options for the UPS implementation. Owing to the current global shortage in computer chips, there is a dearth in the supply of such components, so it could take some weeks to source the kit.

Building the flight unit

Having proven with the breadboard prototype that the design meets the requirements in principle, the next step was to build the components into a permanent hardware solution suitable for flight.

Figure 10 shows the result with all the components soldered to a strip-board specifically designed for the Raspberry Pi. Moreover, the SSL hardware is wholly contained on it’s own stripboard that connects to the Raspberry Pi via a stackable GPIO header. This physical modularity is a key benefit of the Raspberry Pi as a host platform. Note that the accelerometer (red breakout board) has been mounted in the geometric centre of the stripboard with the positive Z-axis pointing vertically downwards so that it reads nominal +1g in straight and level flight.

Figure 10. Build-out of the prototype SSL flight unit using soldered joints on a single piece of stripboard rather than the assortment of circuit boards used in the “breadboard” (Figure 2). The cables visible in the bottom of the image are for USB mouse & keyboard and wired networking. These make programming and testing the SSL much more convenient than the alternative approach of accessing the Raspberry Pi for development via wireless remote login. These cables will be absent under normal operation of the SSL when the only physical cable connection will be the power supplied (from the 5V end of the voltage regulator) via a USB-C connector to the Raspberry Pi. When the unit has been finalised, I will further secure all components and joints with (non-conducting) epoxy to provide additional physical robustness. The box for housing the device has not yet been selected since the required dimensions will depend on the choice of UPS which is still an open question. The housing box will be mounted on a frame that fits identically in the location (behind the glovebox in the Bulldog cockpit) currently occupied by the legacy unit. Note that the LEDs are mounted on long cables so they can eventually be position within the housing box behind cut-outs in a manner that they are visible through the perspex window in the Bulldog glovebox (in front of the fatigue meter location). In this way, the aircrew will be able to determine the status of the SSL by simply looking at the LEDs through the perspex window. The final layout of the voltage regulator and the power cable connections has still to be established (once the final dimensions of the housing box are known).

Testing

So far, all testing has been ad hoc, on the bench, whilst building and proving the circuitry and software. Basically, this has amounted to running the system continuously for days, and exciting the accelerometer by manually shaking the unit, checking that the bin counters are responding in the the recorded archive.

More formal testing will be required once the flight unit has been completed. My intention is to fly the SSL alongside the legacy fatigue meter on my Bulldog, and check that both devices give the same readings. In this way, the SSL will have been calibrated against a calibrated instrument (the legacy device).

To obtain approval, I expect that it may also be necessary to formally calibrate the new device using the same approach adopted for the legacy devices (ground-testing on a centrifuge etc). But the aim would be that this can be a one-off exercise by the relevant company (i.e., the replacement company for the now defunct Pandect). Thereafter there should be no requirement for recurring (e.g., three yearly) overhaul / calibration since unlike the legacy device, the SSL has no moving parts (i.e., no mechanical wear). So, if the SSL passes its internal health check on boot-up each time, it would be deemed fit for flight, irrespective of how many years in service. It is the same logic applied when determining whether any other avionics unit is fit for flight. Radios and GPS units etc., don’t need to be overhauled on a recurring basis. They are deemed fit to fly if they power-up properly and exhibit nominal behaviour. Only on failure are they serviced or replaced, irrespective of service life.

Next steps

From today’s perspective, the major next steps are as follows:

• Source the uninterruptible power supply (UPS), integrate it in the hardware and software stack
• Select a suitable housing box and mount the SSL components within it
• Flight test the SSL in parallel with the legacy device and compare the measurements
• 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 will report on progress in future post(s).