Open source timing software. - Page 40
Like Tree164Likes

Thread: Open source timing software.

Page 40 of 41 FirstFirst ... 30 31 32 33 34 35 36 37 38 39 40 41 LastLast
Results 391 to 400 of 409
  1. #391
    Member Iandk's Avatar
    Join Date
    Mar 2016
    Location
    Canada
    Posts
    1,166

    Re: Open source timing software.

    Quote Originally Posted by coralnut View Post
    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.

  2. #392
    Member
    Join Date
    Sep 2017
    Location
    Perth, Australia
    Posts
    523

    Re: Open source timing software.

    Coralnut, all I can say is that it seems to work well. Here's the designer's explanation of how the calibration works...

    https://forums.watchuseek.com/f6/ope...l#post29970370
    contrate_wheel likes this.

  3. #393
    Member
    Join Date
    Sep 2015
    Posts
    86

    Re: Open source timing software.

    Quote Originally Posted by coralnut View Post
    ...

    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.
    Last edited by contrate_wheel; August 17th, 2018 at 17:24. Reason: Misinterpreted the OP, sorry.
    Iandk, 24h and Stuey63 like this.

  4. Remove Advertisements
    WatchUSeek.com
    Advertisements
     

  5. #394
    Member
    Join Date
    Sep 2015
    Posts
    86

    Re: Open source timing software.

    Quote Originally Posted by Ciro View Post
    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.

  6. #395
    Member
    Join Date
    Sep 2018
    Posts
    12

    Re: Open source timing software.

    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.

  7. #396
    Member
    Join Date
    Sep 2018
    Posts
    12

    Re: Open source timing software.

    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.

  8. #397
    Member
    Join Date
    Oct 2016
    Posts
    21

    Re: Open source timing software.

    Sorry double post

  9. #398
    Member
    Join Date
    Oct 2016
    Posts
    21

    Re: Open source timing software.

    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.

  10. #399
    Member
    Join Date
    Oct 2016
    Posts
    21

    Re: Open source timing software.

    Quote Originally Posted by contrate_wheel View Post
    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.

  11. #400
    Member
    Join Date
    Mar 2016
    Posts
    13

    Re: Open source timing software.

    Quote Originally Posted by louloukos View Post
    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.

Page 40 of 41 FirstFirst ... 30 31 32 33 34 35 36 37 38 39 40 41 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

    Similar Threads

    1. Open Source for Ambit
      By hal_c_on in forum Suunto
      Replies: 1
      Last Post: May 9th, 2013, 12:05
    2. Timing Machine software
      By zodiac in forum Public Forum
      Replies: 12
      Last Post: October 24th, 2009, 23:14
    3. BIBURO watch timing software users?
      By Av8tor1 in forum Watchmaking
      Replies: 15
      Last Post: April 27th, 2009, 22:30
    4. Open Source Watch Project
      By fstshrk in forum High Accuracy Quartz watches
      Replies: 4
      Last Post: April 5th, 2009, 07:26
    5. Great design software that is Open-source *free*
      By bfgreen in forum Watch Concepts & Designs
      Replies: 1
      Last Post: October 7th, 2007, 01:42

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •