I tried to keep this brief, but failed. I've really got to learn to not try to say everything in one post.
- Create a low cost, accurate measurement system for evaluating (and possibly regulating) HAQ watches
- Improve on the precision/accuracy of video methods, and at a lower cost
- Make it easier than the manual stopwatch method
- Where possible, use free and/or open source tools, and ideally something that will work on my Linux development system, as well as being useful for people on Windows systems (and maybe Mac too).
references and inspiration
- Methods of Determining the Accuracy of a Watch (sticky on this forum) https://forums.watchuseek.com/f9/meth...ch-382752.html
- Hans Moleman's methods for determining the accuracy of his Longines VHP https://forums.watchuseek.com/f9/just...ds-168460.html
- Igna's idea of using an affordable telephone inductive pickup https://forums.watchuseek.com/f9/meth...l#post13295914
- use a computer sound-card for a cheap and accessible sampling system. My computer's built in sound-card supports 192KHz sampling, giving a resolution of around 5 microseconds. 96/48/44.1 kHz will probably work fine as well. This is better time resolution than video methods even at 240fps, and assuming most people have access to a computer, it is cheaper than buying a camera
- use a hobbyist GPS unit for an affordable and accurate timebase reference. Adafruit sells a unit for around $40 that has a pulse-per-second (PPS) output that is accurate to 20 nsec when the GPS has a fix. Note that the sound-card time resolution will be the limiting factor. NOTE: The biggest weakness of this approach is the cost of the GPS, and the need to do some simple soldering to connect it.
- A python script was written using pyaudio to read the sound-card data, analyze it for PPS pulses and watch ticks, and calculate timing data in a format suitable for further analysis. This should work on Linux and Windows platforms, and hopefully Mac too! I don't think I can inline the source, but it is available here: http://aa1i.net/haq/haqpps.zip
- Adafruit ultimate GPS breakout https://www.adafruit.com/products/746
- stereo to mono splitter "breakout" adapter/cable. I used a Hosa YMM-261 off Amazon for a few bucks, but there are many similar ones available for cheap. Make sure it is a stereo->L/R breakout, not a Y-splitter (stereo->2xstereo)
- Headphone volume control used as inline attenuator for PPS pulses. I used a Radio Shack 42-2559 'Volume control 8" (20.3cm) headphone extension cord'. The important part is the volume control, not the extension cord.
- external amplified GPS antenna
- adapter cable from GPS board to connector for antenna
- Various stereo mini patch cables
- various resistors to make voltage divider to step down PPS voltage
- PPS LED and current limiting resistor - nice for hacking watches.
- USB powered hub. I used a unit from plugable that is recommended.
Hook-up is very similar to Igna's setup, except that instead of using a microphone (or direct line connection) from the time.is "beep", I used the PPS output of the GPS.
Some simple soldering is required to hack up a mini-stereo cable and connect it to the PPS pin on the GPS module. Since the PPS pulse is actively driven by the GPS, I used a stereo jack for this connection. I'm afraid of the bare stereo plug brushing against something and causing a short that burns out the PPS pin. Using the jack end of a cable here makes this idiot-resistant I used a short stereo mini patch cable to connect the PPS jack to the headphone volume control.
Using a computer USB cable to power the GPS seems to make so much noise that the measurements are useless. I've had good luck with a powered USB hub made by "Plugable". The GPS is still attached to a Raspberry PI computer from a different/unrelated project. I might get better noise performance by taking the unnecessary Raspberry Pi out of the setup, and powering the GPS directly from USB power, or perhaps a 5V bench supply. Adafruit also sells an affordable USB to serial breakout that can connect to the pin header on the GPS and provide power from the USB port. I haven't tested this yet, but it should work.
The PPS output of the GPS is at a a higher level than the microphone input of sound-card can handle. I placed a headphone volume control inline to cut the level down. I have also been playing with a resistive voltage divider, but this requires soldering and I have yet to find resistor values that allow me to get rid of the volume control. Without the voltage divider, the volume control needs to be set to near minimum volume. With my current voltage divider (30kohm/1Kohm) I use about half volume. Ideally I'd like full volume/no volume control, but I'm not there yet. I admit to resorting to try-and-fail when I should have gone with measure-and-engineer.
The sound-card's microphone input is AC-coupled, which distorts the rectangular PPS pulse so that it looks like the top plot in this [The bottom plot is a watch stepper motor pulse captured from the Igna inductive pickup]:
I have been unable to figure out an (easy) way to eliminate this distortion. I've seen some online posts on using a VCO, but the program detects the PPS pulses just fine anyway, so I don't see the need for that complexity.
I routed the PPS signal through the volume control and into the R channel ("R" for "Right" and "Reference") of the breakout cable. I routed the watch pulse inductive pickup to the L channel (sorry, no catchy phrase for this one...).
Setting the microphone gain levels correctly via your computer's sound control panel is important. I had a gnuradio installation handy, and this made it easy to mock-up an audio input source to a time domain plot sink that allowed me to set mic gains and observe waveforms in near real-time. I expect this approach is not suitable for most people. You are free to use any audio program that is convenient to you. Perhaps I can add some plotting functions to the python script.
If you set the mic gain too high, the PPS pulse will saturate/clip and look like this:
Try placing the inductive pickup at various places on or near the seconds hand movement until a maximum signal is found.
Current detection thresholds are at half scale (0.5). I toyed with dynamically setting the thresholds based on the amplitudes of both signals, but it seems easier to set the mic gains to optimal levels. An absolute value function is used, so both positive and negative pulses can be detected. Most watches seem to have a "tick" and a "tock" pulse train that are mirror images of each other.
Plots with a good pickup signal:
I found I had to use quite a bit of gain on the inductive pickup. This means more noise is present in the samples. If the gain is set too high, noise can trigger the pulse detection, leading to bad measurements. Setting the mic gain so that the watch pulse is just slightly above the detection threshold seems to minimize these spurious samples, but at the cost of slightly more jitter in the detection of the pulse time.
I seem to get better results with this slight jitter. Even a single spurious watch pulse detection throws off the average offset calculation noticeably, while the jittery pulses seem to average out. The initial pulses in the train are steep, so this jitter is slight.
It might be possible to hand-wind an inductive pickup that is more sensitive for lower noise, but  the telephone pickup suggested by Igna[/edit] really wins on low cost and ease of use.
I found my sound-card sampling rate was not exactly 192000 samples/s. The script uses the time between PPS pulses to calculate the exact sample rate. Using an average allows this to be measured more accurately than an integer number of samples. In my case, the sound card seems to run at 192004.3 samples/s. The program only detects pulses on integer samples, and then uses this averaged sample rate to convert to time values. Sometimes I get 192004, sometimes I get 192005, but they average out to 192004.3 .
I believe there are techniques that allow detecting the time of the pulses to a resolution better than a single sample (windowing?), but I don't think that level of resolution is needed. Integer samples at 192KHz are just fine.
Once a PPS pulse and a watch pulse are detected, the time offset between them is calculated. Some sample output from verbose mode is below:
003233970 16.843210 tic 72658 0.378418
003353316 17.464790 PPS 192004 0.999998
003425952 17.843095 tic 72636 0.378304
003545320 18.464790 PPS 192004 0.999998
003617937 18.842997 tic 72617 0.378205
003737325 19.464795 PPS 192005 1.000003
003809920 19.842882 tic 72595 0.378090
003809920 19.842882 offset 0.377682
003809920 19.842882 rate -2.859993e-06 spd -0.247103 spy -90.192734
first column is sample count, second is time in seconds. PPS is for PPS ref pulses, with sample count from last pulse and time in seconds since last pulse. Note how is bounces between 192004 and 192005. tic is for a watch tick, with an offset from the last PPS pulse given in samples and seconds. In this case the watch tick is 378 msec after the PPS pulse. Note that this is only fractional seconds. The stopwatch method is still needed to figure out how many integer seconds the watch is off, but this method should provide a good measuremnt of the fractional portion.
When an inhibition period is complete, an average offset is calculated (in this case 377.682 milliseconds). If a previous offset is available, it is used to make an estimate of rate - in this case -2.859993e-06 seconds/s, and also scaled to -0.247 spd and -90 spy [this is obviously not a HAQ - it is my beater/tester Casio Edifice]. Better results can be obtained by performing a linear fit on the offset data that is saved to a file, but this measurment may be useful as a quick peek for regulating a watch.
The PPS offsets are averaged over the inhibition period. My current collection has watches with inhibition periods of 10, 60, and 480(960?) seconds.
There is some primitive error handling to detect the loss of the PPS reference pulse. When this occurs, the averaging buffers are reset. Averages are only reported when a full un-interrupted inhibition period of data is available. Note that as long as an exact inhibition period is averaged, it doesn't matter where in the inhibition cycle the average is started.
The raw watch tick PPS offsets are saved to a file. The average offsets calculated over the inhibition period are saved to another file.
I dump the data to a text file, and for convenience have been using Gnuplot to calculate the linear fits to rate and make the graphs. If anyone is interested, I will share my gnuplot commands. Perhaps in the future the graphs can be generated from within the python code automatically.
Here's a sample run on my C7 COSC chronometer:
I'll try to post some more plots of results on various (non-HAQ) watches in follow-up posts.
It seems someone on another forum has a much more polished solution for using a microphone to regulate a mechanical watch: https://forums.watchuseek.com/f6/open...e-2542874.html