Also see (now published)
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.
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
- Dynamically selectable range ±6g/±12g/±24g
- Embedded self-test
- Digital output interface
- Low cost (USD 13 / GBP 9)
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
Figure 2 shows the prototype SSL.
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.
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).
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.
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 ).
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.
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.
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.
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.
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).