[contrate_wheel]

Dear forum members, first post for me, and I have a question: what exactly
is beat error? More precisely, let us denote by t_1 the time between a tic
and the following toc, and by t_2 the time between a toc and the following
tic of a watch movement. Assume that these quantities are stable enough.
There seems to be disagreement on whether the beat error is t_1-t_2 or
(t_1-t_2)/2. In particular:

Supporting (t_1-t_2)/2
* We have this document of the Witschi company
http://www.witschi.com/assets/files/sheets/Test and measuring technology mechanical watches.pdf
paragraph 1.2.2 in page 5. And other similar manuals from Witschi.
* We have no precise definition from the makers of the Vibrograh machine,
neverthelss in this manual
http://greinervibrograf.com/appl/file.php?id=231
at page 4, we find a diagram indicating that the beat error is the
distance between the two parallel lines of dots generated by the machine,
and this, in fact, turns out to be (t_1-t_2)/2.

Supporting t_1-t_2
* We have this page on the MicroSet website
http://www.bmumford.com/mset/beaterrormode.html
informing us that "MicroSet will measure the length of two beats and
compare them. It will then display the difference between them".
* We have other resources on the web, for instance this page
http://hiro.alliancehorlogere.com/en/Glossary/Beat_Error
* We have a few posts on this very forum, for instance lysanderxiii's
post in this thread
https://www.watchuseek.com/f6/beat-error-now-what-583431.html
tells us that "2.8 ms means the swing in one direction is 2.8 ms longer
than the the other direction".

I couldn't find a definite answer, yet I didn't venture into the technical
litterature. Anyway the fact that Wischi (industry standard) and MicroSet
(very solid repuatation) seem to disagree on their definition needs to be
explained, doesn't it? If one had the two mechines side by side, he could
throw a movement intentionally out of beat by various amounts, and then
compare the readings.

Hope that someone can explain my little impasse, and thank you all in
advance for reading!

 

[mpalmer]

Welcome to the forums!

 

[El @]

Dear forum members, first post for me, and I have a question: what exactly
is beat error?

Watch:

 

[pithy]

Dear forum members, first post for me, and I have a question: what exactly is beat error? . . . .

Doh.

Lack of symmetry in the half oscillations of the balance.

Are we going to have to go through a big rig-a-ma-row or do you just want the source code (or are you wanting us to help you attempt to write your own)?

Java?

What is needed is a better gain algorithm/filter.

 

[BenchGuy]

Watch:

El, is this your you tube post?

 

[BenchGuy]

To OP: Each manufacturer describes the derivation of output for its particular device so that users will understand the meaning. At the end of the day, regardless of computation, "zero" beat error is the objective...and ends up being the same regardless of calculation method...there is no discrepancy in this. Witschi is the standard, and using Mumford in the same sentence is an insult (of course in the one case it is an insult to Witschi and in the other to Mumford...you are a philosopher, so I'm sure you'll figure this out). Best regards and welcome to f6, BG

 

[El @]

El, is this your you tube post?

No, it's my attempt to help the OP posting a link to a pertaining video, if you don't mind and allow me.

 

[contrate_wheel]

To OP: Each manufacturer describes the derivation of output for its particular device so that users will understand the meaning. At the end of the day, regardless of computation, "zero" beat error is the objective...and ends up being the same regardless of calculation method...there is no discrepancy in this. Witschi is the standard, and using Mumford in the same sentence is an insult (of course in the one case it is an insult to Witschi and in the other to Mumford...you are a philosopher, so I'm sure you'll figure this out). Best regards and welcome to f6, BG

Thank you BG for your answer! So, as I get it, the precise definition is
known to depend on the manufacturer, and that's fine for me. Pithy was
right in his guess that I am writing my own timing software. In fact I
already have it, and considering that there is no open source timing
software around, I am thinking to release it as free software. As you may
immagine, there is some polishing that a program made for personal use
needs to undergo before it can be published. That is the origin of my
question: I intend to display as beat error the same number that the
majority of users expects to see, and not double nor half of it. Having to
choose, I opt for the Witschi definition (no insult intended here for
other manufacturers, but I agree with you that they have the authority to
be considered the standard).

I hope to be able to contribute my program soon, it has been in an
unfinished state for almost one year now, but in a few more week ends it
will be ready, at least under Linux.

 

[poisonwazthecure]

I myself prefer Matlab.

 

[Roland Ranfft]

Hi there,

I opt for the Witschi definition (no insult intended here for
other manufacturers, but I agree with you that they have the authority to
be considered the standard).

Authority? based on what? The price?

I'm pretty sure that Chinese manufacturers sell much more than Witschi. And standard should be what the majority uses, and not the one with the most overpriced equipment.

However, if you create an own software, do it better than all: Displaying the error in milliseconds is pretty useless, disregarding wheter you display the time difference, half of it, or 37,58% of it. Do it better and display the error in degrees. This would help immediately to turn the spring collet to the right position with the first attempt.

Regards, Roland Ranfft

 

[pithy]

. . . . Pithy was right in his guess that I am writing my own timing software. . . . .

Not real hard to deduct.

Obfuscation is par for the F6 course.

Virtually all the engineers that loaf here have one or more horological software projects.

And counting/sampling isn't the most interesting of them.

None of the systems utilizing an onboard transducer are effective enough to be of any commercial benefit.

Most of the code - be it ported for whatever form factor - is only marginally productive even with a common external pickup.

On the other hand, when I couple a huge old crystal to the sound card or specially shielded, preamp driven USB mic - the gain jumps and or sharpness of the attack is accentuated and the wave markers can be be unmistakeably discerned.

Optimize the gain and filter the noise - then you'll have something - oherwise its more wheels.

 

[pithy]

. . . . Do it better and display the error in degrees. . . . .

You'd love the led strobe trigger.

 

[contrate_wheel]

Hi there,

Authority? based on what? The price?

I'm pretty sure that Chinese manufacturers sell much more than Witschi. And standard should be what the majority uses, and not the one with the most overpriced equipment.

However, if you create an own software, do it better than all: Displaying the error in milliseconds is pretty useless, disregarding wheter you display the time difference, half of it, or 37,58% of it. Do it better and display the error in degrees. This would help immediately to turn the spring collet to the right position with the first attempt.

Regards, Roland Ranfft

Thank you for your opinion Ronald. Let me make an apology first for my
attribution of authority, as I, for once, don't have the authority to
discuss that. Please everyone understand that it is not my intention to be
contentious.

Your suggestion of using angles is quite sensible from the watchmaking
point of view: I trust you on this. Unfortunately from the signal
processing point of view is a bad idea, for the following reason. I have
designed my algorithm to work with crappy audio, this is my top priority
in this project. So, the beat of a movement is the easiest and most stable
number to get. Then comes the beat error (in time units), almost on par.
You can get this numbers, up to a reasonable tolerance, even if you can
not resolve the three sounds of each beat. The amplitude, by contrast, is
far less reliable. Now, if we do the math, in order to get the angle
corresponding to a given beat error, we basically need the amplitude and
the beat error measured in time. In general, making the more reliable
result depend on the less reliable is not good. It would be great if I
were designing a program for clean signals, but I am doing the opposite.

Still I can produce both results, or a translation table. I will
definitely think to this, so thanks again!

A funny thing that I noticed is that on a bad movement the tic and the toc
waveform may differ in length by more than the beat error of the movement
(say 1ms difference with 0.something beat error). So if you take as
reference point for the computation, say, the first sound or the third
sound you get entirely different results. This is why I say that the beat
error has slightly larger uncertainty than the rate.

Ok, enough boring stuff, and someone will complain again that I am asking
for help, which I am not. I am sharing some precious bit of ignorance, so
rare on the internet.

 

[contrate_wheel]

Not real hard to deduct.

Obfuscation is par for the F6 course.

Virtually all the engineers that loaf here have one or more horological software projects.

And counting/sampling isn't the most interesting of them.

None of the systems utilizing an onboard transducer are effective enough to be of any commercial benefit.

Most of the code - be it ported for whatever form factor - is only marginally productive even with a common external pickup.

On the other hand, when I couple a huge old crystal to the sound card or specially shielded, preamp driven USB mic - the gain jumps and or sharpness of the attack is accentuated and the wave markers can be be unmistakeably discerned.

Optimize the gain and filter the noise - then you'll have something - oherwise its more wheels.

Thanks a lot, sorry for missing your answer. I am not an enigineer, in
fact I have got my PhD in mathematics. But I guess it's almost the same.

No, I am not trying to write anything commercial, as I said, I will
release the source code as soon as it is presentable.

For the filtering part, I decided to do away with the tigger based
algorithms altogether, so I am not looking for edges. This is the
technique that everyone uses, and it works fine if you have a very clean
signal, but badly otherwise. What I do is to detect the whole waveform,
more or less along the lines of what they do with adapted filters in
radars. As it is now, the thingy can trigger happily on a decently loud
watch held on my wrist at five centimeters from my laptop internal
microphone, in a quiet environment. And I am quite pleased with it. Still
it would be no match for a proper setup: if you can have a sharp waveform,
just triggering on the edges is the way to go. The whole thing is designed
to be much more amateurish.

 

[pithy]

Thanks a lot, sorry for missing your answer. I am not an enigineer, in fact I have got my PhD in mathematics. But I guess it's almost the same. No, I am not trying to write anything commercial, as I said, I will release the source code as soon as it is presentable. For the filtering part, I decided to do away with the tigger based algorithms altogether, so I am not looking for edges. This is the technique that everyone uses, and it works fine if you have a very clean signal, but badly otherwise. What I do is to detect the whole waveform, more or less along the lines of what they do with adapted filters in
radars. As it is now, the thingy can trigger happily on a decently loud watch held on my wrist at five centimeters from my laptop internal microphone, in a quiet environment. And I am quite pleased with it. Still it would be no match for a proper setup: if you can have a sharp waveform, just triggering on the edges is the way to go. The whole thing is designed to be much more amateurish.

There's been a bit of work been done on digital waveform recognition as an automated diagnostic tool.

This will be incorporated into the next gen of professional timers.

 

[Roland Ranfft]

Hi there,

Your suggestion of using angles is quite sensible from the watchmaking
point of view: I trust you on this. Unfortunately from the signal
processing point of view is a bad idea....

....I have got my PhD in mathematics.

Fine, from your math studies you'll know that the angle speed is nearly constant near the zero transition. So a linear approximation for the beat error angle would be more than sufficient for the needs of a watchmaker. You need just the frequency, the time difference, and a constant factor - peanuts compared with capturing the trigger points.

Regards, Roland Ranfft

 

[contrate_wheel]

Hi there,

Fine, from your math studies you'll know that the angle speed is nearly constant near the zero transition. So a linear approximation for the beat error angle would be more than sufficient for the needs of a watchmaker. You need just the frequency, the time difference, and a constant factor - peanuts compared with capturing the trigger points.

Regards, Roland Ranfft

Sorry, no. The angular velocity at the center of the oscillation is
directly proportional to the amplitude. So it has the same relative error
(50% error in the amplitude immediately translates to 50% error in the
angular velocity). Yet I could go for a default of, say, 250 degrees of
amplitude, assuming that the watch is between 200 and 300 this gives me a
+-20% error in the angle. Not totally wrong, but it doesn't feel right
anyway, does it? Why to introduce a new source of uncertainty?

On the other hand, you convinced me that showing both results is possibly
a good idea. I will maybe display something like "x ms (~y deg)", to make
it clear that the angle is just a guess, and then use a default amplitude
for the computation. Do you think that 250 degrees is a reasonable choice?

 

[pithy]

. . . . near the zero transition. . . . . .

. . . . at the center of the oscillation . . . .

hmmm

 

[Roland Ranfft]

Hi there,

The angular velocity at the center of the oscillation is
directly proportional to the amplitude.

And this is your problem??

Math guys tend to make things complicated, while engineers are simple minds. So I thought you wanted to calculate the angle after the exact waveform of the balance motion, and therefore I mentioned that the velocity near zero transition is fairly constant.

A modern timing software needs entering the lift angle to calculate the amplitude from measuring the lift angle by capturing the according noises. So you have the ratio between time (measured) and angle (entered). This actually is the angular velocity near zero transition, and you can use it to calculate the angular error from the (half) time difference.

Here the simple formula (with ea = error angle, et = error time, la = lift angle, lt = lift time):

ea = (et/2) * (la/lt)

No callenge for an Apple II from 1980, peanuts for a phone processor. Of course it is an approximation, but it is better than a watchmaker will ever need to adjust the hairspring collet (by ea), and it is even sufficient if he takes a default 50° for the lift angle. And if this watchmaker hasn't lost his marbles, he'll not even consider a beat error unless the amplitude is reasonably bigger than the lift angle (after visual judgement).

Regards, Roland Ranfft

 

[Roland Ranfft]

Hi pithy,

I have also another imagination from a center, but 1st I don't put every word on a scale, and 2nd I also should have defined zero as rest position of the balance to make the term zero transiton precise, and I should have given a precise deviation from linearity to define "near". But I believe too exact definitions prevent people from reading posts.

Regards, Roland Ranfft