Posts: 141
Joined: Tue Dec 18, 2012 10:34 am

A Tower Bell "pullometer"

Fri Mar 23, 2018 4:53 pm

Hi all.

A write-up of my latest Pi project which is a device to aid those learning (and those teaching others to learn) the art of tower bell ringing.

It requires a lot of practice to do well.

It is true that, fundamentally, you are just pulling on a rope (called a sally in the parlance) but you have to pull just hard enough to allow your bell to be properly controlled and accurately enough so that you are in time with all the other ringers in your band. Many people struggle to learn the art and I am a case in point in that I started to learn to ring but gave up (as too many do) after a few months.

At the start of 2017 a friend (who has rung for years) pointed me in the direction of an article in the Ringing World publication, which was a call-to-arms and a competition to design a pullometer intended to be used as a training aid for bell ringers. The article is here: ... llenge.pdf.

This was right up my street and I spent much of my free time in the early part of 2017 designing a solution.

The "right" way to measure tension in a rope is to use an offset pulley arrangement whereby the rope runs through a set of three pulleys with the middle one being offset and applying sprung tension to the rope. As the (pulled) tension on the rope changes the position of the middle pulley changes in a way that is proportionate to the pull. This can be measured by a strain gauge. After a bit of thought, I decided not to follow this route as it needed quite a lot of setup if it needed to be mounted and dismounted or moved from tower to tower. I also thought it would be quite noisy because the surface of the rope is not smooth.

I very quickly settled on an IMU-based route and a quick proof of concept using an Arduino, a MPU6050 IMU breakout board and a Bluetooth module showed pretty promising results. The solution involves the device being attached to something called the headstock (a big lump of metal that is attached to both the bell and the axle on which the bell rotates) and so it rotates with the bell. My first test used duct tape to attach the device to the headstock and I have not changed this (its fast, secure and cheap).

The final form ended up pretty complex and uses a Pi Zero to pull data from the IMUs, put it through a Kalman filter and some other processing and push angle, rotational velocity and rotational acceleration data to a websocket. The Pi also serves a web page and Javascript that takes the data from the websocket and presents it to the users browser (on a laptop, tablet or whatever).

Here is a pic of a prototype of the the device:

There is more detail on the technicalities on the project's Github and in particular on the wiki and there will probably be quite a lot here that may be useful to anyone interested in:

(a) battery power to the Pi with on/off switch and low battery detection (using a Pimoroni LiPo shim, 4 diodes, a couple of resistors, a LED and a push button) - I have not looked at the power enable pin on the 3B+ but I suspect something similar could be created using that
(b) wifi access point creation
(c) use of dual MPU6050 IMUs to obtain smoother data and synchronising the FIFOs on the IMUs
(d) Kalman filtering
(e) websockets, javascript and HTML5 canvases
Have fun

Posts: 141
Joined: Tue Dec 18, 2012 10:34 am

Re: A Tower Bell "pullometer"

Tue Jun 25, 2019 5:20 pm

Hi all.

I am about to release a second version of this device. There are lots of changes between the first and second version but most of these will be of interest to bell ringers. What will be of more general interest here is what I have done regarding the IMU and powering the unit.

On the IMU, I was previously using two MPU6050 breakout boards, averaging the data between them and pushing the readings through this code to get pose data (Euler angles). Because of some issues of drift of the pose data under the repetitive swinging motion of the bell (as much as 1 degree a minute) I decided to try something else.

After some experimentation(!) I moved to the ICM20689 IMU (the manufacturer-recommended replacement to the MPU6050) and calibrated the IC's gyros and accelerometers using the mechanism described here This calibration process is somewhat difficult to initially set up but produced excellent results. All that's needed is to have the device stable (in any position) for a minute and then move it into 40 or so different positions (any position, just a load of different ones). After some number-crunching, calibration data (misalignment, scale and bias) is output.

The imu_tk calibration was only going to be done once (i.e. after PCB assembly) but gyro biases are known to shift so I needed some dynamic calibration too. I used a feature of bell ringing to enable gyro re-biasing when the bell is still (it just detects when the bell is not moving and then automatically re-biases (zeros) the gyros). The pose estimation now uses the well-known Mahony filter (which I was not able to improve upon, even using more complex filters). I think the results are quite good. I am getting static yaw drift rates (i.e. gyro only) of less than 0.3 degrees per hour and dynamic pose estimation error seems to be less than 1 degree even when the bell is rotating at 450 degrees/s. What's better for my particular use case is that you can start the bell at rest (against the stay), ring for a few minutes and the angle reported when the bell returns to rest against the stay is within 0.2 degrees of when it started - the drift I had been experiencing had pretty much gone.

On power, I needed a smaller device than the original so that it could be fitted closer to the axle of the bell (reducing centripetal effects). This (and needing to find a case that would fit everything in) required a LiPo battery. Using a LiPo battery, meant I needed a charger and charge controller. The result is a LiPo-powered Pi Zero using a MCP7383 as a charge IC and the charge controller is a ATmega328 with an Arduino bootloader installed (so it behaves and can be programmed like an Arduino). What I think is neat is that the battery can be charged by just plugging power to the Pi via its usual power port.

Battery level is measured by the ATmega's ADC pins (one of them is connected (via a divider) to the 3.3V produced by the Pi). If the voltage from the battery get's too low, it instructs the Pi to shut down (and if it does not do so, the ATmega will forcibly shut power off).

One thing to note is that the Pi is powered directly* to its 5V pins by the voltage from the LiPo. This means that the Pi is powered by a variable 4.2V(ish) to 3.45V(ish). It does not seem to harm anything and other people have also reported success in doing things this way. I would not expect that all USB devices plugged into the PI's USB port will work at this lower voltage but all of the ones I have tried seem OK. (*not quite directly - there is an ideal diode controlled by the ATmega between the LiPo and the 5V pins).

One late addition was the creation of a sleep mode, the user can instruct the device to sleep for a period of time (eg 10 hours). The Pi will then be shut down and the ATmega will force the Pi's run pin low (so low power state). After the time period has elapsed the run pin is released and the Pi boots up again. Current consumption during sleep is about 10mA.

The ATmega does other stuff too like reporting power status using a LED, monitoring the power button and storing the calibration data created during the initial imu_tk calibration process.

Battery life is about 6 hours using a 800mAh battery (longer if using sleep). Some people might be interested in creating a UPS using some of this. I have thought about it a bit but not tested it - it was not important for my use case. Indeed, I have arranged things so that the Pi is not running when power is plugged in because I did not want people to try keeping the device powered over USB when it's attached to a bell!

I'm afraid the power solution here is Pi Zero specific. The other current Pis have a more complex power supply (using a PMIC) and (although I have not analysed the schematics) magic blue smoke could easily be released (or worse) if the device's PCB attempts to power these Pis when they are also powered via USB. If that's not enough, the ideal diode I used has a current limit of 1A which won't be enough for many Pi configurations.

Lots more information and construction details are in the Github linked in my last post (particularly in the Wiki, although much of that is bell-ringing specific).

I hope someone finds some of this useful.

Have fun.


Posts: 78
Joined: Mon Mar 19, 2018 1:18 pm

Re: A Tower Bell "pullometer"

Thu Jun 27, 2019 8:03 am

cool project.
Why not a hanging scale anywhere on the pulling rope instead?
Modified to sense + record/transmit both pull tension and vertical acceleration. No need for giro calibration since it needs to measure only relation between pull force and vertical acceleration/speed.

Posts: 141
Joined: Tue Dec 18, 2012 10:34 am

Re: A Tower Bell "pullometer"

Thu Jun 27, 2019 9:02 am

Hi blimpyway.

I know that others who have tried this have thought exactly that. I decided not to follow that route because the scales (however implemented) would have to fit above the sally (so as to not interfere with the ringing action) and as the tail end of the rope is supported by the ringer during part of the stroke and (at times) there is general wobbliness of the rope/sally I thought that there would be too much "randomness" which could not be calibrated out.

Some others have done something similar which involves measuring tension in the rope using pulley system with one pulley offset and spring loaded to push onto the rope. This will not need the rope to be split but (in my mind, others have had some success) I again through there would be too much randomness.

Others have tried having the ringer stand on scales (or even a Wii Fit board) but again there will be problems if the ringer shifts weight or bends knees.

I do have to calibrate out quite a lot in my approach (the overall calibration is a bit more involved than just gyro and accelerometers) but what I have to calibrate out is pretty regular (i.e. not random, so it can be measured). This element is not quite finished yet(!).


Return to “Automation, sensing and robotics”