WatchUSeek Watch Forums banner

381 - 400 of 450 Posts

·
Registered
Joined
·
80 Posts
Could you record a minute or so of your favorite quartz watch and send it to me?
Sure... though I'm not quite sure of what you're asking for -- I'm familiar with taking snapshots but I'm not aware of a recording mode in the software. If you could explain exactly what you'd like me to do, I'd be happy to do it. My suspicion though, is that we're going to see that none of my quartz watches are being picked up by the mic. I typically see only a screen that shows nothing happening.

Screenshot_20180715_144550.png

My suspicion is that the sofware has no problem picking up the sound of my mechanical watches (see previous images) but that the software just isn't able to hear my quartz watches, even with the preamp gain full-on. It seems that the quartz watches are just too quiet for this type of mic. Of course, this is all guessing on my part, as I'm not getting any clear error message out of the software. That is to say, maybe I just don't know what I should be looking for.

Thanks.
 

·
Registered
Joined
·
2,220 Posts
Sure... though I'm not quite sure of what you're asking for -- I'm familiar with taking snapshots but I'm not aware of a recording mode in the software. If you could explain exactly what you'd like me to do, I'd be happy to do it. My suspicion though, is that we're going to see that none of my quartz watches are being picked up by the mic. I typically see only a screen that shows nothing happening.

My suspicion is that the sofware has no problem picking up the sound of my mechanical watches (see previous images) but that the software just isn't able to hear my quartz watches, even with the preamp gain full-on. It seems that the quartz watches are just too quiet for this type of mic. Of course, this is all guessing on my part, as I'm not getting any clear error message out of the software. That is to say, maybe I just don't know what I should be looking for.

Thanks.
Download Audacity (it's free) and make a recording though that.
 

·
Registered
Joined
·
87 Posts
Discussion Starter #383
Download Audacity (it's free) and make a recording though that.
Thanks.

@coralnut: as 24h says, just make an audio recording with whatever program (Audacity is excellent, and probably you have it in Fedora). Use the same mic setup that you would with tg.
 

·
Registered
Joined
·
63 Posts
Any recommendation for a low cost microphone I could buy? I wanted to buy piezo clip (as it is stated in pdf user's guide) but it has not 3,5 mm jack which I could use with my computer (just like any other microphone).
 

·
Registered
Joined
·
273 Posts
Hi blackarrow,

if you want to verify, that a piezo mic is really insufficient without an amplifier, you can search for a 6,3mm mono to 3,5mm strereo adaptor (in which I had no luck). Mono to stereo adaptor for the reason of definitely not shorting right channel to ground.
If you are familiar with soldering, then just use a 3,5mm stereo jack and solder it to the cable instead of the 6,3mm mono. Or just cut the cable with jack from an old headphone and solder it to the pick up clip.

br Klaus
 

·
Registered
Joined
·
25 Posts
I would like to thank the developer for the lovely software. I tried it with small 27mm piezo sensor (Clip on guitar sensors will be ok as well) and Kemo M040N preamp with 9v battery and I only could say WOW.
Hi chaps,
I got a Kemo M040n preamp.
Has anyone got idea how to use it to make TG works? (some one here said used with TG, it was “WOW”)
 

·
Registered
Joined
·
63 Posts
Hi blackarrow,

if you want to verify, that a piezo mic is really insufficient without an amplifier, you can search for a 6,3mm mono to 3,5mm strereo adaptor (in which I had no luck). Mono to stereo adaptor for the reason of definitely not shorting right channel to ground.
If you are familiar with soldering, then just use a 3,5mm stereo jack and solder it to the cable instead of the 6,3mm mono. Or just cut the cable with jack from an old headphone and solder it to the pick up clip.

br Klaus
Thanks. I managed to find some pickup microphone on eBay, but not sure if they will work properly.

s-l1600.jpg
It has a standard 3,5 mm jack.

However, if I look up my microphone jack on the Microsoft Surface it is combined jack for microphone & earphones. Is this a problem if I have combined jack only?
 

·
Registered
Joined
·
25 Posts
Hi,

Any one got idea why when using TG, it keeps all the time like this:
Rock-steady -1739 s/d 00ms 000deg
The rest (paper strip emulator, scape cycles windows and waveform), seem working and changing constantly.
 

·
Registered
Joined
·
80 Posts
Thanks.

@coralnut: as 24h says, just make an audio recording with whatever program (Audacity is excellent, and probably you have it in Fedora). Use the same mic setup that you would with tg.
Sorry for the delayed reply.

I am familiar with Audacity, but I have't been able to use it lately due to a library incompatibility problem that's come along with a recent software upgrade. The result is that when I attempt to record, Audacity does not use the sampling rate and bit depth that I specify and the results turn out to be unpredictable and inconsistent. Once I have it working again, what settings do you require as recording defaults?

Back to the subject of calibration -- I'm having trouble understanding why we have a quartz-referenced calibration procedure in the first place, for two reasons:

First, Quartz isn't all that accurate. That is to say, Quartz is better than most mechanical movements, but it's nowhere near as accurate as a computer clock that's running at megahertz frequencies. Quartz watch accuracy is on the order of +/- 500 milliseconds/day. Although that's better than many mechanical movements, 1/2 spd isn't a good accuracy reference if you're trying to measure a watch that has an accuracy on the order of 2 spd. The Nyquist theorem tells us that sampling at 2x the desired frequency is the absolute minimum acceptable standard. With a quartz reference we barely have enough accuracy to measure the performance of a mechanical chronometer with a resolution of +/- 2 spd.

Second, any modern computer is equipped with a Network Time Protocol based system clock that operates at megahertz frequency. My plain-Jane Fedora system uses Chronyd, which performs regular time-syncs, polling it's upstream time server every 2^6 seconds, and between polls it automatically compensates for any skew in the system clock. The following query shows that the NTP-calibrated system clock on my PC is 1.78 nanoseconds slow of NST.gov's atomic NTP time as I type this:

Code:
[FONT=monospace][COLOR=#5454FF][B]#[/B][/COLOR][COLOR=#000000] chronyc tracking                                                                                                  [/COLOR]
Reference ID    : 0A0A0A01 (*********)
Stratum         : 2
Ref time (UTC)  : Mon Aug 13 22:58:52 2018
[B]System time     : 0.000001780 seconds slow of NTP time[/B]
Last offset     : -0.000003389 seconds
RMS offset      : 0.000005357 seconds
Frequency       : 37.157 ppm fast
Residual freq   : -0.002 ppm
Skew            : 0.077 ppm
Root delay      : 0.036606569 seconds
Root dispersion : 0.047560256 seconds
Update interval : 64.6 seconds
Leap status     : Normal
[/FONT]
Nanosecond resolution is millions of times higher resolution than millisecond resolution. Using a quartz based reference that has accuracy on the order of 500 msec doesn't seem worth the effort when a call to the system clock can obtain time at 1.78 nsec resolution. That's actually a difference of what, 280 million times higher frequency?

Given that any modern PC uses NTP time sycing (Microsoft, Apple or Linux, take your pick), nanosecond level time accuracy is available on any modern PC. I don't understand why the timing software is querying the soundcard clock as a time reference, as the soundcard clock is uncalibrated. It also doesn't make sense to me why the software expects a user to use a quartz-based calibration procedure using an external time source (watch) when polling the system clock would provide a reference source for calibration that's accurate to the nanosecond level and is presumably hundreds of millions of times more accurate. Polling the soundcard for timing seems like it would provide a lesser result than polling the system clock on any NTP-based PC system.

I have to assume that I'm misunderstanding something. Thanks for your time.
 

·
Registered
Joined
·
2,220 Posts
Sorry for the delayed reply.

I am familiar with Audacity, but I have't been able to use it lately due to a library incompatibility problem that's come along with a recent software upgrade. The result is that when I attempt to record, Audacity does not use the sampling rate and bit depth that I specify and the results turn out to be unpredictable and inconsistent. Once I have it working again, what settings do you require as recording defaults?

Back to the subject of calibration -- I'm having trouble understanding why we have a quartz-referenced calibration procedure in the first place, for two reasons:

First, Quartz isn't all that accurate. That is to say, Quartz is better than most mechanical movements, but it's nowhere near as accurate as a computer clock that's running at megahertz frequencies. Quartz watch accuracy is on the order of +/- 500 milliseconds/day. Although that's better than many mechanical movements, 1/2 spd isn't a good accuracy reference if you're trying to measure a watch that has an accuracy on the order of 2 spd. The Nyquist theorem tells us that sampling at 2x the desired frequency is the absolute minimum acceptable standard. With a quartz reference we barely have enough accuracy to measure the performance of a mechanical chronometer with a resolution of +/- 2 spd.

Second, any modern computer is equipped with a Network Time Protocol based system clock that operates at megahertz frequency. My plain-Jane Fedora system uses Chronyd, which performs regular time-syncs, polling it's upstream time server every 2^6 seconds, and between polls it automatically compensates for any skew in the system clock. The following query shows that the NTP-calibrated system clock on my PC is 1.78 nanoseconds slow of NST.gov's atomic NTP time as I type this:

Code:
[FONT=monospace][COLOR=#5454FF][B]#[/B][/COLOR][COLOR=#000000] chronyc tracking                                                                                                  [/COLOR]
Reference ID    : 0A0A0A01 (*********)
Stratum         : 2
Ref time (UTC)  : Mon Aug 13 22:58:52 2018
[B]System time     : 0.000001780 seconds slow of NTP time[/B]
Last offset     : -0.000003389 seconds
RMS offset      : 0.000005357 seconds
Frequency       : 37.157 ppm fast
Residual freq   : -0.002 ppm
Skew            : 0.077 ppm
Root delay      : 0.036606569 seconds
Root dispersion : 0.047560256 seconds
Update interval : 64.6 seconds
Leap status     : Normal
[/FONT]
Nanosecond resolution is millions of times higher resolution than millisecond resolution. Using a quartz based reference that has accuracy on the order of 500 msec doesn't seem worth the effort when a call to the system clock can obtain time at 1.78 nsec resolution. That's actually a difference of what, 280 million times higher frequency?

Given that any modern PC uses NTP time sycing (Microsoft, Apple or Linux, take your pick), nanosecond level time accuracy is available on any modern PC. I don't understand why the timing software is querying the soundcard clock as a time reference, as the soundcard clock is uncalibrated. It also doesn't make sense to me why the software expects a user to use a quartz-based calibration procedure using an external time source (watch) when polling the system clock would provide a reference source for calibration that's accurate to the nanosecond level and is presumably hundreds of millions of times more accurate. Polling the soundcard for timing seems like it would provide a lesser result than polling the system clock on any NTP-based PC system.

I have to assume that I'm misunderstanding something. Thanks for your time.
While I don't fully understand how a computer's clock functions related to the processor, I believe that in the case of watch timing software we are solely relying on the sound card clock.
I find the best way to calibrate TG and Watch-O-Scope is to start a timing test for a quartz watch with an app like Toolwatch.io for an ENTIRE month while storing your watch somewhere with a consistent temperature.
The readout in this app is your KNOWN RATE.

For this example, let's say that the known rate is +0.4 s/d.
Now, start a calibration in the software. We'll use a CALIBRATION readout of -0.6 s/d.
Subtract KNOWN RATE from CALIBRATION.
-0.6 - 0.4 = -1.0

Since the software is effectively 1 second slow we need to correct it with a positive number.
Enter the calibration value of +1.0 in the software.
If your number after performing the subtraction is positive, use a negative number for the calibration value.
 

·
Registered
Joined
·
1,181 Posts
Given that any modern PC uses NTP time sycing (Microsoft, Apple or Linux, take your pick), nanosecond level time accuracy is available on any modern PC. I don't understand why the timing software is querying the soundcard clock as a time reference, as the soundcard clock is uncalibrated. It also doesn't make sense to me why the software expects a user to use a quartz-based calibration procedure using an external time source (watch) when polling the system clock would provide a reference source for calibration that's accurate to the nanosecond level and is presumably hundreds of millions of times more accurate. Polling the soundcard for timing seems like it would provide a lesser result than polling the system clock on any NTP-based PC system.
The reason behind this is because the audio that comes in through the mic is converted by your soundcard into your digital waveform by its DAC, at a sampling rate of (for example) 44.1khz. The trick is, of course, with the soundcard's own quartz crystal reference which is part of the DAC circuitry to time its sampling rate, which depending on the sound card's electronics, is very likely not running at exactly 44.1khz. This could be due to quality of crystal oscillator (high quality ones can cost more than your typical sound card costs in total), voltage control to set its reference frequency, temperature of the crystal (which the sound card likely doesn't even take into account), or even aging of the crystal.

Hence the requirement to calibrate TG so that it knows what sampling rate of the digital audio actually is, since though you might tell the sound card that you want audio at 44.1khz, it's not going to be exactly that (from reports I've read most sound cards tend to be off within +/- 100ppm).

Now, as for the computer's clock, since it's completely out of the loop with regards to the DAC circuitry, it can't be used to help in that regard.
 

·
Registered
Joined
·
87 Posts
Discussion Starter #393 (Edited)
...

Nanosecond resolution is millions of times higher resolution than millisecond resolution. Using a quartz based reference that has accuracy on the order of 500 msec doesn't seem worth the effort when a call to the system clock can obtain time at 1.78 nsec resolution. That's actually a difference of what, 280 million times higher frequency?

Given that any modern PC uses NTP time sycing (Microsoft, Apple or Linux, take your pick), nanosecond level time accuracy is available on any modern PC. I don't understand why the timing software is querying the soundcard clock as a time reference, as the soundcard clock is uncalibrated. It also doesn't make sense to me why the software expects a user to use a quartz-based calibration procedure using an external time source (watch) when polling the system clock would provide a reference source for calibration that's accurate to the nanosecond level and is presumably hundreds of millions of times more accurate. Polling the soundcard for timing seems like it would provide a lesser result than polling the system clock on any NTP-based PC system.

I have to assume that I'm misunderstanding something. Thanks for your time.
Thanks for you comments, and to all those that answered already. I don't have much to add to their excellent responses, yet, maybe, I can clear up some misunderstanding.

The system clock of a modern pc, when disciplined via NTP, would time mechanical watches adequately, no question about that. However, let me point out that the situation is not precisely as the lines above imply. From a typical home network, connected via DSL, one might have a 30ms round trip time to a geographically close internet node (just try ping google.com). This is about the inherent uncertainty of any internet based synchronization mechanism. By averaging several samples and assuming that the round trip is symmetric (which often a DSL connection is not), NTP might bring the uncertainty down to a few milliseconds. Nanoseconds, however, no way. It's like measuring lengths with a stick having marks every 30mm: with a bit of luck, one might guess the nearest millimeter, but nanometers? Quoting from ntp.org: Home of the Network Time Protocol (I'll assume they know their stuff).

The typical accuracy on the Internet ranges from about 5ms to 100ms, possibly varying with network delays. A recent survey suggests that 90% of the NTP servers have network delays below 100ms, and about 99% are synchronized within one second to the synchronization peer.
Yet, even though it is not nanosecond accurate, I believe that the system clock of a PC is a decent reference for our task of timing watches. The real problem, for me, is to interface with the system clock. There are two obstacles. The first and largest one is that I get sound samples, obviously, through the sound card (which, nowadays, is often integrated into whatever chip on the mainboard). This particular piece of hardware has, in general, its own clock, so this is the clock that times the samples, and, by necessity, this is the clock that I have to characterize. To handle sound in a cross-platform portable manner, I rely on a library called portaudio, used and developed by the Audacity folks. This library, hands to tg a bunch of samples every now and then: it's up to the library itself to decide precisely when. Portaudio, in turn, receives the audio from whatever underlying infrastructure the operating system might have, and the OS receives it from the hardware. Now, there is a unpredictable and unspecified delay at each step of this chain, so I cannot know, at any given moment, when the sound samples that tg just received have been actually collected. Then, if I had to correlate this samples with the system clock, I would have another bunch of uncertainties coming from it, even though it is generally more reliable. For instance, you see that on your very machine the ntp daemon resets the clock every ten minutes: how could tg know when the clock is being reset on every system? Surely there will be machines that just set the time once when they are powered on, or some that never do it (consider that tg has been installed on Raspberry Pi's): for timing purposes this is the same, and these computer clocks are often quite bad if not reset by NTP. In conclusion, I would have to embed a little NTP client inside tg just to get a reliable time source, and even if, then, I cannot reliably correlate it with the sound card clock anyway.

My solution has been to use a time signal that is fed directly through the sound card, so the correlation is effected by just timing the reference clock with the device that I want to characterize. This is the direct simple solution, and, I believe, rather robust. I do not say that one cannot use system clock plus NTP. I say that I cannot do it reliably in a manner that works cross-platform on most setups.

Edit. I understand that the 0.5s/d of a quartz watch might sound less than impressive, but that is just the level of uncertainty of the rest of the system. Consider that 0.5s/d is 5ppm, or 0.1ms in 20s. Tg integrates samples over a period of 16s, and one can not realistically ask more than 0.1ms, corresponding to 10KHz, from the audio, which is cut at 20KHz by the anti-aliasing filter anyway.
 

·
Registered
Joined
·
87 Posts
Discussion Starter #394
Hi,

Any one got idea why when using TG, it keeps all the time like this:
Rock-steady -1739 s/d 00ms 000deg
The rest (paper strip emulator, scape cycles windows and waveform), seem working and changing constantly.
Hi, sorry, I missed your post. Like that, I have no idea. Could you please record about a minute of the very same sound that you are feeding tg, using Audacity or any other similar program, and then post or send to me the recording. With that, I can try to debug your issue.
 

·
Registered
Joined
·
12 Posts
Just a quick thank you to the author of this software for all the hard work and many hours that have gone in to designing, testing and distributing it.

It installed without issue, from the .debs on my two Ubuntu 18.04 laptops (one old 32bit one and one new 64 bit one).

The only problem I've discovered so far is that my Thinkpad T460 has been designed by an idiot who thought it a good idea to place the microphone adjacent to the trackpad and next to the fan. Needless to say, the intermittent fan noise is an issue when trying to decipher the gentle ticking of watch, and every trackpad move or click throws up spurious results. The rather obvious solution is to use an external microphone. My other, older laptop has no such issues, and worked perfectly first time.

Thanks once again for this very functional and capable piece of work. I'm going to have a lot of watch tinkering fun using it.
 

·
Registered
Joined
·
12 Posts
Just a quick thank you to the author of this software for all the hard work and many hours that have gone in to designing, testing and distributing it.

It installed without issue, from the .debs on my two Ubuntu 18.04 laptops (one old 32bit one and one new 64 bit one).

The only problem I've discovered so far is that my Thinkpad T460 has been designed by an idiot who thought it a good idea to place the microphone adjacent to the trackpad and next to the fan. Needless to say, the intermittent fan noise is an issue when trying to decipher the gentle ticking of watch, and every trackpad move or click throws up spurious results. The rather obvious solution is to use an external microphone. My other, older laptop has no such issues, and worked perfectly first time.

Thanks once again for this very functional and capable piece of work. I'm going to have a lot of watch tinkering fun using it.
 

·
Registered
Joined
·
21 Posts
Anyone having problems measuring a rolex because of the chiming echoe sound of the movement ?
I pass the sound via Ableton to EQ it a bit but its a bit jumpy. My Omega is way easier and clean (sound).

I use a guitar piezo for tuning etc. Via a mixer with dedicated Mic input.
 

·
Registered
Joined
·
21 Posts
I can try to debug your issue.
any idea how to get more logging out of it?
im trying to calibrate with a good gps pps signal with gives a good (as i see it) signal when passed via Abletons spectrum analyser and some EQIng but in the end i get “fail”. The “dot” display seems good.
 

·
Registered
Joined
·
21 Posts
Anyone having problems measuring a rolex because of the chiming echoe sound of the movement ?
I pass the sound via Ableton to EQ it a bit but its a bit jumpy. My Omega is way easier and clean (sound).

I use a guitar piezo for tuning etc. Via a mixer with dedicated Mic input.
If you could share an audio file to browse we may be able to offer help.
 
381 - 400 of 450 Posts
Top