Ringing Forums

I’m not familiar with CAS but they’re is an alternative you might like to look at. We use CIREL which takes input from a Bagley sensor and saves touches in Lowndes format.
The analysis is simpler than what Hawkear (I assume using CAS) gives but we find it useful.
We have calibrated our sensor timings to match the clapper timings by ringing te bell own with Abel sound as well and adjusting the delay until we couldn’t tell which was first. All can’t (or couldn’t when we did it) adjust for oddstruckness but our bells aren’t.
Apply to share our experience.
See: cirel.org.uk.

Thank-you John. Cirel looks promising, complete with some explanation. I'll have a play with that.
I did initially set the sensor outputs close to the sound and if we establish a means of analysing our striking, will check and refine the setup further.
We have some very slight oddstruckness, I don't think sufficient to cause an issue at this stage. If it does become an issue (living in hope!) I could trial offsetting the sensor from BDC.

Almost every discussion on this topic starts with how to adjust Abel to match the odd-struckness of the bells. I would urge you not to do this, and instead to fix the bells to match Abel.

As you say slight odd-struckness is not your primary concern for your current band so I wouldn't worry about altering either for now.

In Abel you start by pressing the "Reset striking records" button (the icon is 3 underscores). Then ring your touch. After you stand press the "Striking" button (the icon is the 3 underscores with the numbers 12 3 above). Then press the "Save As" button, this will create a file in "My Documents\AbelSim\Striking".
You can also save the file by just pressing Ctrl+F while in the main Abel window.

Now run CAS and open this file to analyze it.

Its been a long time since I used CAS but my memory is that its more useful feature was the ability to visualise piece of ringing. This is effectively a "blue line" diagram showing the ringing as it was actually rung rather than having numbers in nice neat columns. We found this visualisation of the ringing, compared to what it should be, to be a very strong tool in making the band sit up and take notice. It also shows very well how inconsistencies in the ringing manifest themselves throughout the change. You can see how very slow leading for example either causes the bells behind to all shift later pushing the back of the change later, or produces a bunched up remainder of the change depending on how the bells later in the change decided to deal with the slow leading.

CAS can also deliver numerical statistics about whether people are consistently quick or slow at each stroke, and what their standard deviation is. We found this to be of relatively little use for a local band, people weren't interested enough by a pure numerical output and weren't prepared to invest the time into understanding the model and what it was telling them.

You don't need to tell CAS what you are ringing. Its model does not take account of where bells should be according to the method. The model simply accepts the order in which they rang as being the order and then works out how far they deviate from where the model interprets that they should be (which is pretty much how a striking competition would be judged). If two bells perfectly swap, there would be no detriment to the striking score.

The downside of this mechanism is that with poor ringing where the bells frequently don't ring in the right order the software struggles to cope with it. It is especially bad if the next change runs into the previous one. In general though if the ringing is like that then it isn't a striking tool that you need.

... how to adjust Abel to match the odd-struckness of the bells. I would urge you not to do this — Jonathan Frye

The question is why you would want the simulated sound to match the odd struckness. If you are trying to train a team to ring those specific odd struck bells as well as possible in a performance then maybe you should, but for any other purpose, notably developing the general capability of a band then I would share Jonathan's view.
However if (as in the original question) you are not generating simulated sound but using sensors to score the accuracy of striking with open sound then it clearly is important for the senhsor signal to match the timing of the sound heard by the ringers.

[CAS] ... more useful feature was the ability to visualise piece of ringing — Jonathan Frye

That's also the primary output of CIREL. It shows the real strike positions of all bells in black with the 'ideal' positions in green behind it, and has the option of adding the line of one or more bells. That is the most useful display for detailed diagnisis of individual issues such as over or under shooting leads and lies, sloppy dodges or places, sluggish turn rounds, and so on. It also has the option to highlight errors above a preset threshold, which can be useful for getting overall impressions, eg more early than late,close hunting up and wide hunting down.
You can also drill down for more detail on individual bells and you can analyse limited portions of the ringing.
But that takes more time to study, so it is most relevant to detailed coaching or team practice before a competition.
In general practices there isn't usually time for that so what gets used most (by us) is the information CIREL generates at the end of every touch: a bar chart of RMS error for every bell with a line across the average, and a bar chart showing prevalence of errors (above threshold) late/early, hand/back for each bell (plus some figures). They are easy to take in from wherever you are ringing (providing the Treble stands to one side).

can also deliver numerical statistics about whether people are consistently quick or slow at each stroke, and what their standard deviation is. We found this to be of relatively little use for a local band — Jonathan Frye

That's what CIREL's graphs show and it is certainly of interest. Most people do look at it after each touch. If it looks particularly good overall someone often asks what the actual value was, and there is quiet rivalry among the better ringers to have lower individual errors. Learners (with higher errors obviously) also look at it to learn 'how' they may have done.

You don't need to tell CAS what you are ringing. ..., The model simply accepts the order in which they rang. — Jonathan Frye

CIREL attempts to identify the method, in which case bells in the wrong place count as (big) errors. If it can't then it just accepts the order they struck.

The downside of this mechanism is that with poor ringing where the bells frequently don't ring in the right order the software struggles to cope with it. — Jonathan Frye

CIREL doesn't struggle, it just generates a result! And the overall error will be correct. The real downside is that errors get moved between bells. Suppose 1, 2, 4, 5, 6 ring perfectly and 3 rings in position 4.1 (ie an error of +1.1 places). 4 will get an error of +1 while 3 gets an error of +0.1.
The practical effect is that all scores look bad in rubbish touches. But you don't need a machine to tell you a touch is rubbish so no one bothers to look.
If the result of a touch doesn't look what someone was expecting it's quite common to ask whoever is near enough to read whether it recognised the method. If not then individual differences get ignored.

You can use "Virtual Belfry Software" with your simulator to analyse live ringing very easily as long as you are ringing reasonably accurately.

what happens if you don’t?

You may find more advice on the Ringing Simulator Users and Suppliers Facebook group. It currently has 572 members https://www.facebook.com/groups/1441867412528870/