Wood Gear Clock With Stepper Motor Drive

Yet another clock with wooden gears. This design was inspired by DickB1's Instructable (shown here at the bottom).

However, in lieu of driving the clock with a magnetically pulsed pendulum, I used a small stepper motor.

First, I need to get a major gripe with DickB1's design out of the way. All mechanical parts of his clock were designed by proprietary software from CarveWright. The design files can be purchased from CarveWright and can be used only if you own a CarveWright router. The files cannot be converted into any other format. So, if you own or want to use some other machine, you are out of luck.

Instructables caters to the do-it-yourself community. If a published design limits you to proprietary methods, in my opinion, this is violating the fundamental ideology of this great site.

However, I commend DickB1 for writing a very detailed Instructable. Studying the design, it was fairly easy to reverse-engineer the parts while maintaining total freedom for dimensions, design and machining software as well as the manufacturing tools.

Next, we will look at the principle of operation.

Please note that this is not a complete Instructable in terms of showing all construction details. It is rather a discussion on how to overcome obstacles and adversities when a parts supplier publishes erroneous data.

The idea was to drive the second shaft with a stepper motor, rotating the shaft by 6 degree once a second. A gear train then reduces the rotation of the second shaft by a factor of 60 for the minute shaft and another factor of 12 for the hour shaft. This is kind of trivial information. We also have to use even number of gear pairs between the three shafts to maintain the clockwise rotation (see Gear Train later).

The motor is controlled by an Arduino Uno where a high-precision crystal clock (ChronoDot) supplies the timing information. Since we have this Real Time Clock (RTC), we also display the time and date on a small OLED display mounted to the control box.

Let's look at the driving method in the next step.

I found a small stepper motor with an internal reduction gear. Here are some facts and figures.

The motor specifications said that the motor output shaft has 512 steps per revolution. That translates to 0.703125 degrees per step. Right away, we can see a problem. No integer multiple of the single step angle will produce 6 degrees.

Solution: Assume that the motor shaft is first "amplified: by a 16:15 gear pair. That will increase the step angle from 0.703125 to (16/15) x 0.70312 = 0.75 degrees.

Take 8 steps and get 8 x 0.75 = 6.0. Voila, insert a 16:15 gear between the motor shaft and the second shaft and we can instruct the electronics to send 8 pulses to the motor every second.

Jumping ahead, the electronics is using a high-precision clock to maintain accurate time.

The gear train just grew by another gear pair. See next step.

The picture show the elements of the gear train in a linear fashion. The three shafts for the second, minute and hour are physically at the same location using concentric brass tubes. The idler and the inverter shafts are stationary posts on which the idlers rotate freely. What's the deal with the "inverter"? It is inserted into the gear train to maintain identical rotation direction of the three hand shafts.

There are other ways to achieve this by changing the gear ratios of the sets between the second and minute shafts. For example, you may want to look at a similar clock design I published earlier.

All larger gear wheels were made from 6 mm Baltic Birch plywood and the pinions use 3/4" thick Cherry wood.

The gear design involves three steps. The program "Gear Template Generator" by Mathias Wandel is a fabulous tool to design gears. It requires just the shaft distance and the number of teeth for wheel and pinion and it is done, well almost.
The program outputs a DXF file which I imported into CorelDraw. Final touchups were added such as the hub dimension and hold-down holes for CNC routing. One image shows the CorelDraw final version of a typical wheel.

After finishing the drawing, it was exported from CorelDraw and imported into VCarve Pro. The latter program was used to make up the toolpaths for the CNC router. Usually, I prefer to make at least two passes, a rough cut with a larger end mill such as 1/8", followed by a finish cut with a 1/16" bit to achieve almost square inside corners.

Designing and machining a total of six wheel-pinion pairs took represents the major mechanical work and took several days.

This not intended to be a course on CNC routing. One could also use a laser cutter. I know of at least one designer who cut out the hears with a scroll saw. Well, I admire his patience.

The back panel is the place holder for all shafts, standoff posts, the stepper motor and some electronic circuitry. I was made from 18 mm Baltic Birch Plywood. There is a shallow skirt around the perimeter to make room in the back for the circuit boards.

8 power and signal lines are needed to drive the clock from the control box. The voltages and currents are very small. A standard unshielded twisted pair cable (Ethernet cable) is used between the two units.

The picture also show the concept of the front panel which holds the 12 numeral disks. The front and back panels are joined by four standoff bolts.

Postponing the assembly of the gears for now, we take a look at the front panel. It was machined from 6 mm Acrylic so that the gears remain visible. The 12 buttons were made from a scrap piece of Padauk. Its reddish color contrasts nicely against the light-colored gears.

The numerals were engraved with my trusted VCarve Pro and the CNC router. A touch of gold paint fills the engravings.

Next, we a going to follow the gear assembly phases.

The gear wheels and pinions were machined using the gear template generator software, CorelDraw XIII, CVarve Pro and my CNC router.

The wheel hubs were machined from aluminum stock. Some of these hubs also have threaded radial holes for set screws. Aluminum spacers and nuts control how the gear parts sit on their posts or shafts.

All idler wheels sit on 1/4-20 hex bolts but can rotate freely on them.

The center shafts deserver dome special attention. There are three concentric brass tubes with 1/4", 3/16" and 3/8" outside diameters will wall thicknesses selected to make the inside diameter fit the outside of the next smaller tube.

The tubes were sanded and polished for a smooth fit. However, I found that this fit did not hold up after assembly since the set screws distorted the tubes slightly. The answer was to turn down the outside diameter for almost the entire length of the tubes except for short sections at the ends.

This is a massive piece of hardware. I like clocks and have built numerous types from fully electronic LED models that look like analog clocks to 6-foot grandfather clocks. However, visitors to the house are always drawn to this one.

The hands were originally made from a light-colored wood but I ended up using three paints which makes it easier to read the time. Watch the short video to see the gears and hands in motion. I also have a 12-hour version so could see all gears rotate at least once. Just kidding.

>

The driver for the clock is based on an Arduino Uno. It obtains the date and time from a high-precision crystal clock (ChronoDot). This real-time clock (RTC) senses the surrounding temperature and uses a capacitor bank to switch in different capacitor values depending on the temperature. It claims to accurate within less than a minute per year.

The stepper motor (28BYI-48) is driven by a small controller board (ULN2003). A small OLED display is also used to show the date and time on the control box.

Finally, 6 push buttons can be used to adjust the RTC and run the mechanical clock fast forward or fast reverse.

For the time being, ignore the section of the schematic labeled "IR Circuitry"

The basic functions in the Arduino sketch dealing with clock drive are very simple. Every second, 8 pulses are sent to the stepper motor which rotates the second shaft by 6 degrees. Yes, there is more to the sketch. We need to obtain the date and time, control the OLED display and take actions as push buttons are pressed.

The associated Arduino sketch is not included here for a very good reason. IT DID NOT WORK.

Running the clock, things seemed to be operating just fine. I calibrated the hands with the electronic time and walked away. The next morning, the mechanical time was several minutes faster than the RTC clock said.

What is going on? Hours and hours of Internet searches resulted in a surprise. The specifications of the stepper motor were WRONG. The internal reduction gear was said to be 1:64. It turned out that is not exactly true. It is something like 1:63.876 or so. That seemed to sink this project altogether.

I was not about to commit the thing to the trash after all this blood and sweat of machining many parts.

Stay tuned for several attempts to rescue the project.

The clock was running fast by about 18 seconds per hour. OK, lets add some more smarts. An infrared emitter and receiver was added behind the back panel, aligned with two holes in the panel. A strip of reflective foil was pasted to the back side of the second hand and the other two hands received some matte black paint in the back.

Here is the idea: When the second hand passes a certain position such the 10 O'clock position, the Arduino sketch looks at the "true second" of the RTC clock. If the two do not coincide, the pulses to the stepper motor are reduced or increased to correct the second hand for the next minute. Brilliant, huh?

Well, not so fast. I watched the clock for hours while the sketch let me know if and when corrections were made. However, the celebration didn't last. In the days to come, the clock wandered off again. A closer inspection showed that the problem happened when the hour hand blocked the infrared path for extended time in the tenth hour.

Scrap it now? No, lets proceed to the next step.

As we know, it takes theoretically 8 pulses to the stepper motor to rotate the second shaft by 6 degrees. We also know that this makes the clock run fast.

Therefore, we take a new approach. Forget the infrared sensing contraption.

We run the clock for a certain time and record the number of seconds the clock departs from the real time. As is, I found that the error was about 18 seconds fast per hour. That is one second (8 pulses) every 200 seconds or one pulse every 25 seconds.

We then instructed the Arduino sketch to slow down the motor by sending only 7 pulses every 25 seconds.

Run the clock again for a longer period, specifically 22.3 hours and we observe a smaller error, this time 5 seconds slow. Math tells us the we should speed up the clock by 1/8th of a second (1 puls) every 2,006 seconds. Put that into the code and run the clock again.

After 337 hours, the clock was two seconds fast. Extrapolate that to a full year the error will be about 50 seconds. That is almost as good as one expects from the RTC clock.

One could now add a third correction to the code, slowing the clock by 1/8th of a second every 75,000 seconds.

This is probably good enough since other factors such as power failure are likely to mess with the mechanical clock.

If the patches made to the Arduino code sound like Band Aids, you are right. I am not Microsoft. They are known to apply tens of thousands of "fixes" over the live of an operation system.

However, being kind of a stickler, I decided to make another change yet. See next step.

We have seen that the clock runs fast by about 18 seconds per hour with no adjustments and some 50 seconds per year with two adjustments as described in the previous step. Can we improve on that?

The answer is yes by adding a shaft encoder to the second shaft and sensing the rotational position of that shaft.

The encoder is a disk with a single hole on one diameter and 60 holes on a second diameter. Two photo interrupters are position that one senses the single hole, the other senses the 60 holes. This called an incremental shaft encoder (requires a reset for every tuen).

The outputs of the interrupters are connected to the Arduino producing two distinct interrupts. The 'single interrupt' resets the rotational position to zero. The '60 interrupt' increments the rotational index by one.

Therefore, we obtain the actual position of the second hand every second. We can then compare that position (in seconds) with the RTC second at some point such as the 30-second mark and accelerate or slow down the mechanical clock by adjusting the pulse count temporarily.

This works in a similar fashion as the first attempt (infrared position sensing) but does nor suffer from the shadowing by the other hands.

This is the final (at least that is what I thought) version I adopted and the electronics will be described in detail below.

This is the final (maybe) version of the electronics. An Arduino Uno is at the center and is responsible for all functions.

First we take a 12 VDC plug-in power supply (wallwart) and step it down to a regulated 7.5 VDC.

A real time clock (RTC) provides accurate date and time. A temperature-compensated ChronoDot is used. The latter interfaces with Arduino through I2C occupying just 2 pins of the Arduino.

A small OLED display (Diymall 0.96" I2C SPI 128 x 64 white) displays the date and time on the control box. I used SPI for the interface requiring 4 pins of the Arduino.

The stepper motor (28BYJ-48) is driven by an UL2003 controller board which is located in the back of the clock.

The rotational position sensing is done with an optical encoder disk and two photo interrupters.

I added some code and a piezo speaker to produce a low-level tic-toc sound as one would hear from a pendulum escapement.

Finally, six push buttons are used to adjust the RTC clock after it eventually drifts off a bit and the mechanical clock can also be adjusted with a fast forward or reverse motion.

There are lots of details yet to be described. As I normally do with all my Arduino sketches, numerous comments are embedded in the code. You are encouraged to inspect the code from top to bottom. This will fully explain how the thing works.

Notes concerning the downloading of the Arduino sketch file below:
When you save it to your computer, it will show up in the downloads folder with a weird name having lots of letters and an file extension of ".ino". Rename it to what ever you like but leave the extension intact.
If you open the file with the Arduino IDE program, It will complain and ask you whether you want to create a new sketch folder and move the file there. Accept that. Unfortunately, the new sketch folder will no also be in your download folder. Move it to where you usually keep your sketches. Still, the sketch is likely not to run since libraries are missing.
Open the sketch (ino) file with Windows WordPad (not Notepad). You see five libraries at the top of the sketch. The first two are inherent to the Arduino software. The remaining three must be installed into the libraries folder
In that case, also download (save) the ClockLibaries.zip file. Again, the file name will contain a bunch of letters. You may ignore that and just extract the three folders. Then, move these folders into the libraries folder of you Arduino master folder.
Now the sketch should run just fine.
The sketch contains a large number of comments explaining the purpose of line of code. I do this routinely in all my sketches not just for the purpose of this write-up. What seems obvious during the design may be puzzling if you revisit the code a year later.

The sketch was written, edited and run using the Arduino IDE Version 1.6.2. It was also tested with version 1.6.8 and seems to run just fine. If you are familiar with Arduino's idiosyncrasies, you know how to handle libraries and where to put your sketches. I use a somewhat unorthodox setup where both the sketches and the extra libraries are kept on a file server. The same is true for all data files associated with CorelDraw, VCarve Pro and the CNC toolpaths. That file server is backed up daily onto external drives. This way, my work is preserved should the main computer become corrupted.

Up to now, the adjustments made to the movement by means of Arduino code have been successful in keeping the mechanical clock in line with the RTC clock. There is something missing yet. What about power failures?

The RTC clock has a battery backup that keeps the time for months without external power. However, the mechanical clock stops when the power fails and will resume from that position after the power comes back.

The code ensures that the second hand is fully in sync with the electronic clock but the two other hands will be off, maybe way off.

Raking my brain for a while, I came up with another idea.

If one could tell the Arduino where the hands are actually located, it could run the clock fast forward or backward until the mechanical clock is, once again, aligned with its electronic master.

OK, we have an OLED display that we will put to use for that purpose. There are three main sections in the Arduino loop. One section drives the motor and makes the fine adjustments to the second hand. Another section is used to tell the Arduino where the hands are located. The third section performs the large range adjustment of the mechanical clock. Arduino's language (C++) does nor have a GoTo statement. So, we use flags that make a section of the code to be skipped or run.

When the system starts, it is assumed that the clock is not showing the correct time. Three buttons on the control box are now active. The display shows three location where it expects the user to enter the current values for hour, minute and second. One button moves the 'active area' from the hour to the minute and the second. The second button advances the numbers from 0 to 11 or 0 to 59.

Finally, the third button exits these settings, calculates the error and causes a code section to run where the hands are moved fast until they are at the correct position. Some finagling had to be done to take care of the 24 to 12 hour conversion and the treatment of the hour 12. When the correction was calculated, it assumed that the clock will be adjusted instantaneously.

Of course that is not true. It takes time to make the adjustment. I measured this time and added a fudge factor to the adjustment routine. It sort of worked as long as the hands had to be changed only for a short period.

There is more to come - See next step

The clock was built and the shaft encoder version was implemented some 8 months prior to publishing this Instructable. It was running just fine until recently. It occasionally lost some time and emitted rattles and clanks.

I took it apart and inspected every gear part starting with hour gear and working backwards towards the motor. Everything looked as it was supposed to be until I looked at the motor. It is cheap ($4) motor and the output shaft at the end of the internal reduction gear has single short sleeve bearing. That bearing showed heavy wear and the output shaft was flopping around wildly. Needless to say, attaching a 5-inch diameter gear wheel amplified this wobbling until the wheel occasionally did not mesh with its partner.

It was time to bite the bullet and look for an alternate motor. See next step.

The pictures show the stepper motor, the driver shield and the result after the modification.

The stepper motor is a much more substantial design than the previous "toy" motor. The Arduino shield is a bit overkill since it can drive two stepper or four DC motors or servos. However, both parts were sitting on the shelf begging to be used.

No, we look at the "gear math" for this motor. It steps 1.8 degrees per step. Therefore, no integer multiple of that will give us 6 degrees that is required for a one second rotation. So, I placed a 1:3 reduction gear between the motor resulting in 0.6 degrees per step. Hurray, 10 steps will yield 6 degrees, not just some approximation but exactly 6 degrees.

This will eliminate the convoluted corrections needed for the previous version. The motor and the driver are both very tolerant of different supply voltages. I used an unregulated 7.5 VDC 400 mA plug-in power supply that feeds the motor driver and the Arduino. No other voltage regulator is needed.

Adafruit also supplied a library for the motor functions. This required a closer look. Stepper motors with two coils can be driven in several modes, often called "single", "double", "interleaved" and "microstep". The library contained some surprises. The single mode which can turn the motor the fastest, indeed, turns the motor by 6 degrees for 10 steps. The single mode produces considerable noise. I use it only for the one-time synchronization between the mechanical and electronic clocks.

When the clock runs in its normal mode, advancing the second hand 6 degrees once a second, I use the slower and much more quiet microstep mode. Here came a surprise. The library step function in that mode requires 9 steps for 6 degrees. Ok, as is common in C++, counting often starts with 0. Ergo, the quantity 9 in that step function actually means 10 steps.

The electronic ingredients are as follows:

1. Arduino Uno R3, actually a DCcduino Uno, ~$6
2. Adafruit Stepper Motor NEMA 17 - 200 steps/rev - 12V 350mA, $14
3. Adafruit Motor/Stepper/Servo Shield v2 Kit - v2.3, $20
4. Plug-in Power Supply 7.5VDC 400 ma unregulated, $5
5. ChronoDot Real Rime Clock - v.1 (Adafruit), $18
6. US 0.96" I2C IIC Serial 128X64 LED OLED LCD Display Module for Arduino White (Amazon), $14
7. 9 Mini Pushbuttons (eBay), $1
8. 1k Potentiometer
9. Piezo Speaker
10. Plastic Project Box 6 x 4 x 2.5 inches (MPJA), $5

Summary of the Arduino sketch functions:

The first part of the sketch defines numerous global variables and defines the structures for the RTC clock, the stepper driver, the OLED display.

The RTC clock, the stepper shield and the OLED display all use I2C for communication. That means that only four wires are needed to each of these parts.

The user can control several modes of operation by means of 9 push buttons.

When the sketch starts and if it is hooked up to a computer USB port, it will synchronize the RTC clock with the computer clock. It should be clear, that it makes sense to first verify that the computer clock is matched to a time sever such as NIST. Once the clock is set, the associated code must be disabled so the sketch can run disconnected from the computer.

Next, the sketch enters a code section in the loop used to record the actual hand positions. The mechanical clock is not running at this time. It will never run by itself after a startup (could be caused by a power failure). One pushbutton is used to position kind of a cursor on the OLED display under the hour, minute or second. A second button advances the value for hour, minute and second as read from the actual hand positions.

To avoid having to hit the 'advance' button lots of times, I usually turn the second hand manually to the 12 O'clock position or keep turning it until I get a small value for the minute.

Once the figures are set, a third button (labelled 'GO') exits that part of the code and performs the one-time synchronization of the hands to the RTC clock

This is done by calculating the number of steps the mechanical clock has to be advanced or retarded and runs the motor in a fast (and noisy) mode for the required steps. Note that this may take several minutes, making the adjustment not quite correct. Anyway, the elapsed time for the adjustment is measured and a second adjustment is made. Again, the execution time is measured and a third adjustment is run. In other words, the final adjustment takes into account that it takes time to do the stuff.

After this stage, the clock hands will be synchronized with the RTC clock.

The RTC clock, while supposedly being accurate to within a minute per year, may eventually drift. 2 push buttons are used to advance or retard the RTC clock by an hour (used probably only when we change from standard to daylight saving time or vice versa. 2 more buttons do the same for the minute. The 2 buttons for the seconds behave differently. One sets the seconds to zero for the current minute, the other sets the seconds to zero but advances the minute. It should be obvious that the mechanical hands may also need to be reset. Therefore, after the RTC clock was altered, one should stop the clock by cycling the power and go though the setup again.

The normal run section of the loop sends a series of steps once a second to advance the second shaft by 6 degrees. Two photo interrupters, one looking at a single hole in the shaft encoder disk, the other looking at 60 holes, trigger two interrupts. These either reset the 'position count' to zero or advance the count every second. This is called an incremental shaft encoder.

One a minute, at the 30-second mark, the value obtained from the shaft encoder is compared to the RTC clock and the motor is slowed down or sped up just for this second. This takes care of some minor inaccuracy of the one-time synchronization which may be due to an error as you recorded the hand positions. Be aware, that the final adjustment can only take care of the second hand.

Would it be possible to do away with the rather involved setup and adjustment procedures? the answer is YES. Assume that we equipped all three shafts for second, minute and hour with absolute shaft encoders (not incremental). Please realize that this a totally different design from one discussed here. Such shaft encoders would need 6 bits each for the second and minute and 4 bits for the hour. Simple photo interrupters could not be used. One would need more complex optical or magnetic systems with a total of 16 channels. Since the Arduino Uno does not have that many input pins, one would have to use an Arduino Mega or pre-process the encoder signals with, for example, digital to analog converters.

By throwing lots of hardware at the problem, the Arduino code would be very simple. The code would now the actual hand positions at all times, even after a power failure and could keep the mechanical clock synchronized with the RTC clock, no matter what.

Well, this may be the subject of a future clock design.

The included files contain the Arduino sketch and the associated library collection.

Notes concerning the downloading of the Arduino sketch file below:
When you save it to your computer, it will show up in the downloads folder with a weird name having lots of letters and an file extension of ".ino". Rename it to what ever you like but leave the extension intact.
If you open the file with the Arduino IDE program, It will complain and ask you whether you want to create a new sketch folder and move the file there. Accept that. Unfortunately, the new sketch folder will no also be in your download folder. Move it to where you usually keep your sketches. Still, the sketch is likely not to run since libraries are missing.
Open the sketch (ino) file with Windows WordPad (not Notepad). You see five libraries at the top of the sketch. The first two are inherent to the Arduino software. The remaining three must be installed into the libraries folder
In that case, also download (save) the ClockLibaries.zip file. Again, the file name will contain a bunch of letters. You may ignore that and just extract the three folders. Then, move these folders into the libraries folder of you Arduino master folder.
Now the sketch should run just fine.
The sketch contains a large number of comments explaining the purpose of line of code. I do this routinely in all my sketches not just for the purpose of this write-up. What seems obvious during the design may be puzzling if you revisit the code a year later.
The sketch was written, edited and run using the Arduino IDE Version 1.6.2. It was also tested with version 1.6.8 and seems to run just fine. If you are familiar with Arduino's idiosyncrasies, you know how to handle libraries and where to put your sketches. I use a somewhat unorthodox setup where both the sketches and the extra libraries are kept on a file server. The same is true for all data files associated with CorelDraw, VCarve Pro and the CNC toolpaths. That file server is backed up daily onto external drives. This way, my work is preserved should the main computer become corrupted.

While running the clock, I was not pleased with how the time set and hand set buttons worked. The pushbuttons were queried within the Arduino main loop which did not always catch the button press.

So, here is the new method: The RTC clock does not require to be adjusted often. An exception is when we switch from standard to daylight saving time and vice versa.

Synchronizing the hands to the electronic clock is another story. This needs to be done evert time the clock is powered up or re-powered up after power failure.

Therefore, the Arduino code works as follows:

When the system starts up the Setup section stops in an infinite loop. One pushbutton can advance or retard the RTC clock by one hour (useful for time switching). A second buttons does the same for the seconds in a faster way. Once you are satisfied with the setting, a third button escapes from this loop and enters a second loop.

There, one button advances sort of a cursor to the place where one advances the number of hours, minutes and seconds to the actual position of the hands. Tip: Manually set the second hand to the 12 0'clock position first so you do not have to bother with seconds. A second button advances the number of hours, minutes and seconds. Once this is done, a third button escapes from this loop and drives the hands at high speed until they are synchronized with the RTC clock. The, the setup section is done and the regular code loop is entered. There was another reason to make changes. See next step.

The original design included a tick-tock sound every second implanted with brute force by the Arduino code and a small piezo speaker. What about sound at the quarter hours and full hours?

Well, I discovered two things, a sound effects board and sound files on a website of the British Parliament. They were recordings of the classic Westminster chimes and chords.

The Adafruit FX Sound Board is small circuit board that stands alone by itself. It only need 5 V power. It contains a 2MB flash memory where one can place small sound files either in WAV or OGG format. Up to 11 trigger pins are used to play the files. The board not very smart. The files are played according to the names of the files. For the purpose of the clock, files are only triggered to play, not looped and not held. The names of the files, in that case, are Tnn.WAV or Tnn.OGG where nn goes from 00 to 10. So, placing trigger button 3 to ground, plays the T03 file through a mini phone jack (usable only for powered speakers or headphones.

The Arduino's role is limited to triggering pins of the sound board.

I edited the composite sound files from the Internet into files for each quarter hour and into short hour sounds plus one hour sound with a longer fad-out. The first three quarter sound are simply called at the appropriate time.

The sound board can only accommodate 2 MB worth of files. OGG (compressed) files have a noticeable delay before they start playing and I stayed with WAV files. However, in view of the limited space, I converted the files using 11kb PCM mono files. This consumed about 1.2 MB of flash space. The loss of quality cannot be perceived.

Playing the sound at the top of the hour is a bit more complex. First, the 4th quarter sound is played, followed by short hour sound for the hour number less one and finishes up with the hours sound that a longer fade-out.

Files cannot be queued up. One has to wait until a sound is played completely before asking for the next file.

The sound editor provided us with the playing time. One could think that we tell the Arduino play files and delay the next file. That does not work because the code that drives the motor needs to run without delays.

The trick for playing the sequenced sounds at the top of the hour is to play 4th quarter file and set a time marker (as perpetual Unix seconds) 15 seconds in the future. The code then traps that time and plays the first of the short hour sounds and sets another time marker 2 seconds in the future. Using 6'oclock as an example, after playing 5 short hour sounds, the last is the hour sound that has a longer fade-out.

I used a pair of very small computer speakers. Just about all speakers these days are powered by USB, I added a USB on the control box supplying the 5 Volts to the speakers.

The default volume does not rattle the walls but is soft enough to be pleasant.

I did not include the Arduino sketch here. If you want it please ask.

Finally, below is an example of a sound.