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