Converting a slave (pulse) clock to use the MSF Radio transmissions.
Designed in 1909, opened in 1926 and expanded in 1930 the Beit Quadrangle is the home of the Student Union of Imperial College and is one of few buildings still remainign inthe style of the original institution.
Inside the quadrangle is a clock, donated by Prof Brereton Baker shortly before his retirment in around 1930. (data from this book)
The clock was originally linked to the college-wide pulse-clock system, and then later to a Union-only pulse master when the college system was decommissioned.
At some point the Union master clock was removed, and the quad clock was reconfigured to be operated by a local time standard based on a mains synchro motor, a cam and a microswitch. This operated for several years, but stopped for unknown reasons.
For many years the clock was stopped, a point not noticed by many, but a source of marked irritation to some. One of those irritated by this was an old student Andy Wilson, a stalward of the '22 Club, the RCS Motor Club and other college organisations. He was determined to fix the clock during his retirement. Unfortunately he didn't get to see much of his retirement, dying suddenly and unexpectedly in 2014.
As a memorial to Andy it was decided that we (a loose agglomeration of folk from the groups that Andy was active in) would attempt to get the clock going again. A preliminary investigation in the cupboard under the stairs where the mechanism lives showed that the old motor + cam system operated when turned on, but the PSU showed an overload error and the clock mechanism failed to respond.
The clock mechanism showed signs of being seized, and of having overheated the coils:
So, the clock mechanism was removed and transported to my secret laboratory in Basildon, where I re-wound the coils, serviced the mechanism and constructed an Arduino-based timekeeping system that receives the "Rugby" signal (actually broadcast from Althorn).
The basis of this is an Antenna which I bought through eBay though the same item is available from the vendors online shop too.
The Arduino uses this module and the (now archived) RadioClock library on Google Code. I have not been able to determine (by a very cursory search) if this project has been exported to GitHub.
My own code is attached at the bottom of this blog entry.
The system was designed to run for a very long time, so to this end the Arduino power supply is a very simple linear design, using a single long-life capacitor. The pulse-power is simply rectified and not smoothed, to eliminate any capacitor in that circuit.
The Arduino has no way to check where the hands are pointed, but every time it moves the hands it writes the last-written time to the Arduino eeprom. At power up it recovers this data and moves thehands from the last-written to the new time (or waits if it is less than a 10 minute wait).
For wear-levelling the high-order bytes of the time_t data of the last time sent are used as an index into the rest of the eeprom to indicate where to look for the remaining bytes. I think that the method used gives an 87 year life from the 100,000 eeprom writes guaranteed by the spec. Some friends and I had a very long discussion about the absolute optimal way to do this, and one of them managed to find a way to eke 873 years out of the 100,000 writes per byte. Then I managed to mess it all up by using the wrong eeprom-write function... (I need to fix that and swap the Arduino for a different one that hasn't had its eeprom toasted).
A couple of buttons on the board advance the time by 30 seconds or 30 minutes.
Here is the finished controller board.
And here a dull video of the mechanism in action.
This is the code, if anyone has a reason to do the same sort of conversion.
I think that there are two bugs in this code, and I intend to fix and test them. I will try to remember to update this code when I do. You can get the code direct fro Github using the Pulseclock.ino link at the bottom of the listing
1) The ul in the union should be a time_t as it is written from a time_t and does maths with a time_t. I think that an occasional "spinning hands" problem is caused by a quirk of the "should I wait, or pulse" code that runs when the system starts.
2) The wear-levelling of the eeprom write is wrong, it needs to use the EEPROM.update function instead or it will actually wear out the EEPROM quickly.