[time-nuts] TCVCXO Adjustment

[Wayne Holder]

> The application is time stamping separate free running devices, in this
> case different video and audio recorders.  So the absolute time is
> arbitrary, but all the devices in use have to agree on the rate of time
> progression for as long as they are being used together.
> The typical requirement is that all the free running devices have timecode
> which will be aligned within one video frame, so ca. 33ms, at the end of
> the time of use.
> So for example, you are making some kind of video, you put all the
> timecode devices together and get their time synchronized, at which point
> they get separated and connected to various audio and video recording
> devices to output a timecode signal that the video and audio devices
> record along with their primary recordings, so that later you can line up
> the recordings from different machines and match same recording from
> different locations, angles, etc. and know they were from the same time.
> You want the last work of the day to still be synchronized to within
> closer than 33ms, so the maximum time you want to be able to work without
> getting your timecode generators back together to synchronize defines your
> drift rate which defines your acceptable accuracy.
> From common specifications it seems that the commercial products converged
> on 24 hours as the  use time limit, so 33ms/24 hours -> 0.033s/86400s ~
> 0.4ppm
>
> Yes, in principle you could use an arbitrary clock rate as well as an
> arbitrary  starting time, but that could only work if all the devices were
> exactly the same rate, so if you have to adjust the devices anyway, and
> some may be coming from 3rd parties that you don't have access to prior to
> use, then the only practical approach is for everyone to calibrate their
> devices to standard rate.
>

Yes, exactly,  You've described my use case much better than I did.  Thanks.


> I'll let the original poster ponder on whether GPS on board is a good
> thing or not, but I think you cannot count on GPS being available in use
> (could be inside a steel building, or a steel reinforced concrete
> building, with no RF reception), so you would still need a local
> oscillator which could hold the rate tightly enough to guarantee less than
> 33ms of phase drift over the course of a day.  Maybe you could relax that
> to "working day" and say it's only over 12 hours, not 24 hours.
>

As you point out, given the need to potentially interoperate with existing
timecode systems and the issue of problematic indoor reception, additional
power consumption, initial lock in time, etc., I think trying to use a GPS
in real time high create more problems than is solves.  But, having it
built in could make off-line calibration easier.


> What I think makes this potentially interesting to time-nuts is that the
> time requirements are pretty loose by time-nuts standards, but potentially
> some of the tricks that people come up with for getting ns level accuracy
> on hobby budgets could be applied to this to find a way for non-nuts (or
> at least not-yet-nuts) to get started on a really low budget.


That was exactly what I was hoping for when I placed my initial post.
While I've been following this list for many years, I still consider myself
a novice "nut" as there are still many, many things I still don't
understand about precision timekeeping.  I understand the basic idea behind
frequency calibration, but I don't really know how to account for all the
potential sources of error and handle them accordingly.  As I think I
mentioned before, I started out by reading this NIST doc
<https://tf.nist.gov/service/pdf/calibrations.pdf>, which starts out
talking about the relationship between the measurement period and measure
phase error to the frequency offset.  So, my simplistic ideas for
calibration are, as follows:

Idea 1: Use a relative long timebase to measure the frequency offset and
tweak the DAC by one bit value at a time until the correction seems to
converge on a range of values and then call that calibrated. But, this
could take a long time and doesn't really give a way to tell the user how
long the calibration might take to complete.

Idea 2: Start with a short timebase, tweak until things seem to converge,
then shift to a longer timebase and repeat, as needed, to increase
accuracy.  It seems like this should be faster, but it's still seems like a
crude approach.

Idea 3: Come up with some sort of calculation (?) that takes into
consideration the accuracy and stability of the timebase and the
manufacturer's specs for the TCVCXO and use this to optimize the step 2
approach by setting limits on the starting and ending measurement periods
and perhaps the step size of the tweaks.  But, how do I know the accuracy
and stability of the reference timebase?

Wayne


On Sat, Apr 14, 2018 at 1:43 PM, Chris Caudle <chris at chriscaudle.org> wrote:

> On Sat, April 14, 2018 8:37 am, Bob kb8tq wrote:
> > big an issue as the TCXO. If it's a single location and the time is
> > arbitrary, then maybe not so big a deal.
> > If it's all arbitrary why worry about drift?
> >
> > GPS on the board looks like a good thing to have to me
>
> The application is time stamping separate free running devices, in this
> case different video and audio recorders.  So the absolute time is
> arbitrary, but all the devices in use have to agree on the rate of time
> progression for as long as they are being used together.
> The typical requirement is that all the free running devices have timecode
> which will be aligned within one video frame, so ca. 33ms, at the end of
> the time of use.
> So for example, you are making some kind of video, you put all the
> timecode devices together and get their time synchronized, at which point
> they get separated and connected to various audio and video recording
> devices to output a timecode signal that the video and audio devices
> record along with their primary recordings, so that later you can line up
> the recordings from different machines and match same recording from
> different locations, angles, etc. and know they were from the same time.
> You want the last work of the day to still be synchronized to within
> closer than 33ms, so the maximum time you want to be able to work without
> getting your timecode generators back together to synchronize defines your
> drift rate which defines your acceptable accuracy.
> From common specifications it seems that the commercial products converged
> on 24 hours as the  use time limit, so 33ms/24 hours -> 0.033s/86400s ~
> 0.4ppm
>
> Yes, in principle you could use an arbitrary clock rate as well as an
> arbitrary  starting time, but that could only work if all the devices were
> exactly the same rate, so if you have to adjust the devices anyway, and
> some may be coming from 3rd parties that you don't have access to prior to
> use, then the only practical approach is for everyone to calibrate their
> devices to standard rate.
>
> I'll let the original poster ponder on whether GPS on board is a good
> thing or not, but I think you cannot count on GPS being available in use
> (could be inside a steel building, or a steel reinforced concrete
> building, with no RF reception), so you would still need a local
> oscillator which could hold the rate tightly enough to guarantee less than
> 33ms of phase drift over the course of a day.  Maybe you could relax that
> to "working day" and say it's only over 12 hours, not 24 hours.
>
> What I think makes this potentially interesting to time-nuts is that the
> time requirements are pretty loose by time-nuts standards, but potentially
> some of the tricks that people come up with for getting ns level accuracy
> on hobby budgets could be applied to this to find a way for non-nuts (or
> at least not-yet-nuts) to get started on a really low budget.
>
> --
> Chris Caudle
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>