Message Boards Message Boards

Accurately calculate tick tock period of mechanical watches?

Posted 6 years ago

I'm looking to find the frequency of a relatively large dataset (or a relatively short audio file) of a repeating sound, like so:

sound Here are the original files, for those willing to play. :) eta2412 data1 Other examples: phenix140sc chaika1601

Blue is the original soundwave, and orange is a Highpass and Wiener filtered form at 44100Hz sample.

A finely zoomed in picture of each "tick" (unfiltered in an audio program) looks like so: enter image description here

It's extremely oscillatory, however, there is a clear and obvious local maximum (when zoomed in far enough anyways (the duration of a tick is 0.016s or so)

I'm not particularly interested per say in the amplitude, however what I'd like to do, is to be able to automate and count the freq. of the "beats/ticks". This is currently done 'by hand' for each individual file I have to deal with and when a person has MMA...well, you get the point

Accuracy is a must in this case, the possible periods of the beats are at 0.200 [s] and 0.166 [s] repeating (5hz, and 6hz respectfully). Any kind of drift more than +/-0.002 second isn't acceptable.

Through many readings of this link, this link,this (the last link does nearly what but alas it's bpm) and many others, I've managed to cobble together something...that doesn't seem to get me anywhere.

dir = NotebookDirectory[];
SetDirectory[dir];
file = "eta2412.m4a";
snd = Import[file];
sndhpf = HighpassFilter[snd, 20000];
sndwf = WienerFilter[HighpassFilter[snd, 20000], 25];
sndSampleRate = Import[file, "SampleRate"];
p1 = AudioPlot[snd,  PlotRange -> {{0, 5}, {-1*10^-2, 1*10^-2}}];
p2 = AudioPlot[sndwf, PlotRange -> {{0, 5}, {-1*10^-2, 1*10^-2}}, PlotStyle -> Purple];
p3 = AudioPlot[sndhpf, PlotRange -> {{0, 5}, {-1*10^-2, 1*10^-2}}, PlotStyle -> Green];
data = Flatten[AudioData[sndwf]];
data1 = Drop[data, {50000, Length[data]}];

I've attempted to do audio processing itself,

getting to

res = AudioLocalMeasurements[sndwf,"RMSAmplitude",PartitionGranularity ->{Quantity[0.1, "Milliseconds"],Quantity[0.1, "Milliseconds"]}];
ListLinePlot[res, PlotStyle -> Red, PlotRange -> {{0, 2}, {0, 0.005}}]

Show[AudioPlot[sndwf, PlotRange -> {{0, 5}, {0, 0.005}}],ListLinePlot[res, PlotStyle -> Red, PlotRange -> {{0, 5}, {0, 0.005}}], AspectRatio -> 3/6, ImageSize -> "Large"]

show

Now, I'm unfortunately at a complete loss on how to get each ticks local peak and calculate their global frequency, or rather, period.

How would one go about this? I've tried in Fourier as suggested in other posts..but the noise seems too extreme to give me anything I can understand or use to get further.

ListLinePlot[p = PeriodogramArray[data1], PlotRange -> All, ImageSize -> Large]

fourer

I have posted this over at stackexchange as well, incase this seems familiar to anyone. But I figured I'd try to hit two birds with two stones, should someone there post a solution I"ll gladly update it here. Thanks for the help! :)

POSTED BY: Mor Bo
16 Replies
Posted 5 years ago

Hi GIlmar, sorry for such a long time to reply, I've been out travelling for some time.

Here are the data files, assuming it's still interesting for you!

zim

phenix 140sc

phenix130

The eta is apparently missing, and infact, I don't seem to have the original file on my laptop anymore.

POSTED BY: Mor Bo

@ Mor Bo (01/04/2019) I see that Dr. Neil Singer was the author of "TickingClock.nb" but, my request about the eta2412 file still holds. Thank you! Gilmar Rodriguez-Pierluissi

@ Mor Bo (01/04/2019) : You provided "TickingClock.nb". Can you provide your "eta2412 data1" as another attachment available in this Mathematica Community post? Your internet link to this data file (and other data files above) are no longer working. Thank you! Gilmar Rodriguez-Pierluissi

Posted 6 years ago

@dontsaywe

I haven't heard a word why OP didn't say why he hadn't used a Tektronix Oscilliscope and whether the OS had given him the answer rather immediately (as is my guess it would do).

I feel like you didn't read.

Yes, I could have simply bought an expensive OS...or you know, the proper machine...like a watch timing machine. And not even wasted the time or money messing around with an OS. Or, if you read my post correctly, you would have noticed I was already using the correct software to analyse and count the audio clip accurately to begin with. Inventing the wheel twice is obviously kinda silly. Again, I agree with you 100%.

you shouldn't bother writing custom software for something you can get cheaply off (ebay amazon etc) that will be far better. it would be like buildign your own custom radio to listen to news

I shouldn't bother doing anything I guess because the industry already did it for me....

Hackaday Here is a nice site for you to gander at. It might help to understand my point.

I'm never going to learn MMA, nor am I ever going to learn how people before me managed to get their things to work in their black box electronics and already compiled code if I don't attempt (with help obviously) to do anything except open my wallet.

Why did I even bother buying MMA If I didn't plan on using any of its features, like audio processing or countless others. If I can just buy something else to do it.

Mr Wolfram should have just bought a matlab license I guess instead of making Mathematica?

improvements, if you offer any, to using MM as an OS would be neat but who will pay? i don't want to discourage improvements to mm :) certainly others have been doing so

I don't give a damn about money, I'm doing my own research not trying to improve MMA, not sell a product, nor sell MMA.

I appreciate you trying to, what you said, "point the OP in the right direction and not wasting others time" or whatever you thought. And your right, there are already solutions, Watch timing machines designed by the industry for hobbiest, professionals and consumers to buy.

But thats not the point now, is it?

I appreciate the thought you're trying to make, Really I do, thank you for your suggestion. In another situation, I'd probably take your advice. I'm not trying to be stiff, or discourage your comments. But Its obvious we have two wildly different views on learning.

POSTED BY: Mor Bo
Anonymous User
Anonymous User
Posted 5 years ago

I feel like you didn't read

i've read it again i see no mention that you already had a solution and were duplicating it for hobby

the OS i showed is obviously just one model - i did not say it was the least cost model needed

POSTED BY: Anonymous User
Anonymous User
Anonymous User
Posted 6 years ago

"Accuracy is a must in this case, the possible periods of the beats are at 0.200 [s] and 0.166 [s] repeating (5hz, and 6hz respectfully). Any kind of drift more than +/-0.002 second isn't acceptable."

Scopes are accurate to Gigahertz.

You can analyze waves in MM but if you want quick and good answers you really need to set aside a little $ and get an OS.

Also: the newer ones interact with PC software.

You shouldn't bother writing custom software for something you can get cheaply off (ebay amazon etc) that will be far better. It would be like building your own custom radio to listen to news.

Also: my comment wasn't to be stiff or discouraging. It was to steer you a good direction. My comment about "time window" and such was to help you decide that you can't quickly and accurately describe "chaos" unless you set windows and use regular metrics. (Obviously, oscilloscopes have more than just FFT builtin to identify curves. You can't use highly analytical Mathematica functions to "quickly process" gigabytes/s of wave data like a scope can.)

Improvements, if you offer any, to using MM as an OS would be neat but who will pay? I don't want to discourage improvements to mm :) Certainly others have been doing so.

My advice would be to arrange your work like the layout of Tektronix and read material about their work. Why will become obvious much later.

POSTED BY: Anonymous User
Anonymous User
Anonymous User
Posted 6 years ago

I haven't heard a word why OP didn't say why he hadn't used a Tektronix Oscilliscope and whether the OS had given him the answer rather immediately (as is my guess it would do).

OP has to name a range (a time range / sweep / horiz) certainly, volts (vertical if applicable), and also the sampling rate for an answer to be formed, i think.

The question of if OS software is freeware and Mathematica has Tektronix software built in, i'm unsure of. Mathematica has many signal analysis functions built-in: but it is not arrange so to make it a drop in replacement for an OS front end.

enter image description here

POSTED BY: Anonymous User

Mor,

Even after fixing the algorithm I do not agree with your manual findings on the Phenix. Are you sure it is correct?

Also, you have to balance the resolution of the FFT with the resolution of what you collect. For example, you have only 6 ticks per second for 60 seconds = 360 events. This fact limits your resolution as well.

Regards,

Neil

POSTED BY: Neil Singer

Mor,

Firstly, is there a reason that you didn't filter the audio files? There is a lot of background noise in the recordings. Or was this simply not required, being FindPeaks ignored anything below 0.002?

I only looked at the one data set so I did not see that the other sets have more noise in them. I agree with you that the filtering helps (especially the noisy sets). I was able to get away with leaving the noise on the eta2412 data so I saved the step. I applied your WeinerFilter and all data sets are improved by less noise and the PeakDetection works better.

The key to the Peak detect is to not have peaks appear in between the ticks. I raised the threshold so only clusters of peaks form on the "tick". The values I used for both the chiaka and phenix was

binarypeaks = PeakDetect[sndData, 0, 0.001, 0.0002];

Where sndData is filtered with your Weiner filter as shown in your post.

What did you mean by DC? A resonsant frequency of some kind?

DC refers to a steady state offset -- the data with a bunch of 1's and 0's has a mean that is not at zero. There are two ways to deal with that -- one way is to subtract the mean before taking the Power Spectrum. Second is to ignore the peak at the first data point (which is the zero frequency point or "DC")

You mentioned the length of the data was low...the other files are around 60 seconds or so. If I use a longer file length, would the 0 padding be required? To be honest, I'm not sure I quite understand the additional padding at all. But you don't need to explain it.

The resolution of the Fourier transform or Power spectrum is directly related to the time duration of your signal. If you have a 10 second signal you will have 6 times lower resolution in determining frequency information than if you have a 60 second signal. You can manipulate this a bit by padding the signal with zeros. You will get no more frequency information and your peaks will slowly shrink as you add more zeros, but you can increase the resolution this way. I changed the script to pad with 6 times your signal length to do the 60 second samples and that gave a good resolution. (even with this padding I only am getting 4 decimal places on the period -- is this good enough for you?). There are some clever ways to increase this without increasing the data size but I would need to understand your issues a bit more. (ie. anti-aliasing and downsampling -- you really do not need 44khz for this, taking longer samples instead of padding, and others)

I find this problem interesting . I also have some ideas on how to significantly improve things. I'd recommend you email me directly at "NeilS" at the domain in my profile. We should probably talk directly.

Regards,

Neil

POSTED BY: Neil Singer
Posted 6 years ago

I will write you an email today, as soon as I get a chance! Definitely looking forward to working with you on this problem :)!

POSTED BY: Mor Bo
Posted 6 years ago

Hallo Neil! I finally got a chance to have a look at your work, and wow. thank you for your hardwork! It's incredible how accurate the algorithm managed to calculate the period.... I do have some questions though. But it may just be something easily modified within the code or having better recordings...

Firstly, is there a reason that you didn't filter the audio files? There is a lot of background noise in the recordings. Or was this simply not required, being FindPeaks ignored anything below 0.002?

What did you mean by DC? A resonsant frequency of some kind?

You mentioned the length of the data was low...the other files are around 60 seconds or so. If I use a longer file length, would the 0 padding be required? To be honest, I'm not sure I quite understand the additional padding at all. But you don't need to explain it.

I'm unsure how familiar you are with watches or specifically their movements and inner workings, if you are ignore this paragraph... ETA is quite famous for having high quality well made movements. The Russians are also known between the 40s and 60s to have some high quality little machines. In general swiss movements are good. However, some brands Phenix for example although nice quality watches, were known to try new things, having made their movements completely inhouse...sometimes doing odd things, which would cause a lot of weird "inner" housing noise.

I noticed the eta2412 produces about 320~ peaks within the 11 seconds clip (from your algorithim I mean) which provides lots of data to produce the accurate calculated Hz/Period (if I understood what is going on anyways) An interesting point of this movement is it's relatively simplicity, but also the use of a timed annular balance wheel and spring regulator.

The Phenix 140SC However, has a much more "complicated' design, on top of it's age (the particular watch I have I mean) It uses a "free spring balance" meaning it's regulated through the interia of the wheel and some other interesting design tidbits, this makes the watch more complicated and difficult to adjust/regulate, however should technially produce a more accurate watch). When running through the algorithm, this particular watch (which has a hand measured period of 0.187, which means the watch runs close to 2 minutes fast per day) produces about 100 peaks (when using a filtered version 30 seconds long, 150~ unfiltered) phenix1 phenix2

The calculated period at the end is 0.19987, which unfortunately is very wrong compared to the hand produced measurement

Another example is the Chaika1600 movement. When running through the algorithm produces only 27 peaks across 30 seconds and in the end a period of 0.166689. This isn't far away from the hand measured value of 0.1678, which would be about 9 seconds slow per day. chai1 chai2

A Third watch the Phenix 130, has a measured period of 0.19989, when running through the algorithm I get 4000 (!) peaks, and a period of 0.19974. Which is right on the money. These three clips I changed the cutoff in findpeak to 0.001, as a side note. phenix1301 phenix1302

Here I would ask if you have an idea of why there is such a huge variation in detected peaks. I feel like there must be an issue with the "shape" of each tick, I will have to investigate to see if they are all wildly different between each watch/fork design

Watches per day generally will drift in a tolerance generally -5/+12 [s] depending on a million things (for good watches of course). because of that, getting 0.1666 or 0.1667 or even 0.165 from hand measured and/or algorithmic data must be averaged over several days with environmental data to get the kind of final research data I'm looking for. This I think shows an incredible robustness of your algorithm and accuracy, both comparing to a 6hz or 5hz signals/watches, and because of that, I can only praise and say thank you.

Unfortunately, the Phenix140SC seems to be measured completely wrong...My assumption would be because of the quality and consistency of the recordings/signals. Could this be over lying issue? My apologies if there is something trivial about the miscalculation I should be easily seeing in the code.

If you think the samples are simply poor, I can gladly record new ones, and retest before having to put more work/thought into the algorithm.

Thanks again so much for the help!

POSTED BY: Mor Bo

Mor,

One other thought -- I also realized that the technique above is insensitive to the parameters to the PeakDetect. For example,

peaks = FindPeaks[sndData, 0, 0.002, 0.002];

Works fine so you should be able to generalize the algorithm to different audio clips -- you may only have to adjust the one number -- the amplitude cutoff for your clip loudness.

Did you try what I posted? Is this what you wanted? If so, I will cross post it in StackExchange.

Regards,

Neil

POSTED BY: Neil Singer

Mor,

As vibration analysis is one of my interests I could not let this one go by! so here is my take on this!

I attached the file at the bottom to make it easier to run.

Start with your import.

dir = NotebookDirectory[];
SetDirectory[dir];
file = "eta2412.m4a";

snd = Import[file];
sndSampleRate = Import[file, "SampleRate"];

Convert the audio to raw data:

sndData = AudioData[snd][[1]];

Use peak finding to get the peaks -- I adjusted the values to do well on this type of data -- The goal is to get more points than you need around the peaks to make sure we get all peaks -- err on the side of overinclusiveness

peaks = FindPeaks[sndData, 0.9, 0.0025, 0.002];
Length[peaks]
ListLinePlot[sndData, Epilog -> {Red, PointSize[0.01], Point[peaks]}, 
 PlotRange -> All, ImageSize -> Large]

enter image description here

Now let's change to use binary (1's or zeros) for the peaks to make a nice time domain array

binarypeaks = PeakDetect[sndData, 0.9, 0.0025, 0.002];

We need better frequency resolution because you only collected 11 seconds of data -- the longer the data, the better the resolution. We can make up for some of that if we pad the data with a ton of zeros:

paddingAmount = 20;    
binarypeaksPad = 
  ArrayPad[binarypeaks, paddingAmount*Length[binarypeaks]];

Use the approximate frequency to window the data to what we care about

approxFreq = 6;
bins = Length[binarypeaksPad];
approxbins = Round[approxFreq*(bins/sndSampleRate) *1.2] // N

This will tell us our resolution we will get in the frequency domain -- make sure we are good enough

resolution = 1/(bins/sndSampleRate) // N

Compute a power spectral density of the binary bins and plot it -- we have a spike at DC and a spike at our desired frequency

spec = Abs[Fourier[binarypeaksPad]^2];
ListLinePlot[spec[[1 ;; approxbins]], PlotRange -> All, 
 ImageSize -> Large]

enter image description here

Find our big peak in this region

freqbin = 
 Position[spec[[1 ;; approxbins]], 
    Max[spec[[Round[approxbins/2] ;; approxbins]]]][[1, 1]] - 1

This is our actual frequency

In[21]:= actualFreq = freqbin/(Length[spec]/sndSampleRate) // N

Out[21]= 5.9996

This is our period

In[22]:= 1/actualFreq // N

Out[22]= 0.166678

It matches your hand processed results.

Regards,

Neil

Attachments:
POSTED BY: Neil Singer
Posted 6 years ago

Hi Daniel! Ahh here are some links for the audio files, with .mp3 extension....the m4a are typically Apple. I attempted to something similar with MaxPeak, however it seemingly failed with the line plot only returning 1s (likely my poor MMA skills at work here)...The only issue I could see with it however, is that there isn't any nice cutoff for maximum peaks, between different movements things can change wildly.

I'll look into trying clip, hope the mp3s are useful :) in the meantime.

phenix140sc chaika1600 eta2412

POSTED BY: Mor Bo

Apparently my Linux machine does not like that format, so I cannot experiment. From the pictures, I wonder if you might use Clip to set values above some threshold to 1, and below to 0. The main frequency might then be more easily obtained from Fourier or similar.

POSTED BY: Daniel Lichtblau
Posted 6 years ago

As additional information I

All the watches I deal with for work are 5hz or 6hz explicitly, to gauge their accuracy, or (where the research is) the degradation of them over time, I load up the recorded file, and measure the peaks by hand in sonic visualiser and average the peak period. Some movement info and examples can be found: eta2412 Phenix 140SC As measured yesterday:

Phenix 140SC has a period of 0.187, making it 96 seconds per day fast Eta2412 has a period of 0.16668, making it -0.112 seconds slow. Chaika1600 has a period of 0.1678, making it -9 second slow.

Thanks again for the help!

POSTED BY: Mor Bo
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract