Bulldog, Flying

A new Fatigue Meter for the Bulldog aircraft


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


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


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



A song for my Mum

Let’s travel on the Mothership
Going at the speed of light
Visit all our other worlds
Where everything’s alright

Lean against the wind and rain
Gaze across the sea
Singing songs from long ago
Dancing you and me

I’ll go to sleep and dream about
Our cottage in the sky
I’ll read the note you left me there
And promise not to cry

About caravans and riverbanks
And fishing rods and reels
Woolworths on the main street
Guitars and bicycles

Dinner table conversations
Dishes in the sink
Homemade Christmas decorations
And now, a final drink

Onwards to the end of time
We run this crazy race
See you at the poolside bar
Beyond the edge of space

Audio, Plugins

Stereo Panner for Ableton Live 9

Frustrated by the lack of proper stereo panning in Ableton Live 9, I built a VST plugin for this explicit purpose. I know there are (convoluted) ways to achieve this in Ableton Live 9, but it’s all too awkward. I also know that this is fixed in Ableton Live 10, but I’m not ready to migrate to that version yet.

Stereo Panner controls

The plugin is described in detail here, and you can download it (plus other plugins) for free from here (for Windows only).

Audio, Music

De-Noising Audio using Spectral Subtraction in MATLAB and Ableton Live

Last time I wrote about audio restoration using simple digital filtering (in MATLAB and Ableton Live). I’ve since received another old Havering recording from Walt. Again from an old cassette tape, this recording is rather noisy. In this post, I explain how I cleaned it up using a more elaborate technique than previously.

Again I used MATLAB for the algorithm development aspects of the process, in combination with Ableton Live for the audio and mix management.

The noise

Here is a clip of the lead-in to the show. The noise is apparent.

Snippet of the raw (noisy) recording

Figures 1 and 2 show the noise spectrum (over the full bandwidth and zoomed-in to the low-frequency zone, respectively) computed via the MATLAB pspectrum function.

Figure 1: Noise spectrum revealing the broadband nature of the background noise in the recording.
Figure 2: Noise spectrum, zoomed-in on the low-frequency regime, revealing the 60 Hz “power hum” plus a distinct peak around 1150 Hz in both channels and a lesser peak around 1700 Hz in the left channel only.

The noise has similar characteristics to the last time: some low-frequency “power hum” (Figure 2) plus a broad-band “tape hiss” over the extent of the audio/music bandwidth (Figure 1). Interestingly, the low-frequency power hum (Figure 2) comprises only the fundamental mode (at approximately 60 Hz) rather than the multiple harmonics observed last time. Also, there is a distinct peak around 1150 Hz in both channels and a lesser peak around 1700 Hz in the left channel only.

Suppressing the “power hum”

As last time, notch filtering was used to suppress the low-frequency peaks from Figure 2. However, rather than using Ableton Live’s notch filtering as I did last time, I used MATLAB. This allowed me to create a suite of filters which could be separately configured for the left and right channels (since as observed in Figure 2, the characteristics of the noise peaks varies between the channels). As a starting point, I used the MultiNotchFilter example “plugin” bundled with the MATLAB Audio Toolbox and extended it to have separate controls for each channel (creating what I call the MultiNotchFilterStereo “plugin”). Figure 3 shows a (partial) screenshot of the plugin configured to suppress the peaks identified in the spectrum from Figure 2.

Figure 3: Screenshot of the MultiNotchFilterStereo plugin (adapted from the MultiNotchFilter plugin bundled with MATLAB) loaded into the MATLAB audioTestBench. The plugin has ten notch filters per channel. Only the first seven of the left channel filter controls are visible in the screenshot (there are similar controls for each of the ten filters per channel). Only three of the notches are being used on the left channel (and only two on the right channel), corresponding to the three noise peaks (at 55 Hz, 1136 Hz, and 1702 Hz) in the left channel (and 55 Hz and 1168 Hz for the right channel).

Here is the result of applying the notch filtering to the original noisy clip:

Result of applying the notch filtering to the snippet of the raw (noisy) recording in order to suppress the low-frequency noise components. Comparing with the raw clip presented earlier, it is clear that the filters have had an audible effect on suppressing some of the components of the noise.

Suppressing the “tape hiss”

Instead of simple filtering used last time, I wanted to try something more sophisticated in an attempt to achieve improved broad-band noise suppression with minimal audible artefacts.

The approach adopted was to adapt the SpectralSubtractor “plugin” bundled with the MATLAB Audio Toolbox, again extended to have separate processing for each channel (creating what I call the SpectralSubtractorStereo “plugin”) since the original plugin catered for mono signals only. Figure 4 shows a screenshot of the plugin configured (by trial-and-error listening experiments) to suppress the broadband noise identified in the spectrum from Figure 2.

Figure 4: Screenshot of the SpectralSubtractorStereo plugin loaded into the MATLAB audioTestBench. The plugin (adapted from the SpectralSubtractor plugin bundled with MATLAB) performs noise reduction by spectral subtraction, applied independently to both channels, but with the same user-configurable parameters configured on both channels.

The algorithm works by subtracting a representation of the noise from the noisy signal in the frequency domain. In this case, the representation of the noise is a simple constant amplitude (band-limited) “white noise” model.

The core of the algorithm is encapsulated in the first line of the following two lines of MATLAB code:

mag_X_out = max (0, abs(X_in)-Mag2Subtract);

X_out = mag_X_out.*exp(li*angle(X_in));

where mag_X_out is the magnitude of the processed spectrum, X_in is the noisy signal spectrum, and Mag2Subtract is the user-selected “noise magnitude” (i.e., configured via the the “Noise Estimate” control in Figure 4). In the second line of code, X_out is the processed spectrum created by reuniting the modified magnitude mag_X_out with the original phase of X_in.

Not shown in this code snippet is the application of the Fast Fourier Transform (FFT) and its inverse — to convert to/from the frequency/time domains — nor have I included the machinery for managing the data buffers, since I wanted to emphasise the crux of the algorithm (rather than the utility code around it) — and moreover, I wanted to demonstrate how compact the MATLAB language is for implementing mathematical expressions applied to complex-valued matrices (such as X_in and X_out).

A schematic illustrating the spectral subtraction technique is shown in Figure 5.

Figure 5: De-noising via the technique of spectral subtraction. The plots are in the frequency domain (i.e., after the FFT computation). Note that these are not actual signal spectra, merely pictorial representations to aid the explanation. Also, just a single-channel (mono) signal is depicted here (in the actual processor, the same algorithm is applied independently to each channel). The number of frequency bins (and hence the frequency resolution for a given sample-rate) is determined by the length of the analysis frame (i.e., the number of samples, per channel, sent to the FFT in each successive computation, performed frame-by-frame over the entire signal duration), adjusted via the “Analysis Frame” control in Figure 4. The “Noisy signal” (blue) in the upper plot corresponds to abs(X_in). The “Noise model” (red) corresponds to Mag2Subtract. The “De-noised signal” (green) in the lower plot corresponds to mag_X_out. It has the value zero whenever the “Noisy signal” is below the level of the “Noise model”. Elsewhere, it has the value given by (abs(X_in) minus Mag2Subtract).

In a sense, the “0” branch in the expression for mag_X_out in the code snippet can be thought of as a frequency-dependent noise gate, whereby for each frequency bin, if the spectral magnitude is below the user-selected threshold (i.e., the “white noise” magnitude), the signal output is cut completely. For the other branch, if the spectral magnitude is above the assumed model noise threshold, then that constant threshold level (representing the “white noise” magnitude) is subtracted from each bin.

The noise threshold is user-adjusted by trial-and-error. Too low, the de-noising is not effective. Too high, and audible artefacts appear in the output as a characteristic “tinkling”. This invariably occurs when frequency-domain audio manipulation is pushed too far. Indeed, it can be used as an effect in itself e.g., vocoders and robotic voices, or in the (well-established) technique of cranking up autotune to the extreme. But for the present purposes of de-noising, the parameters have been adjusted such that maximal noise suppression is achieved with minimal perceivable adverse effects on the output signal. Note that the “Analysis Window” (i.e., the type of windowing used before performing the FFT), the “Analysis Frame” (i.e., the length of the data chunk sent to the FFT), and the “Frame Overlap” are commonly-used in spectral analysis (as described in many references, so not detailed here). Suffice it to say, for present purposes, these parameters were selected by trial-and-error (via subjective listening experiments) to give the best result on the audio file in question.

Here is the result of applying the spectral subtraction to the noisy clip using the settings displayed in Figure 4:

Result of applying the spectral subtraction to the previous clip (i.e., the one with the power hum already removed). Comparing with the original raw clip presented at the start, it is clear that the spectral subtraction algorithm is very effective for suppressing the broad-band noise. There is a little bit of “tinkling” evident in the output, but this is effectively masked by the music (once it starts playing).

“One click” plugin creation

Having built and tested the MultiNotchFilterStereo and the SpectralSubtractorStereo “plugins” entirely within the MATLAB environment, I then converted each of them to VST plugins using the “one click” conversion button provided in the MATLAB Audio Toolbox audioTestBench interface.

Additional tweaks to the mix within Ableton Live

I then loaded the VST plugins into Ableton Live, applied a noise gate in front of them, and some equalisation and dynamic range control downstream, as shown in the screenshot in Figure 6.

Figure 6: End-to-end plugin effects chain implemented in Ableton Live for this de-noising project. The first (“Short Cut” noise gate) and last (“Punchy Dance Master” compressor/limiter/equaliser component) are Ableton built-in plugins used to tweak the mix. The middle two components (“MultiNotchFilterStereo” and “SpecralSubtractorStereo”) are the VST plugins built entirely in MATLAB and are the core of the de-noising solution presented in this article.

This effects chain was applied to the noisy recording of the entire radio show. The resulting cleaned-up audio can be streamed from here.


The spectral subtraction method, using a simple flat “white noise” model, is found to be rather effective in removing broad-band “tape hiss” noise from audio/music recordings. Compared with simple digital filtering (covered in the previous post), the spectral subtraction method is found to be superior (from informal subjective listening trials).

As an enhancement of the technique, it would be interesting to try subtracting a shaped noise spectrum (rather than the simple flat value used here). This could be computed from a noise-only portion of the recording. Likewise, it would be interesting to compare the spectral subtraction approach with alternative techniques such as wavelet-based de-noising, machine-learning/deep-learning based de-noising, and adaptive filtering. All these can be explored via MATLAB.

MATLAB is again found to be a very powerful and convenient environment for prototyping the audio processing algorithms. Moreover, the (remarkable) “one click” creation of VST plugins from entirely within MATLAB makes it trivially simple to bring the algorithms into the Digital Audio Workstation (DAW) universe.


You may have noticed this logo in the compiled MATLAB VST plugin screenshots above. There is a history to this. Just over twenty years ago, I worked with a very talented programmer, Pepijn Sitter, from The Netherlands, to create an audio effects processing software product called WaveWarp. We distributed it under the trading name Sounds Logical. It was critically acclaimed, winning an Editor’s Choice Award from Electronic Musician Magazine in 2001.

WaveWarp enabled you to build your own audio effects from a library of modular building blocks. In that sense, it’s architecture resembled Simulink, but was fundamentally much faster (even compared with the compiled version of Simulink deployed via the RealTimeWorkshop) on account of the fact that the WaveWarp audio engine (and each individual module) was written in highly-optimised C code (making extensive use of pointer arithmetic) such that it could process multi-channel audio in real-time, sample-by-sample, on a typical desktop PC of the age. Moreover, it had full multi-rate functionality (via a library of decimators, interpolators, polyphase filterbanks, etc) allowing for elaborate mixed sample-rate designs. It used the FFTW (Fastest Fourier Transform in the West) library for spectral analysis, just as MATLAB does now. The WaveWarp software worked in standalone mode or as a DirectX plugin, and even had a real-time interface to MATLAB (akin to the audioTestBench available in the MATLAB Audio Toolbox today).

Alas, WaveWarp is now long gone. Moreover, I lost track of the source-code years ago, and I don’t have a running version. Also, it has almost completely faded from the internet. I could find only this review on PCRecording.com.

Anyway, given that I find myself delving into the world of audio processing again, I thought it fitting to revive the logo.

Audio, Music

Basic audio restoration using Ableton Live and MATLAB

Walt, the drummer from The Havering, just sent me an mp3 file of a Havering recording from a Stanford College Radio show in 1989. The mp3 file was created from the original recording on a thirty year old cassette tape, so the quality is not fantastic. The aim here is to clean it up and publish it on The Havering song archive.

My Digital Audio Workstation (DAW) of choice when working with audio clips and samples is Ableton Live which is the main environment I’ll use for this mini-project.

This project also presents a good opportunity to test drive the MATLAB Audio Toolbox.

Restoring the audio involves multiple stages, much of which is trial-and-error. Foremost is noise removal.

Noise Removal

Here is the start of the first song (“Trust”). The background noise is rather apparent during the non-music lead-in, continuing into the music:

Snippet of the raw (noisy) recording

Helpfully, because this is a recording of a live radio show, there are lulls in the music where only the noise is present. For example, here is the snippet of noise from the non-music lead-in (amplified for emphasis):

Just the noise lead-in from the previous snippet (amplified)

The first step in removing or suppressing the noise is to try and gain an understanding of it. Since we have the noise-alone snippet, we can analyse it in isolation (this isn’t always the case: often we only have the music-plus-noise available. But we are lucky here). Loading the noise file into MATLAB (via the audioread function) and utilising the pspectrum function to generate the noise spectrum yields the plot displayed in Figure 1:

Figure 1: Noise spectrum revealing the broadband nature of the background noise in the recording.

This is a “textbook” example of broadband noise whereby the power spectrum is effectively uniform over the frequency range of interest (i.e., over the audio range from 20 Hz to 20 kHz, approximately). It does drop off dramatically around 17 kHz or so, but even so, the noise level is effectively constant (and high) over the audio/musical range of interest, and so will be quite tricky to deal with. Listening to the noise, it appears to be classic “tape hiss”, prevalent in analogue recordings such as the cassette tape used in this recording.

It is helpful to zoom-in on the low-frequency portion of the chart and view on a log-scale, as displayed in Figure 2.

Figure 2: Noise spectrum, zoomed-in on the low-frequency regime, revealing the 60 Hz “power hum” and its harmonics

There is a series of distinct peaks. Using the MATLAB findpeaks function reveals these to be at the following frequencies (averaged across both channels): 60 Hz, 120 Hz, 180 Hz, 240 Hz, 300 Hz, 430 Hz, and 680 Hz. The majority of these (60, 120, 180, 240, and 300 Hz) are classic “power hum” (fundamental mode plus four harmonics) from the AC power supply (the recording was made in California, US, where the power-grid AC fundamental frequency is 60 Hz — rather than 50 Hz in the UK).

Suppressing the “power hum”

Since the frequencies are well-defined for the low-frequency “power hum” components of the noise, this suggests utilising a bank of notch filters tuned to each mode of the noise (i.e., to “notch out” each noise component). Ableton Live has a built-in 8-band equalizer which can be used for this purpose. See the screenshot in Figure 3 below where the equalizer has been configured as required.

Figure 3: Ableton Live equalizer component configured with multiple notch filters tuned to suppress the “power hum” harmonics from Figure 2.

Below are the “before” and “after” audio clips. The notch filtering is effective at removing the “power hum”. Note: with these compressed mp3 snippets in this blog article, the low frequencies are suppressed by the mp3 encoding algorithm, so you may have to turn the volume up to hear the difference. Even then, it may be difficult to perceive the differences, though they are readily apparent in the uncompressed WAV files in Ableton and MATLAB.

“Before”: snippet of the raw (noisy) recording (from earlier)
“After”: snippet after processing to remove the “power hum”

Suppressing the “tape hiss”

The simplest approach to suppress the remaining tape hiss (now that the hum has been successfully removed) is to implement digital filtering to target the frequencies where the noise is most apparent to human hearing. In future I may experiment with more sophisticated techniques (e.g., STFT-thresholding, wavelet-transform-thresholding, Deep Learning, adaptive filtering, etc).

But for now, my approach is to design a digital filter with the aim of suppressing the noise (as perceived by a human listener) as far as possible without adversely affecting the music to a significant extent. There will inevitably be a trade-off between these competing goals.

I could continue with Ableton’s built-in filters to experiment with filter design, but for demonstration purposes I’ll switch over to MATLAB which has an extensive library of digital filter design algorithms (via the Signal processing Toolbox and the DSP System Toolbox) which can be brought to bear. Additionally, the Audio Toolbox has real-time audio streaming capabilities which enable the algorithm-under-test to be inserted in a real-time stream to/from audio files or devices or both.

After some trial-and-error , I settled on a high-frequency band-stop filter. Moreover, I selected an algorithm which happens to be provided as one of the out-of-the-box plugin examples (namely, the “Shelving Equalizer”) bundled with the MATLAB Audio Toolbox in order to demonstrate those capabilities.

Figure 4 contains a screenshot of the Shelving Equalizer loaded into a MATLAB audioTestBench which I’ve configured to stream data from a source audio file, through the filters, and out to the audio interface (in this case, a Focusrite Scarlett 2i4 soundcard with ASIO drivers). I manually adjusted the filter parameters by trial-end-error on-the-fly whilst listening to the processed audio in real-time. Note that the low-frequency filter is disabled (by setting its gain to 0 dB).

Figure 4: The audioTestBench utility from the MATLAB Audio Toolbox configured with the Shelving Equalizer with its parameters tuned to suppress the high frequency “tape hiss” (the low-frequency filter is disabled).

Below are the “before” and “after” audio clips (in this case, “before” is not the original raw file, but rather the file with the hum removed from the previous step in the process). As can be heard, the filtering is effective at removing the high-frequency “tape hiss” (again, with these mp3 snippets, you may have to turn the volume up to hear the difference). There is nevertheless some noise remaining in the mid-frequency range which I was not able to filter out without adversely affecting the music.

“Before”: snippet with “power hum” removed (from earlier)
“After”: snippet after further processing to remove the high-frequency “tape hiss”

One-click plugin

A very useful feature of the MATLAB Audio Toolbox is the ability to create a VST plugin from an algorithm prototyped in MATLAB, by clicking a single button. For example, I converted the Shelving Equalizer into a VST plugin by clicking the “generate VST Plugin” button located on the audioTestBench graphical-user-interface. By copying the resulting dll into Ableton’s plugin folder, the Shelving Equalizer becomes available from within Ableton Live, as illustrated in the screenshot in Figure 5 below. This allowed me to process the “tape hiss” via the MATLAB filter design, without having to bring the audio tracks out of Ableton. A considerable convenience.

Figure 5: Shelving Filter designed in MATLAB (see Figure 4), then converted to a VST plugin (via one mouse-click in the MATLAB audioTestBench), and imported to Ableton Live.

Noise Gate

Being a recording of a radio show, there are many quiet intervals between songs (e.g., when the band is introducing the next song, or the DJ is chatting, etc). It is during these lulls that the (remaining) noise is most apparent — and distracting. A simple technique to minimise this distraction is to use a Noise Gate to cut-out the audio when the volume falls below a given threshold. Then, when the music volume increases to performance levels, the music effectively masks the noise. This is a handy consequence of psychoacoustics: even though the noise is still there, we don’t perceive it to be at the same distracting level as we do during the lulls in the music.

Rather than simply deploying a noise gate, we can utilise a clever trick as described in this article. The trick is summarised as follows: (i) make a duplicate of the original noisy track, and keep the original aside for the moment; (ii) reverse the phase of each channel in the duplicate (i.e., multiply the amplitude of every sample by -1). Now, when played together, (i)+(ii) results in complete cancellation and total silence. That’s okay; (iii) pass the phase-reversed channel from (ii) through an inverted noise gate with its upper-and-lower thresholds configured such that only the noise passes through when the music volume is low, and nothing passes through when the music volume increases; (iv) play the original noisy track (i) together with the inverse-gated phase-reversed track (iii). The end result is complete silence during the lulls in the music. Away from the lulls, when the music is playing, the noise is still present, but the distracting noise at low music volumes is completely eliminated, giving the overall impression that the noise has been removed throughout (even though it actually hasn’t). This approach is a simplistic implementation of the technique of active noise cancellation (insofar as it utilises destructive interference of the noise waveform, albeit on the noise-only segments of the track, though without a separate noise measurement and adaptive filtering continually correcting the entire track).

Figure 6 contains a screenshot of Ableton’s built-in phase-reverser and inverted noise gate where the respective parameters have been specifically tuned (by trial-and-error) to implement (iii) on the noisy music recording in question.

Figure 6: Ableton Live’s phase reverser and noise gate (with “flip” enabled to invert the gate’s behaviour), with the thresholds tuned to allow only the noise to pass through the gate. When the music level rises, nothing passes through. The phase-reversed gated signal is added to the non-gated original phase signal such that the noise is totally cancelled at low levels e.g., in the lulls between songs.

Additional tweaks to the mix

Before applying the noise removal process, I reduced the overall dynamic range of the entire track by passing it through a compressor to suppress the peaks. Figure 7 contains a screenshot of the built-in Ableton compressor with appropriate settings for The Havering track (adjusted by trial-and-error).

Figure 7: Ableton Live’s built-in compressor applied to reduce the dynamic range of the original file before application of the de-noising algorithms.

I then applied the aforementioned de-noising processes, after which the resulting track seemed a little “lacking in body” compared with the original. To bring it back to life, I deployed a penultimate stage of filtering (equalisation): specifically, utilising Ableton’s built-in equaliser with its “Dance Master” configuration preset, inserted before the MATLAB-based Shelving Equalizer, as shown in the screenshot below in Figure 8. I also adjusted the overall gain of the final mix to maximise the available volume.

Figure 8 Equalization applied via Ableton Live’s built-in EQ to “revive the body” of the de-noised audio before application of the MATLAB-based Shelving Equalizer.

The final result

Original mp3 noisy recording of the entire radio show (approximately 24 minutes runtime)
Processed mp3 recording of the entire radio show after all stages of restoration have been applied (approximately 21 minutes runtime since silent lulls between songs have been removed)

In my opinion, comparing the noisy track with the cleaned-up track, the restoration has been a success. But it is subjective, so judge for yourself.

Here is the cleaned-up recording on Bandcamp where you can retrieve it in uncompressed FLAC format (better quality than mp3).


Basic digital filtering techniques have been shown to be somewhat effective for removing noise from an mp3 file of a live music recording transcribed from an old cassette tape, with minimal perceptible distortion of the underlying music signal.

The use of a digital audio workstation (e.g., Ableton Live) plus MATLAB is found to be a powerful combination in terms of extensive algorithmic capabilities and ease-of-workflow.

The ability to effortlessly create a VST Plugin from within the MATLAB Audio Toolbox is remarkable and very useful.

All of the mp3 audio snippets presented in this post were created using the MATLAB audiowrite function which supports such export. Another considerable convenience. By contrast, Ableton Live (at least Version 9 which I’m using) does not support mp3 export (!)

It would be interesting to compare the simple approach presented here with more advanced noise-processing techniques (as alluded to earlier), and with commercially-available 3rd party de-noising plugins (such as the much-acclaimed Rx 7).


After the concert, the organisers (Amnesty International) sent us a letter thanking us. Here is the letter. It was nice to receive it. The closing sentence makes mention of the very cassette tape used in this restoration project.

All audio content presented in this post is copyright The Havering 1989–2020, all rights reserved.

Audio, Music

Drummer Found

Last night I re-connected via WhatsApp with Walt Fulde, the drummer from The Havering. Walt happened across The Havering page on Bandcamp, as per my previous post.

Fortunately, Walt has previous form when it comes to responding to bulletin boards. Below are the original posters we displayed across the Stanford Campus when seeking a drummer almost thirty years ago. Walt responded, completing our four-piece. Zooming forward three decades, we will now embark on some transatlantic musical collaborations. Stay tuned.

Audio, Music

The Havering

I came across some old recordings of The Havering, a band I played in whilst at Stanford University in California. We were active from 1989 to 1991. Perhaps it could be claimed that the songs have aged reasonably well, or then again, maybe they haven’t ? Judge for yourself, if you so wish. All songs can be streamed from here (via BandCamp, a well-organised resource for musicians, took me only a couple of hours to post the songs up there today).



It’s been ten years since I started this blog. Until now, I’ve been using Blogger (from Google). I’ve finally made the decision to move away. Reason: the Blogger editor has steadily become unusable in my opinion. For example, it is now impossible to copy-and-paste text without the underlying html getting messed up. I persevered because of inertia. But the time has come.

So here I am now. On wordpress.com. Albeit another hosted blog site (since I don’t have the inclination to configure and manage a self-hosted site). I’ve also gone for a bit of a facelift. The old site seemed dark and closed-in. This is the opposite. Light and open (I hope).

For archive purposes, I will keep the existing posts on Blogger.

For convenience, here is my latest post from Blogger:

Deep Learning Analysis of COVID-19 lung X-Rays using MATLAB: Part 6 (June 2020)

…and here are my most popular articles and pages (in descending order of popularity):

Flight route planning, the old-fashioned way (September 2012)

Really Simple Moving Map Users Guide (April 2017)

iNavCalc Mobile App Users Guide (November 2013)

Training an Object Detector with TensorFlow (January 2018)

Garmin 795 Flight Plans now supported (December 2012)

When the wind blows, you always lose on the roundtrip (June 2011)

iNavCalc: a complete flight planning solution for SkyVector (March 2014)

Weather Prediction with Machine Learning (May 2018)

Convert a gpx file to a Garmin fpl file (March 2013)

RAF Leuchars Airshow (September 2013)

iNavCalc Web App Users Guide (April 2017)