[time-nuts] synchronization for telescopes

[Azelio Boriani]

AM radio in Italy (what is left) is from 525KHz to 1715KHz and the TV
broadcast is now all digital, using QPSK or QAM COFDM modulation: not
so easy to use as a synchronization signal.

On Wed, May 4, 2016 at 7:42 PM, Chris Albertson
<albertson.chris at gmail.com> wrote:
> How to increase the SNR.  Remember you are doing this in post processing
> not in real time.  So for each even that needs to be trimmed yo have access
> to literally millions of cycles of RF data both in the past and future
> relative to the event.  The signal cane near the noise floor of your
> receiver but it won't be.  These a stations with tens of kilowatts of power
> and yo get to use any number of them simultaneously if you like.
>
> HDD space might be a problem but you don't need to continuously record the
> data.  you only need X milliseconds per second.  X is what every you need
> for good statistics.  You assume your local oscillator (a $25 crystal) does
> not drift much over 100 milliseconds.
>
> Basically what you'd really like to do is have a two channel recorder one
> for your data and one for a continuously broadcast "timecode"  Then in post
> processing you create the time tag for each event by interpolating the time
> code.  All telescope listen to and record the same broadcast time code.  In
> post you remove the time of flight delay from broadcaster to each telescope.
>
> The question then is what to use as a time code.  You just need a
> transmitter that is common to everyone.  GPS can work.  GPS might be best
> because the receivers are dirt cheap because they are mass produced.
> But if you can sample a "free" rf signal in quadrature you can recover the
> phase very accurately if you have a 100,000 samples of it.  Take those
> 100,000 samples 10 times per second and you only have a 8MB/sec data rate.
> Those are made-up numbers.  I don't thing SNR is a problem as you are using
> an autocorrelation function to time aligned large data blocks not working
> in real time on each sample
>
> On Wed, May 4, 2016 at 11:52 AM, Ilia Platone <info at iliaplatone.com> 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.
>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>> --
>> Ilia Platone
>> via Ferrara 54
>> 47841
>> Cattolica (RN), Italy
>> Cell +39 349 1075999
>>
>> _______________________________________________
>> 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.
>>
>
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
> _______________________________________________
> 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.