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.
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.
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.
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.
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.
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.
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:
- 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.
- 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.
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.
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 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 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.
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 16 shows the harness connected to the old and new fatigue meters (on the bench).
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.
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.
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!
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.