Re: [time-nuts] Phase noise from Allan Deviation ?

2015-12-18 Thread Tom McDermott
An initial gnuradio GRC flowgraph for measuring Time Intervals, and
dumping raw binary to a file is now on github.  There are two helper
Python files: one to convert from binary to floating-point-ASCII-text,
and another to take that from raw measurements to Time-Intervals.

That file can be sent straight into TVB's ADEV.C program.

The TEXT-to-TimeInterval python program pretty aggressively defines
outliers and throws them out.  This is due to a bug in the particular SDR
being used which seems to insert random large glitches into the 1-Hertz
output.

The flowgraph and python code are quite simple, undoubtly one would
want to tweak it.

I've measured an external disciplined signal input to the SDR running on
it's internal crystal oscillator, and another measurement of a GPSDO that
is both the external clock reference for the SDR and simultaneously the
unknown.
The purpose is this later is to characgterize what the background ADEV
looks like.
The GPSDO compared to itself is of course a lot better and pretty straight
as 1/tau
for an hour or so becausue it's just measuring anything bad the SDR does to
it.

https://github.com/Tom-McDermott/SDR-time-interval

-- Tom, N5EG



On Mon, Dec 14, 2015 at 10:01 PM, Tom McDermott  wrote:

> Hi Iain,
>
> I'll publish a flowgraph soon.  I built a Out-Of-Tree module to decimate
> the output
> down to one sample per reading to keep the output file small for even long
> runs.
> On the order of about 48000:! decimation.  Strange thing is - it works
> when the
> QT Time Sink is enabled, but gives very wrong outputs when the QT Time Sink
> is Disabled (the only change).
>
> So I suspect my custom OOT is doing something wrong, but not sure why
> enabling/disabling the scope display changes the gnuradio behavior so much.
> I'd like to get more to the bottom of this before publishing the code.
>
> Have done some short runs throwing 48,000 samples/sec to the output file,
> then post
> processing that in Python, and it gives the same results as my OOT module
> when the
> QT GUI is showing.  Very strange, but the data file is much too verbose:
> 700 Megabytes/hour.
>
> -- Tom, N5EG
>
>
>
> On Mon, Dec 14, 2015 at 1:15 AM, Iain Young  wrote:
>
>> Hi Tom,
>>
>> On 14/12/15 03:15, You wrote:
>>
>> I've constructed a homebrew setup to measure time intervals using a
>>> software defined radio.  Basically a single-channel downconversion to
>>> about one hertz, then count samples from the SDR clock to time stamp
>>> the zero crossings.  This is done in gnuradio and saved to a file for
>>> post processing. The resolution is theoretically good, but the accuracy
>>> is unknown.
>>>
>>
>> Very interesting. Would you consider making your flowgraph available ?
>>
>> I have done similar things with just thresholding and looking for the
>> start of second (or minute) marker of various distant radio clocks, and
>> then graphing how far apart they were, as well as feeding NTP.
>>
>>
>> 73s
>>
>> Iain
>>
>>
>> ___
>> 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] Phase noise from Allan Deviation ?

2015-12-15 Thread Tom McDermott
Hi Iain,

I'll publish a flowgraph soon.  I built a Out-Of-Tree module to decimate
the output
down to one sample per reading to keep the output file small for even long
runs.
On the order of about 48000:! decimation.  Strange thing is - it works when
the
QT Time Sink is enabled, but gives very wrong outputs when the QT Time Sink
is Disabled (the only change).

So I suspect my custom OOT is doing something wrong, but not sure why
enabling/disabling the scope display changes the gnuradio behavior so much.
I'd like to get more to the bottom of this before publishing the code.

Have done some short runs throwing 48,000 samples/sec to the output file,
then post
processing that in Python, and it gives the same results as my OOT module
when the
QT GUI is showing.  Very strange, but the data file is much too verbose:
700 Megabytes/hour.

-- Tom, N5EG



On Mon, Dec 14, 2015 at 1:15 AM, Iain Young  wrote:

> Hi Tom,
>
> On 14/12/15 03:15, You wrote:
>
> I've constructed a homebrew setup to measure time intervals using a
>> software defined radio.  Basically a single-channel downconversion to
>> about one hertz, then count samples from the SDR clock to time stamp
>> the zero crossings.  This is done in gnuradio and saved to a file for
>> post processing. The resolution is theoretically good, but the accuracy
>> is unknown.
>>
>
> Very interesting. Would you consider making your flowgraph available ?
>
> I have done similar things with just thresholding and looking for the
> start of second (or minute) marker of various distant radio clocks, and
> then graphing how far apart they were, as well as feeding NTP.
>
>
> 73s
>
> Iain
>
>
> ___
> 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] Phase noise from Allan Deviation ?

2015-12-14 Thread Bob Camp
Hi

ADEV to phase noise can be full of gotcha’s. What you have out of your 
system is a series of phase samples. You don’t *have* to convert those 
samples to ADEV. There are a whole bunch different variances you can 
calculate. The best thing to do (by far) is to save the phase samples. That
way you can post process them with whatever variance you happen to be
interested in. 

As an example, you may find that modified ADEV and Hadamard help you
sort out various noise processes. There also is the option of doing an FFT on
the phase samples.  

Bob


> On Dec 13, 2015, at 10:15 PM, Tom McDermott  wrote:
> 
> I've constructed a homebrew setup to measure time intervals using a
> software defined radio.  Basically a single-channel downconversion to
> about one hertz, then count samples from the SDR clock to time stamp
> the zero crossings.  This is done in gnuradio and saved to a file for
> post processing. The resolution is theoretically good, but the accuracy
> is unknown.
> 
> The result produces ADEV vs. Tau charts with reasonably sane looking
> results.
> The 'unknown' is a Rubidium oscillator locked to CDMA pilot (TS2700),
> and the internal crystal oscillator in the SDR radio as the reference.
> Thus, ADEV probably is mostly measuring that internal crystal rather than
> the TS2700.  Later on a GPSDO will be tried as the reference clock to
> see if the Adev results are better.
> 
> It brings up a question:  Is it possible to estimate the phase noise of that
> internal crystal from the ADEV measurements?  There are a bunch of
> papers that go the other way:  from Phase Noise to Adev.   Searching
> brings up only one paper that goes from ADEV to Phase Noise but it's text
> does not seem to be readily available.  It apparently models the oscillator
> as a couple of well known error models.
> 
> -- Tom, N5EG
> ___
> 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] Phase noise from Allan Deviation ?

2015-12-14 Thread Mark Spencer
Yes.   I was not overly pleased with the performance of my 2700's.   I ended up 
pulling the PRS10 out of one of them and purchased the breakout connector board 
from SRS and used the resulting 10 MHz and 1 PPS outputs.From time to time 
I would sync the unit to one of my GPSDO's using the 1 PPS input.

I haven't powered up my 2700's in several years.


Your mileage may vary.


> On Dec 14, 2015, at 1:10 PM, Bob Camp  wrote:
> 
> Hi
> 
> One of the reasons the TS2700’s went out of favor is the “quality” of the 
> CDMA signals 
> available. The design assumption was that the CDMA carriers provided timing 
> as good 
> as GPS on their over the air systems. After the units had been in the field 
> for a while it
> became apparent that the 2700’s were not performing up to expectations. 
> Further investigation
> turned up a range of issues that degraded the CDMA timing relative to GPS. A 
> lot of it 
> boiled down to “we are a phone service not a time service”.  System wise, 
> CDMA gets 
> into trouble at the 10us level. GPS is in trouble at the 100 ns level….
> 
> Yes there are all sorts of rules and regulations. In the end it’s “this works 
> fine” that trumps
> a lot of them. 
> 
> Bob
> 
>> On Dec 14, 2015, at 1:15 PM, Charles Steinmetz  wrote:
>> 
>> Tom wrote:
>> 
>>> The 'unknown' is a Rubidium oscillator locked to CDMA pilot (TS2700)
>> 
>> There is very little information publicly available on the Symmetricom 
>> "BesTime" engine ("BTE"), but after playing with a few TS2700s for quite 
>> some time, including monitoring a number of internal signals, several things 
>> became apparent.  First, the 2700 does not seem to discipline the PRS10.  
>> The rubidium runs open loop and the BTE keeps track of the offset and the 
>> drift rate from "BTE time" (which is synthesized from all available sources 
>> -- however many CDMA signals it is receiving, plus any wireline telco timing 
>> signals and the PRS10 -- using a proprietary algorithm to estimate the 
>> reliability of each source and outputting BTE time and frequency using DDS). 
>>  Hobby users won't be feeding the unit any telco timing signals, so the BTE 
>> has only the CDMA signals to work from.  During holdover (and assuming no 
>> telco timing signals), the Rb is the sole input to the BTE, which uses the 
>> stored offset and drift to calculate BTE time.
>> 
>> I found that the TS-2700 is more than an order of magnitude less stable than 
>> a Trimble Thunderbolt, even with a full complement of rock-solid CDMA 
>> sources.  This may vary somewhat, depending on the CDMA equipment in use at 
>> any particular location and the diligence of the CDMA operator.
>> 
>> Best regards,
>> 
>> Charles
>> 
>> 
>> ___
>> 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] Phase noise from Allan Deviation ?

2015-12-14 Thread Magnus Danielson

Rick,

On 12/14/2015 07:04 AM, Richard (Rick) Karlquist wrote:

On 12/13/2015 7:15 PM, Tom McDermott wrote:


It brings up a question:  Is it possible to estimate the phase noise
of that
internal crystal from the ADEV measurements?  There are a bunch of
papers that go the other way:  from Phase Noise to Adev.   Searching
brings up only one paper that goes from ADEV to Phase Noise but it's text
does not seem to be readily available.  It apparently models the
oscillator
as a couple of well known error models.

-- Tom, N5EG]


In general, you cannot determine phase noise from ADEV,
even though you can determine ADEV from phase noise.
This is just a mathematical reality.

Mike Fischer (of HP) presented papers at the 1977 and
1978 that show conversions between PN and ADEV for
individual noise processes, where each process has a
specific slope of amplitude vs frequency.  The only
time you can go from ADEV to PN is if you can isolate
a process.


1976 PTTI paper by Fischer:
http://tycho.usno.navy.mil/ptti/1976papers/Vol%2008_38.pdf

1977 PTTI paper by Chi (Fischer being adviser):
http://tycho.usno.navy.mil/ptti/1977papers/Vol%2009_34.pdf

1978 PTTI paper by Fischer:
http://tycho.usno.navy.mil/ptti/1978papers/Vol%2010_14.pdf

Things have happen since those papers, in many ways.


In the specific case of crystal oscillators, in general,
they follow a flicker noise of frequency process model
close to the carrier (within 100 Hz).  You can often
assume that ADEV is dominated by this process and therefore
translate it to an equivalent PN.  The way to tell if
ADEV is dominated by this process is that it will be
independent of tau, for tau of 0.1 sec or less.

On the IEEE UFFC site, there is a tutorial on crystal oscillator
design by Mike Driscoll (you don't have to be a member to
access it).  I believe this covers this topic.  You go
from ADEV to "frequency noise" and then to phase noise


http://www.ieee-uffc.org/frequency-control/learning/2003_IEEE_Tutorial.PDF

Other tutorials is at:
http://www.ieee-uffc.org/frequency-control/tutorials.asp

In particular, check out Francois Vernottes presentation:
http://www.ieee-uffc.org/frequency-control/learning/pdf/Vernotte-Varience_Measurements.pdf
He covers a lot of ground there, and in the end he also covers 
curve-fitting to estimate noise levels.



You can "practice" this calculation on any crystal oscillator
that has published ADEV and phase noise.   It is of course
extremely easy to screw it up :-)   What I have found
is that most crystal oscillators seem to obey the flicker
model.

I have been able to measure flicker noise on crystals that
were not installed in an oscillator, and then install them
in an oscillator and the ADEV turned out to be what
was predictable from the phase noise.  It really works!


Indeed. However, one has to be careful with ones methods, or one will 
not estimate the noise-levels properly. Regardless if you use the 
frequency method or time method, doing meterologically sound and 
traceable measurements remains a difficult task indeed.


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] Phase noise from Allan Deviation ?

2015-12-14 Thread Bob Camp
Hi

One of the reasons the TS2700’s went out of favor is the “quality” of the CDMA 
signals 
available. The design assumption was that the CDMA carriers provided timing as 
good 
as GPS on their over the air systems. After the units had been in the field for 
a while it
became apparent that the 2700’s were not performing up to expectations. Further 
investigation
turned up a range of issues that degraded the CDMA timing relative to GPS. A 
lot of it 
boiled down to “we are a phone service not a time service”.  System wise, CDMA 
gets 
into trouble at the 10us level. GPS is in trouble at the 100 ns level….

Yes there are all sorts of rules and regulations. In the end it’s “this works 
fine” that trumps
a lot of them. 

Bob

> On Dec 14, 2015, at 1:15 PM, Charles Steinmetz  wrote:
> 
> Tom wrote:
> 
>> The 'unknown' is a Rubidium oscillator locked to CDMA pilot (TS2700)
> 
> There is very little information publicly available on the Symmetricom 
> "BesTime" engine ("BTE"), but after playing with a few TS2700s for quite some 
> time, including monitoring a number of internal signals, several things 
> became apparent.  First, the 2700 does not seem to discipline the PRS10.  The 
> rubidium runs open loop and the BTE keeps track of the offset and the drift 
> rate from "BTE time" (which is synthesized from all available sources -- 
> however many CDMA signals it is receiving, plus any wireline telco timing 
> signals and the PRS10 -- using a proprietary algorithm to estimate the 
> reliability of each source and outputting BTE time and frequency using DDS).  
> Hobby users won't be feeding the unit any telco timing signals, so the BTE 
> has only the CDMA signals to work from.  During holdover (and assuming no 
> telco timing signals), the Rb is the sole input to the BTE, which uses the 
> stored offset and drift to calculate BTE time.
> 
> I found that the TS-2700 is more than an order of magnitude less stable than 
> a Trimble Thunderbolt, even with a full complement of rock-solid CDMA 
> sources.  This may vary somewhat, depending on the CDMA equipment in use at 
> any particular location and the diligence of the CDMA operator.
> 
> Best regards,
> 
> Charles
> 
> 
> ___
> 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] Phase noise from Allan Deviation ?

2015-12-14 Thread Richard (Rick) Karlquist

On 12/13/2015 7:15 PM, Tom McDermott wrote:


It brings up a question:  Is it possible to estimate the phase noise of that
internal crystal from the ADEV measurements?  There are a bunch of
papers that go the other way:  from Phase Noise to Adev.   Searching
brings up only one paper that goes from ADEV to Phase Noise but it's text
does not seem to be readily available.  It apparently models the oscillator
as a couple of well known error models.

-- Tom, N5EG]


In general, you cannot determine phase noise from ADEV,
even though you can determine ADEV from phase noise.
This is just a mathematical reality.

Mike Fischer (of HP) presented papers at the 1977 and
1978 that show conversions between PN and ADEV for
individual noise processes, where each process has a
specific slope of amplitude vs frequency.  The only
time you can go from ADEV to PN is if you can isolate
a process.

In the specific case of crystal oscillators, in general,
they follow a flicker noise of frequency process model
close to the carrier (within 100 Hz).  You can often
assume that ADEV is dominated by this process and therefore
translate it to an equivalent PN.  The way to tell if
ADEV is dominated by this process is that it will be
independent of tau, for tau of 0.1 sec or less.

On the IEEE UFFC site, there is a tutorial on crystal oscillator
design by Mike Driscoll (you don't have to be a member to
access it).  I believe this covers this topic.  You go
from ADEV to "frequency noise" and then to phase noise

You can "practice" this calculation on any crystal oscillator
that has published ADEV and phase noise.   It is of course
extremely easy to screw it up :-)   What I have found
is that most crystal oscillators seem to obey the flicker
model.

I have been able to measure flicker noise on crystals that
were not installed in an oscillator, and then install them
in an oscillator and the ADEV turned out to be what
was predictable from the phase noise.  It really works!

Rick Karlquist N6RK

___
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] Phase noise from Allan Deviation ?

2015-12-14 Thread Magnus Danielson

Tom,

On 12/14/2015 04:15 AM, Tom McDermott wrote:

I've constructed a homebrew setup to measure time intervals using a
software defined radio.  Basically a single-channel downconversion to
about one hertz, then count samples from the SDR clock to time stamp
the zero crossings.  This is done in gnuradio and saved to a file for
post processing. The resolution is theoretically good, but the accuracy
is unknown.

The result produces ADEV vs. Tau charts with reasonably sane looking
results.
The 'unknown' is a Rubidium oscillator locked to CDMA pilot (TS2700),
and the internal crystal oscillator in the SDR radio as the reference.
Thus, ADEV probably is mostly measuring that internal crystal rather than
the TS2700.  Later on a GPSDO will be tried as the reference clock to
see if the Adev results are better.


You will see the SDR clock noise, as it most likely will dominate.


It brings up a question:  Is it possible to estimate the phase noise of that
internal crystal from the ADEV measurements?  There are a bunch of
papers that go the other way:  from Phase Noise to Adev.   Searching
brings up only one paper that goes from ADEV to Phase Noise but it's text
does not seem to be readily available.  It apparently models the oscillator
as a couple of well known error models.


Yes.

Allan Deviation was invented in order to reliably estimate the strengths 
of the different noise-types and separate them. Today we can do this in 
the phase-noise domain, but that was hard to do in the 60thies so they 
had to use counters.


Look at the Allan Deviation wikipedia article, where I have included the 
formulas for various forms of noises and their ADEV curve. These are the 
formulas you need.


In order to separate white phase noise from flicker noise, ADEV isn't a 
good tool, so you need to use the MDEV instead. David Allan recommends 
MDEV for this purpose, as the lack of separation was nagging him and it 
took some additional 15 years before the problem was solved.


In order to estimate the noise levels, you do a curve fit of the AVAR or 
MVAR to the noise-slopes. I recommend the writings of Francois Vernotte. 
He has study the field and understood the matching process needed.


As always, remember that the system bandwidth B will be important to the 
estimation of the noise-level of a source. The sigma-counters for 
instance have much lower system bandwidth to reduce the white phase 
noise, but as you estimate you will can get the wrong estimated value 
unless you use the correct value. For omega-counters, Vernotte showed 
how the proper formulas to be used looks, great work there. The PDEV is 
so far the optimum processing-tool, but MDEV (which is easier to get 
right) is not far behind. No one using omega-counters can get the PDEV 
right to this day, but we are discussing how to correctly remedy that.


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] Phase noise from Allan Deviation ?

2015-12-14 Thread Iain Young

Hi Tom,

On 14/12/15 03:15, You wrote:


I've constructed a homebrew setup to measure time intervals using a
software defined radio.  Basically a single-channel downconversion to
about one hertz, then count samples from the SDR clock to time stamp
the zero crossings.  This is done in gnuradio and saved to a file for
post processing. The resolution is theoretically good, but the accuracy
is unknown.


Very interesting. Would you consider making your flowgraph available ?

I have done similar things with just thresholding and looking for the
start of second (or minute) marker of various distant radio clocks, and
then graphing how far apart they were, as well as feeding NTP.


73s

Iain

___
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] Phase noise from Allan Deviation ?

2015-12-14 Thread Anders Wallin
>From PN to ADEV you integrate under the PN-curve with a certain
weighting-function. This paper shows the weighting function:
https://www.researchgate.net/publication/6308454_Considerations_on_the_measurement_of_the_stability_of_oscillators_with_frequency_counters

to go the other way around you would indeed have to assume the shape of the
PN-curve, such as the Leeson model or similar. This is quite an assumption
and probably best avoided.

What you want to do is rather than mix down to 1Hz instead mix down to
maybe 1 kHz...200 kHz or so - stream all those phase-samples to the
computer, and compute the PN as the PSD of the phase data.
As an aside I've found that FFT (e.g. Stable32 uses this) sometimes gives
funny PSD results, and the Welch-method (periodogram) is more robust.

Anders


On Mon, Dec 14, 2015 at 5:15 AM, Tom McDermott  wrote:

> I've constructed a homebrew setup to measure time intervals using a
> software defined radio.  Basically a single-channel downconversion to
> about one hertz, then count samples from the SDR clock to time stamp
> the zero crossings.  This is done in gnuradio and saved to a file for
> post processing. The resolution is theoretically good, but the accuracy
> is unknown.
>
> The result produces ADEV vs. Tau charts with reasonably sane looking
> results.
> The 'unknown' is a Rubidium oscillator locked to CDMA pilot (TS2700),
> and the internal crystal oscillator in the SDR radio as the reference.
> Thus, ADEV probably is mostly measuring that internal crystal rather than
> the TS2700.  Later on a GPSDO will be tried as the reference clock to
> see if the Adev results are better.
>
> It brings up a question:  Is it possible to estimate the phase noise of
> that
> internal crystal from the ADEV measurements?  There are a bunch of
> papers that go the other way:  from Phase Noise to Adev.   Searching
> brings up only one paper that goes from ADEV to Phase Noise but it's text
> does not seem to be readily available.  It apparently models the oscillator
> as a couple of well known error models.
>
> -- Tom, N5EG
> ___
> 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] Phase noise from Allan Deviation ?

2015-12-14 Thread Charles Steinmetz

Tom wrote:


The 'unknown' is a Rubidium oscillator locked to CDMA pilot (TS2700)


There is very little information publicly available on the 
Symmetricom "BesTime" engine ("BTE"), but after playing with a few 
TS2700s for quite some time, including monitoring a number of 
internal signals, several things became apparent.  First, the 2700 
does not seem to discipline the PRS10.  The rubidium runs open loop 
and the BTE keeps track of the offset and the drift rate from "BTE 
time" (which is synthesized from all available sources -- however 
many CDMA signals it is receiving, plus any wireline telco timing 
signals and the PRS10 -- using a proprietary algorithm to estimate 
the reliability of each source and outputting BTE time and frequency 
using DDS).  Hobby users won't be feeding the unit any telco timing 
signals, so the BTE has only the CDMA signals to work from.  During 
holdover (and assuming no telco timing signals), the Rb is the sole 
input to the BTE, which uses the stored offset and drift to calculate BTE time.


I found that the TS-2700 is more than an order of magnitude less 
stable than a Trimble Thunderbolt, even with a full complement of 
rock-solid CDMA sources.  This may vary somewhat, depending on the 
CDMA equipment in use at any particular location and the diligence of 
the CDMA operator.


Best regards,

Charles


___
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] Phase noise from Allan Deviation ?

2015-12-13 Thread Tom McDermott
I've constructed a homebrew setup to measure time intervals using a
software defined radio.  Basically a single-channel downconversion to
about one hertz, then count samples from the SDR clock to time stamp
the zero crossings.  This is done in gnuradio and saved to a file for
post processing. The resolution is theoretically good, but the accuracy
is unknown.

The result produces ADEV vs. Tau charts with reasonably sane looking
results.
The 'unknown' is a Rubidium oscillator locked to CDMA pilot (TS2700),
and the internal crystal oscillator in the SDR radio as the reference.
Thus, ADEV probably is mostly measuring that internal crystal rather than
the TS2700.  Later on a GPSDO will be tried as the reference clock to
see if the Adev results are better.

It brings up a question:  Is it possible to estimate the phase noise of that
internal crystal from the ADEV measurements?  There are a bunch of
papers that go the other way:  from Phase Noise to Adev.   Searching
brings up only one paper that goes from ADEV to Phase Noise but it's text
does not seem to be readily available.  It apparently models the oscillator
as a couple of well known error models.

-- Tom, N5EG
___
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.