Organ Pipe Clock

Clocks can come in various basic forms: traditional mechanical ones that need to be manually wound, electronic/quartz ones that are powered by batteries, and digital versions that are often provided integrated into microprocessors. These are most often driven by a crystal oscillator that is integrated into the microprocessor circuitry.

Clocks are also often characterised by their sounds: the striking on the hour number and possibly playing a tune to match. Traditionally these sounds are produced by a chime (or gong) mechanism, and now often from digitally recorded sounds and played on a small speaker.

This project was developed to build a clock using a microprocessor-based kit that will have a digital display, and with sounds generated from a set of mini organ pipes. The project provides a range of challenges to integrate a number of technologies into a working and attractive clock.

This project has been stimulated by some previously published projects, in particular:

1. A PVC Pipe Organ (https://www.instructables.com/PVC-Pipe-organ) that describes how a small-scale pipe organ could be built using PVC piping.
2. Let’s Build an Organ Pipe (https://cauliflowerlabs.blogspot.com/2014/10/lets-build-organ-pipe.html) that provides a useful description for how to make an organ pipe using PVC pipe.

There are, of course, many online resources about organs, their pipes, how they work and how they can be made.

The operation of this Organ Pipe clock is built with:

1. A microprocessor to provide the required clock data, including year, month, date and day, hour, minute and seconds; and to provide the digital display and to support user interactions to make the clock work effectively.
2. A graphic display with a touch sensitive screen to present the current date and time information to the observer and to manage user interactions.
3. A small set of organ pipes (8 off) to provide the required sounds for the clock. These will be activated by providing compressed air from a fan-driven air supply.
4. The option to set/correct the local (microprocessor) time by obtaining the current time from an NTP Time server using a WiFi connection.
5. A set of (8) buttons that would allow the organ pipes to be played manually (independently of the clock status).

The operation of the clock will have these features:

1. A display of the current date and time, updated every second, with a 12 or 24 hour time format.
2. The option to play a melody on the quarter, half and full hours.
3. The option to play a chime, for the hour number, on the hour.
4. Several melody and chime options, to be user defined.
5. An option to change the volume of the sounds played.
6. An option to set/update the local time with a time signal from an NTP server using a WiFi connection.
7. The ability to enter the required WiFi access point details as well as the local time zone offsets.
8. An option to manually play melodies on the pipes using the manual push buttons.

1. A suitable microprocessor. The one chosen was the Arduino GIGA R1 WiFi, though other more basic Arduino models may be suitable. The GIGA was chosen as it supports the touch display (see item 2) and it also has a built-in real time clock and a WiFi module. The software (as described below) requires about 1 mByte of program space and about 250 kByte for global variables. These requirements would need to be considered when choosing a suitable alternative microprocessor. Using the GIGA board does present some challenges over the simpler Arduino boards; one particular one relates to the time it take to compile a sketch. The GIGA compile times are much longer than might be expected when using the Ardiuino IDE.
2. A touch screen display. The one chosen was the matching Arduino GIGA Display Shield. It has a resolution of 480x800 pixels (52x 86 mm), 16.7 million colours with a capacitive touch sensor. It is large enough to build an effective user interface. This display does offer some real advantages over smaller alternatives.
3. A radial fan to generate compressed air. The one chosen was a Delta Electronics model BFM1012UHFF8. Cheaper fans may not be suitable as we need to be able to provide about 10 l/sec of air at a pressure of about 240 Pa to operate one of the organ pipes. This fan can deliver 10 l/sec at a pressure of 1400 Pa at full speed. This fan is rated at 8 Amp at 12 VDC. It also supports a PWM speed control that is used to change the volume of the sounds produced.
4. Solenoids to operate the 8 air-supply control valves. The ones chosen were the generic 12VDC, 10mm JF-0530B push-pull solenoids. These solenoids should only be operated for short periods of time (they can get quite hot), so playing notes of short tunes will be OK. Each solenoid is rated at 300mA.
5. 12 VDC relays (9 in total), one for the air supply fan and one for each of the solenoids. The ones chosen were suitable to be driven by 5VDC DIO signals from the microprocessor and could supply the current to drive the fan and solenoids. The solenoids draw 300 mA and the fan up to 8 A, both at 12 VDC.
6. A Digital port expander to accommodate 16 of the DIO signals; 8 for the solenoids and 8 for the manual play buttons. The one chosen was the MCP23017 that provides 16 DIO ports. This module was not absolutely necessary as there are sufficient DIO pins on the GIGA, but it simplified the wiring from the microprocessor to the pin sources/destinations for the play buttons and solenoids using the I2C bus.
7. Momentary (SPST) push button switches (8 off) for the manual play buttons.
8. A small 12 VDC (50mm) cooling fan to provide ventilation for the microprocessor and other electronics.
9. Power Supply: a 12VDC 150 W switchmode power supply, sufficient to run the microprocessor, fan and solenoids, with wiring cables and sockets for connection to an external AC power source.

A number of small components, and the containing box were and made using a CNC router and a 3D printer, as described later.

The design of the clock, selection and integration of the various components as well as the containing box was done with the aid of a 3D model. The wooden box is made from 19 mm thick timber cut from glued-up panels as it is difficult to get wide sections of timber off the shelf at your local timber supplier. The timber chosen was Eucalyptus marginata (Jarrah), but many timber varieties would be suitable.

The basic containing box consisted of three parts:

1. The front section to contain the microprocessor (surface mounted in a 3D printed made-to-measure box to display the date/time and to provide access to the touch screen), the power supply, other electronic components (digital port expander, relays and the small cooling fan). Also, the main air supply fan is mounted on the left side, and the 8 manual play buttons are placed on top of this section of the box.
2. The rear section that forms the air box that also contains the eight solenoid-driven valves to provide air to each of the pipes.
3. The top section holds the pipes in position.

To fully understand how the final clock fits together and how it might look a 3D model was first built. The various pieces for the box are shown in the three exploded views. The two CAD drawings provide the key dimensions for each part of the box. Note that in these drawings the required rebates in the panels are included, and the panels are dimensioned to allow for 3 mm deep rebates where required. The details of each panel can be obtained by downloading the DXF drawing and importing this into your favourite 2D drafting package. The wooden panels were machined with a CNC router that is most useful in achieving accurate sizes ready for assembly.

The left side panel has a hole with a protective mesh cover for air entry to the main fan, the exhaust from this fan goes though a hole in the central dividing panel into the air box. While the power supply has its own cooling fan, the air in the front section is exhausted out through the grid of holes on the right hand side. There is also a grid of holes in the front base panel to allow air to enter from under the front part of the box.

The air box, at the rear, is otherwise sealed to prevent air leakage (by close fitting the wooden panels).

The required dimensions for the containing box are governed by:

1. The sizes of the electronic components
2. The size of the fan
3. The size of the power supply
4. The size of the air box (to contain a small volume of compressed air).
5. The size of the solenoid driven air valves. For this design these are placed inside the air box, thus saving some space.

And, of course, the required overall appearance and proportions for the clock.

The parts of the box are screwed together, from the sides, bottom and rear so that the screws are not visible from the front. Screwing the panels allowed access to each compartment to insert/remove parts, and to fix problems. It is just practical to presume that it will be necessary to have easy access to all the parts to get the whole clock working.

The core part of the electronics is the Arduino microprocessor, the GIGA R1 WiFi, in this case, with its Graphics Shield. The graphics shield clips on to the rear of the microprocessor board leaving all the I/O pins exposed for circuit connections. For this design it was decided that the graphics display will be mounted on the front of the clock box. This is most conveniently done using a 3D printed case that can contain the microprocessor board and the graphics shield. The details of this case can be down loaded from here ready for 3D printing. This box comes in two parts, the front part exposes the touch screen, and the rear part exposes the GIGA I/O pins. The assembled case can then be mounted to the front of the clock box with bolts. This case also provides side access to the microprocessor's USB type C port for programming, the USB type A port for data access and the audio port. Only the first of this is used in the final design (see later for comments).

Other Arduino microprocessors could be used, and there are a range of touch screen options to match. The packaging and mounting of the display (on the front of the clock box) would need to be worked out to suit each option.

The digital port extender and the relays are mounted on a 3D printed bracket that fits into the front section of the box next to the power supply. This can be seen in the image showing all of these parts assembled in the front section of the box, viewed from the bottom.

The air valves are made from 3D printed parts with an aluminium channel upstand to which the solenoid is bolted (also serves as a heat sink). The air valves are placed inside the air box. Opening the air valve (with the solenoid) allows the compressed air to pass into the valve base and then out through the attached 8 mm tube that is connected to the base of the respective pipe. A neoprene pad fitted to the end of the solenoid is used to seal the valve when not in use.

The pipe consists of a length (varying) of 18 mm (ID) PVC pipe that has a mouth cut at its bottom end, then an end cap added with a wooden plug that allows the air that enters the base of the end cap to pass up the small gap in the pipe through to the upper lip of the mouth where the sound is generated.

The length of the pipe is adjustable (and thus tunable), by moving the top sleeve up and down (see Step 7).

To achieve the required functions, as outlined above, There needs to be a clear description of how the main components fit together. The circuit diagram shows the complete wiring connections. The 8 solenoids and the fan are driven by 12V relays. The 8 relay outputs and 8 manual button inputs are first wired to the digital port expander module which is connected to the I2C bus on the microprocessor.

This diagram shows:

1. The Arduino GIGA microprocessor and the used I/O pins.
2. The digital port expander connected to the I2C bus to provide 16 ports closer to the relays. 8 are inputs from the manual buttons, and 8 are outputs to the relays. Note that this module is optional as there are plenty of I/O ports on the GIGA, but is it used for convenience only to move the large number of wires away from the microprocessor.
3. The 9 relays, 8 of them to drive the solenoids for the air valves, and one to turn the fan on and off.
4. The 8 manual buttons
5. The SD card for data storage connected to the SPI bus.
6. The fan with a PWM connection to the microprocessor to control its speed.
7. A 12 VDC 130 W power supply to power the fan, the relays and the GIGA itself.
8. A 3.2 DVC button battery to power the on-board real time clock when the main power is off.

The circuit diagram is really quite simple, only complicated by the number of wires required. The relays and the port expander are all mounted on the 3D printed bracket as described above so the whole module can be inserted and removed as a single unit.

The software for the clock is perhaps the most challenging part of the project. It includes a number of user interface features and tasks that will both facilitate the operation of the primary time and sound functions as well as the user interface operations necessary to achieve these capabilities.

Programming the Arduino GIGA offers some challenges as it uses a STM32H747XI dual Cortex®-M7+M4 32bit low power Arm® MC processor (rather than the more commonly used ATMega series). While the GIGA is supported by the Arduino IDE, some of the commonly used libraries are not compatible and alternatives must be used. This offers some challenges for the software developer.

In addition, some of the features available in the GIGA were not able to be used as the author could not resolve the programming challenges, and there seems to still be some commonly identified problems described in the user forums. Over time these issues will be resolved. The particular features that might have been useful, but are not used in the project, are:

1. The USB-A port for loading externally generated files to define the melodies and chimes to be played by the clock could not be made to work.
2. The GIGA does not support the traditional EEPROM, but rather a KVSTORE that coule not be made to work effectively. The data storage requirements have been implemented using an SD card instead for storing of melody and chime data.
3. The graphics capabilities were limited to the GFX library rather than the LVGL more comprehensive (and more complex) option.

The software consists of a series of modules as follows:

1. PipeClock.ino: This is the main module and contains the library inclusions, the initial definitions and setup() tasks, the primary loop() process and some core utility functions.
2. buttonManager.ino: This module allows simple on-screen buttons to be defined and to manage their presses,
3. mainScreen.ino: This module displays the date and time and manages the playing of melodies and chimes,
4. optionsScreen.ino: This module provides the user with access to various settings; choosing the melody to be played, turning melodies and chimes on and off and accessing the NTP time server.
5. playScreen.ino: This modules allows the user to play the pipes from the manual buttons, and also to set the volume for the sounds.
6. timeServer.ino: This module connects to the local WiFi network, gets the time from a NTP server, and then updates the local clock time to match.
7. WiFiSetup.ino: This module allows the user to enter the required WiFi connection parameters (SSID and password), the local time zone (hours offset from GMT) and summer time offset (in minutes).
8. keyboard.ino: This module provides a simple on-screen keyboard to facilitate user data entry.

and the following header files to define the required data sets:

1. Logo.h: to define the logo when the clock is first powered up, encoded in RGB16 format.
2. kbdef.h: to define the key mappings for the onscreen keyboard.
3. Melodies.h: to define the melodies and chime definitions (as a fall back if the SD card fails).

The specific Arduino libraries required are detailed in the code, and it is of note that the LVGL library is required for some functions, but not the most recent version. Version 8.3.5 is used in this project as the more recent versions still (at this point in time) has problems with the GIGA.

The code modules are, mainly, structured to support the various user-interface screens. This allows a polling loop to be defined for each screen mode and thus access to buttons and other screen interactions to be managed for the currently displayed screen. Note that this approach is different from using an interrupt-driven design.

There are some notable parts of the code that deserve a special mention:

1. The Real Time Clock: It is perhaps surprising that the on-board RTC is not especially accurate (errors of many seconds per day). This appears to be a common problem with onboard RTCs. One solution is to use an external RTC (not a big deal). In this case it was decided to calibrate the onboard RTC using some purpose built code as described here.
2. For some, as yet, unknown reason accessing the SD card (to get the melody definitions) seems to be a little unreliable, so the (default) melody definitions were also embedded in the code. If access to the SD card fails, the melodies are loaded from the code. The first preference was to use the built-in USB-A port to load melody data, but could not be make to work by the author.
3. The WiFi parameters are also saved on the SD card so that they are remembered over power outages. They can also be set by the user for each installation location.
4. When using the GIGA-specific MBED and LVGL libraries any run time errors can cause the boot loader of the GIGA to "lock up" and the "flashing red LED" on the board appears. This must be reset by a double push of the reset button before uploading a new version of the code.

When the clock is first powered up the user-defined logo is displayed then, after range of initialisation tasks, the date and time is then displayed on the Clock screen. The logo provides a way of personalising the clock.

The Clock screen:

1. The date and time is displayed. The time can be in 12 or 24 hour mode (see Options screen) and is refreshed every second.
2. If enabled, the selected melody/chime is played on the pipes on the hour and at each quarter and half hours.
3. When a melody is to be played the fan motor is turned on, and allowed to come up to speed then turned off when done.
4. This screen has two buttons (bottom left and right): The <Play> button opens the Play screen, and the <Options> button opens the Options screen.

The Play screen:

1. Turns the fan on.
2. Enables the manual play buttons to allow the user to play a tune on the pipes.
3. Allows the user to change the volume in the range 0 to 9 (changes fan speed), with the up/down red arrows.
4. The <Clock> button turns the fan off and returns to the Clock screen.

The Options screen:

1. Enable/disable melody/chiming on the hour, half and quarter hours, using the check boxes.
2. Sets the time of day range when the melody/chiming is activated from the radio buttons.
3. Selects the melody by name.
4. Selects the 12 or 24 hour tine display.
5. This screen also has three buttons:
6. The <Clock> buttons returns to the Clock screen;
7. The <WiFi> button opens the WiFi settings screen.
8. The <NTP time> button gets the time from the NTP server and updates the local clock time. The NTP server is accessed via the available WiFi, it returns the current GMT time, and then the clock time is updated allowing for the local time zone and summer time settings.

The WiFi screen:

1. Allows the user view and to set the details for the local WiFi access point (SSID and password).
2. The user can set the local time zone (in hours from GMT) and the local summer time (in minutes)
3. Each parameter is set by pressing the relevant arrow buttons. These launch the on-screen keyboard where the user can enter Upper/Lowercase characters, digits and other special characters.
4. The <Clock> button returns to the Clock screen.
5. These parameter values are also stored on the SD card in a file named "WiFi.txt".

The touch selections used in the user interface design are of these types:

1. Simple rectangular buttons with a text label to go to another screen, and to select characters in the on-screen keyboard.
2. Coloured arrows to change the value of a parameter.
3. Check boxes to turn selections on and off.
4. Radio buttons to choose one of a set of options.

These are implemented in the code.

There are a number of traditional melodies that are used for chiming clocks. Historically they are mostly defined for the available bell/gong devices that have a limited range of notes. Some examples are Westminster, St Michael's and Whittington. This clock has just unique 8 notes.

There are, now, a number of key design decisions that are required:

1. The notes that can be generated on each pipe and their tuning to the required frequency.
2. The score that needs to be played to generated the required melody.

The first decision was to adopt a musical scale to describe the available notes. A diatonic scale was chosen as it provides a generally useful scale over 8 notes based on A4 at 440 Hz. This scale is then:

1. A4 (440Hz)
2. B4 (494 Hz)
3. C#5 (554 Hz)
4. D5 (587 Hz)
5. E5 (659 Hz)
6. F#5 (740 Hz)
7. G#5 (831 Hz)
8. A5 (880 Hz)

Choosing this scale is also dependent on the notes that can be achieved from the pipes in this clock that are likely to have a maximum length about 350 mm.

Given that the chosen PCV pipe to be used for the pipes has an internal diameter of 18 mm, the actual length of an open ended pipe to give a frequency of 440 Hz is given (approximately) by:

Length of pipe =velocity of sound/(2 x frequency) - 0.6 x diameter

that gives: L = 343 m/sec /(2 x 440 Hz) -0.6 x0.018 m = ~ 379 mm.

This calculation is only approximate as there are a range of design issues (choice of materials, shapes of the air paths and so on) that effect the final dominant frequency and the quality of the sound. The image shows an Excel spreadsheet for the calculations for the 8 notes, showing pipe lengths from 379 mm (for A4) down to 184 mm (for A5).

Given the uncertainties involved, each pipe must be calibrated (tuned) to get close to the required dominant frequency. This is facilitated by using the sliding top on each pipe (as shown in Step 3), and then moving this top piece up and down to tune the pipe to its required note. Tuning is done with a microphone (connected to your computer) and by using one of the many on-line tuning tools. This process is simply:

1. Play a chosen pipe.
2. Observe the dominate frequency as picked up by the microphone and analysed by the online tuner.
3. Adjust the length of the pipe until the required frequency is observed.

With the pipes tuned the next step is to define the required melodies in terms of the 8 available notes.

Each melody is therefore based on four (possibly different) note sequences:

1. For the first quarter hour
2. For the half hour
3. For the third quarter hour
4. For the whole hour

Plus, the chime note(s) chosen for the hour number. Here is a typical example for melody number 1 named Westminster:

M:1,Westminster,500

M1Q1:5,6,4,1

M1Q2:4,6,5,3,5,6,4,1

M1Q3:5,4,3,2,4,6,5,3,5,6,4,1

M1Q4:3,5,4,1,5,4,3,2,4,6,5,3,5,6,4,1

M1H:1

For this case we can see that:

1. This is melody number 1, with a name "Westminster"
2. The beat time (duration of notes) is 500 mSec.
3. For Q1 (the first quarter hour): the notes are: 5,6,4,1
4. Similarly for Q2, Q3 and Q4 (with varying numbers of notes in each case)
5. The chime for the hour is note 1 here (but we can have more than one note)

Each available melody is defined in this way both in the the code (as a fall back) and on the SD card that can be updated by the user.

The user is free to define their own melodies, or to adapt any of the commonly available ones (within the limits of the available 1 octave scale). The melodies are created on a separate computer as a text file matching the format described above. Up to 10 melodies are allowed for. These are copied to the SD card in a file named "Mel.txt". The SD card can be removed (with the power off), and the melody definitions updated. The SD card is then re-inserted and the clock powered up to get the new versions. A sample melody file is attached.

The instructions provided for this project do not provide all the detailed steps to create the Organ Pipe Clock, but they do provide sufficient guidance for the potential maker to resolve most of the technical challenges. The selection of components that can be integrated together and achieve the necessary performance requirements is a critical part of producing a successful result.

The project does provide some challenges and requires a range of skills in making and assembling electro-mechanical devices, and especially in software development for the Arduino platform.