The Project
For my work experience with Embecosm, I was given a real-life project by Rev. Peter Salisbury, the vicar of St Thomas’ church in Lymington. The project was to measure the accuracy of the church clock and pendulum, by using a magnetic hall effect sensor to detect a magnet stuck to the bottom of the pendulum. The accuracy would be determined as the difference between the theoretical timing of the pendulum and the actual timing calculated according to an algorithm running on a Raspberry Pi. Under the mentoring of Lewis Revill, and working closely with Peter, I had to come up with a design for both the hardware and the software to make this happen.
Revision 1
My first step was to design a circuit to help me get familiar with the various aspects of the final system. I needed to test the Raspberry Pi’s GPIO pins, work out how the pins were assigned & learn how to receive a digital input in software. I built the circuit shown above, which used a pull-up resistor connected to a push button in order to create an input to the GPIO pin which would be ‘pulled low’ when the button was pushed, making a connection to ground. Debouncing, a process which would ensure a single push of the button produced only a single signal, was to be done in software.
Revision 2
For the final hardware design I needed to incorporate the hall effect sensor to replace the push button. The hall effect sensor has 3 pins, VCC, GND, and OUT. Due to the fact that when the sensor is active it makes a connection to ground, the VCC pin must be connected through a 10kΩ resistor to ensure the same behaviour as the test circuit.
Software design
As you can see, the hardware design turned out to be a very simple circuit. The main bulk of the design was focused on coming up with and implementing an algorithm to calculate and display time drift of the church clock.
The first part was crafting a formula appropriate for the task, which would utilize the inputs received through the hall effect sensor. We went through many different formulas and algorithms, in the end we settled on the following method of reporting the accuracy:
- We would not report the accuracy for every single pass of the pendulum, since the period is only 4 seconds (2 seconds for the pass in each direction), and we would not be able to
report the inaccuracy because it would be too small. We decided instead to wait for a longer period of time, for example 2 minutes (15 ‘ticks’) before checking the time difference to
the previous tick:
Difference = Current time stamp (UTC) – Last time stamp (UTC)
Inaccuracy = Difference – Expected difference (number of ticks * 2 seconds) - To keep things simple only the last two timestamps are stored. To report differences over larger periods of time we store separate timestamps and perform a separate calculation just
as above, but with a larger number of ticks between calculations.
The python script that implemented this algorithm can be found here: https://github.com/Gvenn666/Church-Clock-Counter/blob/master/source.py
The Web Server
Since the Raspberry Pi would be installed in a clock tower which is not easy to access, the project required the ability to access the data collected by the Pi from an external device. Ideally this would be done by serving the reported results from the Pi to a web server to be accessed over the internet.
The method chosen for this task was to use the Node.js web server framework implemented using Javascript. The hosting of the web pages was handled by the Express node package, and the serving of the CSV file produced by the Python script was done by utilizing routes and the Response object.
For reference, the source of the web server can be found here: https://github.com/Gvenn666/Church-Clock-Counter/blob/master/server.js
Putting the design into practice
The first problem we encountered when integrating the Raspberry Pi and it’s sensor hardware into the clock tower was that it was really difficult to reach the magnet on the pendulum with the hall effect sensor. A lot of blu-tack was utilized to hold things in place and the hall effect ‘probe’ had to be bent in order to be close enough to the magnet to detect it. We also found that the Wi-Fi signal was not strong enough to be detected where we were, so the solution was to use a portable hotspot while testing.
Over the course of the project we had to keep returning to the clock tower to test whether the fixes that we made worked correctly. This took a significant amount of time and made it difficult to quickly test ideas. In addition, there were a few times where I left the system running in the clock tower in order to collect results, but when I returned to retrieve the results I found that the system stopped logging data after a short time. Initially we assumed the sensor had moved too far away from the pendulum but eventually I figured out that it was because the process that contained the running program was killed by Linux after we disconnected from the Raspberry Pi. This was solved by using the ‘nohup’ (no hangup) program to launch the process.
In the end, the system was able to report the calculated offsets correctly. The last test we were able to do showed some slightly alarming numbers for the offset, which we believe is most likely due to inaccuracies in the method of generating a timestamp via the time.time() method in Python. This method uses the system clock, which itself may have some inaccuracies when compared to real UTC, and the call to the method doesn’t take into account the variation in time it takes for the method to return. However the system itself was behaving exactly as expected.