[time-nuts] A better Lady Heather 4.0 download page

[Mark Sims]

John Miles is now hosting the latest Lady Heather 4.0 files.  His server is a 
little less skeezy than tinyupload.com (which on Windows machines apparently 
offers to update your Java with about every click).  I've used tinyupload for 
years on a Mac, and never got such a "generous" offer.  No telling what other 
scuzz that would install...
http://www.ke5fx.com/heather/readme.htm
Linux users should download the .ZIP file and also check the link to the Linux 
install instructions.  There is a heather.cfg file in the ZIP that sets some 
command line options for enabling a singing clock and the analog watch face and 
satellite position map.  You might want to edit that file to add a command to 
select your desired serial port/ethernet connection, etc.   

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] OT: A paper on Cs + Zeeman etc.

[Pete Lancashire]

Even though nothing to do with time, I found the paper

CESIUM OPTICALLY PUMPED MAGNETOMETERS

http://www.gserentals.co.uk/gse/pdf/Theory%20Cesium%20Optically%20Pumped%20Magnetometers.pdf

to be an interesting read.

I can only imagine what HP and Varian engineers went through

-pete
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] SE880 GPSDO

[Bruce Griffiths]

On Wednesday, April 27, 2016 09:40:05 PM Attila Kinali wrote:
> On Wed, 27 Apr 2016 20:18:10 +0200
> 
> Mike Cook  wrote:
> > > Use this CW signal on all the telescope stations to phase lock a local
> > > OCXO. Using a good OCXO, it should be possible to use loop bandwidths
> > > in the 0.1-10Hz range. My guess is, that this frequency transfer system
> > > would yield stabilities in the order of 10^-12 @ 1s (or even better).
> > > For additional performance, one could modulate the CW with a PRN
> > > sequence
> > > to get a better SNR and probably get another order of magnitude out of
> > > it.
> > > For the simple CW case, the circuitry should be fairly simple and easy
> > > to do. The PRN case would require at least some processing in an FPGA.
> > 
> > It might be possible to clock the FPGA directly from a suitably massaged
> > CW. Do any clock at 1GHz+???
> > It would be also possible to do away with LO’s in this case..
> 
> That would make the system more complicated than simpler, because
> you need to extract a signal from a noisy environment, pass it through
> narrow band filter so you get something that resembles a sinus in order
> to use it in the electronics. This kind of works when the reference
> signal comes in via cable. With over the air transmission, this wont work.
> 
> Using an OCXO together with a PLL basically forms a very narrow band
> filter that has a very small tempco, adjustable (and adaptive)
> frequency and allows to change the filter coefficiencts quickly
> to acquire the signal at start-up.
> 
> Very few chips (of any kind, not just FPGA) allow input clocks higher
> than a couple 100MHz. Single ended CMOS inputs usually go only up
> to 200MHz, often much lower than that. Differential (LVDS and PECL)
> ends usually in the 500MHz range.
> 
> Also. Running an FPGA at 1GHz is not trivial at all. Most designs
> don't do more than 500MHz even on the fastest FPGAs out there.
> 100-300MHz are common values. And unlike with CPUs, there is often
> no need to run an FPGA faster than the data arrives or leaves, as
> the functions can be run in parallel and use a pipelined architecture..
> 
> > The CW could also carry time, and if it was feasible, local GPS would be
> > unnecessary.
> 
> If the CW would carry time, it wouldn't be CW anymore ;-)
> 
> Yes, that's the idea with the PRN modulation i mentioned in the other mail.
> But it wont lift the necesity of GPS. There is an unknown delay from the
> sender to the receiver, through multiple filter and frequency conversion
> stages. Some of them can be measured, some of them come from the ambiguity
> of the phase in the system. Others, like the path delay, cannot be measured.
> 
> One solution would be, to use 2 transmitters with known positions and
> known phase relations, then it would be possible to extract time,
> given one knows the positions of the receivers exactly.
> To get around that requirement, one would need at least 4 transmitters...
> Ie. one would be recreating the GPS system... at which point it becomes
> simpler to just use GPS and live with the degraded accuracy.
> 
> Also keep in mind, that with GPS it is well known where the errors
> come from and how big they are. Also lots of techniques are implemented
> to counter those. With a DIY-GPS system, one would need to implement
> those and measure their performance again, which would be a whole lot of
> work.
> 
>   Attila Kinali
The solution to this conundrum is to use a high speed serial to parallel 
converter and proces 4/8/16 timeslots in parallel at 1/4, 1/8 or 1/16 the 
serial clock rate as required.

If the high speed serial interface offered by many modern FPGAs could be used 
for this then 100ps or finer timestamp quantisation may be feasible.

Bruce

Bruce
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] SE880 GPSDO

[Attila Kinali]

On Wed, 27 Apr 2016 20:18:10 +0200
Mike Cook  wrote:

> > Use this CW signal on all the telescope stations to phase lock a local
> > OCXO. Using a good OCXO, it should be possible to use loop bandwidths
> > in the 0.1-10Hz range. My guess is, that this frequency transfer system
> > would yield stabilities in the order of 10^-12 @ 1s (or even better).
> > For additional performance, one could modulate the CW with a PRN sequence
> > to get a better SNR and probably get another order of magnitude out of it.
> > For the simple CW case, the circuitry should be fairly simple and easy
> > to do. The PRN case would require at least some processing in an FPGA.
> 
> It might be possible to clock the FPGA directly from a suitably massaged CW. 
> Do any clock at 1GHz+???
> It would be also possible to do away with LO’s in this case. 

That would make the system more complicated than simpler, because
you need to extract a signal from a noisy environment, pass it through
narrow band filter so you get something that resembles a sinus in order
to use it in the electronics. This kind of works when the reference
signal comes in via cable. With over the air transmission, this wont work.

Using an OCXO together with a PLL basically forms a very narrow band
filter that has a very small tempco, adjustable (and adaptive)
frequency and allows to change the filter coefficiencts quickly
to acquire the signal at start-up.

Very few chips (of any kind, not just FPGA) allow input clocks higher
than a couple 100MHz. Single ended CMOS inputs usually go only up
to 200MHz, often much lower than that. Differential (LVDS and PECL)
ends usually in the 500MHz range.

Also. Running an FPGA at 1GHz is not trivial at all. Most designs
don't do more than 500MHz even on the fastest FPGAs out there.
100-300MHz are common values. And unlike with CPUs, there is often
no need to run an FPGA faster than the data arrives or leaves, as
the functions can be run in parallel and use a pipelined architecture.

> The CW could also carry time, and if it was feasible, local GPS would be
> unnecessary.

If the CW would carry time, it wouldn't be CW anymore ;-)

Yes, that's the idea with the PRN modulation i mentioned in the other mail.
But it wont lift the necesity of GPS. There is an unknown delay from the
sender to the receiver, through multiple filter and frequency conversion
stages. Some of them can be measured, some of them come from the ambiguity
of the phase in the system. Others, like the path delay, cannot be measured.

One solution would be, to use 2 transmitters with known positions and
known phase relations, then it would be possible to extract time,
given one knows the positions of the receivers exactly. 
To get around that requirement, one would need at least 4 transmitters...
Ie. one would be recreating the GPS system... at which point it becomes
simpler to just use GPS and live with the degraded accuracy.

Also keep in mind, that with GPS it is well known where the errors
come from and how big they are. Also lots of techniques are implemented
to counter those. With a DIY-GPS system, one would need to implement
those and measure their performance again, which would be a whole lot of work. 

Attila Kinali
-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Advise on building a DIY GPSDO?

[Magnus Danielson]

Lars,

On 04/27/2016 02:14 PM, Lars Walenius wrote:

Thanks Magnus and Charles,

Could you please explain a little more about this:

Charles wrote:

  Loop filters in commercial GPSDOs use algorithms that suppress
systematic ripple on the VCO control related to the comparison frequency.

Magnus wrote:

It will be there, so you need to manage it one way or another.


What is the systematic ripple?


On the comparison frequency, whatever it is, there will be measurements 
and adjustments. The overtones of the sample rate it represents will be 
a systematic "tone".



Is the comparison frequency normally 1Hz (1PPS)?


Yes.


What is the algorithms used?


There can be many. Oversampling and smoothing that way helps for 
instance. Resolution in adjustment is an indirect way.



If I sample the difference between the PPS and the divided 10MHz output every 
second and have a third order loop driving a DAC will I get systematic errors?


Yes. Depending on how picky you are you can live with it or you find 
ways to manage it.


Cheers,
Magnus


Lars

Från: Magnus Danielson
Skickat: den 27 april 2016 10:02
Till: time-nuts@febo.com
Kopia: mag...@rubidium.se
Ämne: Re: [time-nuts] Advise on building a DIY GPSDO?



On 04/27/2016 01:12 AM, Charles Steinmetz wrote:

Lars wrote:


I have wondered what is meant by a proper digital filter below?

Is a proper digital filter something more than the LP-filter + PI-loop
I use in the DIY Arduino GPSDO?
What is used in commercial GPSDOs?


The loops are substantially more sophisticated than a simple LP filter
-- typically 3rd order or higher.


The lowpass-filter + PI-loop is third order.


  Well-designed commercial GPSDOs also
have several time constants so they can achieve basic lock using a wider
loop, then narrow the loop in steps until it is fully narrow (unless S/N
is low, in which case they may not reach full narrow and should set an
alarm).


Some care needs to be taken in articulating the filter such that you do
not have to scale the state as you change the parameters. This is
however fairly simple for both the low-pass filter and integrator (which
hold state).

With some care you can articulate the P and I in the forms of equations
relating to the loop parameters you want and compensating for the
DAC/EFC control gain (exact value not important, but getting bandwidth
and damping in the right neightborhood is).

The heuristics about when changing parameters takes some learning. One
of the design criteria is to be able to always capture, but you also
want it to go as quick as possible. Finding a good balance can be
problematic. There is tricks to track-in quicker.


  Loop filters in commercial GPSDOs use algorithms that suppress
systematic ripple on the VCO control related to the comparison frequency.


It will be there, so you need to manage it one way or another.


It is extremely unlikely that someone would stumble upon workable
parameters for this sort of loop by trial and error.  One needs to
measure and characterize the open-loop behavior, then carefully design
the loop filter to achieve the desired result.


If you know what you are doing, you can get a good start using analysis,
knowing the damping and bandwidth you want. It always becomes a measure
and trim exercise.

Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] SE880 GPSDO

[Mike Cook]

> 
> Assuming that you have an amateur radio license, you could use a 
> well located central station to transmit a CW signal in the 70cm or
> 23cm band. There should be some effort put into this station
> to make it stable (eg by using a good rubidium as frequency source,
> or even an ensemble) and low noise.
> 
> Use this CW signal on all the telescope stations to phase lock a local
> OCXO. Using a good OCXO, it should be possible to use loop bandwidths
> in the 0.1-10Hz range. My guess is, that this frequency transfer system
> would yield stabilities in the order of 10^-12 @ 1s (or even better).
> For additional performance, one could modulate the CW with a PRN sequence
> to get a better SNR and probably get another order of magnitude out of it.
> For the simple CW case, the circuitry should be fairly simple and easy
> to do. The PRN case would require at least some processing in an FPGA.

It might be possible to clock the FPGA directly from a suitably massaged CW. Do 
any clock at 1GHz+???
It would be also possible to do away with LO’s in this case. 

> 
> Now that all stations have the "same" frequency, one can use the GPS
> module to get the time information using long integration times.
> Under the assumption that the (sawtooth corrected) PPS is good to +/-10ns
> an has a nice, time-invariant distribution, it should be possible to get
> below 1ns in precision within 100s. Using common view phase data it
> should be possible to get even better than that. 

The CW could also carry time, and if it was feasible, local GPS would be 
unnecessary.
The  telescope sites would receive the ticks at different times but the delta 
could be post processed out provided the positions are known to a few 
centimeters.

> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

"The main function of a modern police force is filling in forms."

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Dead tree material: Ships, Clocks, and Stars: The Quest for

[Gordon Batey]

Greetings Time Nuts,

I read the message below and made a trip to my closest OLLIE's store in
Harrisonburg, VA.  I found the book with the assistance of the book area
manager and purchased it.  They now have 5 left in Harrisonburg.  If you are
interested in the book and have an OLLIE'S nearby it might be worth checking
them out.

Now to start reading,

Gordon WA4FJC

Original message...
Message-ID: <4096.10.0.0.63.1461693191.squir...@www.marcdatabase.com>
Content-Type: text/plain;charset=iso-8859-1

I usually don't have very much to contribute to this list, a lot of what
gets discussed here is a bit above my pay grade, so I mostly just read and
hope some of it sinks in.  Also not sure how much interest there is on this
list in dead tree material.

That being said, I was at Ollie's Bargain Outlet,
https://en.wikipedia.org/wiki/Ollie's_Bargain_Outlet and I saw four copies
of Ships, Clocks, and Stars: The Quest for Longitude Hardcover – November 4,
2014 by Richard Dunn (Author), Rebekah Higgitt (Author),
http://www.amazon.com/Ships-Clocks-Stars-Quest-Longitude/dp/006235356X for
$10.  I was thinking of buying a copy for myself and wondered if there might
be some interest from others.  According to the USPS web site this book can
be shipped at media mail rates for less than $5, so at $20 on your doorstep
this book is about $15 cheaper than it appears to be available any where
else. Any interest?

   Thomas Valerio

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] SE880 GPSDO

[Michael Wouters]

On Wed, Apr 27, 2016 at 7:21 PM, Bruce Griffiths
 wrote:
> Stabilising the GPS receiver antenna temperature is probably a good idea 
> particularly if it has bandpass filter(s).

It's not so clear that temperature stabilization of the antenna is
necessary. There have been reports of tempcos of 0.2 ps to 10 ps/C for
various choke ring antennas so this doesn't seem so bad. I don't know
how a $100 antenna fares in such a test. Temperature stabilization of
the receiver is probably more important. Again though, I don't know of
any data for low-cost receivers, only geodetic timing receivers.

Cheers
Michael
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] More graphs: OCXO step, holdover recovery

[Lars Walenius]

Lars wrote:
>> What puzzles me is the large hump upwards in DACvalue. Anyone knows what is
>> the reason?

Hal wrote:
>My guess is poor filtering on the initial data when coming out of holdover, 
>probably complicated by inadequate testing and/or that case not being 
>important.
>
>I'm pretty sure there is at least one GPS data sheet that says to ignore the 
>first 3 samples.


But the large hump and small jump seems to come more than 15 minutes after 
holdover and at the same time after both holdovers. The first part after the 
holdover seems to be normal for a PI-loop is my assumption but the hump and 
jumps are not.

Lars



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Lady Heather Ver 4.0 beta test available (has Linux support)

[John Miles]

I've updated my existing LH download page with Mark's new beta version in both 
.zip and (Windows) setup.exe formats:
http://www.ke5fx.com/heather/readme.htm

There's also a link to his readme.txt file with Linux build instructions.  
(Mark is the best point of contact for anyone with questions on that, as I'm 
just the Windows guy.)

-- john, KE5FX
Miles Design LLC



> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Mark
> Sims
> Sent: Tuesday, April 26, 2016 5:50 PM
> To: time-nuts@febo.com
> Subject: [time-nuts] Lady Heather Ver 4.0 beta test available (has Linux
> support)
> 
> I have uploaded a ZIP file to tinyupload.com with the source and a Windoze
> .EXE file for the beta test version of Lady Heather.  For Windows users, copy
> the heather.exe to your current Lady Heather directory (might want to first
> rename or copy your old heather.exe as a backup.
> For Linux users,  unzip the archive into a new directory,  read the readme.txt
> file.  You will need libx11-dev and g++ installed to build it.
> http://s000.tinyupload.com/index.php?file_id=28617692862395218928
> PLEASE direct comments and questions off-list... no need to clutter up the
> list.
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-
> bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Advise on building a DIY GPSDO?

[Lars Walenius]

Thanks Magnus and Charles,

Could you please explain a little more about this:

Charles wrote:
>>  Loop filters in commercial GPSDOs use algorithms that suppress
>> systematic ripple on the VCO control related to the comparison frequency.
Magnus wrote:
>It will be there, so you need to manage it one way or another.

What is the systematic ripple?
Is the comparison frequency normally 1Hz (1PPS)?
What is the algorithms used?
If I sample the difference between the PPS and the divided 10MHz output every 
second and have a third order loop driving a DAC will I get systematic errors?

Lars

Från: Magnus Danielson
Skickat: den 27 april 2016 10:02
Till: time-nuts@febo.com
Kopia: mag...@rubidium.se
Ämne: Re: [time-nuts] Advise on building a DIY GPSDO?



On 04/27/2016 01:12 AM, Charles Steinmetz wrote:
> Lars wrote:
>
>> I have wondered what is meant by a proper digital filter below?
>>
>> Is a proper digital filter something more than the LP-filter + PI-loop
>> I use in the DIY Arduino GPSDO?
>> What is used in commercial GPSDOs?
>
> The loops are substantially more sophisticated than a simple LP filter
> -- typically 3rd order or higher.

The lowpass-filter + PI-loop is third order.

>  Well-designed commercial GPSDOs also
> have several time constants so they can achieve basic lock using a wider
> loop, then narrow the loop in steps until it is fully narrow (unless S/N
> is low, in which case they may not reach full narrow and should set an
> alarm).

Some care needs to be taken in articulating the filter such that you do
not have to scale the state as you change the parameters. This is
however fairly simple for both the low-pass filter and integrator (which
hold state).

With some care you can articulate the P and I in the forms of equations
relating to the loop parameters you want and compensating for the
DAC/EFC control gain (exact value not important, but getting bandwidth
and damping in the right neightborhood is).

The heuristics about when changing parameters takes some learning. One
of the design criteria is to be able to always capture, but you also
want it to go as quick as possible. Finding a good balance can be
problematic. There is tricks to track-in quicker.

>  Loop filters in commercial GPSDOs use algorithms that suppress
> systematic ripple on the VCO control related to the comparison frequency.

It will be there, so you need to manage it one way or another.

> It is extremely unlikely that someone would stumble upon workable
> parameters for this sort of loop by trial and error.  One needs to
> measure and characterize the open-loop behavior, then carefully design
> the loop filter to achieve the desired result.

If you know what you are doing, you can get a good start using analysis,
knowing the damping and bandwidth you want. It always becomes a measure
and trim exercise.

Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] SE880 GPSDO

[Bruce Griffiths]

Stabilising the GPS receiver antenna temperature is probably a good idea 
particularly if it has bandpass filter(s).
Bruce
 

On Wednesday, 27 April 2016 9:01 PM, Attila Kinali  wrote:
 

 On Wed, 27 Apr 2016 01:30:49 +0200
Ilia Platone  wrote:

> I will use a dedicated FPGA design, and the data will be stored into an 
> SDXC card (UHS), or an IDE drive (maybe not), in RAW mode (no filesystem)..

Please be aware that SDCards performance spec is peak and best case.
Additionally, you need to prepare for writes taking several ms when
the SDCard firmware remaps blocks. Ie you will need to be able to
buffer several MB of data before you write to the SDCards. It would
probably be a good idea to push the data into a CPU (ARM9, or Cortex-A)
and handle the buffering/writing in software instead of an FPGA.

> Each timestamp will be stored into a word of 48bits, the clock will be 
> 400MHz, so the quantization will be 2.5ns, but the maximum error/clock 
> offset should be 1/10 of this, so 500ps , as said by Bruce.

I thought a little bit more about this problem this morning and came up
with something that should be rather simple to implement:

Assuming that you have an amateur radio license, you could use a 
well located central station to transmit a CW signal in the 70cm or
23cm band. There should be some effort put into this station
to make it stable (eg by using a good rubidium as frequency source,
or even an ensemble) and low noise.

Use this CW signal on all the telescope stations to phase lock a local
OCXO. Using a good OCXO, it should be possible to use loop bandwidths
in the 0.1-10Hz range. My guess is, that this frequency transfer system
would yield stabilities in the order of 10^-12 @ 1s (or even better).
For additional performance, one could modulate the CW with a PRN sequence
to get a better SNR and probably get another order of magnitude out of it.
For the simple CW case, the circuitry should be fairly simple and easy
to do. The PRN case would require at least some processing in an FPGA.

Now that all stations have the "same" frequency, one can use the GPS
module to get the time information using long integration times.
Under the assumption that the (sawtooth corrected) PPS is good to +/-10ns
an has a nice, time-invariant distribution, it should be possible to get
below 1ns in precision within 100s. Using common view phase data it
should be possible to get even better than that. 

Of course, the GPS modules would still need to be calibrated against
eachother to get the accuracy below the 10ns level. I am still not
sure how to go below 1ns, though I think this approach should make
that easier. Most likely you will need some temperature stabilization
of the electronics.

It's also quite easy to verify the frequency transfer by letting
each telescope station transmit a CW signal back to the central
station on a different frequency. Then use some SDR system to extract
the relative phase/frequency of each station.

            Attila Kinali

-- 
Reading can seriously damage your ignorance.
        -- unknown
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


  
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] SE880 GPSDO

[Ilia Platone]

It was a joke :)

Interesting the idea of Attila, it can be the less expensive solution:

"Assuming that you have an amateur radio license, you could use a
well located central station to transmit a CW signal in the 70cm or
23cm band. There should be some effort put into this station
to make it stable (eg by using a good rubidium as frequency source,
or even an ensemble) and low noise."

...

"Now that all stations have the "same" frequency, one can use the GPS
module to get the time information using long integration times.
Under the assumption that the (sawtooth corrected) PPS is good to ±10ns
an has a nice, time-invariant distribution, it should be possible to get
below 1ns in precision within 100s. Using common view phase data it
should be possible to get even better than that."

Regards,
Ilia.

Il 27/04/2016 10:12, Bruce Griffiths ha scritto:

A 60kHz receiver is unlikely to be useful for nanosecond timing applications.
Bruce
  


 On Wednesday, 27 April 2016 6:36 PM, Ilia Platone  
wrote:
  


  Hi All,

I read from an article about this receiver: C-Max CMMR-6P-60

Can it be useful?

One of the places where I'll setup the telescopes will be in mount
Carpegna, near where I live. There are the repetitors of television and
radio over there. Can the carrier wave of such repetitors be used as
clock? they will be distant 5 Km or less from the observation location.

Regards,

Ilia.


Il 26/04/2016 23:51, Attila Kinali ha scritto:

On Wed, 27 Apr 2016 08:25:55 +1200
Bruce Griffiths  wrote:


1) Relative position of any pair of clocks located up to 2km apart has to be
known to within 3cm or so. Post processing is OK, however differential Earth
tides between the clock locations may need to be considered.

That's doable. People at ETHZ got sub cm accuracy from LEA-6T modules
with post-processing of the recorded phase data with an integration time
of several hours. Using phase data of multiple timing modules should give
relative positions with better than 1cm accuracy on these short baselines..
I don't know how much post-processing is necessary though. Haven't looked
into the the field of RTK[1] and PPP[2] yet. Probably data from IGS[3] is
needed as well.


2) The difference in the time offset between any pair of clocks located up to
2km apart shall not vary by more than 200ps (1ns time stamp quantisation) or
2ns (10ns timestamp quantisation) over an 8 hour period (at night).
Post processing of data to fit wander etc is not practical as the SNR is too
low to support this.

Now this is quite a bit more challenging. While i'd say 1ns should be doable
(using receivers that are calibrated against each other and using common in
view mode during post-processing of the data), i'm not so sure whether 200ps
is possible. What might work is using an LEA-M8F with it's external frequency
input, to record the phase of an stable external reference (e.g. Rb).
Averaging that over a dozen minutes or so should make it possible to
measure the phase of the reference oscillator with 200ps precision, relative
to the other stations.

Another way would be to use L1/L2 receivers with calibrated antennas.
I know that BIPM has a GPS station that can deliver time transfer
accuracy <2ns over a distance of several 100km. It could be possible
to use such receivers with the <3km distances to deliver 10 times better,
if they are frequently calibrated (eg. every couple of days).
But of course, this makes things much more expensive.

But all this is a wild guess. I haven't seen anything like this done.
If you want a more precise answer i would need to think about the design
of the system for some time.


I guess using some cable/fibre between the telescopes is out of question?


 Attila Kinali

[1] http://www.navipedia.net/index.php/Real_Time_Kinematics
[2] http://www.navipedia.net/index.php/Precise_Point_Positioning
[3] http://www.igs.org/



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

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] SE880 GPSDO

[Michael Wouters]

On Wed, Apr 27, 2016 at 7:51 AM, Attila Kinali  wrote:
>
>
>
> Another way would be to use L1/L2 receivers with calibrated antennas.
> I know that BIPM has a GPS station that can deliver time transfer
> accuracy <2ns over a distance of several 100km. It could be possible
> to use such receivers with the <3km distances to deliver 10 times better,
> if they are frequently calibrated (eg. every couple of days).

> But of course, this makes things much more expensive.
>
> But all this is a wild guess. I haven't seen anything like this done.

There was a discussion in 2005 that's pertinent to this:

https://www.febo.com/pipermail/time-nuts/2005-August/019158.html

The references are interesting, with some real data about what is
achievable on short baselines.
eg Fig 7 in http://gpstime.com/files/PTTI/PTTI_2002_CNS_Testbed.pdf
shows that two receivers keep within about 5 ns of each other on a
21.5 km baseline.

As I think I said in a similar discussion a few weeks ago, two
identical geodetic receivers that I have on a 400 m baseline keep
within about 100 ps of each other, using a Precise Point Positioning
solution for the (common) clock.
If you were brave, then 2 km would scale to 500 ps synchronization
(works for 5 ns/20 km too ..)

Cheers
Michael
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] SE880 GPSDO

[Bruce Griffiths]

A 60kHz receiver is unlikely to be useful for nanosecond timing applications.
Bruce
 

On Wednesday, 27 April 2016 6:36 PM, Ilia Platone  
wrote:
 

 Hi All,

I read from an article about this receiver: C-Max CMMR-6P-60

Can it be useful?

One of the places where I'll setup the telescopes will be in mount 
Carpegna, near where I live. There are the repetitors of television and 
radio over there. Can the carrier wave of such repetitors be used as 
clock? they will be distant 5 Km or less from the observation location.

Regards,

Ilia.


Il 26/04/2016 23:51, Attila Kinali ha scritto:
> On Wed, 27 Apr 2016 08:25:55 +1200
> Bruce Griffiths  wrote:
>
>> 1) Relative position of any pair of clocks located up to 2km apart has to be
>> known to within 3cm or so. Post processing is OK, however differential Earth
>> tides between the clock locations may need to be considered.
> That's doable. People at ETHZ got sub cm accuracy from LEA-6T modules
> with post-processing of the recorded phase data with an integration time
> of several hours. Using phase data of multiple timing modules should give
> relative positions with better than 1cm accuracy on these short baselines..
> I don't know how much post-processing is necessary though. Haven't looked
> into the the field of RTK[1] and PPP[2] yet. Probably data from IGS[3] is
> needed as well.
>
>> 2) The difference in the time offset between any pair of clocks located up to
>> 2km apart shall not vary by more than 200ps (1ns time stamp quantisation) or
>> 2ns (10ns timestamp quantisation) over an 8 hour period (at night).
>> Post processing of data to fit wander etc is not practical as the SNR is too
>> low to support this.
> Now this is quite a bit more challenging. While i'd say 1ns should be doable
> (using receivers that are calibrated against each other and using common in
> view mode during post-processing of the data), i'm not so sure whether 200ps
> is possible. What might work is using an LEA-M8F with it's external frequency
> input, to record the phase of an stable external reference (e.g. Rb).
> Averaging that over a dozen minutes or so should make it possible to
> measure the phase of the reference oscillator with 200ps precision, relative
> to the other stations.
>
> Another way would be to use L1/L2 receivers with calibrated antennas.
> I know that BIPM has a GPS station that can deliver time transfer
> accuracy <2ns over a distance of several 100km. It could be possible
> to use such receivers with the <3km distances to deliver 10 times better,
> if they are frequently calibrated (eg. every couple of days).
> But of course, this makes things much more expensive.
>
> But all this is a wild guess. I haven't seen anything like this done.
> If you want a more precise answer i would need to think about the design
> of the system for some time.
>
>
> I guess using some cable/fibre between the telescopes is out of question?
>
>
>             Attila Kinali
>
> [1] http://www.navipedia.net/index.php/Real_Time_Kinematics
> [2] http://www.navipedia.net/index.php/Precise_Point_Positioning
> [3] http://www.igs.org/
>

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

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


  
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] SE880 GPSDO

[Attila Kinali]

On Wed, 27 Apr 2016 01:30:49 +0200
Ilia Platone  wrote:

> I will use a dedicated FPGA design, and the data will be stored into an 
> SDXC card (UHS), or an IDE drive (maybe not), in RAW mode (no filesystem).

Please be aware that SDCards performance spec is peak and best case.
Additionally, you need to prepare for writes taking several ms when
the SDCard firmware remaps blocks. Ie you will need to be able to
buffer several MB of data before you write to the SDCards. It would
probably be a good idea to push the data into a CPU (ARM9, or Cortex-A)
and handle the buffering/writing in software instead of an FPGA.

> Each timestamp will be stored into a word of 48bits, the clock will be 
> 400MHz, so the quantization will be 2.5ns, but the maximum error/clock 
> offset should be 1/10 of this, so 500ps , as said by Bruce.

I thought a little bit more about this problem this morning and came up
with something that should be rather simple to implement:

Assuming that you have an amateur radio license, you could use a 
well located central station to transmit a CW signal in the 70cm or
23cm band. There should be some effort put into this station
to make it stable (eg by using a good rubidium as frequency source,
or even an ensemble) and low noise.

Use this CW signal on all the telescope stations to phase lock a local
OCXO. Using a good OCXO, it should be possible to use loop bandwidths
in the 0.1-10Hz range. My guess is, that this frequency transfer system
would yield stabilities in the order of 10^-12 @ 1s (or even better).
For additional performance, one could modulate the CW with a PRN sequence
to get a better SNR and probably get another order of magnitude out of it.
For the simple CW case, the circuitry should be fairly simple and easy
to do. The PRN case would require at least some processing in an FPGA.

Now that all stations have the "same" frequency, one can use the GPS
module to get the time information using long integration times.
Under the assumption that the (sawtooth corrected) PPS is good to +/-10ns
an has a nice, time-invariant distribution, it should be possible to get
below 1ns in precision within 100s. Using common view phase data it
should be possible to get even better than that. 

Of course, the GPS modules would still need to be calibrated against
eachother to get the accuracy below the 10ns level. I am still not
sure how to go below 1ns, though I think this approach should make
that easier. Most likely you will need some temperature stabilization
of the electronics.

It's also quite easy to verify the frequency transfer by letting
each telescope station transmit a CW signal back to the central
station on a different frequency. Then use some SDR system to extract
the relative phase/frequency of each station.

Attila Kinali

-- 
Reading can seriously damage your ignorance.
-- unknown
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] SE880 GPSDO

[Ilia Platone]

Hi All,

I read from an article about this receiver: C-Max CMMR-6P-60

Can it be useful?

One of the places where I'll setup the telescopes will be in mount 
Carpegna, near where I live. There are the repetitors of television and 
radio over there. Can the carrier wave of such repetitors be used as 
clock? they will be distant 5 Km or less from the observation location.


Regards,

Ilia.


Il 26/04/2016 23:51, Attila Kinali ha scritto:

On Wed, 27 Apr 2016 08:25:55 +1200
Bruce Griffiths  wrote:


1) Relative position of any pair of clocks located up to 2km apart has to be
known to within 3cm or so. Post processing is OK, however differential Earth
tides between the clock locations may need to be considered.

That's doable. People at ETHZ got sub cm accuracy from LEA-6T modules
with post-processing of the recorded phase data with an integration time
of several hours. Using phase data of multiple timing modules should give
relative positions with better than 1cm accuracy on these short baselines.
I don't know how much post-processing is necessary though. Haven't looked
into the the field of RTK[1] and PPP[2] yet. Probably data from IGS[3] is
needed as well.


2) The difference in the time offset between any pair of clocks located up to
2km apart shall not vary by more than 200ps (1ns time stamp quantisation) or
2ns (10ns timestamp quantisation) over an 8 hour period (at night).
Post processing of data to fit wander etc is not practical as the SNR is too
low to support this.

Now this is quite a bit more challenging. While i'd say 1ns should be doable
(using receivers that are calibrated against each other and using common in
view mode during post-processing of the data), i'm not so sure whether 200ps
is possible. What might work is using an LEA-M8F with it's external frequency
input, to record the phase of an stable external reference (e.g. Rb).
Averaging that over a dozen minutes or so should make it possible to
measure the phase of the reference oscillator with 200ps precision, relative
to the other stations.

Another way would be to use L1/L2 receivers with calibrated antennas.
I know that BIPM has a GPS station that can deliver time transfer
accuracy <2ns over a distance of several 100km. It could be possible
to use such receivers with the <3km distances to deliver 10 times better,
if they are frequently calibrated (eg. every couple of days).
But of course, this makes things much more expensive.

But all this is a wild guess. I haven't seen anything like this done.
If you want a more precise answer i would need to think about the design
of the system for some time.


I guess using some cable/fibre between the telescopes is out of question?


Attila Kinali

[1] http://www.navipedia.net/index.php/Real_Time_Kinematics
[2] http://www.navipedia.net/index.php/Precise_Point_Positioning
[3] http://www.igs.org/



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

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Advise on building a DIY GPSDO?

[Magnus Danielson]

On 04/27/2016 01:12 AM, Charles Steinmetz wrote:

Lars wrote:


I have wondered what is meant by a proper digital filter below?

Is a proper digital filter something more than the LP-filter + PI-loop
I use in the DIY Arduino GPSDO?
What is used in commercial GPSDOs?


The loops are substantially more sophisticated than a simple LP filter
-- typically 3rd order or higher.


The lowpass-filter + PI-loop is third order.


 Well-designed commercial GPSDOs also
have several time constants so they can achieve basic lock using a wider
loop, then narrow the loop in steps until it is fully narrow (unless S/N
is low, in which case they may not reach full narrow and should set an
alarm).


Some care needs to be taken in articulating the filter such that you do 
not have to scale the state as you change the parameters. This is 
however fairly simple for both the low-pass filter and integrator (which 
hold state).


With some care you can articulate the P and I in the forms of equations 
relating to the loop parameters you want and compensating for the 
DAC/EFC control gain (exact value not important, but getting bandwidth 
and damping in the right neightborhood is).


The heuristics about when changing parameters takes some learning. One 
of the design criteria is to be able to always capture, but you also 
want it to go as quick as possible. Finding a good balance can be 
problematic. There is tricks to track-in quicker.



 Loop filters in commercial GPSDOs use algorithms that suppress
systematic ripple on the VCO control related to the comparison frequency.


It will be there, so you need to manage it one way or another.


It is extremely unlikely that someone would stumble upon workable
parameters for this sort of loop by trial and error.  One needs to
measure and characterize the open-loop behavior, then carefully design
the loop filter to achieve the desired result.


If you know what you are doing, you can get a good start using analysis, 
knowing the damping and bandwidth you want. It always becomes a measure 
and trim exercise.


Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.