[time-nuts] Time Interval Counter(?) for high-precision watch measurement

[Bob kb8tq]

Hi


> On Sep 8, 2020, at 1:59 PM, Raven L <cuervamellori at gmail.com> wrote:
> 
> Hi Bob, thanks very much for all the info!
> 
> You're right that my input signal is pretty crummy - if anything you
> overestimate it. Eyeballing it on the scope, the edge is not particularly
> defined at all - resolution better than a couple of microseconds just isn't
> possible. I've typically used gate times in the 10^4 to 10^5 seconds range
> (though typically collecting a measurement each second and doing the gating
> myself in software, as modern watches have multi-millisecond phenomenon
> that are interesting to study in the 1 to 100 second range).  I have tried
> picking up electrical signals from the actual contacts going from the IC to
> the motor, but even then the cleaner edge I got wasn't worth the trouble.

Opening the case and messing with the seal often degrades the reliability of
the mechanism. If you want to see what the “real world” watch does, keep 
the case shut if you can.

> 
> I took an initial pass through the manuals of the models you mentioned, I
> really appreciate the guidance. (and the well-deserved correction on 2g
> tipover for AT crystals - I'm not sure what I was thinking when I wrote
> that but my notes confirm I was way off). I do hope to move up to a basic
> home lab running off CSAC and Rb standards in the next few years once I've
> seen all there is to see in wristwatches, but it looks like I have a lot to
> digest.

As Tom mentions in his post, the PPS “tick” out of a (cheap) GPS module is plenty
good enough for this sort of thing (to the now reduced requirements). It is likely
good to < 100 ns. That’s way better than your noise floor.

Log the GPS and watch pulse time of arrival and go from there. The TAPR TICC 
makes this drop dead easy. (provided you also have a 10 MHz reference).  Most 
two channel counters can do the job with the possible issue of confusion in the 
data when both pulses arrive almost at the same time. 


> 
> One question if you know the answer on these 53131 and family models - the
> manual mentions that RS232 is talk-only to a printer.

It’s “talk only” serial. That means you can’t send commands *in* to the counter 
via the serial port. Any terminal program you can think of or any programming 
language you are familiar with is capable of logging the drop dead standard serial
the counter puts out. There also are programs out there like TimeLab from John Miles 
that will grab the counter data. 


> Are there reasonable
> tools out there for emulating a printer on a computer to pick up the data?
> Otherwise it looks like I would need to set up GPIB.

GPIB is great for setting up multiple runs on a counter or for doing odd things.
One of those is running 100 second long data with a 5335. There are cheap 
USB dongles out there to do the GPIB if you decide to go that way.

Bob

> 
> On Tue, Sep 8, 2020, 1:12 PM Bob kb8tq <kb8tq at n1k.org> wrote:
> 
>> Hi
>> 
>> First off, 0.001 seconds per year is ~ 3x10^-11. If you are talking about
>> the 2G tip effect on a typical AT cut crystal that’s up around 2 ppb.
>> 
>> Next up, low frequency / small package crystals are (inevitably) relatively
>> low Q devices. Low Q degrades ADEV performance / increases noise. If
>> you *could* measure a high Q device to 3x10^-11 in one second, it’s a
>> good bet that a low Q device will take 10X to 100X that amount of time.
>> 
>> The stepper motor in a watch is a low frequency inductive device. The
>> waveform out of it has a (very) limited bandwidth. Again another factor
>> that
>> will stretch out the time involved in the measurement. Your pickup coil
>> likely
>> also has some issues. ( That assumes the watch is still closed up. I would
>> not
>> recommend opening one up for testing …).
>> 
>> So far, none of this is looking at the frequency counter. We’re just
>> looking
>> at the device you are trying to measure.
>> 
>> Since there does not appear to be a need to get the data really quickly,
>> none of this is a show stopper. It simply suggests that something out in
>> the hundreds of seconds is likely to be the sort of gate time involved.
>> 
>> If you are after 3x10^-11 on a 100 second gate, that comes out to a rather
>> convenient 3 ns resolution. Better than that would be fine, but that’s
>> roughly
>> what you “need” to have.
>> 
>> There are lots of low cost counters out there that will hit that sort of
>> number.
>> The HP 5334 and HP 5335 both come to mind. They should be available for
>> < $200 (delivered). The TAPPR TIC would easily do the job for slightly
>> more.
>> The TIC probably would be easier to automate compared to running GPIB
>> on the 5334 or 5335.
>> 
>> Next step up would be something like a 53181 or 53131. They seem to start
>> out around $300 (delivered). You now have an RS-232 serial I/O and a device
>> that is about 10X better than your “need”.
>> 
>> These are only a very small sample of the vast number of counters out
>> there.
>> The only reason for picking them is that they all are devices I have used
>> a lot.
>> They all (with some effort) can be used to do what you are trying to do.
>> 
>> Fun !!!
>> 
>> Bob
>> 
>>> On Sep 7, 2020, at 6:23 PM, Raven L <cuervamellori at gmail.com> wrote:
>>> 
>>> Hello time nuts and greetings from the 10^-10 world of high precision
>>> wristwatches.
>>> 
>>> I'm trying to set up a lab for automated watch measurement. I have a
>> basic
>>> GPSDO with a PPS and a 10MHz output. I use an inductive sensor to pick up
>>> the signal from the motor inside the watch.
>>> 
>>> I've been using a basic digital oscilloscope to measure the interval
>>> between the PPS and the watch signal.  The signal from the watch has a
>>> total rise time of about 10us to 40us, varying by watch, and rises a few
>>> volts above a noise floor of about 50mV. The oscilloscope does a
>>> serviceable job but doesn't allow automated measurements and can't be
>>> driven by an external timebase. My goal is to make measurements with a
>>> precision of about 10us, with a goal of ultimately pinning down a rate to
>>> better than 0.001 seconds per year (initial testing shows this is what I
>>> need to resolve the effect of tipover on AT-cut MHz-range quartz
>> crystals).
>>> 
>>> Are there specific time interval counters or frequency counters that
>> would
>>> make this easier?  I've been looking at the SR620 as a candidate, which
>>> appears to be available used for around 2k USD, but wouldn't be surprised
>>> to learn if there was something that was a meaningfully better fit.
>> Thanks!
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts at lists.febo.com
>>> To unsubscribe, go to
>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>>> and follow the instructions there.
>> 
>> 
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com
>> To unsubscribe, go to
>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>> and follow the instructions there.
>> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.