Re: [time-nuts] Improving on basic L1 timing

[Angus]

Hi Michael,

Thanks, that plot and the info gives a useful comparison. 

I think in light of everything, doing some tests with a generally
upgraded setup would be the way to go for now.

There would actually be several rubidiums, although initially with a
bit of cheating - 1 counter, a 10PPS reference and a multiplexer.
Later hopefully a separate TDC's though.

I'm up in the north of Scotland, so unfortunately not much in the way
of reference stations etc nearby, which does rule out some options.

Angus.


On Thu, 16 Jun 2016 17:53:39 +1000, you wrote:

>I promised a plot and here it is.
>
>In a bit more detail:
>
>(a) "GPSCV 800 km baseline" is single-frequency transfer between two
>5071s with standard tubes. I've divided by sqrt(2), assuming both
>clocks contribute equally to TOTDEV.
>
>(b) "std tube spec" is from the 5071 manual, for comparison
>
>(c) "sawtooth corrected pps" is Javad receiver + std tube 5071
>
>(d) "PPP solution" is precise point positioning (carrier phase) clock
>solution, setup (c) but with a receiver which takes external 1 pps and
>10 MHz. The win here is that measurements are now made wrt your clock
>with very high resolution (ten ps or so for carrier phase)  and you
>don't have the sawtooth correction introducing noise.
>The reference timescale in the PPP solution is a zero-weighted mean of
>visible SV clocks.
>
>(e) "CGTTS" is single frequency, modeled ionosphere in CGGTTS files, setup (c)
>
>As you can see, you get a factor of two going from the
>sawtooth-corrected PPS to CGGTTS. You can get rid of some
>ionosphere-induced stability in a common view comparison.
>
>You get another factor of two going to a carrier-phase time solution.
>
>So as I said, you have to work hard/spend big to get a relatively
>modest improvement.
>
>Hope this helps.
>
>Cheers
>Michael
>
>
>
>
>
>On Wed, Jun 15, 2016 at 4:21 PM, Michael Wouters
> wrote:
>> I should have added,  if you do all of the above, the improvement in
>> stability over just using a sawtooth-corrected PPS is not all that
>> spectacular, a factor of two or three. I'll post a plot of some data
>> tomorrow.
>>
>> Cheers
>> Michael.
>>
>>
>> On Wednesday, 15 June 2016, Michael Wouters 
>> wrote:
>>>
>>> If you followed the link to www.openttp.org and are wondering where the
>>> software is, follow the link on the home page to GitHub and then look in the
>>> Develop branch. The ublox branch is for the new '8' series receivers.
>>>
>>> Cheers
>>> Michael
>>>
>>> On Tuesday, 14 June 2016, Michael Wouters 
>>> wrote:

 Hello Angus

 If you have 3 rubidiums of similar stability + 3 counters, you could
 do a 3-cornered hat.

 Otherwise, GPS common view to a better clock may be an option. If you
 are reasonably close to a national standards lab, you might be able to
 use their time-transfer files to compare your rubidiums with their
 time scale - not everyone makes them publically available though.
 Otherwise, if there is an IGS station near you, you could use the
 station RINEX files and IGS clock solutions which are freely
 available. Many IGS stations have a H-maser as the local clock. But it
 may be just as good to simply use the comparison with GPS time
 inherent in the time-transfer file.

 The advantage of generating a time-transfer file is the possibility of
 then improving upon the various corrections broadcast by GPS,
 effectively repeating what the GPS receiver does to generate its
 realization of GPS time but with better data.

 With post-processing, the short to medium term (less than 1 day)
 performance  can be improved a bit as you are suggesting when you
 referred to "atmospheric issues". Improved ionospheric models are
 available  or if there is an IGS station nearby, for example, the
 measured ionosphere could be used. Other improvements can be had with
 good antenna coordinates and using final orbits in the processing.

 What can you use for your time-transfer receiver ? Some low-cost
 single-frequency receivers are suitable eg the Trimble Resolution T.
 The essential requirement is the availability of  raw code
 measurements - with these you can generate CGGTTS time-transfer files
 and/or RINEX observation files.

 At least part of the software infrastructure to do this exists: the
 OpenTTP project (www.openttp.org) has software for CGGTTS and RINEX
 file generation for a few older,single frequency receivers, with
 support for some other,current receivers under active development.
 There is other software around, but it is orientated towards dual
 frequency receivers and carrier phase processing.

 Although it would be relatively straightforward to hack in use of
 improved ionosphere, using final orbits is a bit harder since these
 are not parameterized the same way as 

Re: [time-nuts] Improving on basic L1 timing

[Angus]

>Make sure you have good skyview (aka good geometry) and very little
>multipath. Both effects can affect the precision of your solution
>much more than the ionospheric delay variation.

Main one is on the peak of a slate roof. Nothing else much higher
around except a large sycamore tree. There's another antenna at the
edge of the roof about 1.5m below the peak, close to one end of the
house, and although it does give slightly poorer stability, it did not
look to be by a huge amount when I checked it.

The reason that I was particularly looking at the ionospheric delay
was that the diurnal variation was quite pronounced. The rubidium and
gps were both in temperature controlled enclosures. That does still
leave the antenna, cable and splitter, along with the counter and PPS
buffering.

>If you live in continental Europe, then you will inevitabely have an
>IGS station nearby. They are everywhere! :-)

I think it's a few hundred km for me!

>The only other thing I can think of is using multiple Rb's as reference,
>measure their temperature, air pressure and drift against GPS. 

That actually is the plan. Most would also be temperature controlled.

>Use all
>this data to build a clock model (aka Kalman filter) that compensates
>for temp/pressure/aging and measure the Rb under test against this ensemble.
>But that's not something that already exists and is ready to use.

That's just the sort of thing that was always the end goal for this
project - control what can be, understand and compensate for what
can't. 

The rubidiums are what I'm primarily interested in - the gps was
originally there for a basic reference, as well as for long term drift
correction. 
Thing is, since I don't have access to a H-maser or good cesium, I'm
also trying to see how well I can get gps to do as a medium to long
term reference. 

It may well be best just to run some ordinary timing receivers for a
while, and use the rubidiums for the rest. By then I'd have a better
idea what performance would be needed to be useful, and if anything
available to me would do that.

Another complication is that a lot of the old data I have was done
with an M12+T without sawtooth correction. With filtering or averaging
it's irrelevant medium to long term which is why I didn't bother, but
it messes up Adev plots making comparisons with a lot of the data out
there more difficult. Some tests with other receivers and corrected or
sawtooth-free data would be a good start.

Angus.
___
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] Improving on basic L1 timing

[Michael Wouters]

I promised a plot and here it is.

In a bit more detail:

(a) "GPSCV 800 km baseline" is single-frequency transfer between two
5071s with standard tubes. I've divided by sqrt(2), assuming both
clocks contribute equally to TOTDEV.

(b) "std tube spec" is from the 5071 manual, for comparison

(c) "sawtooth corrected pps" is Javad receiver + std tube 5071

(d) "PPP solution" is precise point positioning (carrier phase) clock
solution, setup (c) but with a receiver which takes external 1 pps and
10 MHz. The win here is that measurements are now made wrt your clock
with very high resolution (ten ps or so for carrier phase)  and you
don't have the sawtooth correction introducing noise.
The reference timescale in the PPP solution is a zero-weighted mean of
visible SV clocks.

(e) "CGTTS" is single frequency, modeled ionosphere in CGGTTS files, setup (c)

As you can see, you get a factor of two going from the
sawtooth-corrected PPS to CGGTTS. You can get rid of some
ionosphere-induced stability in a common view comparison.

You get another factor of two going to a carrier-phase time solution.

So as I said, you have to work hard/spend big to get a relatively
modest improvement.

Hope this helps.

Cheers
Michael





On Wed, Jun 15, 2016 at 4:21 PM, Michael Wouters
 wrote:
> I should have added,  if you do all of the above, the improvement in
> stability over just using a sawtooth-corrected PPS is not all that
> spectacular, a factor of two or three. I'll post a plot of some data
> tomorrow.
>
> Cheers
> Michael.
>
>
> On Wednesday, 15 June 2016, Michael Wouters 
> wrote:
>>
>> If you followed the link to www.openttp.org and are wondering where the
>> software is, follow the link on the home page to GitHub and then look in the
>> Develop branch. The ublox branch is for the new '8' series receivers.
>>
>> Cheers
>> Michael
>>
>> On Tuesday, 14 June 2016, Michael Wouters 
>> wrote:
>>>
>>> Hello Angus
>>>
>>> If you have 3 rubidiums of similar stability + 3 counters, you could
>>> do a 3-cornered hat.
>>>
>>> Otherwise, GPS common view to a better clock may be an option. If you
>>> are reasonably close to a national standards lab, you might be able to
>>> use their time-transfer files to compare your rubidiums with their
>>> time scale - not everyone makes them publically available though.
>>> Otherwise, if there is an IGS station near you, you could use the
>>> station RINEX files and IGS clock solutions which are freely
>>> available. Many IGS stations have a H-maser as the local clock. But it
>>> may be just as good to simply use the comparison with GPS time
>>> inherent in the time-transfer file.
>>>
>>> The advantage of generating a time-transfer file is the possibility of
>>> then improving upon the various corrections broadcast by GPS,
>>> effectively repeating what the GPS receiver does to generate its
>>> realization of GPS time but with better data.
>>>
>>> With post-processing, the short to medium term (less than 1 day)
>>> performance  can be improved a bit as you are suggesting when you
>>> referred to "atmospheric issues". Improved ionospheric models are
>>> available  or if there is an IGS station nearby, for example, the
>>> measured ionosphere could be used. Other improvements can be had with
>>> good antenna coordinates and using final orbits in the processing.
>>>
>>> What can you use for your time-transfer receiver ? Some low-cost
>>> single-frequency receivers are suitable eg the Trimble Resolution T.
>>> The essential requirement is the availability of  raw code
>>> measurements - with these you can generate CGGTTS time-transfer files
>>> and/or RINEX observation files.
>>>
>>> At least part of the software infrastructure to do this exists: the
>>> OpenTTP project (www.openttp.org) has software for CGGTTS and RINEX
>>> file generation for a few older,single frequency receivers, with
>>> support for some other,current receivers under active development.
>>> There is other software around, but it is orientated towards dual
>>> frequency receivers and carrier phase processing.
>>>
>>> Although it would be relatively straightforward to hack in use of
>>> improved ionosphere, using final orbits is a bit harder since these
>>> are not parameterized the same way as the broadcast orbits. Maybe
>>> someone on time-nuts has software to do the conversion (and this would
>>> have to be hacked into the OpenTTP software, rather than the final
>>> time comparison).
>>>
>>> The sort of performance you get on a zero baseline is a TDEV of a few
>>> ns - you can extrapolate frequency stability from that.
>>> On a 1000 km baseline, you can compare two Cs to better than 1 part in
>>> 10^13 @ 1 day.
>>>
>>> All of the above is software-oriented, whereas you seem to be looking
>>> for a hardware solution, but that's what I know best.
>>>
>>> Cheers
>>> Michael
>>>
>>> On Tue, Jun 14, 2016 at 6:16 PM, Angus  

Re: [time-nuts] Improving on basic L1 timing

[Michael Wouters]

I should have added,  if you do all of the above, the improvement in
stability over just using a sawtooth-corrected PPS is not all that
spectacular, a factor of two or three. I'll post a plot of some data
tomorrow.

Cheers
Michael.

On Wednesday, 15 June 2016, Michael Wouters 
wrote:

> If you followed the link to www.openttp.org and are wondering where the
> software is, follow the link on the home page to GitHub and then look in
> the Develop branch. The ublox branch is for the new '8' series receivers.
>
> Cheers
> Michael
>
> On Tuesday, 14 June 2016, Michael Wouters  > wrote:
>
>> Hello Angus
>>
>> If you have 3 rubidiums of similar stability + 3 counters, you could
>> do a 3-cornered hat.
>>
>> Otherwise, GPS common view to a better clock may be an option. If you
>> are reasonably close to a national standards lab, you might be able to
>> use their time-transfer files to compare your rubidiums with their
>> time scale - not everyone makes them publically available though.
>> Otherwise, if there is an IGS station near you, you could use the
>> station RINEX files and IGS clock solutions which are freely
>> available. Many IGS stations have a H-maser as the local clock. But it
>> may be just as good to simply use the comparison with GPS time
>> inherent in the time-transfer file.
>>
>> The advantage of generating a time-transfer file is the possibility of
>> then improving upon the various corrections broadcast by GPS,
>> effectively repeating what the GPS receiver does to generate its
>> realization of GPS time but with better data.
>>
>> With post-processing, the short to medium term (less than 1 day)
>> performance  can be improved a bit as you are suggesting when you
>> referred to "atmospheric issues". Improved ionospheric models are
>> available  or if there is an IGS station nearby, for example, the
>> measured ionosphere could be used. Other improvements can be had with
>> good antenna coordinates and using final orbits in the processing.
>>
>> What can you use for your time-transfer receiver ? Some low-cost
>> single-frequency receivers are suitable eg the Trimble Resolution T.
>> The essential requirement is the availability of  raw code
>> measurements - with these you can generate CGGTTS time-transfer files
>> and/or RINEX observation files.
>>
>> At least part of the software infrastructure to do this exists: the
>> OpenTTP project (www.openttp.org) has software for CGGTTS and RINEX
>> file generation for a few older,single frequency receivers, with
>> support for some other,current receivers under active development.
>> There is other software around, but it is orientated towards dual
>> frequency receivers and carrier phase processing.
>>
>> Although it would be relatively straightforward to hack in use of
>> improved ionosphere, using final orbits is a bit harder since these
>> are not parameterized the same way as the broadcast orbits. Maybe
>> someone on time-nuts has software to do the conversion (and this would
>> have to be hacked into the OpenTTP software, rather than the final
>> time comparison).
>>
>> The sort of performance you get on a zero baseline is a TDEV of a few
>> ns - you can extrapolate frequency stability from that.
>> On a 1000 km baseline, you can compare two Cs to better than 1 part in
>> 10^13 @ 1 day.
>>
>> All of the above is software-oriented, whereas you seem to be looking
>> for a hardware solution, but that's what I know best.
>>
>> Cheers
>> Michael
>>
>> On Tue, Jun 14, 2016 at 6:16 PM, Angus  wrote:
>> > Hi,
>> >
>> > I'm planning to test some rubidiums again, but since Santa never did
>> > get me that hydrogen maser I asked for, I'm still stuck with ordinary
>> > gps timing receivers as a separate medium to long term reference. The
>> > atmospheric issues are probably the main ones I would like to get rid
>> > of, although the more errors removed the better.
>> >
>> > It does not have to be done in real time, but even an single test run
>> > would last weeks, so there could be a lot of data to tie together.
>> >
>> > It would really need to be something that actually exists rather than
>> > just an idea of how it might be done, since I really just don't have
>> > time for any more major projects anytime soon. I've found from
>> > experience that too much time spent making the test gear etc means
>> > that I don't get the time to actually use it!
>> >
>> > I'm also looking for something that's not too expensive - like up to
>> > hundreds rather than thousands of pounds.
>> > A good cesium or 2+ frequency gps with relevant options might be fine,
>> > but also rather out of my price range.
>> >
>> > BTW, I do plan on uploading the end results, in case anyone is
>> > interested.
>> >
>> >
>> > If anyone knows of some way to do this, (or even has something
>> > appropriate they want to sell) I'd appreciate hearing 

Re: [time-nuts] Improving on basic L1 timing

[Bob Camp]

Hi

With some searching and dedicated bidding, you can find older L1/L2 GPS 
gear fairly cheaply. It may take a year or two of bidding to get something you
can use….That gets you back to the issue of “am I fiddling around waiting 
to do something or doing it”. 

Bob

> On Jun 14, 2016, at 4:16 AM, Angus  wrote:
> 
> Hi,
> 
> I'm planning to test some rubidiums again, but since Santa never did
> get me that hydrogen maser I asked for, I'm still stuck with ordinary
> gps timing receivers as a separate medium to long term reference. The
> atmospheric issues are probably the main ones I would like to get rid
> of, although the more errors removed the better.
> 
> It does not have to be done in real time, but even an single test run
> would last weeks, so there could be a lot of data to tie together.
> 
> It would really need to be something that actually exists rather than
> just an idea of how it might be done, since I really just don't have
> time for any more major projects anytime soon. I've found from
> experience that too much time spent making the test gear etc means
> that I don't get the time to actually use it!
> 
> I'm also looking for something that's not too expensive - like up to
> hundreds rather than thousands of pounds.
> A good cesium or 2+ frequency gps with relevant options might be fine,
> but also rather out of my price range. 
> 
> BTW, I do plan on uploading the end results, in case anyone is
> interested.
> 
> 
> If anyone knows of some way to do this, (or even has something
> appropriate they want to sell) I'd appreciate hearing about it, on or
> off-list.
> 
> Thanks,
> Angus.
> ___
> 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] Improving on basic L1 timing

[Michael Wouters]

If you followed the link to www.openttp.org and are wondering where the
software is, follow the link on the home page to GitHub and then look in
the Develop branch. The ublox branch is for the new '8' series receivers.

Cheers
Michael

On Tuesday, 14 June 2016, Michael Wouters  wrote:

> Hello Angus
>
> If you have 3 rubidiums of similar stability + 3 counters, you could
> do a 3-cornered hat.
>
> Otherwise, GPS common view to a better clock may be an option. If you
> are reasonably close to a national standards lab, you might be able to
> use their time-transfer files to compare your rubidiums with their
> time scale - not everyone makes them publically available though.
> Otherwise, if there is an IGS station near you, you could use the
> station RINEX files and IGS clock solutions which are freely
> available. Many IGS stations have a H-maser as the local clock. But it
> may be just as good to simply use the comparison with GPS time
> inherent in the time-transfer file.
>
> The advantage of generating a time-transfer file is the possibility of
> then improving upon the various corrections broadcast by GPS,
> effectively repeating what the GPS receiver does to generate its
> realization of GPS time but with better data.
>
> With post-processing, the short to medium term (less than 1 day)
> performance  can be improved a bit as you are suggesting when you
> referred to "atmospheric issues". Improved ionospheric models are
> available  or if there is an IGS station nearby, for example, the
> measured ionosphere could be used. Other improvements can be had with
> good antenna coordinates and using final orbits in the processing.
>
> What can you use for your time-transfer receiver ? Some low-cost
> single-frequency receivers are suitable eg the Trimble Resolution T.
> The essential requirement is the availability of  raw code
> measurements - with these you can generate CGGTTS time-transfer files
> and/or RINEX observation files.
>
> At least part of the software infrastructure to do this exists: the
> OpenTTP project (www.openttp.org) has software for CGGTTS and RINEX
> file generation for a few older,single frequency receivers, with
> support for some other,current receivers under active development.
> There is other software around, but it is orientated towards dual
> frequency receivers and carrier phase processing.
>
> Although it would be relatively straightforward to hack in use of
> improved ionosphere, using final orbits is a bit harder since these
> are not parameterized the same way as the broadcast orbits. Maybe
> someone on time-nuts has software to do the conversion (and this would
> have to be hacked into the OpenTTP software, rather than the final
> time comparison).
>
> The sort of performance you get on a zero baseline is a TDEV of a few
> ns - you can extrapolate frequency stability from that.
> On a 1000 km baseline, you can compare two Cs to better than 1 part in
> 10^13 @ 1 day.
>
> All of the above is software-oriented, whereas you seem to be looking
> for a hardware solution, but that's what I know best.
>
> Cheers
> Michael
>
> On Tue, Jun 14, 2016 at 6:16 PM, Angus  > wrote:
> > Hi,
> >
> > I'm planning to test some rubidiums again, but since Santa never did
> > get me that hydrogen maser I asked for, I'm still stuck with ordinary
> > gps timing receivers as a separate medium to long term reference. The
> > atmospheric issues are probably the main ones I would like to get rid
> > of, although the more errors removed the better.
> >
> > It does not have to be done in real time, but even an single test run
> > would last weeks, so there could be a lot of data to tie together.
> >
> > It would really need to be something that actually exists rather than
> > just an idea of how it might be done, since I really just don't have
> > time for any more major projects anytime soon. I've found from
> > experience that too much time spent making the test gear etc means
> > that I don't get the time to actually use it!
> >
> > I'm also looking for something that's not too expensive - like up to
> > hundreds rather than thousands of pounds.
> > A good cesium or 2+ frequency gps with relevant options might be fine,
> > but also rather out of my price range.
> >
> > BTW, I do plan on uploading the end results, in case anyone is
> > interested.
> >
> >
> > If anyone knows of some way to do this, (or even has something
> > appropriate they want to sell) I'd appreciate hearing about it, on or
> > off-list.
> >
> > Thanks,
> > Angus.
> > ___
> > 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 

Re: [time-nuts] Improving on basic L1 timing

[Attila Kinali]

On Tue, 14 Jun 2016 21:37:20 +1000
Michael Wouters  wrote:

> On Tue, Jun 14, 2016 at 6:16 PM, Angus  wrote:
> > I'm planning to test some rubidiums again, but since Santa never did
> > get me that hydrogen maser I asked for, I'm still stuck with ordinary
> > gps timing receivers as a separate medium to long term reference. The
> > atmospheric issues are probably the main ones I would like to get rid
> > of, although the more errors removed the better.

Make sure you have good skyview (aka good geometry) and very little
multipath. Both effects can affect the precision of your solution
much more than the ionospheric delay variation.


> Otherwise, GPS common view to a better clock may be an option. If you
> are reasonably close to a national standards lab, you might be able to
> use their time-transfer files to compare your rubidiums with their
> time scale - not everyone makes them publically available though.
> Otherwise, if there is an IGS station near you, you could use the
> station RINEX files and IGS clock solutions which are freely
> available. Many IGS stations have a H-maser as the local clock. But it
> may be just as good to simply use the comparison with GPS time
> inherent in the time-transfer file.

If you live in continental Europe, then you will inevitabely have an
IGS station nearby. They are everywhere! :-)

I wonder how good the final IGS solution for ionospheric and orbits
are, repectively how much you get out of waiting longer?
Especially if the next IGS station is more than a couple km away.
Does anyone have data on that?

> All of the above is software-oriented, whereas you seem to be looking
> for a hardware solution, but that's what I know best.
> and follow the instructions there.

I don't think you can get much better with an hardware only solution
than by using the IGS files. Even if an L1/L2 receiver gives you better
ionospheric estimates, the orbit uncertainties still need postprocessing
to be corrected.


The only other thing I can think of is using multiple Rb's as reference,
measure their temperature, air pressure and drift against GPS. Use all
this data to build a clock model (aka Kalman filter) that compensates
for temp/pressure/aging and measure the Rb under test against this ensemble.

But that's not something that already exists and is ready to use.
And I doubt that this can shave off much more than one order of magnitude
in ADEV.

Attila Kinali

-- 
Malek's Law:
Any simple idea will be worded in the most complicated way.
___
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] Improving on basic L1 timing

[Michael Wouters]

Hello Angus

If you have 3 rubidiums of similar stability + 3 counters, you could
do a 3-cornered hat.

Otherwise, GPS common view to a better clock may be an option. If you
are reasonably close to a national standards lab, you might be able to
use their time-transfer files to compare your rubidiums with their
time scale - not everyone makes them publically available though.
Otherwise, if there is an IGS station near you, you could use the
station RINEX files and IGS clock solutions which are freely
available. Many IGS stations have a H-maser as the local clock. But it
may be just as good to simply use the comparison with GPS time
inherent in the time-transfer file.

The advantage of generating a time-transfer file is the possibility of
then improving upon the various corrections broadcast by GPS,
effectively repeating what the GPS receiver does to generate its
realization of GPS time but with better data.

With post-processing, the short to medium term (less than 1 day)
performance  can be improved a bit as you are suggesting when you
referred to "atmospheric issues". Improved ionospheric models are
available  or if there is an IGS station nearby, for example, the
measured ionosphere could be used. Other improvements can be had with
good antenna coordinates and using final orbits in the processing.

What can you use for your time-transfer receiver ? Some low-cost
single-frequency receivers are suitable eg the Trimble Resolution T.
The essential requirement is the availability of  raw code
measurements - with these you can generate CGGTTS time-transfer files
and/or RINEX observation files.

At least part of the software infrastructure to do this exists: the
OpenTTP project (www.openttp.org) has software for CGGTTS and RINEX
file generation for a few older,single frequency receivers, with
support for some other,current receivers under active development.
There is other software around, but it is orientated towards dual
frequency receivers and carrier phase processing.

Although it would be relatively straightforward to hack in use of
improved ionosphere, using final orbits is a bit harder since these
are not parameterized the same way as the broadcast orbits. Maybe
someone on time-nuts has software to do the conversion (and this would
have to be hacked into the OpenTTP software, rather than the final
time comparison).

The sort of performance you get on a zero baseline is a TDEV of a few
ns - you can extrapolate frequency stability from that.
On a 1000 km baseline, you can compare two Cs to better than 1 part in
10^13 @ 1 day.

All of the above is software-oriented, whereas you seem to be looking
for a hardware solution, but that's what I know best.

Cheers
Michael

On Tue, Jun 14, 2016 at 6:16 PM, Angus  wrote:
> Hi,
>
> I'm planning to test some rubidiums again, but since Santa never did
> get me that hydrogen maser I asked for, I'm still stuck with ordinary
> gps timing receivers as a separate medium to long term reference. The
> atmospheric issues are probably the main ones I would like to get rid
> of, although the more errors removed the better.
>
> It does not have to be done in real time, but even an single test run
> would last weeks, so there could be a lot of data to tie together.
>
> It would really need to be something that actually exists rather than
> just an idea of how it might be done, since I really just don't have
> time for any more major projects anytime soon. I've found from
> experience that too much time spent making the test gear etc means
> that I don't get the time to actually use it!
>
> I'm also looking for something that's not too expensive - like up to
> hundreds rather than thousands of pounds.
> A good cesium or 2+ frequency gps with relevant options might be fine,
> but also rather out of my price range.
>
> BTW, I do plan on uploading the end results, in case anyone is
> interested.
>
>
> If anyone knows of some way to do this, (or even has something
> appropriate they want to sell) I'd appreciate hearing about it, on or
> off-list.
>
> Thanks,
> Angus.
> ___
> 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] Improving on basic L1 timing

[Angus]

Hi,

I'm planning to test some rubidiums again, but since Santa never did
get me that hydrogen maser I asked for, I'm still stuck with ordinary
gps timing receivers as a separate medium to long term reference. The
atmospheric issues are probably the main ones I would like to get rid
of, although the more errors removed the better.

It does not have to be done in real time, but even an single test run
would last weeks, so there could be a lot of data to tie together.

It would really need to be something that actually exists rather than
just an idea of how it might be done, since I really just don't have
time for any more major projects anytime soon. I've found from
experience that too much time spent making the test gear etc means
that I don't get the time to actually use it!

I'm also looking for something that's not too expensive - like up to
hundreds rather than thousands of pounds.
A good cesium or 2+ frequency gps with relevant options might be fine,
but also rather out of my price range. 

BTW, I do plan on uploading the end results, in case anyone is
interested.


If anyone knows of some way to do this, (or even has something
appropriate they want to sell) I'd appreciate hearing about it, on or
off-list.

Thanks,
Angus.
___
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.