WatchUSeek Watch Forums banner

301 - 320 of 451 Posts

·
Registered
Joined
·
272 Posts
Yes, I read that post about calibration procedure. Idea is to take quartz watch as reference and compare it to sound card, because sound card is not so accurate (also described in that post). I'm just little confused about mentioned "correction procedure" of quartz watch, because it goes usually fast +10 s/day. So what is the real accurate reference? What is the result of calibration procedure ? Is it diff between quartz clock and sound card clock?
If so, we can use digital metronome too, they are declared as accurate, they usually have audio output, adjustable beat rate etc...
The reason I'm talking about whole this stuff is:
conventional timegraphers are usually calibrated in factory to same reference timing source, so they will all have very similar results. They also have same sound pickup method, so inputs in state machine are pretty solid, right? So you can expect similar results with some small error rate...
TG is excellent idea, ingenious algorithm, it should be used to it's limits. If we don't have sort of standardized pickup and time reference, we can not compare results precisely, right?
I'm thinking of running it on dedicated platform (RPI3 with some Linux, even better try would be Android tablet (ARM or x86) with some Linux distro), so now I'm picking up best practice tips regarding sound pickup and calibration.
I know it can be done via GPS, for example, have to study it in more details... But I think it would be overkill, because result values are not in that precision range as GPS time reference.
Building some stable oscillator reference would be "long road" too, even if I'm sure there must be some ready modules out there... So I'm trying to get best effort reference.

Pretty much we have excellent product here... Imagine you can have this software running on some embedded platform (like RPI or similar). It is affordable, you know what is "inside", it is upgrade-able etc.
So, open questions like sound pickup and calibration would be 99% of that road.
I' not speaking about price. If you compare price of RPI+Sound Pickup+Some Display+Miscellaneous stuff, it is similar to cheap timegrapher machine from Far East... But it is huge difference if you build it, you can debug it, upgrade, service etc... Not to mention contribution of members of such a large community of watch hobbyist and enthusiasts.
Thank you, please share your thoughts.
 

·
Registered
Joined
·
87 Posts
Discussion Starter #302
First, many thanks to dmnc for the mac installer!

Djolemag makes many good suggestions, for which I am very grateful. Let me express my opinion on them one by one...

djolemag said:
1. Start/stop/pause/restart features : very convenient when you change the position of watch, so false/error readings (during change of position) are not written
This one is not complicated to implement. I'm trying to evaluate whether it would be an really needed. The most straightforward way to keep track of various position is to time them separately (hitting clear between one and the next), make one snapshot per position, and then save all the snapshots together in the same file using the "save all snapshots" option. Notice that you can name snapshots, so you can call them with the name of the respective positions.

djolemag said:
2. Someone already mentioned lift angle in decimals... I know it will not cause too much errors, but maybe to reconsider adding it
It mostly boils down to what you find less annoying. Without decimals, it's quicker to adjust with the up and down arrows (ten times less clicks for equal adjustments). With decimals, you have the peace of mind that if your movement is 51.4 you can set precisely 51.4. Technically, those 0.4 degs do not make any difference at all. Possibly the best solution is to allow decimals and program the arrows to jump by integer steps (those who want decimals still can enter them via keyboard). I will put this on the todo list.

djolemag said:
3. Screenshots are really nice feature. One or two textboxes on mainscreen for comment would be great, so you can add what watch you measured in what position.
The name of the snapshots is editable, and allows you to do precisely that. You suggest a larger text area?

djolemag said:
Also, have you though of putting timestamp on screenshot, very convenient feature?
Great idea. This is definitely near the top of the todo list.

djolemag said:
4. Printing ... AS I understood, it is in TODO list... My opinion is that it should have only measured values and paper graph - dots. Finally, it is enough to print it into PDF, then everyone can print it to physical printer if needed... Very common way for many diagnostic equipment.
Yes, that's more or less how I envisage the printouts. It's a lot of code to implement, that's why it is not yet there. The move to GTK+3 of the latest version will allow me to merge some code from an old pull-request of a GitHub user named wahlstedt (I think he is also a member here) that implements a prototype for printing...

djolemag said:
Also, I've seen a lot of people are using piezo microphone with amplifier.. So it is not a general problem, but I couldn't figure out about audio input: should be stereo or mono? If stereo, I have to wire it in parallel to get same signal on L and R channel?
I'm strongly for piezo pickup because reduction of environmental noise...
For now, tg takes the default audio input and makes the average of the two stereo channels. Selection of audio input is also something that needs to be improved in tg, and there is also material in this direction in wahlstedt's pull request.

Finally, I completely agree with alvh on this.

alvh said:
That's not completely correct etc.
Tg is just a comparator that, indirectly, checks a mechanical watch under test against a reference quartz watch, using the clock of a sound card to transfer this information. It's like weighing an apple against a kilogram weight by first using the weight to calibrate a scale and then using the scale to weigh the apple. A quartz watch is usually good enough for the job, unless you seek the very ultimate haute horologerie kind of precision.

One last note. Snapshots are not just screenshots. The format is actually numeric, this means that if you see a snapshot on a tg window of a different size, or even on a different computer running a different operating system, the snapshot will still look, in a sense, as good as new. More importantly, when we finally have printing, all snapshots even taken today will be pretty-printable by just loading and hitting "print".
 

·
Registered
Joined
·
87 Posts
Discussion Starter #303
Yes, I read that post about calibration procedure. Idea is to take quartz watch as reference and compare it to sound card, because sound card is not so accurate (also described in that post). I'm just little confused about mentioned "correction procedure" of quartz watch, because it goes usually fast +10 s/day. So what is the real accurate reference? What is the result of calibration procedure ? Is it diff between quartz clock and sound card clock?
If so, we can use digital metronome too, they are declared as accurate, they usually have audio output, adjustable beat rate etc...
Sorry, this post came while I was writing my other post...

So quartz watches are very accurate and by design often they achieve this accuracy in a slightly counter-intuitive manner. The quartz crystal in them is made to go fast, each individual crystal is characterized at the factory, and the specific watch is programmed to apply a periodic correction which is precisely equal and opposite to excess speed of the quartz. The result is very accurate, but, because of the periodic correction, the trace does has this zig-zag shape that you see in the figure of my calibration post. This is also the reason why the calibration procedure needs to be a little long: to average the zig-zags.

I have no experience with metronomes. Watches are designed for long-term stability: to keep time accurately for long. Metronomes, being designed for the music, I would guess are not necessarily engineered for accurate time-keeping at the part-per-million level. Clearly, the ultimate time reference would be the 1PPS from a GPS receiver, and, as you say, that's definitely overkill.
 

·
Registered
Joined
·
272 Posts
Thanx for quick answer, let me elaborate my idea in short as possible.


Djolemag makes many good suggestions, for which I am very grateful. Let me express my opinion on them one by one...



This one is not complicated to implement. I'm trying to evaluate whether it would be an really needed. The most straightforward way to keep track of various position is to time them separately (hitting clear between one and the next), make one snapshot per position, and then save all the snapshots together in the same file using the "save all snapshots" option. Notice that you can name snapshots, so you can call them with the name of the respective positions.
Haven't thought of it in such way, good point.
However, I mentioned in some previous post, if we go in "blackbox" design way, it is good to think about start/stop/pause feature. Personally, if I have to implement it on some RPI (which was my first thought :D ), I would also hook few GPIO pins with these button actions in mainthread. In that way I would need almost no action from keyboard/mouse. Also, if I put it to run on Linux distro on some tablet-like device, I have full benefit of touchscreen, so I can start/stop/pause routine without much GUI complications....




It mostly boils down to what you find less annoying. Without decimals, it's quicker to adjust with the up and down arrows (ten times less clicks for equal adjustments). With decimals, you have the peace of mind that if your movement is 51.4 you can set precisely 51.4. Technically, those 0.4 degs do not make any difference at all. Possibly the best solution is to allow decimals and program the arrows to jump by integer steps (those who want decimals still can enter them via keyboard). I will put this on the todo list.
This is good idea, very efficient. Default step by arrows is One, decimals must be entered separately. in "blackbox" design, I would add decimal spinner, for example... But honestly, it complicates GUI...


The name of the snapshots is editable, and allows you to do precisely that. You suggest a larger text area?
My suggestion was like this:
Add one (or two) text fields for user input. If user want, can edit them. By default, they are blank (or timestamp...). So, me as user, I can add title "Omega Seamaster ....." in first field, "DU" as DialUp testing position.
Now, when you take snapshot, you have all relevant data to pull from screen and perform auto-naming of snapshot....
In bottom line, very similar, but user has less intervention. In mathematic way, it is sort of optimization / minimization, you type name only once per session, changing only watch position....

Great idea. This is definitely near the top of the todo list.



Yes, that's more or less how I envisage the printouts. It's a lot of code to implement, that's why it is not yet there. The move to GTK+3 of the latest version will allow me to merge some code from an old pull-request of a GitHub user named wahlstedt (I think he is also a member here) that implements a prototype for printing...




For now, tg takes the default audio input and makes the average of the two stereo channels. Selection of audio input is also something that needs to be improved in tg, and there is also material in this direction in wahlstedt's pull request.
Yes, I noticed that, also I've been reading some comments/conversation on Git regarding pull request and changes.
Does it mean I can wire L and R channel in parallel when wiring mic?

Finally, I completely agree with alvh on this.



Tg is just a comparator that, indirectly, checks a mechanical watch under test against a reference quartz watch, using the clock of a sound card to transfer this information. It's like weighing an apple against a kilogram weight by first using the weight to calibrate a scale and then using the scale to weigh the apple. A quartz watch is usually good enough for the job, unless you seek the very ultimate haute horologerie kind of precision.
Good, now is more clear. Honestly, I was little confused at first reading because I saw zig zag line. Now I see that calibration makes zig zag average, so everything is just fine.

One last note. Snapshots are not just screenshots. The format is actually numeric, this means that if you see a snapshot on a tg window of a different size, or even on a different computer running a different operating system, the snapshot will still look, in a sense, as good as new. More importantly, when we finally have printing, all snapshots even taken today will be pretty-printable by just loading and hitting "print".
Nice. So basically, you record data and interpret them via GUI interface. I've took a brief look of .tgj file, very good point. It represents "frozen" state of GUI in particular moment in time. Congrats! Much better than screenshot as .blob or sort of image.

One kind note: My primary job makes me to read a lot of code each day, various platforms, languages etc. I work as senior technical consultant for some IT/electronic production company. So, 99% of day I read a code or projct demands, but I'm not in "good shape"of writing a code, maybe I'm loosing focus or I'm getting old... :D
So, from that point of view, I know how annoying some "software/project changes" could be. From my perspective, I tried to filter all my "first snapshot" ideas and converge to something which could give real effort and improvement.
Once again, I see your idea as brilliant and I'm very proud if I can add at least a tiny idea to improve software....
 

·
Registered
Joined
·
272 Posts
Sorry, this post came while I was writing my other post...

So quartz watches are very accurate and by design often they achieve this accuracy in a slightly counter-intuitive manner. The quartz crystal in them is made to go fast, each individual crystal is characterized at the factory, and the specific watch is programmed to apply a periodic correction which is precisely equal and opposite to excess speed of the quartz. The result is very accurate, but, because of the periodic correction, the trace does has this zig-zag shape that you see in the figure of my calibration post. This is also the reason why the calibration procedure needs to be a little long: to average the zig-zags.

I have no experience with metronomes. Watches are designed for long-term stability: to keep time accurately for long. Metronomes, being designed for the music, I would guess are not necessarily engineered for accurate time-keeping at the part-per-million level. Clearly, the ultimate time reference would be the 1PPS from a GPS receiver, and, as you say, that's definitely overkill.
Now is more clear, thank you. I have to think loud, please correct me if I'm wrong:
In normal usage of 24h, mechanical watch will change many positions and variations of them (positions). So, it means that sum of slow and fast rates during the day will give some effort to final 24h result, in practice.
Quartz watch does not have that problem. Maybe some temperature, humidity and battery level will have gain/impact on final 24 h result. That result would be better than on average mechanical watch. That makes a Quarty watch good enough for time reference.

Using GPS is good idea, but it needs a lot of tweaks and job. Final effort is not so big, so yes, it is overkill... However, that brings me to some new idea.. I have some broken ARM tablets at home, working but wiht bad displays (kids ...) . So, if I think about it, it has:
Audio input
GPS (not sure, I think one have it)
Enough CPU power

So, getting some Linux distro on it would be perfect playground. If it has GPS, then it is feasible to to use pulses from it for time reference...
I will post results if successful.
Thanx, cheers!
 

·
Registered
Joined
·
1,282 Posts
Now is more clear, thank you. I have to think loud, please correct me if I'm wrong:
In normal usage of 24h, mechanical watch will change many positions and variations of them (positions). So, it means that sum of slow and fast rates during the day will give some effort to final 24h result, in practice.
Quartz watch does not have that problem. Maybe some temperature, humidity and battery level will have gain/impact on final 24 h result. That result would be better than on average mechanical watch. That makes a Quarty watch good enough for time reference.

Using GPS is good idea, but it needs a lot of tweaks and job. Final effort is not so big, so yes, it is overkill... However, that brings me to some new idea.. I have some broken ARM tablets at home, working but wiht bad displays (kids ...) . So, if I think about it, it has:
Audio input
GPS (not sure, I think one have it)
Enough CPU power

So, getting some Linux distro on it would be perfect playground. If it has GPS, then it is feasible to to use pulses from it for time reference...
I will post results if successful.
Thanx, cheers!
Hi djolemag

I've been following this thread for a while but I still may have missed something so please excuse.

However, my question is What are you trying to solve with a super accurate time source?
It would appear to me that the calibration system works well and is not broken.

My electronics skills are far less than yours and by all means go for it with this project but, if you have the capability, it would seem that a neat cheap preamp would be far more useful to the majority of users.
 

·
Registered
Joined
·
272 Posts
Hi,
idea is to have sort of standardized approach to sound pickup, that is why I ask about piezo mic and preamp. I tested TG with headphones and it works nice, however it must be quiet room in order to work efficiently. Therefore, my choice is piezo guitar pickup, will test it when I get back from vacation.
About accurate time source: as I explained in previous post, I was confused about accuracy of quartz watch, now is everything clear.
But, I like to have things straight... If I can use GPS module for free (like in tablet), why not to try?
Main reason, to be honest : I have only one quartz watch and lot of mechanical watches :)
 

·
Registered
Joined
·
7 Posts
If I can use GPS module for free (like in tablet), why not to try?
I was wondering how you are imagining this? Hooking up a GPS timesignal straight to the input of the PC's sound card somehow? Because, if you would route it via the tablet's audio output or something, you would introduce yet another unknown error source (the tablet's DAC)...
 

·
Registered
Joined
·
272 Posts
I was wondering how you are imagining this? Hooking up a GPS timesignal straight to the input of the PC's sound card somehow? Because, if you would route it via the tablet's audio output or something, you would introduce yet another unknown error source (the tablet's DAC)...
Well, idea is to do it from source code, not by physically routing PPS to sound card...
As contrate_wheel explained in calibration procedure post
As any computer program that emulates a timing machine, tg necessarily
takes its time reference from the clock of the audio card of the computer.
There is anecdotal evidence that audio cards have usually relatively
stable clocks. However, unfortunately, these clocks are often affected by
a constant deviation from true time, sometimes of many seconds per day. To
correct for it, one must measure the deviation by comparison to a more
accurate time source, and then inform the program of its value. With tg,
this can be done either manually or through an automatic calibration
procedure.
......
The automatic calibration feature works by comparing any analog quartz
watch (producing one beat per second) to the sound card. Operationally,
you put a quartz watch on the microphone and then you click on the
calibrate button.
...
So, we have a sound card internal clock which has unknown accuracy. On the other hand, we have a quartz watch, beating 1 beat per second and we suppose it is accurate enough (and as we agree in previous posts, it usually is accurate enough for our needs).
So, we still can get sound card clock and compare it to PPS of 1 pulse per second reference we got from GPS. That is usually achievable by standard gpsd daemon in Linux, haven't been looking to much, but is feasible for sure, with one constraint: if GPS module has PPS feature or not, which may vary from model to model.
However, as i mentioned in previous post, it is worth to give a try... nevermind if result is success or failure, some other user will have useful info, to go or not to go that way in further research....

Please correct me if I'm wrong, thank you for getting interest in this discussion.
 

·
Registered
Joined
·
1,282 Posts
Hi,
idea is to have sort of standardized approach to sound pickup, that is why I ask about piezo mic and preamp. I tested TG with headphones and it works nice, however it must be quiet room in order to work efficiently. Therefore, my choice is piezo guitar pickup, will test it when I get back from vacation.
About accurate time source: as I explained in previous post, I was confused about accuracy of quartz watch, now is everything clear.
But, I like to have things straight... If I can use GPS module for free (like in tablet), why not to try?
Main reason, to be honest : I have only one quartz watch and lot of mechanical watches :)
Sounds like quite a challenge so will be interesting to see your solution.

Regarding piezo pickups etc, this thread has a bit of discussion that you might find of use.

https://www.watchuseek.com/f6/what-microphone-use-tg-open-source-timing-software-3606906.html

I think the summary was if one is using a piezo then a pre amp looks necessary.

Always interested to find better ways to use this great software.
 

·
Registered
Joined
·
272 Posts
Sounds like quite a challenge so will be interesting to see your solution.

Regarding piezo pickups etc, this thread has a bit of discussion that you might find of use.

https://www.watchuseek.com/f6/what-microphone-use-tg-open-source-timing-software-3606906.html

I think the summary was if one is using a piezo then a pre amp looks necessary.

Always interested to find better ways to use this great software.

Thank you, totally agree with this statement
Always interested to find better ways to use this great software
Will look in more details when get back home.. Now I have to prepare for long journey called "driving from vacation"...
In general, piezo is good for eliminating environmental noise. It is also too weak (I suppose) to produce acceptable signal, so pre-amp is almost mandatory.
However, it would be good to know what frequency range is needed for TG, so pre-amp can make cut-off of unwanted noise or other type of disturbances.

@contrate_wheel : could you please advise regarding optimal frequency range for TG?
 

·
Registered
Joined
·
492 Posts
Hi,
idea is to have sort of standardized approach to sound pickup, that is why I ask about piezo mic and preamp.
I've been experimenting with piezo pickup and op amp preamp circuit based on watch o scope schematic with good success. I have a lot of (not healthy) mechanical watches also. :)

Let me know if you want to converse further about the preamp and piezo or if I can help.

I was planning on designing a board with SMT parts designed for a common enclosure. Need to build the case holder / pickup next though.

Sent from my XT1096 using Tapatalk
 

·
Registered
Joined
·
272 Posts
I've been experimenting with piezo pickup and op amp preamp circuit based on watch o scope schematic with good success. I have a lot of (not healthy) mechanical watches also. :)

Let me know if you want to converse further about the preamp and piezo or if I can help.

I was planning on designing a board with SMT parts designed for a common enclosure. Need to build the case holder / pickup next though.

Sent from my XT1096 using Tapatalk
Hi, yes, I would like to converse further about preamp and piezo.
I think contrate_wheel would have something interesting to tell us about frequency range needed for TG.
We all know that piezo has high impedance, so preamp should be adjusted according to that.
In next days I will try to get some guitar pickup with EQ and give it a try with TG.
Currently, I've just came from vacation, so lot of things are in queue for solving... Hope I will have enough time during the week.
Will inform you on progress.
Cheers!
 

·
Registered
Joined
·
127 Posts
Just a little message to announce the new version of tg, namely Tg 0.5.0.

New features include:
- Ability to take and save snapshots
- The distinction between light and regular version has been eliminated (it is now a setting)
- Minor improvements to the user interface

Snapshots are just what you think they are. The new version of tg can load and save files, which are basically archives of snapshots.

Windows, debian, and source code distributions are as usual available at:
https://tg.ciovil.li
https://github.com/vacaboja/tg

I have been in contact with dmnc, who has already tested the new version on Mac OS X. He will surely produce a homebrew install script for it shortly. (Thanks a lot dmnc for your continued support of Tg on OS X.)

On the technical side (for those interested):
- Version 3 of GTK+ has replaced version 2 as the widget library for Tg
- Thanks to an excellent contribution of Stefan Talpalaru, the build system is now based on GNU autotools.

Comments, suggestions, bug reports are as always very welcome!

PS: alvh, Klaus, landk, 1afc: completely agree, thanks for answering djolemag's question!
alas, this new release breaks support under Raspbian PIXEL under the Raspberry Pi armhf... the sticking point in the ./configure is libportaudio2...

configure: error: Package requirements (portaudio-2.0) were not met:

No package 'portaudio-2.0' found

even though installed:

$ dpkg --list | grep portaudio2
ii libportaudio2:armhf 19+svn20140130-1 armhf Portable audio I/O - shared library

it appears that the develop libs, libportaudio-dev, are incompatible and there is no supported portaudio package for the build:

$ dpkg --list | grep portaudio-dev
ii libportaudio-dev 18.1-7.1 armhf Portable audio I/O - development files

(there is no portaudio2-dev package available in the armhf Raspbia repositories)

so... i'll stick with the old version for now and hope for a resolution?

still love Tg! works great! (am now doing a build for my OS X Sierra Macbook Air)

update #1: so i downloaded the latest portaudio release, built and installed, then received:

configure: error: Package requirements (fftw3f) were not met:

No package 'fftw3f' found

(and there is no corresponding pkg 'fftw3f' in the Raspbian repository)

update #2: the brew install under Mac OS X 10.12.5 works! kudos to the wonderful coder across the Pond!

update #3: well, the attempt at a build of the new Tg 0.5.0 for Raspbian PIXEL has failed... after downloading, building and installing fftw3, the ./configure script still reports (even after doing a 'sudo ldconfig'):

configure: error: Package requirements (fftw3f) were not met:

No package 'fftw3f' found

so i'm stuck at this point with 0.4.0 under the armhf Debian release... (well, not really 'stuck,' as i'll keep hacking at this...)

update #4: installing the libfftw3-dev package finally gets through the configure process:

# sudo apt install libfftw3-dev

then the ./configure process results in:

Tg 0.5.0
=====

prefix: /usr/local

compiler: gcc
cflags: -g -O2 -Wall -Wextra
ldflags: -Wl,--as-needed

a quick 'make,' insertion of a cheap CMEDIA US$5 USB sound dongle, and:

so it looks like you must build and install portaudio2 to run Tg 0.5.0 under the latest armhf Debian - thanks to all!

update #5 - the new tg-timer builds fine (after gtk3, glib2, fftw3 package installs) under pre-PIXEL Raspbian - at least on my little RPi3 w/a TFT LCD that also uses Pulseaudio... it was necessary to have an available sound input device available and to start the Pulseaudio server before launch:

$ start-pulseaudio-x11 ; tg-timer &

willie
on the stinking hot Gulf of Mexico
 

Attachments

·
Registered
Joined
·
52 Posts

Hi - thanks contrate_wheel for the great software ! And everyone else who has contributed through feedback....!

I withdrew some watches I had listed on ebay because they were quite a long way off spec (according to the software) . Using the software, I believe I achieved a lot better timing results, so I can relist them now :) Had to adjust the beat lever.

"I am a true believer......!"


Thanks again Stephen
 

·
Registered
Joined
·
86 Posts
Is it possible (or practicable) to add support for beat rates higher than 72000? I have a couple 360000 and a 108000bph stopwatches that I'd like to graph. I have them adjusted pretty well as it is, but it would still be nice to be able to run them by the timegrapher. No worries, though, if it's a pain in the rear to add such support.
 

·
Registered
Joined
·
48 Posts
Stumbled across this thread and I am very happy to have found it. Can't wait to try the software with my humble Sennheiser PC 360 mic when I get off work.
 

·
Registered
Joined
·
87 Posts
Discussion Starter #318
Hi all,

sorry for not being very active.

I'm happy that linux.author managed to build Tg 0.5.0 successfully. The fftw3f is, in fact, a bit confusing...

Is it possible (or practicable) to add support for beat rates higher than 72000? I have a couple 360000 and a 108000bph stopwatches that I'd like to graph. I have them adjusted pretty well as it is, but it would still be nice to be able to run them by the timegrapher. No worries, though, if it's a pain in the rear to add such support.
We may try. Can you send me some recordings of your stopwatches? (I will be on vacations until September, but then I will have time to look into it...)
 

·
Registered
Joined
·
21 Posts
Hello everyone. I'm already enjoying version 5 of Tg. Excellent improvements. Congratulations contrate_wheel, Thanks for new features of the program.
I have a question: Can I save the screenshots in image format?

Guido
 
301 - 320 of 451 Posts
Top