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.

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

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

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)

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.

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.

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!

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.