Re: [time-nuts] TCVCXO Adjustment

[Bob kb8tq]

HI

> On Apr 14, 2018, at 7:11 PM, Wayne Holder  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
> , 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

Re: [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
, 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  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 ma

Re: [time-nuts] TCVCXO Adjustment

[Bob kb8tq]

Hi

It’s reasonable to expect the slope of the EFC to vary 2:1 over it’s range. 
Could be more,
could be less. How much depends a lot on what the original OEM wanted on 
surplus parts. 
In the case of “bought new” you would have to check the data sheet. If there’s 
no spec, it’s 
reasonable to assume 4:1 slope ratio over the range. 

Note that none of this tells you what the curve looks like. It only gets into 
the change in slope. 
Why? Well, if you are looking for a tuning increment, that is what you are 
after. It is still not 
a perfect measure, but it’s about as close as you are going to get. 

The shape of the curve depends on a lot of things. The crystal overtone and its 
parameters
certainly get in there. The exact varicap (or set of varicaps) used get in 
there. Finally the offset
from series (or anti-resonance) gets into it all. 

So lots of variables, lots of curves …..

Bob

> On Apr 14, 2018, at 4:03 PM, Hal Murray  wrote:
> 
> 
> kb...@n1k.org said:
>> The gotcha is that you do not have a calibrated adjustment. Put another way,
>> there isn’t a perfect correlation between DAC bits and ppm. Each adjustment
>> you make is subject to a bit of error. When you are trying to get within a
>> ppm,  your measurements are quicker, so the larger error ( percentage of
>> step) may not be as big a deal. When you get close, it is likely to become a
>> big deal.  
> 
> Interesting.  Thanks.
> 
> How much does it vary from unit to unit?  How non-linear is it likely to be?  
> How much does it change with temperature?
> 
> Anybody have data?
> 
> Are fancy OCXOs more linear?
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Bob kb8tq]

Hi

That’s one possible application. Jim’s VLBI in the back yard is another 
possible 
application. If this is aimed at “distributed VLBI” then the requirements are … 
errr …
pretty tight.

Bob

> On Apr 14, 2018, at 4:43 PM, Chris Caudle  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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Chris Caudle]

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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Hal Murray]

kb...@n1k.org said:
> The gotcha is that you do not have a calibrated adjustment. Put another way,
> there isn’t a perfect correlation between DAC bits and ppm. Each adjustment
> you make is subject to a bit of error. When you are trying to get within a
> ppm,  your measurements are quicker, so the larger error ( percentage of
> step) may not be as big a deal. When you get close, it is likely to become a
> big deal.  

Interesting.  Thanks.

How much does it vary from unit to unit?  How non-linear is it likely to be?  
How much does it change with temperature?

Anybody have data?

Are fancy OCXOs more linear?


-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Bob kb8tq]

Hi



> On Apr 14, 2018, at 11:10 AM, Adrian Godwin  wrote:
> 
> What if you iterated toward a suitable minimum-error setting, then looked
> for cyclic corrections with a period of weeks to months. Once you start to
> see that, choose the centre of the cycle and track it (or perhaps just
> increase the time constant).

If you only get one data point per month, then it will be a pretty basic plot. 
Even with a data point a week, it will be pretty sparse. 

We get very used to “data everywhere” sorts of situations. With most of the
proposed approaches *if* tight set is desired the data will be pretty sparse. 
It’s still a bit unclear what the target accuracy is (or even if the TCXO needs
setting at all …).

Bob


> 
> On Sat, Apr 14, 2018 at 2:37 PM, Bob kb8tq  wrote:
> 
>> Hi
>> 
>> The gotcha is that you do not have a calibrated adjustment. Put another
>> way,
>> there isn’t a perfect correlation between DAC bits and ppm. Each
>> adjustment
>> you make is subject to a bit of error. When you are trying to get within a
>> ppm,
>> your measurements are quicker, so the larger error ( percentage of step)
>> may
>> not be as big a deal. When you get close, it is likely to become a big
>> deal.
>> 
>> You could track all of your changes (month to month). The issue there is
>> that the
>> drift in the TCXO month to month is not likely to be the same. Sorting all
>> of that out
>> could be a bit nasty …..
>> 
>> 
>> 
>> TCXO drift is not the only contributor to the accuracy of a time code
>> generator.
>> The other obvious one is setting it to the correct time in the first
>> place.  If the
>> objective is to compare data from different locations, getting it set may
>> be as
>> 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 ….
>> 
>> Bob
>> 
>> 
>>> On Apr 14, 2018, at 6:35 AM, Adrian Godwin  wrote:
>>> 
>>> If you compare VCXO time with UTC or GPS once a month to an accuracy of
>> 1s
>>> (with NMEA or even a time signal and manual pushbutton) and make a
>>> correction for the 2.5 million seconds that occurred since the last
>>> correction, you'll be better than 0.5 ppm.
>>> 
>>> Is that good enough ?
>>> 
>>> On Sat, Apr 14, 2018 at 5:59 AM, Hal Murray 
>> wrote:
>>> 
 
 kb...@n1k.org said:
> The alternative is to plug a USB GPS into the mac and do a bit of code
>> to
> compare things. If you want to pass the gizmo around to your friends ….
 that
> can be done. Pretty good ones are “sub $10” delivered.
 
 USB GPS gizmos generally don't have a PPS and the timing on the NMEA
 sentences is generally crappy.  (I may be biased by a few bad examples.)
 
 Does anybody have a list of ones known to work well?
 
 There is at least one GPS-USB with PPS, the Navisys
 GR-601W/GR-701W/GR-801W,
 They were hard to get retail.  Looks like idealez sells them Taiwan for
 $47
 for the 701W (Ublox 7), $50 for the 801W (Ublox 8) (plus shipping).  I
 haven't tried ordering through them.  Gary and/or Mark may have some for
 sale.
 
 --
 
 Plan B is a GPS breakout and a USB-serial breakout and a few wires.  4x
 less
 USB jitter if your USB-Serial chip is full-speed.
 
 I got mine from SparkFun:
 Venus GPS with SMA Connector
 https://www.sparkfun.com/products/11058
 USB to Serial Breakout - FT232RL
 https://www.sparkfun.com/products/12731
 
 --
 
 Google found this.  I don't know anything more:
 https://www.zti-communications.com/z050-gps-dongle/
 
 
 --
 These are my opinions.  I hate spam.
 
 
 
 
 ___
 time-nuts mailing list -- time-nuts@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@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@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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Adrian Godwin]

What if you iterated toward a suitable minimum-error setting, then looked
for cyclic corrections with a period of weeks to months. Once you start to
see that, choose the centre of the cycle and track it (or perhaps just
increase the time constant).

On Sat, Apr 14, 2018 at 2:37 PM, Bob kb8tq  wrote:

> Hi
>
> The gotcha is that you do not have a calibrated adjustment. Put another
> way,
> there isn’t a perfect correlation between DAC bits and ppm. Each
> adjustment
> you make is subject to a bit of error. When you are trying to get within a
> ppm,
> your measurements are quicker, so the larger error ( percentage of step)
> may
> not be as big a deal. When you get close, it is likely to become a big
> deal.
>
> You could track all of your changes (month to month). The issue there is
> that the
> drift in the TCXO month to month is not likely to be the same. Sorting all
> of that out
> could be a bit nasty …..
>
> 
>
> TCXO drift is not the only contributor to the accuracy of a time code
> generator.
> The other obvious one is setting it to the correct time in the first
> place.  If the
> objective is to compare data from different locations, getting it set may
> be as
> 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 ….
>
> Bob
>
>
> > On Apr 14, 2018, at 6:35 AM, Adrian Godwin  wrote:
> >
> > If you compare VCXO time with UTC or GPS once a month to an accuracy of
> 1s
> > (with NMEA or even a time signal and manual pushbutton) and make a
> > correction for the 2.5 million seconds that occurred since the last
> > correction, you'll be better than 0.5 ppm.
> >
> > Is that good enough ?
> >
> > On Sat, Apr 14, 2018 at 5:59 AM, Hal Murray 
> wrote:
> >
> >>
> >> kb...@n1k.org said:
> >>> The alternative is to plug a USB GPS into the mac and do a bit of code
> to
> >>> compare things. If you want to pass the gizmo around to your friends ….
> >> that
> >>> can be done. Pretty good ones are “sub $10” delivered.
> >>
> >> USB GPS gizmos generally don't have a PPS and the timing on the NMEA
> >> sentences is generally crappy.  (I may be biased by a few bad examples.)
> >>
> >> Does anybody have a list of ones known to work well?
> >>
> >> There is at least one GPS-USB with PPS, the Navisys
> >> GR-601W/GR-701W/GR-801W,
> >> They were hard to get retail.  Looks like idealez sells them Taiwan for
> >> $47
> >> for the 701W (Ublox 7), $50 for the 801W (Ublox 8) (plus shipping).  I
> >> haven't tried ordering through them.  Gary and/or Mark may have some for
> >> sale.
> >>
> >> --
> >>
> >> Plan B is a GPS breakout and a USB-serial breakout and a few wires.  4x
> >> less
> >> USB jitter if your USB-Serial chip is full-speed.
> >>
> >> I got mine from SparkFun:
> >> Venus GPS with SMA Connector
> >>  https://www.sparkfun.com/products/11058
> >> USB to Serial Breakout - FT232RL
> >>  https://www.sparkfun.com/products/12731
> >>
> >> --
> >>
> >> Google found this.  I don't know anything more:
> >>  https://www.zti-communications.com/z050-gps-dongle/
> >>
> >>
> >> --
> >> These are my opinions.  I hate spam.
> >>
> >>
> >>
> >>
> >> ___
> >> time-nuts mailing list -- time-nuts@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@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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Bob kb8tq]

Hi

The gotcha is that you do not have a calibrated adjustment. Put another way,
there isn’t a perfect correlation between DAC bits and ppm. Each adjustment 
you make is subject to a bit of error. When you are trying to get within a ppm, 
your measurements are quicker, so the larger error ( percentage of step) may
not be as big a deal. When you get close, it is likely to become a big deal. 

You could track all of your changes (month to month). The issue there is that 
the
drift in the TCXO month to month is not likely to be the same. Sorting all of 
that out
could be a bit nasty …..



TCXO drift is not the only contributor to the accuracy of a time code 
generator. 
The other obvious one is setting it to the correct time in the first place.  If 
the
objective is to compare data from different locations, getting it set may be as
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 ….

Bob


> On Apr 14, 2018, at 6:35 AM, Adrian Godwin  wrote:
> 
> If you compare VCXO time with UTC or GPS once a month to an accuracy of 1s
> (with NMEA or even a time signal and manual pushbutton) and make a
> correction for the 2.5 million seconds that occurred since the last
> correction, you'll be better than 0.5 ppm.
> 
> Is that good enough ?
> 
> On Sat, Apr 14, 2018 at 5:59 AM, Hal Murray  wrote:
> 
>> 
>> kb...@n1k.org said:
>>> The alternative is to plug a USB GPS into the mac and do a bit of code to
>>> compare things. If you want to pass the gizmo around to your friends ….
>> that
>>> can be done. Pretty good ones are “sub $10” delivered.
>> 
>> USB GPS gizmos generally don't have a PPS and the timing on the NMEA
>> sentences is generally crappy.  (I may be biased by a few bad examples.)
>> 
>> Does anybody have a list of ones known to work well?
>> 
>> There is at least one GPS-USB with PPS, the Navisys
>> GR-601W/GR-701W/GR-801W,
>> They were hard to get retail.  Looks like idealez sells them Taiwan for
>> $47
>> for the 701W (Ublox 7), $50 for the 801W (Ublox 8) (plus shipping).  I
>> haven't tried ordering through them.  Gary and/or Mark may have some for
>> sale.
>> 
>> --
>> 
>> Plan B is a GPS breakout and a USB-serial breakout and a few wires.  4x
>> less
>> USB jitter if your USB-Serial chip is full-speed.
>> 
>> I got mine from SparkFun:
>> Venus GPS with SMA Connector
>>  https://www.sparkfun.com/products/11058
>> USB to Serial Breakout - FT232RL
>>  https://www.sparkfun.com/products/12731
>> 
>> --
>> 
>> Google found this.  I don't know anything more:
>>  https://www.zti-communications.com/z050-gps-dongle/
>> 
>> 
>> --
>> These are my opinions.  I hate spam.
>> 
>> 
>> 
>> 
>> ___
>> time-nuts mailing list -- time-nuts@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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Bob kb8tq]

Hi

The uBlox based parts will provide pretty good timing into a directly connected 
PC. By that I mean, they are on a dedicated USB controller hooked directly to
the CPU. 

In this context, the objective is microsecond level timing. We’re not after 
a TimeNut couple of nanoseconds. Even if it’s 10 us, you still get to 0.1 ppm 
in 100 seconds…..

Bob

> On Apr 14, 2018, at 12:59 AM, Hal Murray  wrote:
> 
> 
> kb...@n1k.org said:
>> The alternative is to plug a USB GPS into the mac and do a bit of code to
>> compare things. If you want to pass the gizmo around to your friends …. that
>> can be done. Pretty good ones are “sub $10” delivered.  
> 
> USB GPS gizmos generally don't have a PPS and the timing on the NMEA 
> sentences is generally crappy.  (I may be biased by a few bad examples.)
> 
> Does anybody have a list of ones known to work well?
> 
> There is at least one GPS-USB with PPS, the Navisys GR-601W/GR-701W/GR-801W,  
> They were hard to get retail.  Looks like idealez sells them Taiwan for $47 
> for the 701W (Ublox 7), $50 for the 801W (Ublox 8) (plus shipping).  I 
> haven't tried ordering through them.  Gary and/or Mark may have some for sale.
> 
> --
> 
> Plan B is a GPS breakout and a USB-serial breakout and a few wires.  4x less 
> USB jitter if your USB-Serial chip is full-speed.
> 
> I got mine from SparkFun:
> Venus GPS with SMA Connector
>  https://www.sparkfun.com/products/11058
> USB to Serial Breakout - FT232RL
>  https://www.sparkfun.com/products/12731
> 
> --
> 
> Google found this.  I don't know anything more:
>  https://www.zti-communications.com/z050-gps-dongle/
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Bob kb8tq]

Hi

Yes you could. If you are listening to them by ear, something in the ~100 ms 
range
is probably a good guess in terms of precision.  There are also propagation 
issues
that may come in with a broadcast system. 

If you are still after 0.1 ppm, that gets you out to a million seconds per 
adjustment 
attempt. Roughly two weeks between attempts is about where that would put you.
At that sort of time period you *would* get a lot of local temperature profile 
averaged
into the result. I’d say that’s a good thing. 



One very basic question on all of this: If the TCXO is the expensive part of 
the system
and GPS modules are (relatively) cheap …. why use the TCXO at all? Simply run a
crystal as the reference. Do a drop / add to keep things running right. When 
the GPS
has lock, you have perfect time sync, When it drops out, you go to the crystal 
as a 
backup. 

If microsecond level accuracy *is* what the goal is, the TCXO, even when it’s 
calibrated
is not a really good way to do that ...

Bob

> On Apr 13, 2018, at 9:02 PM, Adrian Godwin  wrote:
> 
> Could you use the "pips" instead of a PPS signal, again comparing them some
> weeks apart to give a long reference time ?
> 
> https://en.wikipedia.org/wiki/Greenwich_Time_Signal
> 
> If your local radio broadcaster doesn't play something like them, they
> could probably be generated with a web application.
> 
> 
> On Sat, Apr 14, 2018 at 12:13 AM, Wayne Holder 
> wrote:
> 
>> Again, thanks for all the great feedback and suggestions.
>> 
>>> Are you familiar with these devices which I just found this week?
>>> https://tentaclesync.com/products
>> 
>> Yes, that's one of the lower cost commercial units available.  Another is
>> the NanoLockiIt by Ambient
>> > recording_acn_nl_nanolockit_miniature_timecode_synchronizer.html>,
>> which is company that's been making timecode products for many years.
>> Compared to more traditional prices for timecode generators, these are
>> relatively inexpensive at about $300.  However you need at least two, or
>> more generators to be useful, so that adds up pretty fast for an amateur
>> videographer, or starving film school student.  In contrast,  BOM for the
>> design I'm working on is less than $30 (the TCVCXO being, by far, the
>> most expensive part.)
>> 
>> My plan is to also write a desktop application, probably in Java to make it
>> portable, that the person building the devices could use to perform the
>> initial calibration and also setup various options.  So, the NTP-based
>> solution is attractive in that it doesn't require any additional hardware.
>> I'm a Mac user so, after a bit of reading the NTP implementation on the
>> Mac, I tried a few experiments.  Typing "ntpq -p" in the terminal
>> app produced this response:
>> 
>> remote   refid  st t when poll reach   delay   offset
>> jitter
>> 
>> 
>> ==
>> 
>> *usdal2-ntp-001. .GPSs.   1 u  428 1024  377   51.1311.944
>> 1.153
>> 
>> and typing  "ntpq -c rl" printed out:
>> 
>> associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
>> 
>> version="ntpd 4.2.8p6@1.3265 Fri Feb  5 17:38:17 UTC 2016 (124.60.2~39)",
>> 
>> processor="x86_64", system="Darwin/16.7.0", leap=00, stratum=2,
>> 
>> precision=-20, rootdelay=51.131, rootdisp=34.160, refid=17.253.2.125,
>> 
>> reftime=de7ba9c1.937e5f86  Fri, Apr 13 2018 15:12:17.576,
>> 
>> clock=de7badf7.39f8d36a  Fri, Apr 13 2018 15:30:15.226, peer=7077, tc=10,
>> 
>> mintc=3, offset=1.944153, frequency=25.163, sys_jitter=0.00,
>> 
>> clk_jitter=0.745, clk_wander=0.001
>> 
>> I believe that the "precision" of -20 value on the 4th line is supposed to
>> be interpreted as 2^-20 seconds which, if my math is correct, works out to
>> be a precision of about 1 PPM. Is that correct?  If so, it would seem like
>> I should be able to use my system's internal clock to perform a "tweak" in
>> around 10,000 seconds, or a little less than 3 hours.  Does this seem
>> correct, or have I missed something?
>> 
>> Alternately, if I included a GPS receiver in the design, the whole process
>> could be done within the device, which would probably be the easiest
>> approach to calibration for the person building one.  This would increase
>> the cost and make the device larger, but users could then maintain
>> calibration by periodically keeping them plugged in for a few hours.  Or,
>> perhaps I could just design a 2nd board for a GPS "calibrator" module that
>> could be plugged into the timecode generators to calibrate them.  Hmm...
>> lots to think about.
>> 
>> Wayne
>> ___
>> time-nuts mailing list -- time-nuts@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 -- tim

Re: [time-nuts] TCVCXO Adjustment

[Magnus Danielson]

Wayne,

On 04/11/2018 01:10 AM, Wayne Holder wrote:
> I'm designing a small, portable, SMPTE LTC Timecode Generator
>  as an open source/hardware
> project for amateur filmmakers and videographers.  LTC Timecode is
> typically recorded on the audio tracks of cameras and sound recorders so
> the video and sound comments can be automatically sync'd later.  I'm
> planing on using a small, SMD TCVCXO such as the LFTVXO075806Cutt
> ,
> which is spec'd at a frequency tolerance or +/- 1 PPM and a frequency
> stability of 0.28 PPM and a yearly aging of +/- 1 PPM max/year which, to
> me, seems pretty impressive for a part that costs about $8.
> 
> Since the TCVCXO includes a voltage control input, my plan is to also add
> a 12-Bit Digital-to-Analog Converter with EEPROM Memory, such as the
> Microchip MCP4725
> 
> to
> provide a way to initially check and calibrate the frequency after surface
> mount soldering and also later to compensate for aging.  But since this is
> intended as an open source/hardware project rather than a commercially
> manufactured one, I've been pondering how someone building the device would
> be able to easily and reliably calibrate it.
> 
> I'm basing the design around the Arduino, so the device could, in theory,
> use the USB Serial connection as a way to connect to a calibration program
> running on a PC.  I have a few idea on how to attempt to do this, but this
> is new territory for me, so I'm asking for advice and/or thoughts on how
> feasible this might be.  Is this a crazy, impractical idea given that all
> the builder will probably have available to perform the calibration is a
> regular PC and an Internet connection, or is there a way to make it work?

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
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Adrian Godwin]

If you compare VCXO time with UTC or GPS once a month to an accuracy of 1s
(with NMEA or even a time signal and manual pushbutton) and make a
correction for the 2.5 million seconds that occurred since the last
correction, you'll be better than 0.5 ppm.

Is that good enough ?

On Sat, Apr 14, 2018 at 5:59 AM, Hal Murray  wrote:

>
> kb...@n1k.org said:
> > The alternative is to plug a USB GPS into the mac and do a bit of code to
> > compare things. If you want to pass the gizmo around to your friends ….
> that
> > can be done. Pretty good ones are “sub $10” delivered.
>
> USB GPS gizmos generally don't have a PPS and the timing on the NMEA
> sentences is generally crappy.  (I may be biased by a few bad examples.)
>
> Does anybody have a list of ones known to work well?
>
> There is at least one GPS-USB with PPS, the Navisys
> GR-601W/GR-701W/GR-801W,
> They were hard to get retail.  Looks like idealez sells them Taiwan for
> $47
> for the 701W (Ublox 7), $50 for the 801W (Ublox 8) (plus shipping).  I
> haven't tried ordering through them.  Gary and/or Mark may have some for
> sale.
>
> --
>
> Plan B is a GPS breakout and a USB-serial breakout and a few wires.  4x
> less
> USB jitter if your USB-Serial chip is full-speed.
>
> I got mine from SparkFun:
> Venus GPS with SMA Connector
>   https://www.sparkfun.com/products/11058
> USB to Serial Breakout - FT232RL
>   https://www.sparkfun.com/products/12731
>
> --
>
> Google found this.  I don't know anything more:
>   https://www.zti-communications.com/z050-gps-dongle/
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Hal Murray]

kb...@n1k.org said:
> The alternative is to plug a USB GPS into the mac and do a bit of code to
> compare things. If you want to pass the gizmo around to your friends …. that
> can be done. Pretty good ones are “sub $10” delivered.  

USB GPS gizmos generally don't have a PPS and the timing on the NMEA 
sentences is generally crappy.  (I may be biased by a few bad examples.)

Does anybody have a list of ones known to work well?

There is at least one GPS-USB with PPS, the Navisys GR-601W/GR-701W/GR-801W,  
They were hard to get retail.  Looks like idealez sells them Taiwan for $47 
for the 701W (Ublox 7), $50 for the 801W (Ublox 8) (plus shipping).  I 
haven't tried ordering through them.  Gary and/or Mark may have some for sale.

--

Plan B is a GPS breakout and a USB-serial breakout and a few wires.  4x less 
USB jitter if your USB-Serial chip is full-speed.

I got mine from SparkFun:
Venus GPS with SMA Connector
  https://www.sparkfun.com/products/11058
USB to Serial Breakout - FT232RL
  https://www.sparkfun.com/products/12731

--

Google found this.  I don't know anything more:
  https://www.zti-communications.com/z050-gps-dongle/


-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Adrian Godwin]

Could you use the "pips" instead of a PPS signal, again comparing them some
weeks apart to give a long reference time ?

https://en.wikipedia.org/wiki/Greenwich_Time_Signal

If your local radio broadcaster doesn't play something like them, they
could probably be generated with a web application.


On Sat, Apr 14, 2018 at 12:13 AM, Wayne Holder 
wrote:

> Again, thanks for all the great feedback and suggestions.
>
> > Are you familiar with these devices which I just found this week?
> > https://tentaclesync.com/products
>
> Yes, that's one of the lower cost commercial units available.  Another is
> the NanoLockiIt by Ambient
>  recording_acn_nl_nanolockit_miniature_timecode_synchronizer.html>,
> which is company that's been making timecode products for many years.
> Compared to more traditional prices for timecode generators, these are
> relatively inexpensive at about $300.  However you need at least two, or
> more generators to be useful, so that adds up pretty fast for an amateur
> videographer, or starving film school student.  In contrast,  BOM for the
> design I'm working on is less than $30 (the TCVCXO being, by far, the
> most expensive part.)
>
> My plan is to also write a desktop application, probably in Java to make it
> portable, that the person building the devices could use to perform the
> initial calibration and also setup various options.  So, the NTP-based
> solution is attractive in that it doesn't require any additional hardware.
> I'm a Mac user so, after a bit of reading the NTP implementation on the
> Mac, I tried a few experiments.  Typing "ntpq -p" in the terminal
> app produced this response:
>
>  remote   refid  st t when poll reach   delay   offset
> jitter
>
> 
> ==
>
> *usdal2-ntp-001. .GPSs.   1 u  428 1024  377   51.1311.944
> 1.153
>
> and typing  "ntpq -c rl" printed out:
>
> associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
>
> version="ntpd 4.2.8p6@1.3265 Fri Feb  5 17:38:17 UTC 2016 (124.60.2~39)",
>
> processor="x86_64", system="Darwin/16.7.0", leap=00, stratum=2,
>
> precision=-20, rootdelay=51.131, rootdisp=34.160, refid=17.253.2.125,
>
> reftime=de7ba9c1.937e5f86  Fri, Apr 13 2018 15:12:17.576,
>
> clock=de7badf7.39f8d36a  Fri, Apr 13 2018 15:30:15.226, peer=7077, tc=10,
>
> mintc=3, offset=1.944153, frequency=25.163, sys_jitter=0.00,
>
> clk_jitter=0.745, clk_wander=0.001
>
> I believe that the "precision" of -20 value on the 4th line is supposed to
> be interpreted as 2^-20 seconds which, if my math is correct, works out to
> be a precision of about 1 PPM. Is that correct?  If so, it would seem like
> I should be able to use my system's internal clock to perform a "tweak" in
> around 10,000 seconds, or a little less than 3 hours.  Does this seem
> correct, or have I missed something?
>
> Alternately, if I included a GPS receiver in the design, the whole process
> could be done within the device, which would probably be the easiest
> approach to calibration for the person building one.  This would increase
> the cost and make the device larger, but users could then maintain
> calibration by periodically keeping them plugged in for a few hours.  Or,
> perhaps I could just design a 2nd board for a GPS "calibrator" module that
> could be plugged into the timecode generators to calibrate them.  Hmm...
> lots to think about.
>
> Wayne
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Hal Murray]

wayne.hol...@gmail.com said:
> I believe that the "precision" of -20 value on the 4th line is supposed to
> be interpreted as 2^-20 seconds which, if my math is correct, works out to
> be a precision of about 1 PPM. Is that correct?

That's the time between ticks or the time it takes to read the clock.  It 
doesn't tell you anything about how correct the clock is.


-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Bob kb8tq]

Hi

With NTP (or any other timing system) you really need 3 or more sources to sort
things out. If you only have one source, eventually everything will converge on 
it. 
That’s not to say that it will be correct, you simply will be 100% locked to 
it. 

GPS modules are a “sub $20” sort of thing these days. You aren’t after super 
duper
precision. Simply drop one on your board and run it all the time ….

The alternative is to plug a USB GPS into the mac and do a bit of code to 
compare
things. If you want to pass the gizmo around to your friends …. that can be 
done. Pretty
good ones are “sub $10” delivered. 

Bob

> On Apr 13, 2018, at 7:13 PM, Wayne Holder  wrote:
> 
> Again, thanks for all the great feedback and suggestions.
> 
>> Are you familiar with these devices which I just found this week?
>> https://tentaclesync.com/products
> 
> Yes, that's one of the lower cost commercial units available.  Another is
> the NanoLockiIt by Ambient
> ,
> which is company that's been making timecode products for many years.
> Compared to more traditional prices for timecode generators, these are
> relatively inexpensive at about $300.  However you need at least two, or
> more generators to be useful, so that adds up pretty fast for an amateur
> videographer, or starving film school student.  In contrast,  BOM for the
> design I'm working on is less than $30 (the TCVCXO being, by far, the
> most expensive part.)
> 
> My plan is to also write a desktop application, probably in Java to make it
> portable, that the person building the devices could use to perform the
> initial calibration and also setup various options.  So, the NTP-based
> solution is attractive in that it doesn't require any additional hardware.
> I'm a Mac user so, after a bit of reading the NTP implementation on the
> Mac, I tried a few experiments.  Typing "ntpq -p" in the terminal
> app produced this response:
> 
> remote   refid  st t when poll reach   delay   offset
> jitter
> 
> ==
> 
> *usdal2-ntp-001. .GPSs.   1 u  428 1024  377   51.1311.944
> 1.153
> 
> and typing  "ntpq -c rl" printed out:
> 
> associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
> 
> version="ntpd 4.2.8p6@1.3265 Fri Feb  5 17:38:17 UTC 2016 (124.60.2~39)",
> 
> processor="x86_64", system="Darwin/16.7.0", leap=00, stratum=2,
> 
> precision=-20, rootdelay=51.131, rootdisp=34.160, refid=17.253.2.125,
> 
> reftime=de7ba9c1.937e5f86  Fri, Apr 13 2018 15:12:17.576,
> 
> clock=de7badf7.39f8d36a  Fri, Apr 13 2018 15:30:15.226, peer=7077, tc=10,
> 
> mintc=3, offset=1.944153, frequency=25.163, sys_jitter=0.00,
> 
> clk_jitter=0.745, clk_wander=0.001
> 
> I believe that the "precision" of -20 value on the 4th line is supposed to
> be interpreted as 2^-20 seconds which, if my math is correct, works out to
> be a precision of about 1 PPM. Is that correct?  If so, it would seem like
> I should be able to use my system's internal clock to perform a "tweak" in
> around 10,000 seconds, or a little less than 3 hours.  Does this seem
> correct, or have I missed something?
> 
> Alternately, if I included a GPS receiver in the design, the whole process
> could be done within the device, which would probably be the easiest
> approach to calibration for the person building one.  This would increase
> the cost and make the device larger, but users could then maintain
> calibration by periodically keeping them plugged in for a few hours.  Or,
> perhaps I could just design a 2nd board for a GPS "calibrator" module that
> could be plugged into the timecode generators to calibrate them.  Hmm...
> lots to think about.
> 
> Wayne
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Wayne Holder]

Again, thanks for all the great feedback and suggestions.

> Are you familiar with these devices which I just found this week?
> https://tentaclesync.com/products

Yes, that's one of the lower cost commercial units available.  Another is
the NanoLockiIt by Ambient
,
which is company that's been making timecode products for many years.
Compared to more traditional prices for timecode generators, these are
relatively inexpensive at about $300.  However you need at least two, or
more generators to be useful, so that adds up pretty fast for an amateur
videographer, or starving film school student.  In contrast,  BOM for the
design I'm working on is less than $30 (the TCVCXO being, by far, the
most expensive part.)

My plan is to also write a desktop application, probably in Java to make it
portable, that the person building the devices could use to perform the
initial calibration and also setup various options.  So, the NTP-based
solution is attractive in that it doesn't require any additional hardware.
I'm a Mac user so, after a bit of reading the NTP implementation on the
Mac, I tried a few experiments.  Typing "ntpq -p" in the terminal
app produced this response:

 remote   refid  st t when poll reach   delay   offset
jitter

==

*usdal2-ntp-001. .GPSs.   1 u  428 1024  377   51.1311.944
1.153

and typing  "ntpq -c rl" printed out:

associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,

version="ntpd 4.2.8p6@1.3265 Fri Feb  5 17:38:17 UTC 2016 (124.60.2~39)",

processor="x86_64", system="Darwin/16.7.0", leap=00, stratum=2,

precision=-20, rootdelay=51.131, rootdisp=34.160, refid=17.253.2.125,

reftime=de7ba9c1.937e5f86  Fri, Apr 13 2018 15:12:17.576,

clock=de7badf7.39f8d36a  Fri, Apr 13 2018 15:30:15.226, peer=7077, tc=10,

mintc=3, offset=1.944153, frequency=25.163, sys_jitter=0.00,

clk_jitter=0.745, clk_wander=0.001

I believe that the "precision" of -20 value on the 4th line is supposed to
be interpreted as 2^-20 seconds which, if my math is correct, works out to
be a precision of about 1 PPM. Is that correct?  If so, it would seem like
I should be able to use my system's internal clock to perform a "tweak" in
around 10,000 seconds, or a little less than 3 hours.  Does this seem
correct, or have I missed something?

Alternately, if I included a GPS receiver in the design, the whole process
could be done within the device, which would probably be the easiest
approach to calibration for the person building one.  This would increase
the cost and make the device larger, but users could then maintain
calibration by periodically keeping them plugged in for a few hours.  Or,
perhaps I could just design a 2nd board for a GPS "calibrator" module that
could be plugged into the timecode generators to calibrate them.  Hmm...
lots to think about.

Wayne
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Bob kb8tq]

Hi

If you have a GPS on your local lan, just use it for the calibration. There’s 
no need for NTP
to get involved.

If you are running NTP over a normal home setup going to the internet, then you 
will be doing
very well to get low ms with NTP. 

Going back to the original post, the request is for a method to calibrate a 
newly assembled board. 
Since we are talking about a generalized calibration procedure, simply saying 
“use NTP” without 
mentioning setting up a LAN / GPS NTP empire seems to be a bit misleading. That 
is a very 
unique system that the vast majority of the world would not be using. 

Bob

> On Apr 13, 2018, at 2:18 PM, David J Taylor via time-nuts 
>  wrote:
> 
> Hi
> 
> NTP will give you “millisecond" level accuracy / stability. If you want to 
> set an
> oscillator to 0.1 ppm, you will need to run for over 10,000 seconds. It is not
> uncommon to have things out in the 10 ms range. That would put you at
> 100,000 seconds. In more common units, a couple of hours to > 1 day
> would be needed.
> 
> Keep in mind, this is for a single observation. If you need to make three or 
> four
> tweaks to get things set, the numbers would go up a bit.
> 
> The earlier mentioned GPS approach with a $10 USB dongle would do it a *lot*
> faster. More or less, you could expect a bit better than a 1000:1 speed
> improvement.
> 
> Bob
> ==
> 
> With respect, NTP using a GPS/PPS clock can give tens of microseconds or 
> better, even on a Raspberry Pi.  For example:
> 
> http://www.satsignal.eu/mrtg/raspi1_ntp.html
> 
> (The slight downward slope back over time is an artefact of MRTG with small 
> integers.)
> 
> Cheers,
> Davis
> -- 
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-tay...@blueyonder.co.uk
> Twitter: @gm8arv 
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[David J Taylor via time-nuts]

Hi

NTP will give you “millisecond" level accuracy / stability. If you want to 
set an
oscillator to 0.1 ppm, you will need to run for over 10,000 seconds. It is 
not

uncommon to have things out in the 10 ms range. That would put you at
100,000 seconds. In more common units, a couple of hours to > 1 day
would be needed.

Keep in mind, this is for a single observation. If you need to make three or 
four

tweaks to get things set, the numbers would go up a bit.

The earlier mentioned GPS approach with a $10 USB dongle would do it a *lot*
faster. More or less, you could expect a bit better than a 1000:1 speed
improvement.

Bob
==

With respect, NTP using a GPS/PPS clock can give tens of microseconds or 
better, even on a Raspberry Pi.  For example:


 http://www.satsignal.eu/mrtg/raspi1_ntp.html

(The slight downward slope back over time is an artefact of MRTG with small 
integers.)


Cheers,
Davis
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Adrian Godwin]

Hi Wayne,

I didn't mean that you should use the PPS signal from a consumer GPS rx
(though you might do that). I was thinking that you'd instead track the
difference between TCXO-maintained time and GPS time over long periods -
weeks or months - and use those to adjust the TCXO.

This would only work if the TCXO was constantly maintaining a clock, which
I'd thought would be the case. If it's in a USB stick that might not be
true and so it wouldn't work as you wouldn't get the long baseline
measurement needed to compare with GPS time.

PCs are a bit of a problem. They may well have the sound chip on USB and
they also have a considerable amount of latency due to buffering in the DAC
and filtering. They're also, somewhat surprisingly, a pain in the neck for
application writing. They might have plenty of development tools, but
you'll find you have to constantly modify it to meet the current operating
system specs, produce Mac, Linux and Windows variants, multiple languages,
etc etc.  Unless you're in that business and can get some of that effort
back through sales, it's a mess.

-adrian




On Fri, Apr 13, 2018 at 3:30 AM, Wayne Holder 
wrote:

> 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
>  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
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Bob kb8tq]

Hi

NTP will give you “millisecond" level accuracy / stability. If you want to set 
an 
oscillator to 0.1 ppm, you will need to run for over 10,000 seconds. It is not 
uncommon to have things out in the 10 ms range. That would put you at 
100,000 seconds. In more common units, a couple of hours to > 1 day
would be needed. 

Keep in mind, this is for a single observation. If you need to make three or 
four
tweaks to get things set, the numbers would go up a bit. 

The earlier mentioned GPS approach with a $10 USB dongle would do it a *lot*
faster. More or less, you could expect a bit better than a 1000:1 speed 
improvement. 

Bob

> On Apr 12, 2018, at 10:30 PM, Wayne Holder  wrote:
> 
> 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
>  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
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [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
 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
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Adrian Godwin]

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 
wrote:

> On Tue, April 10, 2018 8:12 pm, Bob kb8tq wrote:
> > 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.
>
> 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
>
>
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Chris Caudle]

On Tue, April 10, 2018 8:12 pm, Bob kb8tq wrote:
> 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.

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


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Chris Caudle]

On Tue, April 10, 2018 6:10 pm, Wayne Holder wrote:
> which is spec'd at a frequency tolerance or +/- 1 PPM and a frequency
> stability of 0.28 PPM and a yearly aging of +/- 1 PPM max/year which, to
> me, seems pretty impressive for a part that costs about $8.

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.

> I've been pondering how someone building the device
> would be able to easily and reliably calibrate it.

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.

> I'm basing the design around the Arduino, so the device could, in theory,
> use the USB Serial connection as a way to connect to a calibration program
> running on a PC.  I have a few idea on how to attempt to do this, but this
> is new territory for me, so I'm asking for advice and/or thoughts on how
> feasible this might be.  Is this a crazy, impractical idea given that all
> the builder will probably have available to perform the calibration is a
> regular PC and an Internet connection, or is there a way to make it work?

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


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Bob kb8tq]

Hi

On a TCXO a proper 12 bit DAC should do fine. The “don’t use for DC” DAC’s
that are built in to a MCU …. who knows. At DC they probably aren’t 12 bits 
anyway. 

If the TCXO is rated to age < 1 ppm per year and has a 10 ppm EFC (yes you 
*could* wonder about that combo) the DAC would need to drift 10% per year to 
match the rating on the oscillator. That’s a pretty horrid DAC. 

If the TCXO is rated for 0.1 ppm in the first year, that’s a mighty tight TCXO. 
The
DAC now needs to do 1% per year. Even the MCU parts *should* get to that level.

The same basic logic applies to temperature. If your TCXO claims 0.1 ppm from 
-30 to +70, best to check it. Even so, the DAC is still at the 1% point and 
likely 
does an adequate job. 

Bottom line - TCXO’s aren’t OCXO’s. They are a bit easier to deal with unless 
you
happen to have one of the exotic ones. If you do have an exotic TCXO you likely
paid more for it than an OCXO and thus know why you did so ….

We are not talking about disciplining the oscillator. We’re just taking about 
putting
it on frequency after it has been built into a system. In the case of 
disciplining, a lot
of things come into play. In the case of one time set to frequency, once you 
get past 
the likely drift over a few weeks …. why bother? 

Bob

> On Apr 11, 2018, at 5:09 AM, Hal Murray  wrote:
> 
> 
> wayne.hol...@gmail.com said:
>> Since the TCVCXO includes a voltage control input, my plan is to also add a
>> 12-Bit Digital-to-Analog Converter ...
> 
> What's the temperature stability of the D/A?
> 
> How does that compare with a 10 turn pot?  I remember a comment about pots 
> aging.  It was somewhat recently.  I don't remember the details.  I think it 
> was something like the wiper wore a small groove which made it hard to make 
> tiny adjustments.  I don't know how long it takes for the groove to form.
> 
> A possible option is to just measure the osc and do the adjustment in 
> software.
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Hal Murray]

wayne.hol...@gmail.com said:
> Since the TCVCXO includes a voltage control input, my plan is to also add a
> 12-Bit Digital-to-Analog Converter ...

What's the temperature stability of the D/A?

How does that compare with a 10 turn pot?  I remember a comment about pots 
aging.  It was somewhat recently.  I don't remember the details.  I think it 
was something like the wiper wore a small groove which made it hard to make 
tiny adjustments.  I don't know how long it takes for the groove to form.

A possible option is to just measure the osc and do the adjustment in 
software.


-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[ed breya]

If it's just to set for the initial setup or aging, just do it the 
old-fashioned way, with a trimmer pot to run the Vt - simple, easy to 
program, and it remembers the setting.

Ed
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TCVCXO Adjustment

[Bob kb8tq]

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 Apr 10, 2018, at 7:10 PM, Wayne Holder  wrote:
> 
> I'm designing a small, portable, SMPTE LTC Timecode Generator
>  as an open source/hardware
> project for amateur filmmakers and videographers.  LTC Timecode is
> typically recorded on the audio tracks of cameras and sound recorders so
> the video and sound comments can be automatically sync'd later.  I'm
> planing on using a small, SMD TCVCXO such as the LFTVXO075806Cutt
> ,
> which is spec'd at a frequency tolerance or +/- 1 PPM and a frequency
> stability of 0.28 PPM and a yearly aging of +/- 1 PPM max/year which, to
> me, seems pretty impressive for a part that costs about $8.
> 
> Since the TCVCXO includes a voltage control input, my plan is to also add
> a 12-Bit Digital-to-Analog Converter with EEPROM Memory, such as the
> Microchip MCP4725
> 
> to
> provide a way to initially check and calibrate the frequency after surface
> mount soldering and also later to compensate for aging.  But since this is
> intended as an open source/hardware project rather than a commercially
> manufactured one, I've been pondering how someone building the device would
> be able to easily and reliably calibrate it.
> 
> I'm basing the design around the Arduino, so the device could, in theory,
> use the USB Serial connection as a way to connect to a calibration program
> running on a PC.  I have a few idea on how to attempt to do this, but this
> is new territory for me, so I'm asking for advice and/or thoughts on how
> feasible this might be.  Is this a crazy, impractical idea given that all
> the builder will probably have available to perform the calibration is a
> regular PC and an Internet connection, or is there a way to make it work?
> 
> Wayne
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] TCVCXO Adjustment

[Wayne Holder]

I'm designing a small, portable, SMPTE LTC Timecode Generator
 as an open source/hardware
project for amateur filmmakers and videographers.  LTC Timecode is
typically recorded on the audio tracks of cameras and sound recorders so
the video and sound comments can be automatically sync'd later.  I'm
planing on using a small, SMD TCVCXO such as the LFTVXO075806Cutt
,
which is spec'd at a frequency tolerance or +/- 1 PPM and a frequency
stability of 0.28 PPM and a yearly aging of +/- 1 PPM max/year which, to
me, seems pretty impressive for a part that costs about $8.

Since the TCVCXO includes a voltage control input, my plan is to also add
a 12-Bit Digital-to-Analog Converter with EEPROM Memory, such as the
Microchip MCP4725

to
provide a way to initially check and calibrate the frequency after surface
mount soldering and also later to compensate for aging.  But since this is
intended as an open source/hardware project rather than a commercially
manufactured one, I've been pondering how someone building the device would
be able to easily and reliably calibrate it.

I'm basing the design around the Arduino, so the device could, in theory,
use the USB Serial connection as a way to connect to a calibration program
running on a PC.  I have a few idea on how to attempt to do this, but this
is new territory for me, so I'm asking for advice and/or thoughts on how
feasible this might be.  Is this a crazy, impractical idea given that all
the builder will probably have available to perform the calibration is a
regular PC and an Internet connection, or is there a way to make it work?

Wayne
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.