[time-nuts] TCVCXO Adjustment

[Bob kb8tq]

HI

> On Apr 14, 2018, at 7:11 PM, Wayne Holder <wayne.holder at gmail.com> wrote:
> 
>> 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?
> 

Whatever you do is constrained by the accuracy of what you compare it to. There is no 
magic involved. You have a reference accuracy and a measurement process that compares
the devices. Combine those numbers and you get a limit on what you can do. Unless you 
consider those numbers, you aren’t going to get a solution. 

in a commercial situation, you can afford a reference that is orders of magnitude more accurate
than the device you are working with. That cost money and time. You also can use equipment 
that minimizes the measurement error, again there is a cost impact. 

In a home lash up, there is no quick and simple “infinite accuracy” standard and no “zero error”
measurement device. You are up against some basic limits that need to be considered.

Bob


> 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.
>> 
> _______________________________________________
> 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.