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
><michaeljwout...@gmail.com> 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 <michaeljwout...@gmail.com>
>> 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 <michaeljwout...@gmail.com>
>>> 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 <not.ag...@btinternet.com> 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.

Reply via email to