Open source timing software.

Finally got around to testing tg on a windows machine, just put the watch on the headphone microphone.

The trace looks wonky, I did get some data with my own software and that looks a bit nicer.


Could it be that those pretty big wobbles of the escapementwheel throw off the peakdetection?
My method goes as:
I get the black raw data, first thing we do is get the derivative, this highlights the sharpest noise. We take the absolute value since we are interested in the location in time of the tick (or tock).
We smooth out those orange peaks with a gaussian filter and compare the resulting green line with the average pulse shape (differs for tick or tock) in blue. To determine the shift between the two we do a crosscorrelation and find where the peak is. That is the shift.

Hello congratulations. We are interested in your technology contributions.
The wobble or zigzag is because you are using the loudest sound in the waveform. This corresponds to the strike of the locking vane on the escape wheel, which is not perfectly circular. The sound that you must register and with which you would obtain a better graph is that of the impact of the ellipse pin of the steering wheel, in the fork of the lever. That would draw a very clean graph. The same happens with tg, and therefore the path is not clean.
In image 1 that I place you can see the three sounds. The first one, the black line: the unlocking, the second, the blue line: the impulse, and the third in cyan: the drop or lock. Image of Biburo.


In the second image a screenshot of tg, you see the zigzagging trace, because the software uses the loudest sound, coming from the escape wheel and the paddle on its locking face.

Yes, you are seeing the effect of the escape wheel. A longer term plot would show oscillations due to the 4th wheel, 3rd wheel, etc.

Tg's algorithm, as I understand it, is:

1. Audio is passed through a high pass filter. In my newer version I extended this to an arbitrary chain of biquad filters with an interactive way to set them up.
2. There is a noise suppressor that removes sounds much louder than the median. I don't think it really does all that much and plan to make an option to turn it off.
3. The audio is rectified: absolute value taken and then passed through a low pass filter. Then DC offset is removed.
4. The auto-correlation is computed. But not just of one beat of audio. It uses a 16 second period (actually the signal dots show the period length 2^dots seconds, max 16).
5. The peak auto-correlation is used to estimate the period. Period means two beats, not just one, so this should be the 2nd peak in the auto-correlation. The first, smaller, peak should be at one beat.
6. That estimate is used to look for the peaks near two periods, three periods, etc. Until a peak at the expected place isn't found or we get past ⅔ of the 16 second buffer. The peak after 15 periods should be higher that the others if the escape wheel as 15 teeth, because the sounds generated by the same escapement teeth are being compared. I wonder if that can be used to find the number of teeth? Or if the estimate from the number of periods equal to the teeth is more accurate? Instead of timing how long each back and forth of the balance takes, we are timing how long each revolution of the escape wheel takes, by comparing the entire 5 second sound of the escape wheel's revolution, made up of 30 slightly different ticks.
7. The final period estimate is the mean of the one period peak auto-correlation, two period peak, and so on. The standard deviation of these measurements is also found.

This period estimate is used as the s/d value. So this doesn't use the time of the loudest sound of each beat, to find the time between each beat, and then average ~10 seconds worth of those. It takes the entire ~10 second sound of the escape wheel making about two full revolutions and tries to find the best period to shift it by to optimally align it with itself. Of course, it's more important to align the loud parts than the quiet parts, so it does to some extent mean this is using the locking sound.

Calculation of the beat error, amplitude, and the points where the dots are drawn on the paperstrip is then an even longer series of computations.

I know @tpiepho you must get inundated with feature requests... and perhaps this isn't a new one. But I was wondering if it'd be possible to somehow show a time series graph of amplitude, beat error, and rate over time? Or short of that, would it be possible to have an option to log these values to a file so that they could be plotted elsewhere? My reason for asking is because I have a case where I'd like to see what my amplitude and beat error are doing as a function of time, specifically I've noticed that the amplitude of my movement drops during the areas indicated in the pic below, but I don't have a way of charting this other than noting the amplitude by hand as each 10s line passes.

chp said:

Thank you for your help.

I didn't. I just tried and nothing happens. No errors, no missing dll's like before. I guess I complied it incorrectly? There were no errors flagged when I compiled it.

Click to expand...

I deleted everything in my home folder and restarted. I'm missing two packages now: gtk+-3.0 and glib-2.0.

Reinstalled Msys2. I now get:

configure: error: Package requirements (gtk+-3.0 glib-2.0) were not met:

Package 'gtk+-3.0', required by 'virtual:world', not found
Package 'glib-2.0', required by 'virtual:world', not found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables GTK_CFLAGS
and GTK_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

tpiepho said:

@chp, I don't use windows myself and can't help with windows build issues. I know people have done it. Maybe the building the Linux version on WSL2 would be easier?

@peterhudson That feature does sound familiar. You'll find this branch has some of the features you want. I think also I've considered a few other features that might help.

Exporting data also considered. I've written something to create a jSON dump that I can work at making graphs in matplotlib. I thought, after adding in a Python interpreter to Tg, that maybe that would be the way to make more interesting longer term graphs.

Click to expand...

This is totally awesome. I had a complete facepalm moment when I went back into your repo and saw I'd compiled from Master which was 75 commits behind your feature branch

The visualization is exactly what I needed. And I love the new scrollable graphs. Great to be able to go back and look at events in the past.

I had a look at the data serialization in the .tgj file... Is there a commit where the data is serialized as JSON? I couldn't find it a commit or PR attached to the feature.

Also, since we're here... I was wondering about keyboard shortcuts for things like moving the paperstrip up & down (PgUp / PgDn), and center (Home). My rational for keyboard shortcuts is that when I'm regulating a watch, I often have a tool in my dominant hand, but after making an adjustment to a regulator, I want to see the paperstrip centered so my eye can easily follow any changes, but currently I have to put down my tool to use the mouse with my dominant hand. A challenge with this suggestion is that the input boxes for BPH, Lift Angle, and Cal, all respond to up/down/home/end/pgup/pgdn keystrokes if they have the focus (at least on Windows). As such we might be overloading the keyboard shortcuts. Maybe a "keep paperstrip centered" mode? although that might be computationally expensive to call the center function for every tic/toc.

Also... a minor bug report: the Clear button doesn't remove the amplitude graph from the paperstrip.

You just need a compiler that's not ancient. gcc has been able to process utf-8 variable names since gcc 10. Clang and Visual C since like a decade ago.

I never got the jSON support to a finished state. There's extra stuff one needs, like put a button somewhere to activate it, document the format, some kind of dialog for choosing the filename to save to, an error message of the file can't be written, etc. Dumping all the timing data to json in way I can load into python and analyze it is only like 10% of the work. Something usable to someone who doesn't look through the source to find it and figure it out takes more.

A continuous center feature would be easy to do. One needs to understand the current center function means to center the most recent beat in the paperstrip. It doesn't look at the entire trace history and try to "best" center everything. Given that, it's easy to keep centered. It's actually far harder to do what I did to keep the trace from moving up/down as it scrolls while also allowing continuous zoom. It's more of a UI problem. Where do you put the button to turn this on and off? Next to the center button? Something in the paperstrip window itself like the zoom button? Another check box in the main menu, which is getting to be kind of long?

The default zoom level, 10x, is somewhat optimistic. If the watch is off by more than few s/d, you get traces that quickly go from edge to edge, like yours does about a minute in. You can zoom out so they don't wrap around so much and I think it's easier to see the changes.

Hello everyone. And thank you very much for contributing to this thread.
Seeing how knowledgeable @tpiepho is in this software, I'd like to make a request to @tpiepho.
The software draws the dots on the paper strip derived from the beat at the “0” point. What makes the succession of points on the paper strip very irregular because the "Zero" point corresponds to the blows of the paddles on the escape wheel. Because it is not perfectly circular, this generates an irregularity in the drawing and, generally, a regular undulation that is repeated every time the escape wheel completes a turn.
My request is the following. Would it be possible to take the beats of the first sound in the waveform to draw the succession of dots on the strip of paper?

Thanks.