[time-nuts] synchronization for telescopes

[Ilia Platone]

Hi,

Sorry if I haven't replied yet to this topic (and sorry for my bad 
english...)

There will be more than two telescopes possibly, as to fill out the 
Fourier plane we'll need more observation points than two, but as a 
starting point two are "good".

The problem was how to lock this central clock with the children clocks 
and to obtain a clock phase between the telescopes with an error 
minimized as possible. In case of independent clocks we considered a 
software solution, this would have some effort in terms of design but 
we've seen it's impractical, as clocks vary in time their stability and 
we'd have no reference for the timestamps during capture. Another 
possibility was to use lasers as clock transfer: the master clock (Rb) 
would be downscaled to 1kHz in this case and pulsed into the children 
receivers. Lasers offer better synchronization possibilities but are 
dangerous except if used in visible wavelengths (I mean if they're 
visible, you're advised). White Rabbit is gorgeous, but it costs too much.
I wanted also to indicate that the locations of the telescopes must be 
known with an error of 7cm.

The solution that is closer to factibility for us is to use a vcoxco 
board at each telescope, phase locked with the central station, where 
must be installed a stable clock (Rubidium), using an IR Lamp at the 
central station and APD at the telescopes, plus some optics to increase SNR.
the clock of the Rubidium Standard will be downscaled into 1KHz, so 
raising/fall times of the leds would be acceptable, and I don't think 
there will be security issues in this case.
There is also the possibility to use optical band-pass optical filters 
at the telescopes optics (which will be some small telescope) to avoid 
interferences.
We've also IR cameras which can be used to detect inerference elements 
and to avoid them.
Each station will have a GPS module, with RAW carrier data output, which 
will record its phase data into an SD card, and these data will be 
processed later.

Please comment this setup, We're in chrisis because a lot of ideas came 
out these weeks and we're much confused.
Regards,
Ilia.

On 05/04/16 11:42, Bob Camp wrote:
> 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 tohttps://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> _______________________________________________
> time-nuts mailing list --time-nuts at febo.com
> To unsubscribe, go tohttps://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>

-- 
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999