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 

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 

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 

Re: [time-nuts] femtosecond jitter

[John Larkin]

Hi, Magnus,

We did a little PC board that has two Analog Devices CML comparators 
that feed the flop.


  https://www.dropbox.com/s/05ti1c57eush0uq/99S394A.pdf?dl=0

An external DAC tweaks the VBIAS voltage to slew the edge times across 
one another, and an external ADC looks at the averaged flop outputs. The 
jitter noise floor is probably dominated by the test signals, not the 
flop under test. We considered something like a micrometer-driven 
differential trombone line... note that 1 fs is one PPM of a nanosecond, 
how far light travels in 12 micro-inches.


The quantization is probably DAC resolution. The step function is just 
the integral of the histogram.


This is going into a test set that needs maybe 1 ps RMS noise floor, so 
this flop is hugely better than what we need. It's a big deal to set 
this up, so I don't think we'll do any more measurements.


As a bang-bang phase detector, with some lowpass filtering in the loop, 
this flop would have a noise floor in the attosecond range. You're 
right, temperature will dominate low-frequency noise, and not just in 
the flop.


John


On 4/14/2018 5:59 AM, Magnus Danielson wrote:

John,

How where these measurements done?
Also, it looks like you have a systematic component in there, about 80
fs guestimating from the plot creating essentially two tracks up the
slope that is the tell-tale of a sinuoid phase modulation of some source.

Considering the temperature stability that you nicely plotted as a
quadratic shape, it seems like a good thermal stability is needed, which
comes as no big chock.

Can do you do a longer measurement and accumulate the data in a
2D-histogram fashion? That is count occurrences for the amplitude/time
position and then color code it accordingly? That have proved to be a
good tool for analysis.

Cheers,
Magnus

On 04/13/2018 05:54 PM, John Larkin wrote:

If you walk the differential data and clock inputs of an NB7V52  CML
flipflop across one another in time, the equivalent jitter is below 20
fs RMS. That's what we're measuring, but our test rig may well dominate
the jitter, so the flop is probably better.

We're using this to test the jitter of some of our timing products, with
1/10 the noise floor and 1e-4 times the cost of other ways to do it.

https://www.dropbox.com/s/1i2yz7otty94o9l/NB7_Jitter_1.jpg?raw=1

https://www.dropbox.com/s/qahpb8uh1xr53vj/NB7_Steps.jpg?raw=1

https://www.dropbox.com/s/tpphhi79yxgzy34/NB7_tc.jpg?raw=1



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



--
** arb

John Larkin, President
Highland Technology, Inc
18 Otis Street
San Francisco, CA 94103

phone 415 551-1700   fax 551-5129
jjlar...@highlandtechnology.com
http://www.highlandtechnology.com

This is a Highland Technology confidential communication

___
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] Spectracom Netclock 2 (cannot enter date time manually)

[D. Resor]

I know this should be as simple as reading the manual however...

 

I am using Tera Term with a PC laptop connected from serial port to serial
port:

 

VT100

9600 Baud

Data: 8 bit

Parity: None

Stop: 1 bit

Flow control: none

 

 

The cable is a DB9 to DB9 "Straight Through" Serial Cable of 6.6 ft length
(New pre-made cable).

 

Dip Switch 4 which allows manual setting of the Netclock 2 is enabled (on).

 

It updates the Tera Term window every second in Format 1 (which is the same
as the rotary switch setting) with its current Day, Date, Month, Year as if
the (T)ime command is being issued again and again.

 

It ignores any and all commands found in the manual.

 

I'm at a loss.

 

Donald R. Resor Jr. T. W. & T. C. Svc. Co.

http://hammondorganservice.com
Hammond USA warranty service
"Most people don't have a sense of humor. They think they do, but they
don't." --Jonathan Winters

 

___
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] femtosecond jitter

[Attila Kinali]

On Fri, 13 Apr 2018 08:54:41 -0700
John Larkin  wrote:

> If you walk the differential data and clock inputs of an NB7V52  CML 
> flipflop across one another in time, the equivalent jitter is below 20 
> fs RMS. That's what we're measuring, but our test rig may well dominate 
> the jitter, so the flop is probably better.

I heard similar numbers for the NB7V52 last week at EFTF. So you
cannot be that far off.

Attila Kinali

-- 
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
___
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] femtosecond jitter

[Magnus Danielson]

John,

How where these measurements done?
Also, it looks like you have a systematic component in there, about 80
fs guestimating from the plot creating essentially two tracks up the
slope that is the tell-tale of a sinuoid phase modulation of some source.

Considering the temperature stability that you nicely plotted as a
quadratic shape, it seems like a good thermal stability is needed, which
comes as no big chock.

Can do you do a longer measurement and accumulate the data in a
2D-histogram fashion? That is count occurrences for the amplitude/time
position and then color code it accordingly? That have proved to be a
good tool for analysis.

Cheers,
Magnus

On 04/13/2018 05:54 PM, John Larkin wrote:
> If you walk the differential data and clock inputs of an NB7V52  CML
> flipflop across one another in time, the equivalent jitter is below 20
> fs RMS. That's what we're measuring, but our test rig may well dominate
> the jitter, so the flop is probably better.
> 
> We're using this to test the jitter of some of our timing products, with
> 1/10 the noise floor and 1e-4 times the cost of other ways to do it.
> 
> https://www.dropbox.com/s/1i2yz7otty94o9l/NB7_Jitter_1.jpg?raw=1
> 
> https://www.dropbox.com/s/qahpb8uh1xr53vj/NB7_Steps.jpg?raw=1
> 
> https://www.dropbox.com/s/tpphhi79yxgzy34/NB7_tc.jpg?raw=1
> 
> 
___
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.
>> 
> 

Re: [time-nuts] getting accurate timing on RTL-SDR output

[Magnus Danielson]

Hi Jim,

> That's the sort of strategy I'm looking at.. find a set of samples where
> the transient occurs, zero pad it out (so that when I do peak picking
> later, I've effectively got interpolation), then run the correlation

You find it using cross-correlation, and once found, you have a fair
idea for the next round where it is so a shorter cross-correlation can
be used if processing is relevat.

> ifft(fft(a).*conj(fft(b))) in matlab

After that, search through for the highest amplitude, which is a linear
search.

The trick of using a reference is that the conj and fft can be done as
common processing and then only the fft, multiply and ifft needs to be
done for each other channel. This removes 1/3 of the needed FFTs.

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

[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] Pulsars, clocks, and time nuts (Jim Palfreyman)

[Achim Gratz]

Bill Hawkins writes:
> It seems that pulsars are rotating stellar objects that have no reason
> to change their rotation, except to decay.

The whole point of that exercise was to determine which of the theories
that predict what the internal structure of a neutron star looks like is
more likely to be correct.  Here's a not too long and not too dense (pun
intended) writeup:

https://arstechnica.com/science/2018/04/neutron-star-glitch-hints-at-superfluid-beneath-its-crust/

> Ruling out causes from the stellar object,

You've taken a wrong turn right there.  The timing variations that were
measured are (most likely) produced by the stellar object.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
___
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] getting accurate timing on RTL-SDR output

[Achim Gratz]

jimlux writes:
>> A maybe not-so obvious approach would be to use RTL-SDR that have been
>> modified for direct sampling (usually via the Q branch) and inject your
>> timing pulse there.  That would limit the disturbance of the actual
>> signal while still relatively easy to extract from the data stream.
>
> That's where it's being injected.. I'm using the RTL-SDR V.3, which
> has the RF input fed right to the Q input.

OK, some more details (I did say it was a bit non-obvious :-) on that
idea.  The R820T tuner in the RTL-SDR v3 only uses the I input of the
RTL2832U as it's a low-IF architecture, leaving the Q inputs free and
unused in the normal mode of operation, which the direct sampling
modification takes advantage of by populating the Q branch with a direct
input.  The other commonly used tuner, the Elonics E4000, uses both
inputs, because it's using a zero IF architecture.  Thus it should be
possible to switch the RTL dongle to zero IF mode, get the I/Q samples
as per normal and you get two perfectly correlated data streams from two
different inputs.  You can modify the hardware to also have a direct
input on the I branch normally used by the tuner.  Alternatively, don't
modify the hardware and use the tuner to downconvert an RF sync signal
to the I branch (you can test if that works by just using it in direct
sampling mode with the I branch selected, but I think the tuner might
get switched off by the rtlsdr library, so there'd need to be some
modifications to the software).

http://datasheetcafe.databank.netdna-cdn.com/wp-content/uploads/2015/09/RTL2832U.pdf
https://www.reddit.com/r/RTLSDR/comments/1uazsw/rtl2832_datasheet_deep_info/

Also, the RTL-SDR v3 does have a clock input, so you can modify the
hardware to use that and make its sampling coherent to a known clock
source.  That would allow you to align the sampling files only
sporadically and then rely on the known relation to the clock as long as
no USB frames are getting dropped.

https://www.rtl-sdr.com/rtl-sdr-blog-v-3-dongles-user-guide/

No, I haven't done anything of that yet, but what initially got me
interested is the idea of correlating DCF77 (through an upconverter)
with GPS.  Still working on the antenna setup, it might be possible to
also receive TDF, MSF and maybe even RBU.  I did get as far as buying a
GPS timing module with a frequency output that I can use for the
external clocking to eventually get coherent sampling.

>> Not all of these are created equal.  Several manufacturers claim to
>> factory calibrate their TCXO to better than 0.5ppm.  I have currently
>> two RTL-SDR that certainly are within 1ppm.  These things get quite hot,
>> so it definitely takes some time before they stabilize even if they do
>> have a TCXO in them.
>
> Could well be.. I just turned it on, waited for the beagle to boot,
> captured the data, and moved on.

My RTL-SDR v3 is still in transit, but I expect your result to indicate
that it was still warming up based on what my other RTL based dongles
do.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
___
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] Pulsars, clocks, and time nuts (Jim Palfreyman)

[Dana Whitlow]

According to my book, each magnetic pole of some pulsars is more
like a rotating circular array of sub-poles, where the direction of induced
radiation varies from sub-pole posetion to sub-pole position.  And only a
small range of sub-pole positions out of the group happens to point in
the direction of the Earth.

A reason for a general slowdown is energy lost to the radiation.  But
the glitches, in the case of the Vela pulsar at least, involve steps upward
in spin rate, although nowhere near enough to cancel the overall
slowing trend.  The authors of "Introduction to Radio Astronomy" do a
much better job of explaining the sawtooth effect than my clumsy attempt.

Robert L. Forward, I suspect.

Dana


On Sat, Apr 14, 2018 at 12:04 AM, Bill Hawkins  wrote:

> It seems that pulsars are rotating stellar objects that have no reason
> to change their rotation, except to decay.
> Ruling out causes from the stellar object, one is left with things that
> might be orbiting the object and their ability to absorb the pulse that
> is aimed at us. One could move further out to the extremely low
> probability that some interstellar object absorbed the pulse. This
> doesn't explain the sawtooth, unless one of those orbiting bodies is
> affecting the rotation rate of the pulsar, such as a binary star.
>
> Disclaimer: I know very little about radio astronomy, but I've read a
> lot of hard science fiction.
>
> Bill Hawkins
>
>
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Dana
> Whitlow
> Sent: Friday, April 13, 2018 8:39 AM
> To: Tom Van Baak; Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] Pulsars, clocks, and time nuts (Jim Palfreyman)
>
> Tom's discussion about pulsars brought back some memories...
>
> Many pulsars exhibit skipped pulses.  And one curiosity that I didn't
> see mentioned in Tom's discussion is that some pulsars even exhibit
> behavior reminiscent of the "sawtooth jitter" so evident in the PPS
> outputs of most GPS receivers.  See figures 12-11 & 12-12 in "An
> Introduction to Radio Astronomy" (2nd edition) by Burke and
> Graham-Smith.  The first ed also contains the basic plot (as figure 12-8
> in this case), but whose explanation is not as up-to-date).
>
> For a deeper treatment of pulsars, also see
>   https://www.cv.nrao.edu/course/astr534/PDFnew.shtml
> by Condon and Ransom (both of NRAO).
>
> The above two references are the best Radio Astronomy tomes I've yet
> seen..
>
> Pulsar timing has been (and still is) a very big deal in radio
> astronomy, as it is key to verification of certain points of Einstein's
> General Theory of Relativity.
>
> Here are two web sites in which audio recordings of various pulsar
> sounds (made with larger radio telescopes) are presented.
>
> https://www.youtube.com/watch?v=uHEVo-LkDrQ
> (You may ignore the video part, even though it's "cute", but the audio
> portion is a fine example of the pulse to pulse variations exhibited by
> many pulsars, all wrapped up in one pulsar)
>
> http://www.jb.man.ac.uk/pulsar/Education/Sounds/0329_stack.mp4
> (I think this is the best overall site, giving quality recordings of a
> fair number of different pulsars)
>
> Dana
>
>
>
>
>
>
> On Fri, Apr 13, 2018 at 2:54 AM, Tom Van Baak 
> wrote:
>
> > Amazing news... 1.2.3.
> >
> > 1) Many of you know that pulsars are weird astronomical sources of
> > periodic signals. Some are so accurate that they rival atomic clocks
> > for stability! True, but I don't have a 100 foot antenna at home so
> > I'll take their word for it. Plus, you have to account for a myriad of
>
> > PhD-level
> > corrections: from earth's rotation to general relativity. And, like
> > quartz or rubidium clocks, pulsars drift (as they gradually slow
> > down). Precision timing is not easy. If you poke around the web you
> > can find numerous articles describing their detection and measurement
> > and exploring their use as reference clocks, both here and potentially
> for deep-space timekeeping.
> >
> > 2) If you do a lot of clock measurement at home then you know the dark
>
> > side of working with precision clocks. There are signal quality
> > issues, measurement resolution issues, reference stability
> > limitations, offset, drift, phase jumps, frequency jumps, missed or
> extra cycles, glitches, etc.
> > For example, quartz oscillators (depending on make / model / luck) can
>
> > exhibit frequency jumps; i.e., without warning they just change
> > frequency without your permission. Ok, maybe not by a lot, but enough
> > to notice; perhaps enough to cause trouble to any naive GPSDO PID
> > algorithm that assumes steady state from the oscillator you thought
> was stable.
> >
> > 3) Now the exciting part! Fellow time-nut Jim Palfreyman studies
> pulsars.
> > You've seen postings from him now and then over the years. It turns
> > out Jim is the first person to catch a pulsar in the act of a
> > 

Re: [time-nuts] Pulsars, clocks, and time nuts (Jim Palfreyman)

[Bill Hawkins]

It seems that pulsars are rotating stellar objects that have no reason
to change their rotation, except to decay.
Ruling out causes from the stellar object, one is left with things that
might be orbiting the object and their ability to absorb the pulse that
is aimed at us. One could move further out to the extremely low
probability that some interstellar object absorbed the pulse. This
doesn't explain the sawtooth, unless one of those orbiting bodies is
affecting the rotation rate of the pulsar, such as a binary star.

Disclaimer: I know very little about radio astronomy, but I've read a
lot of hard science fiction.

Bill Hawkins


-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Dana
Whitlow
Sent: Friday, April 13, 2018 8:39 AM
To: Tom Van Baak; Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Pulsars, clocks, and time nuts (Jim Palfreyman)

Tom's discussion about pulsars brought back some memories...

Many pulsars exhibit skipped pulses.  And one curiosity that I didn't
see mentioned in Tom's discussion is that some pulsars even exhibit
behavior reminiscent of the "sawtooth jitter" so evident in the PPS
outputs of most GPS receivers.  See figures 12-11 & 12-12 in "An
Introduction to Radio Astronomy" (2nd edition) by Burke and
Graham-Smith.  The first ed also contains the basic plot (as figure 12-8
in this case), but whose explanation is not as up-to-date).

For a deeper treatment of pulsars, also see
  https://www.cv.nrao.edu/course/astr534/PDFnew.shtml
by Condon and Ransom (both of NRAO).

The above two references are the best Radio Astronomy tomes I've yet
seen..

Pulsar timing has been (and still is) a very big deal in radio
astronomy, as it is key to verification of certain points of Einstein's
General Theory of Relativity.

Here are two web sites in which audio recordings of various pulsar
sounds (made with larger radio telescopes) are presented.

https://www.youtube.com/watch?v=uHEVo-LkDrQ
(You may ignore the video part, even though it's "cute", but the audio
portion is a fine example of the pulse to pulse variations exhibited by
many pulsars, all wrapped up in one pulsar)

http://www.jb.man.ac.uk/pulsar/Education/Sounds/0329_stack.mp4
(I think this is the best overall site, giving quality recordings of a
fair number of different pulsars)

Dana






On Fri, Apr 13, 2018 at 2:54 AM, Tom Van Baak 
wrote:

> Amazing news... 1.2.3.
>
> 1) Many of you know that pulsars are weird astronomical sources of 
> periodic signals. Some are so accurate that they rival atomic clocks 
> for stability! True, but I don't have a 100 foot antenna at home so 
> I'll take their word for it. Plus, you have to account for a myriad of

> PhD-level
> corrections: from earth's rotation to general relativity. And, like 
> quartz or rubidium clocks, pulsars drift (as they gradually slow 
> down). Precision timing is not easy. If you poke around the web you 
> can find numerous articles describing their detection and measurement 
> and exploring their use as reference clocks, both here and potentially
for deep-space timekeeping.
>
> 2) If you do a lot of clock measurement at home then you know the dark

> side of working with precision clocks. There are signal quality 
> issues, measurement resolution issues, reference stability 
> limitations, offset, drift, phase jumps, frequency jumps, missed or
extra cycles, glitches, etc.
> For example, quartz oscillators (depending on make / model / luck) can

> exhibit frequency jumps; i.e., without warning they just change 
> frequency without your permission. Ok, maybe not by a lot, but enough 
> to notice; perhaps enough to cause trouble to any naive GPSDO PID 
> algorithm that assumes steady state from the oscillator you thought
was stable.
>
> 3) Now the exciting part! Fellow time-nut Jim Palfreyman studies
pulsars.
> You've seen postings from him now and then over the years. It turns 
> out Jim is the first person to catch a pulsar in the act of a 
> frequency jump. After
> 3 years of continuous searching! This is really cool. Just amazing. 
> You can't get more time nutty than this. And it just got published in
Nature.
> It's a perfect never-give-up, i-eat-nanoseconds-for-breakfast, time 
> nut thing to do. I am so impressed.
>
> To quote Jim:
>
> On December 12, 2016, at approximately 9:36pm at night, my phone
> goes off with a text message telling me that Vela had glitched.
The
> automated process I had set up wasn't completely reliable - radio
> frequency interference (RFI) had been known to set it off in
error.
>
> So sceptically I logged in, and ran the test again. It was
genuine!
> The excitement was incredible and I stayed up all night analysing 
> the data.
>
> What surfaced was quite surprising and not what was expected.
Right
> as the glitch occurred, the pulsar missed a beat. It didn't pulse.
>
> Here is a very readable description of his 

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.