Open source timing software.

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.

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

Click to expand...

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

Click to expand...

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.

Click to expand...

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?

Click to expand...

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.

Click to expand...

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...

Click to expand...

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.

Click to expand...

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".

djolemag said:

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...

Click to expand...

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.

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.

Click to expand...

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 ), 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.

Click to expand...

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?

Click to expand...

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.

Click to expand...

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.

Click to expand...

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".

Click to expand...

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...
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....

contrate_wheel said:

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.

Click to expand...

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!

alvh said:

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)...

Click to expand...

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.
...

Click to expand...

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.

contrate_wheel said:

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!

Click to expand...

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