[time-nuts] TCVCXO Adjustment

[Wayne Holder]

First, thanks for all the comments and suggestions,  It's given me a lot to
think about and research.

Based on the feedback I've received, I've started to investigate using the NTP
server approach suggested by Chris Caudle.  I also found this NIST Paper
<https://tf.nist.gov/service/pdf/calibrations.pdf> to be very useful, as it
gave me some insight into the measurement period needed to achieve a given
accuracy in the DUT given a certain level of deviation in the reference
used.  But, I think further reading will be required before I can reduce
this approach to a plan.  I anyone knows of additional info on using NTP to
calibrate precision oscillators, I'd appreciate hearing about it.

The basic unit of measurement for Longitudinal Timecode is the video frame
rate, or approximately 30 fps, depending on the video medium in use.
Current commercial Timecode Generators make claims like having a drift
of only 1 frame over 24 hours, so that's been my target for my design.   Based
on my math, I think a drift of only 1/30th of a second in 24 hours is
perhaps +/-0.5 PPP, or so, but someone please correct me if I'm wrong.
  Another solution used with older, less accurate timecode generators is to
periodically resync (or "Jam Sync") the different timecode generators to
the master timecode generator thoughout the day but, while I'm not a video
production expert, I think think this is a less desirable solution.

Using a GPS, as suggestion by Adrian Godwin, is also an option, as the PPS
signal could be used as a calibration reference.   Cheap, consumer GPS
modules have gotten quite cheap and, based on my own experience
using various uBlox modules, some can even function fairly well indoors
under some conditions.  However, I seem to recall some discussion here some
time back about the relative reliability of the PPS signal in some
situations.  I'll have to dig back though the archives and see if I can
learn anything from those threads.

To provide some additional details on my project for those that
are interested, the current plan is to build everything into a USB Stick
form factor.  The USB connection would be used to configure internal
options (frame rate, etc.), charge the internal Li-Poly battery and
also, potentially, perform the calibration.  The time code signal would
be output from a 3.5mm phone connector, so the suggestion to connect this
to the audio input of the computer doing the calibration also makes sense,
as this would take USB latency out of the picture (assuming that the sound
interface in the PC is not just implemented via a chip on the USB bus.)

Wayne