[time-nuts] synchronization for telescopes

[Bob Camp]

Hi

Take a careful look at the phase noise requirements on a (say) 28 MHz signal source with 
a jitter of 1 ps. It’s trivial if the low end of the integration bandwidth stops at 1 MHz. If you take
the lower limit into 1 Hz and below, it gets quite challenging. Even the math gets a bit wonky due
to the noise models changing There are  noise floor limits in these modules that are 
fine at the many 100’s of ps level, but show up when you try to go below that.

Bob



> On May 4, 2016, at 6:11 AM, Michael Wouters <michaeljwouters at gmail.com> wrote:
> 
> Dear Attila
> 
> On Tue, May 3, 2016 at 10:05 PM, Attila Kinali <attila at kinali.ch> wrote:
> 
>> I have some numbers of an project of the ETH that did use standard
>> LEA-6T recording the phase data and got in the post processing
>> to an uncertainty of <4mm averaging over several hours. Translating
>> that to timing resolution would mean an uncertainty of less than 13ps.
>> Of course, this number is completely theoretical, but it shows that
>> it should be possible to go below 1ns in time resolution, if the
>> phase data could be related to a stable reference oscillator in
>> post-processing and if the offsets between the different receiver
>> and antenna combinations are calibrated out.
> 
> There are  differences between solving for position and solving for  time.
> 
> In the case of position, it's constant so you can average over long
> times. In the case of time, you can't assume this and long-term
> averaging is not reasonable. So position uncertainty does not
> translate directly to time uncertainty (although it probably tells you
> about the precision of the individual measurements).
> 
> The other key difference (and difficulty) is in your statement "if the
> phase data could be related to a stable reference oscillator in
> post-processing". In the case of position, the solution is for a point
> in space. In the case of time, you have to relate it to the output of
> some physical clock.
> 
> In the case of a single frequency receiver, the measurements are made
> with respect to the internal TCXO, which is operated much like the
> software clock in eg the Linux kernel clock. You then have to know the
> (continuously varying) offset between this clock and the receiver's
> reference timescale, the offset between the nominal output 1 pps and
> the reference time scale in some cases, and the sawtooth correction,
> to finally relate the raw measurements to your external clock.
> 
> Several people have mentioned that there are some low-cost receivers
> which apparently allow for an external oscillator. This may result in
> improved time-transfer operation but the key question is the
> relationship between the output 1 pps and the 1 pps derived from the
> external oscillator - it is not obvious that this will be constant
> between eg power cycles of the receiver. This is something you have to
> test for.
> 
>> That's why I'm proposing timing receivers. They are the ones that have
>> the additional software and hardware bits which allow to relate an
>> external oscillator to the satellite phases.
> 
> I think we're talking about the same thing here. By 'geodetic receiver' I meant:
> L1/L2 + carrier phase measurements + externally supplied 10 MHz and 1 pps.
> This is the typical kind of receiver installed at an IGS station, with
> the external clock a Cs or H-maser. They cost around $10-$15K.
> 
>> I don't know what resolution the LEA family offers there, but the
>> spec of the protocol defines a 1ps resolution in the data. So I would
>> guess that the phase data resolution is probably in the order of 10-100ps.
> 
> Coincidentally, I am currently writing software so that I can test the
> LEA-8MT for GPSCV time-transfer. This is code-based, in the usual way.
> I will be doing a comparison of a number of different single-frequency
> receivers for time-transfer - this may be of interest to the time-nuts
> community because the testing platform is all open source
> (www.openttp.org) .
> 
> This whole discussion has been very useful  because it has alerted me
> to an interesting application for post processed timing!
> 
> Cheers
> Michael
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.