Hi

In a commercial setting calibration would be done against a local standard.
It might be checked with a counter. It also might be checked against something
more complex.

A reasonable level of calibration would be 0.1 ppm. Anything much more accurate
than that would be quickly swamped by the temperature coefficient of a typical TCXO.

Simply put, 0.1 ppm is 1 microsecond over 10 seconds. If your time code is capable of
resolving 1 us, monitor the output of the board for 10 seconds. If it is lower accuracy,
the time period would be longer. It does get a bit impractical on something like a 1 ms
code ….

The sensitivity of the TCXO should be reasonably well understood. That should give
you a ppm / bit sort of number. As an example, a 10 ppm trim range might not be
that crazy. Your 12 bit DAC would give you roughly 0.01 ppm per bit.

Since your typical PC does not have anything in it that is accurate to 0.1 ppm, you
still need something as a reference to compare things to. A GPS module or a GPSDO
are probably the easiest things to get ahold of.

Bob

On Tue, April 10, 2018 6:10 pm, Wayne Holder wrote:

Something like this MEMS oscillator may also be worth consideration:
https://www.sitime.com/products/super-tcxo/sit5356

That page says the device is sampling now, so I have not seen one yet, but
the datasheet claims +/- 0.1ppm over temperature, initial tolerance of
1ppm, 1 year aging of +/- 0.5ppm, and 20 year aging of +/- 1ppm.

MEMS oscillators rely on fractional frequency PLL as an intrinsic part of
the design, so if you get the right part number you just write a frequency
update via I2C, so you would  not need an external DAC.

One of the big limitations in a commercial factory environment that you do
not face with a user built or user calibrated device is that commercial
test and calibration time is a cost incrementing by the minute.  For a
user calibration procedure you can take advantage of the fact that there
are several time sources which are noisy on short time scales, but average
out to low long term error.

For a time-nuts class user the answers would be different, if you really
want to assume nothing but a PC and Internet it seems like you would be
limited to averaging external (i.e. off premise, contacted over the
Internet) NTP servers for long-ish periods of time.
Since the device you described is similar to a clock in that it just
constantly outputs time information, it seems that in principle you would
just need to read the timecode output from your device, compare that to a
known reliable time source (which for a typical non-time-nut I assume
would involve NTP), and average for long enough to build up confidence in
the rate difference between the known time source and your device.  Send
down a command to your device to adjust the frequency by enough to negate
the rate difference, then send down a command to update the current device
time to jump over whatever time error accumulated.

The amount of time you want to average (I think) just depends on how noisy
you think your current time estimates are, and how much precision you want
in the estimation of the rate differences.  Noise in the current time of
the calibration PC would typically be down to variations in network
latency if using remote network time sources.  Noise in retrieving the
current time of the timecode device would be in USB latency variations if
retrieving via USB (which would be on the order of the 1ms USB frame
time). You might be able to get better data from the timecode device by
just decoding the timecode audio stream in software.

The only other option which comes to mind would be incorporating longwave
radio receivers into the time setting in some way, but that would require
differences for each geographical region, and I do not think would be any
lower noise than network time for most users on modern Internet
connections.

Important to do up front will be to define specific performance limits you
would like to hit, and minimum acceptable performance.  I don't think you
will be able to really evaluate feasibility until you put real numbers on
your goals (initial accuracy, desired rate accuracy after x number of
weeks, whether you want to always adjust rate and current time
simultaneously, or if there are cases were averaging time to detect rate
it too long so you just want to jam sync current time, temperature range
over which the device has to maintain time, etc.).

--
Chris Caudle

On Tue, April 10, 2018 8:12 pm, Bob kb8tq wrote:

Catching up on some of the time-nuts traffic, some of the messages about
GPS API on phones make me wonder if a phone would not be a better option
for a typical non-time-nut user than a PC.  Setting up a GPS receiver with
PPS output with a modern PC that does not have a RS232 port available can
be pretty tricky (you would probably be starting with a bare circuit board
rather than a nicely packaged GPS device for starters), so maybe a phone
with GPS built in that lets you grab raw time data would be a better setup
for a user with limited experience setting up time measurement systems.

Or maybe a GPS Arduino shield and build a calibration system from a second
Arduino.
Multiple possibilities that are hard to rule out until the hard
performance limits are defined.

--
Chris Caudle

Why not put a GPS receiver in it ?  It won't always get a lock, but if it
gets accurate time every few weeks it can do the long-term tweaking someone
suggested in the watch thread (call in to the watch repair two weeks
apart). Except it can be done more or less EVERY two weeks.

I agree, a phone app is also a way to implement the time code generator.
But there's a lot to be said for a self-contained box for some jobs, and
the hassle of linking it to a phone or PC can be avoided for $10 on the
BOM. It doesn't even need to be a 'good' one - the TCXO is going to keep it
accurate enough over the months you can spend tracking the error.

On Thu, Apr 12, 2018 at 11:21 PM, Chris Caudle chris@chriscaudle.org
wrote:

Wayne,

On 04/11/2018 01:10 AM, Wayne Holder wrote:

When recording things like this, if you manage to synchronize everything
to the same source locally, you don't care too much about the absolute
frequency of that source. The unsteered oscillator would suffice, as
within 10 ppm is what is modern specifications.

Consider if you can produce black-burst video reference and word-clock
signals as well, as that helps to actually synchronize video and audio
sample rates. Some cameras may not take "genlock" video but have video
out, then you could take that to be the common clock and produce the
rest from that as reference.

A trick that has been used especially under battery operation has been
to have stable clocks, that is OCXOs, and before the shoot synchronize
them to each other and then during the shoot have them free-wheel. Since
they are stable they do not loose frequency and phase too much and that
saves effort later in the post-processing. That is where you would use
steering to make them agree before hold-over. Then the relative
frequency difference is what matters.

You should also look at ViTC, for the video time code form of SMPTE 12M
time code standard.

Cheers,
Magnus