[time-nuts] Common sky pps errors for any GPSDOs?
boyscout at gmail.com
Mon Jan 5 21:04:52 EST 2009
On Mon, Jan 5, 2009 at 2:56 PM, Lux, James P <james.p.lux at jpl.nasa.gov> wrote:
>> -----Original Message-----
>> From: time-nuts-bounces at febo.com
>> [mailto:time-nuts-bounces at febo.com] On Behalf Of Matt Ettus
>> Sent: Monday, January 05, 2009 2:28 PM
>> To: Discussion of precise time and frequency measurement
>> Subject: Re: [time-nuts] Common sky pps errors for any GPSDOs?
>> On Mon, Jan 5, 2009 at 12:13 PM, Lux, James P
>> <james.p.lux at jpl.nasa.gov> wrote:
>> >> -----Original Message-----
>> >> From: time-nuts-bounces at febo.com
>> >> [mailto:time-nuts-bounces at febo.com] On Behalf Of Matt Ettus
>> >> Sent: Monday, January 05, 2009 11:31 AM
>> >> To: Discussion of precise time and frequency measurement
>> >> Subject: [time-nuts] Common sky pps errors for any GPSDOs?
>> >> I am working with someone who needs to have time synchronized
>> >> reception of signals in various locations which are
>> separated by less
>> >> than 100 km. This is a situation similar to VLBI, but since the
>> >> distances are shorter, the center frequencies are lower, and the
>> >> integration times are much shorter, we probably don't need
>> a Hydrogen
>> >> Maser, and the application can't afford one.
>> >> The real question is whether we can get away with a GPS
>> >> OCXO or whether we would need to use a Rubidium.
>> >> Does anyone have any data on the relative frequency and/or phase
>> >> errors of the 10 MHz reference out, and relative PPS time
>> errors of
>> >> any commonly available GPSDOs?
>> > Isn't that just the Allan Deviation data? Symmetricom has
>> datasheets on their website for their various modules. They
>> have a GPS discplined quartz oscillator in several flavors.
>> > %20XLi%20Options%202.pdf
>> I don't think Allan Deviation is the right measure. First,
>> standard Allan dev numbers won't take environmental
>> differences into account.
>> Also, isn't Allan Dev measured vs. a better reference?
> Environmental differences, as in the environment of the box? Or the propagation path?
> For the box, the short term is going to be dominated by the OCXO, isn't it? So it's relatively environment immune.
> Allan Dev is the box against itself,in the adjacent time slice, but wouldn't that be pretty similar to a box against an identical box, because the noise is assumed to be uncorrelated from time slice to time slice.
>> > Something else to consider is doing post processing.. Use a
>> nice quiet 10MHz oscillator for your source/sampling clock,
>> and record the 1PPS from the GPS receiver as well as your
>> unknown, then figure out after the fact what the oscillator was doing.
>> Unfortunately, post processing isn't possible in this app,
>> since it is a real-time communications application.
> OH.. This is like doing a distributed phased array for EME (or, as N5BF wants to do, EVE)
Yes, a very similar application.
> On the basis of your other mail a few minutes later, you're looking at very short integration time (e.g. 10ms), so wouldn't phase noise be your more appropriate thing to look at, and for that, you're almost certainly looking at the basic properties of the quartz oscillator.
Well, basically, I need to be able to coherently add signals from
multiple locations without first looking at those signals to determine
what the phase error is.
> OTOH, if you're trying to a phased uplink sort of thing, then you are concerned about longer time intervals (e.g. you want the relative phases of Tx1 and Tx2 to be constant over intervals of seconds)
Yes, we would need the relative phase to be constant over time scales
up through about a second or two.
More information about the time-nuts