[time-nuts] synchronization for telescopes

[Bob Camp]

HI

These days, there is no need to “just use one” if you are talking about AM stations. Digitizing the entire AM band is pretty 
a pretty low end SDR task these days. Storing the result will take some storage, but noting insane;

100 Msps @ 16 bits => 200 MB / sec. 
Run overnight: 30K sec
Total on the disk at each end: 6 TB. 

Yes, that’s a not a trivial disk, but it is hardly a “break the bank” sort of thing. 

Done this way,  phase noise on the transmitted carriers is fine. You have the same noise at both sites. That part of 
the problem should cancel out in post processing. The same is true of things like frequency drift. You have a MHz 
of bandwidth so the net signal *could* be fairly complex. That’s also a good thing …

Bob



> On May 4, 2016, at 2:53 PM, jimlux <jimlux at earthlink.net> wrote:
> 
> On 5/4/16 11:52 AM, Ilia Platone wrote:
>> You got it, however: It only matters relative time. Start and Stop times
>> will be known, and that is solved.
>> Someone has proposed using TV or other broadcasting carrier as reference
>> clock: this can be another very cheap solution. There are many AM
>> stations near the places we chosen, and these can be used.
> 
> AM stations are nice, because it's ground wave, so the propagation is reasonably stable, but the frequency is on the order of 1 MHz (and not very stable in a time-nuts sense).  if your two sites are 2km apart, in the worst case, that's a time difference for your AM signal of 6 microseconds.  I'm not sure what the phase noise on an AM transmitter is at 160kHz out from the carrier, but it could be pretty bad and not affect the audio quality on someone's car radio.
> 
> TV intended for simulcasting is MUCH better (because the digital receiver needs to see the multiple arriving signals as if they were multipath scattered versions of a single signal).
> 
> If you have line of sight to a TV station, I would think this could be quite good, and it's up around 100 MHz.  The period is 10ns (or 10,000 ns, 1E7 ps).  You want 100ps kind of timing, that's measuring the phase of the TV signal to 1 part in 100,000, which is challenging, but not impossible.
> 
> 
> 
> 
> 
>> A problem found was how to increase SNR: do you have a solution for
>> this? If possible this method would be the best, since longer baselines
>> could be made. The distance from the carrier source is not a problem
>> since we'd use a GPS module at each telescope. Also the software part is
>> not a problem too.
>> Good the relative timestamp also, as it saves HDD space.
>> 
>> Regards,
>> Ilia.
>> 
>> On 05/04/16 15:28, Chris Albertson wrote:
>>> One more comment.   It seems to me time-raging events is hard because you
>>> need many very good clocks that tracks absolute time.
>>> 
>>> If you redefine the problem to be "determine the time difference
>>> between to
>>> events that occurred a couple nights ago it might be much easier.  This
>>> does not need to be done in real  time
>>> 
>>> On Wed, May 4, 2016 at 8:25 AM, Chris Albertson
>>> <albertson.chris at gmail.com>
>>> wrote:
>>> 
>>>> Maybe there is some simpler way to synchronize the telescopes.   Do they
>>>> even need to know the absolute time?  I think only relative time maters.
>>>> 
>>>> For that all they need is some kind of a signal that all the
>>>> telescope can
>>>> "see".   Could they use an FM or TV broadcast station?  They could
>>>> sample
>>>> and record the signal at a very high sample rate (maybe 4X the career
>>>> frequency) and record their data at the same time.  each telescope would
>>>> need to know its distance to the broadcast antenna.
>>>> 
>>>> The idea is to make the hardware cheaper and simpler and put all the
>>>> "work" on the post processing software developers.
>>>> 
>>>> For this purpose, measuring the time difference of photons detected at
>>>> different locations, I don't think the broadcast career needs to be
>>>> exceptionally stable.  In post all you do to slide the recorded signal
>>>> until a best match is found.  So we do need a modulated carrier.  We
>>>> also
>>>> have LOTS of data to use to compute the time alignment because you do it
>>>> later, we'd have billions of samples so it should be immune to noise
>>>> 
>>>> 
>>>> 
>>> 
>> 
> 
> _______________________________________________
> 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.