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.

Figure 1 PiJuice HAT uninterruptible power supply which conveniently stacks on top of the Raspberry Pi via the GPIO pins. It incorporates a lithium-ion battery which enables the Raspberry Pi to keep running when the mains power is interrupted (e.g., when the Bulldog airspeed switch cuts the power when the airspeed is low). The Fatigue Meter circuit board (from PART ONE) stacks in turn on top of the PiJuice board. When the mains power is (re-)connected, the power control logic within the PiJuice directs power to the Raspberry Pi (and to the Fatigue Meter board), whilst also re-charging the lithium-ion battery. Testing under load suggests that the system can run on battery for approximately two hours on the standard battery shipped with the PiJuice, pictured above, with all functionality active (Raspberry Pi, accelerometer, WiFi, status leds). So there is no need to install a larger battery (an option available in principle with the PiJuice). The PiJuice HAT including the standard battery costs USD 69 (GBP 48).

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 14. Electrical power connectors (obtained from Lane Electronics) compatible with the legacy “Plessey” connector in the Bulldog. The female connector (top of image) is the same as the plug which connects the Bulldog airspeed switch to the legacy fatigue meter.

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.