Group Abstract Group Abstract

Message Boards Message Boards

Accurately calculate tick tock period of mechanical watches?

Posted 7 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 6 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 7 years ago
POSTED BY: Mor Bo
Anonymous User
Anonymous User
Posted 6 years ago
POSTED BY: Anonymous User
Anonymous User
Anonymous User
Posted 7 years ago
POSTED BY: Anonymous User
Anonymous User
Anonymous User
Posted 7 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
POSTED BY: Neil Singer
Posted 7 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 7 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
Attachments:
POSTED BY: Neil Singer
Posted 7 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
POSTED BY: Daniel Lichtblau
Posted 7 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