Re: [time-nuts] Thunderbolt code phase measurement

[Michael Wouters]

Hello Mark

By "hosing" do you mean that you lose messages for the next second? That
was a problem with the Resolution T too. I wanted to get ephemerides from
the receiver so I ended up minimising lost messages by tracking satellites
as they popped into view, and then requesting an ephemeris after a suitable
wait. This problem went away in the SMT 360.

Regard resolving the ms ambiguity, you could look at the code in mktimetx,
which does just what Magnus D describes.
The code lives at
https://github.com/openttp/openttp/tree/master/software/gpscv/common/process/

Cheers
Michael

On Wed, 16 May 2018 at 4:02 pm, Mark Sims  wrote:

> Many thanks Peter for confirming what I suspected.   The problem with the
> Trimble receivers is that requesting the satellite C/A code data can hose
> up a lot of them.  So, I'm stuck with calculating the integer number of
> milliseconds.   How to do that?  I do know my position to a few feet.
>
> I have Lady Heather generating RINEX files for the Ublox timing receivers,
> the NVS-08, the Furuno GT-87, and the Ashtech Z12 (with both L1/L2 data).
> It would be nice to be able to support the Trimble receivers.   With L1
> only data I am getting results in the < 200 mm range.  The Z12 with L1/L2
> data gets me to around 40 mm.
>
> 
>
> > If you know your position to within 150 kilometers (0.5 ms), you can
> dispense with the pseudorange-assembly arithmetic and just use the code
> phase directly, after adding in the appropriate integer number of
> milliseconds, only one of which will put you within your known
> 300-kilometer-diameter (1 ms) sphere.
> ___
> 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] nuts about position

[Michael Wouters]

The US-based services work fine with non-local data. I've  used them with
Australian locations. The IGS network is global so nearby stations in the
IGS network are used for the solution. There are non-US services too, like
AusPos.

The topic of better antenna coordinates seems to come up now and again. It
might be a good cooperative  timenuts project to put together a travelling
receiver system that could be used to survey antenna positions. With a bit
more effort, it could also be used to calibrate delays, where receiver data
is being post-processed for time-transfer.

Cheers
Michael

On Fri, 27 Apr 2018 at 8:02 am, Bob kb8tq  wrote:

> Hi
>
> If you shop for a while on eBay, you can find older L1 / L2 survey
> receivers for < $300 and
> an antenna that will work for them for < $100. Yes it will take a bit of
> heavy duty shopping and
> some level of “wait and see”.  How well they work and how much of a pain
> is associated with
> this process ….. who knows.
>
> Once you have a radio you can get data out of, submitting the files to any
> of the free services
> in the US is pretty easy. If you are outside the US, you may still be fine
> or you may have a tough
> time with the data reduction.
>
> Bob
>
> > On Apr 26, 2018, at 1:04 PM, Scott McGrath  wrote:
> >
> > Swiftnav has a centimeter accurate multi band receiver RTK-585. Its
> about 600 bucks minus antenna.
> >
> > You would need a choke ring antenna to get centimeter accuracy i think
> but receiver with a quality timing antenna will provide necessary accuracy
> >
> > On Apr 25, 2018, at 8:06 AM, George Watson  wrote:
> >
> > Create your own DGPS?
> >
> > Trimble is good at this.
> >
> > George K. Watson
> > K0IW
> >
> >> On Apr 25, 2018, at 10:56 AM, Tom Van Baak  wrote:
> >>
> >> List -- I had a recent query by a researcher who would like to pinpoint
> the location of his telescope(s) within 0.3 meters. Also (he must be a true
> scientist) he wants to do this on-the-cheap. He may have timing
> requirements as well, but that's another posting.
> >>
> >> So I toss the GPS question to the group. Surely some of you have
> crossed the line from precise time to precise location?
> >>
> >> How easy, how cheap, how possible is it to obtain 0.3 m accuracy in 3D
> position?
> >>
> >> When we run our GPSDO in survey mode how accurate a position do we get
> after an hour, or even 24 or 48 hours? And here I mean accurate, not
> stable. Have any of you compared that self-reported, self-survey result
> against an independently measured professional result or known benchmark?
> >>
> >> Do you know if cheap ublox 5/6/7/8 series receivers are capable of 1
> foot accuracy given enough time?
> >>
> >> If not, what improvement would -T models and RINEX-based web-service
> post-processing provide?
> >>
> >> It that's still not close enough to 0.3 m, is one then forced to use
> more expensive multi-frequency (L1/L2) or multi-band (GPS, GLONASS,
> Galileo) to achieve this level of precision? If so, how cheaply can one do
> this? Or is the learning curve more expensive than just hiring an survey
> specialist to make a one-time cm-level measurement for you?
> >>
> >> Something tells me 1 foot accuracy in position is possible and actually
> easier than 1 ns accuracy in time. I'm hoping some of you can help
> recommend solution(s) to the researcher's question or shed light on this
> interesting challenge.
> >>
> >> Thanks,
> >> /tvb
> >>
> >> ___
> >> 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.
>
> ___
> 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] RINEX for Android

[Michael Wouters]

Hello Jim,

There's a Perl script here
https://github.com/openttp/openttp/blob/develop/software/gpscv/ublox/ubloxlog.pl
that's for configuring and logging a ublox NEO-8MT. The caveat is that
it uses a custom file format. However, the associated processing
software, mktimetx,
will read this and produce RINEX. You will need to produce a fake file
of time-interval counter readings though, since mktimetx folds these
into the pseudoranges
(the software is for GPS common view time-transfer). As you will see,
this is all running on a Beaglebone.

If you want to modify the script to produce native binary files, the
equivalent script for the NVS NV08C
https://github.com/openttp/openttp/blob/develop/software/gpscv/nvs/nv08log.pl
does this, so you can use it as a guide for modifying - there are just
a few lines to change.

Cheers
Michael


On Thu, Apr 12, 2018 at 8:46 PM, jimlux  wrote:
> It turns out that some of the newer Android phones support an API which
> returns raw GNSS data and that can be logged to a file in RINEX format.
> There's a few apps out there that do this although I've not tried it (my
> Samsung S6 doesn't have the right hardware).
>
> In any case, it might be interesting, if you have one of these devices, to
> let it log for a while, with the phone in a fixed place, and then post
> process the data.
>
> I ran across this when looking for software to generate RINEX files from
> data from NEO-7 GPS modules (which I'm still looking for)
>
> ___
> 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] new longwave time service planned in India

[Michael Wouters]

India has IRNSS, their own GNSS augmentation system.
FWIW, S Korea is about to start testing its own radio time signal but the
range is only 500 km or so as I remember.

Cheers
Michael

On Thu, 5 Apr 2018 at 12:23 am, Bob kb8tq  wrote:

> Hi
>
> It’s also *way* cheaper than putting up your own satellite based timing
> and navigation
> gear. I suspect that the whole “what if this or that set of  sat’s have
> issues?” thing is
> beginning to sink in ….
>
> Bob
>
> > On Apr 4, 2018, at 2:47 AM, Poul-Henning Kamp 
> wrote:
> >
> > 
> > In message 

Re: [time-nuts] PRS10 Information and help needed

[Michael Wouters]

Hello Arnold,

A frequency offset of a part in 10E-11 still sounds healthy to me. I wonder
whether there is some kind of electronic problem?
I have run 40 or so PRs10s and the lamp is the usual bit that dies.
If you hook up a computer to the RS232 port, there are lots of diagnostics
available.

Cheers
Michael

On Thu, 1 Mar 2018 at 5:47 am, Arnold Tibus  wrote:

> Hello fellow timenuts,
>
> for my old PRS10 I need some information and help with technical
> informations.
> I have this item bought quite some years ago and I have manufactured an
> interface cable with the special connector last year. Did work fine.
> Taken out of storage I do get anymore the lock and PPS signal out.
> The 10 MHz output does look very good, the unloaded sine voltage is 2.8
> Vpp and the frequency is very precise and stable very close to the
> trimble thunderbolt GPS-out signal at abt. 10E-11.
> In the annex you can see the data output with more delailed info.
> Can somebody tell me more, is the life at the end and what and how can
> be done to revitalize this nice time machine? How much time more is
> expectable?
>
> kind regards,
>
> Arnold
> ___
> 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] Team of physicists repeats tvb Project GREAT

[Michael Wouters]

Sorry, missed the last character in the URL:

https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.118.073601

On Thu, 15 Feb 2018 at 4:42 pm, Michael Wouters <michaeljwout...@gmail.com>
wrote:

> There's a photo here:
>
> https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.118.07360
>
> Cheers
> Michael
>
> On Thu, 15 Feb 2018 at 1:47 pm, Chris Caudle <ch...@chriscaudle.org>
> wrote:
>
>> On Wed, February 14, 2018 7:06 pm, jimlux wrote:
>> > At substantially more expense, and with an experimental lattice clock,
>>
>> Does that schematic figure in the paper imply that the "transportable"
>> strontium and ytterbium clocks are built into trailers instead of the
>> traditional rack enclosure?
>> Actually now that I look more closely it looks like maybe two trailers.
>> Doesn't seem like something that Jim is going to be flying any time soon.
>>
>> --
>> Chris Caudle
>>
>>
>> ___
>> 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] Team of physicists repeats tvb Project GREAT

[Michael Wouters]

There's a photo here:

https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.118.07360

Cheers
Michael

On Thu, 15 Feb 2018 at 1:47 pm, Chris Caudle  wrote:

> On Wed, February 14, 2018 7:06 pm, jimlux wrote:
> > At substantially more expense, and with an experimental lattice clock,
>
> Does that schematic figure in the paper imply that the "transportable"
> strontium and ytterbium clocks are built into trailers instead of the
> traditional rack enclosure?
> Actually now that I look more closely it looks like maybe two trailers.
> Doesn't seem like something that Jim is going to be flying any time soon.
>
> --
> Chris Caudle
>
>
> ___
> 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] Anyone have experience with this antenna?

[Michael Wouters]

That does represent a limiting case but it's a bit pessimistic. The longest
path is for very shallow incident angles eg a 3 mm thick and 150 mm radius
disk gives an angle of only about 1 degree. At 10 degrees, the path is
about 20 mm; with a refractive index of 1.5, the path is only 10 mm longer.
10 degrees might be what you set in the receiver's elevation mask.

A mm thick layer of dirt is just going to be roughly another mm of plastic;
worse if it's absorbed moisture, true.

You have a point about water. Water has about 10 times the refractive index
of plastic (real part of n)  so this is more of a worry. A 1 mm film will
have triple the path through a nominal 3 mm of plastic so at 10 degrees
incidence there is now about 40 mm extra path which you might see in
post-processing. But you're not going to see that in the 1 pps.

Cheers
Michael

On Wed, 7 Feb 2018 at 8:14 am, Bob kb8tq <kb...@n1k.org> wrote:

> Hi
>
> Since we are talking about an L1 / L2 antenna here, a reasonable assumption
> would be that the target is something better than an “average result”. If
> you construct
> a cover out of a piece of PVC pipe (as shown in the original drawing),
> your worst
> case path has a foot or so of PVC in it compared to a best case path with
> well under
> a tenth of an inch. That’s going to give you a bit of variation ….. Add
> some dirt or water
> or ice to the equation and who knows what the result might be.
>
> Bob
>
> > On Feb 6, 2018, at 3:45 PM, Michael Wouters <michaeljwout...@gmail.com>
> wrote:
> >
> > I can see why the geodetic community would worry about antenna phase
> centre
> > variation when a radome is installed but is it really an issue in timing
> > applications? The few papers I've read suggest PCVs of less than 10 mm,
> or
> > equivalently, 30 ps. This is at the level of precision available from
> > post-processed, carrier phase time-transfer but  invisible in the 1 pps
> > coming out of your receiver, even with a good sawtooth correction. Am I
> > missing something?
> >
> > Cheers
> > Michael
> >
> > On Wed, 7 Feb 2018 at 4:14 am, Bob kb8tq <kb...@n1k.org> wrote:
> >
> >> Hi
> >>
> >> There are “cell site” specific GPS antennas on the market. Panasonic has
> >> had one out
> >> for quite a while. I’m sure there are several others.
> >>
> >> One issue with doing any sort of “cover” for a precision antenna is
> >> distorting it’s pattern.
> >> Plastic (or whatever you use) will have different properties than air. A
> >> path through a blob
> >> of “not air” will change the effective path length. That impacts the
> >> timing and thus the
> >> navigation solution. If you are worried about 2mm sort of pattern
> >> accuracy, things get
> >> tricky. Early on, there was a big “throw out the radomes push when this
> >> was first noticed.
> >>
> >> Bob
> >>
> >>> On Feb 6, 2018, at 6:15 AM, Bo Hansen <timen...@rudius.net> wrote:
> >>>
> >>> Hi
> >>>
> >>> Besides the RF characteristics it may also be worth considering the
> >> quality of the plastics used. Over time water ingress may become an
> issue.
> >> Fours years after the installation of a CN brand antenna, sourced
> locally
> >> so probably not counterfeit either, we had to replace it at OZ7IGY
> >> www.oz7igy.dk
> >>>
> >>> RF wise 42 dB of gain IS an issue. Again at OZ7IGY, with 12 carriers in
> >> the air especially 13 cm and 23 cm, blocking and IMD were an issue
> before
> >> we mounted a BPF. I have taken apart the above mentioned antenna, a
> >> Motorola antenna and an eBay "hockey puck" antenna. The best design was
> >> clearly the Motorola one because it had a BPF after the pre-amp -
> probably
> >> because it was designed by RF competent people too. Each of the other
> ones
> >> had two FETs/MMICs in series and then a BPF. Of cause if no nearby
> carriers
> >> are in the air it may be less of an issue.
> >>>
> >>> So designing a really good antenna and pre-amp may be a business
> >> opportunity. There are many hi IP3 MMICs available designed for GPS and
> the
> >> like purposes. SAW BPFs with <1 dB loss are available fairly cheap so
> one
> >> before the FET/MMIC with a 1 dB NF is the way to go. A DIY radome using
> >> standard materials from any hardware shop is attached.
> >>>
> >>> Bo, OZ2M
> >>>
> >>> ___

Re: [time-nuts] Anyone have experience with this antenna?

[Michael Wouters]

I can see why the geodetic community would worry about antenna phase centre
variation when a radome is installed but is it really an issue in timing
applications? The few papers I've read suggest PCVs of less than 10 mm, or
equivalently, 30 ps. This is at the level of precision available from
post-processed, carrier phase time-transfer but  invisible in the 1 pps
coming out of your receiver, even with a good sawtooth correction. Am I
missing something?

Cheers
Michael

On Wed, 7 Feb 2018 at 4:14 am, Bob kb8tq  wrote:

> Hi
>
> There are “cell site” specific GPS antennas on the market. Panasonic has
> had one out
> for quite a while. I’m sure there are several others.
>
> One issue with doing any sort of “cover” for a precision antenna is
> distorting it’s pattern.
> Plastic (or whatever you use) will have different properties than air. A
> path through a blob
> of “not air” will change the effective path length. That impacts the
> timing and thus the
> navigation solution. If you are worried about 2mm sort of pattern
> accuracy, things get
> tricky. Early on, there was a big “throw out the radomes push when this
> was first noticed.
>
> Bob
>
> > On Feb 6, 2018, at 6:15 AM, Bo Hansen  wrote:
> >
> > Hi
> >
> > Besides the RF characteristics it may also be worth considering the
> quality of the plastics used. Over time water ingress may become an issue.
> Fours years after the installation of a CN brand antenna, sourced locally
> so probably not counterfeit either, we had to replace it at OZ7IGY
> www.oz7igy.dk
> >
> > RF wise 42 dB of gain IS an issue. Again at OZ7IGY, with 12 carriers in
> the air especially 13 cm and 23 cm, blocking and IMD were an issue before
> we mounted a BPF. I have taken apart the above mentioned antenna, a
> Motorola antenna and an eBay "hockey puck" antenna. The best design was
> clearly the Motorola one because it had a BPF after the pre-amp - probably
> because it was designed by RF competent people too. Each of the other ones
> had two FETs/MMICs in series and then a BPF. Of cause if no nearby carriers
> are in the air it may be less of an issue.
> >
> > So designing a really good antenna and pre-amp may be a business
> opportunity. There are many hi IP3 MMICs available designed for GPS and the
> like purposes. SAW BPFs with <1 dB loss are available fairly cheap so one
> before the FET/MMIC with a 1 dB NF is the way to go. A DIY radome using
> standard materials from any hardware shop is attached.
> >
> > Bo, OZ2M
> >
> > ___
> > 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] Trimble thunderbolt accuracy expectations

[Michael Wouters]

If UTC accuracy is your goal then the practical limits are well-established.

National labs operating clock ensembles (multiple Cs , H-masers) with
calibrated time links ( GPS, two way satellite time- transfer) and steering
them to UTC with predictive algorithms typically achieve 5 to 10 ns
accuracy to UTC.

Calibration of GPS receiver + antenna delays can be done with one of BIPM's
travelling receivers to an accuracy of about 1.5 ns. The uncertainty
increases to 2.5 ns when this is transferred to another receiver - this is
what you would get if your system was calibrated by one of the national
labs whose receiver is calibrated directly by the BIPM.

Realising this accuracy requires post-processing of time-transfer data with
precise antenna co-ordinates, satellite ephemeris etc.

Absolute calibration of delays using a GNSS simulator as Bob suggests is a
bit trickier than it first appears because of the need to include the
antenna. This is usually done in a microwave anechoic chamber but this may
be overkill for timing.

Cheers
Michael

On Mon, 4 Dec 2017 at 3:44 am, Bob kb8tq  wrote:

> Hi
>
> I agree that your TBolt likely had some sort of issue. That probably needs
> to be
> tracked down independent of any other “quest”. First recommendation would
> be
> to run the filter tune stuff in LH.
>
> Accuracy, stability, and repeatability are all different things. They do
> bump into
> each other from time to time. ADEV measures stability. Good ADEV is
> something
> people do focus on. In a GPSDO, it may not go hand in hand with good
> accuracy.
> Lots of corrections may give you good accuracy and lousy ADEV.
>
> The biggest issue (even if you are NIST) with UTC accuracy are static
> offsets. The
> delay through a piece of coax can be calculated. Delay through an antenna
> or a
> receiver, maybe not so much. Since all antennas and receivers exhibit a
> delay,
> comparing one to another may not be the best solution. There are
> relatively cheap
> GPS simulators that claim nanosecond level accuracy. Rigging them to work
> with
> this or that GPS may or may not be very easy.
>
> The next layer to this is the ionosphere. We go round and round about
> this. It’s not
> an easy thing to dig into. GPS has a model of the ionosphere that it
> updates. The
> model is not very complex. It is not updated minute to minute. If you have
> a lot of
> sunspot activity, this can be an issue. If you are at the low point in a
> cycle, it may not
> be as big a deal.  L1/L2 receivers are one way to help with this in an
> active situation.
>
> Over a lot of years, people have popped up with the observation that the
> best thing to
> do with a clock is to just let it run. Don’t try to adjust it. Don’t poke
> at it. Don’t move it
> around. Don’t change it’s environment. Just leave it alone. Observe it’s
> rate and compensate
> for that rate with math.
>
> Expanding any system to multiple devices tends to help reduce errors. Ten
> clocks
> (each made a different way) are likely to each have their own odd
> behavior. The result
> of looking at them as a group will be a better thing than just looking at
> any one of them.
> There are a number of papers on this going back over a *lot* of years.
>
> So enough yack, what’s the suggestion?
>
> Set up a group of free running clocks and the gear to monitor them to
> something like 1 ns.
> That’s not a massive endeavor these days. There are a lot of ways to do it
> on the cheap.
>
> Set up something with good short term stability (OCXO maybe?) and
> synthesize your pps
> from it. Aim for the same ~1 ns step level. Again, not a crazy hard number
> with the kind
> of stuff that’s out there today.
>
> Feed your data into a PC and look at what’s going on. Steer the PPS as
> best you can to
> match GPS. Get the GPS to UTC offsets from the various internet sources.
> You have an offset
> from GPS to NIST or USNO. You also have an offset from USNO or NIST to
> BIH. Correct for them
> in your processing. Will. you hit 1 ns as a result or will you “only” get
> to 10 ns? Time will tell….
>
> With 1 ns steps, the ADEV of your pps will not be super duper (when it
> steps). Your accuracy
> will more likely be limited by things other than that 1 ns resolution. If
> you get to the point that
> 1 ns *is* the issue, there are ways to bump things up by an order of
> magnitude without spending
> an infinite amount of money.
>
> Also remember, once you move a foot, your 1 ns time needs to be corrected
> …..
>
> Bob
>
>
>
>
> > On Dec 3, 2017, at 8:41 AM, Forrest Christian (List Account) <
> li...@packetflux.com> wrote:
> >
> > A couple of weeks back I caught my thunderbolt way out of lock, and doing
> > some sort of weird sawtooth oscillation in the DAC and PPS reading
> causing
> > the PPS alignment to swing +-50ns or so away from correct alignment
> (based
> > on some +-10ns GPS receivers I have here).After lots of attempts at
> > various things, I finally issued it a 'factory reset' command 

Re: [time-nuts] inexpensive, black box, GPS or NTP based TTL time capture?

[Michael Wouters]

Hello Jim

We are using BeagleBone Black + GPS 1 pps etc in our time-transfer system

You can see the overlays in
https://github.com/openttp/openttp/tree/develop/software/system/device-tree-overlays

Best regards
Michael

On Wed, Oct 25, 2017 at 11:43 AM, jimlux  wrote:
> On 10/24/17 5:04 PM, Nick Sayer via time-nuts wrote:
>>
>> FWIW, I’ve documented the whole R-Pi GPS NTP thing at
>> https://hackaday.io/project/15137
>>
>> As a disclaimer I will also say that I’m not even remotely the first. But
>> what’s kind of nice is that I have a R-Pi desk clock display board that
>> plays really well with a bolt-on GPS cap. In fact, I’ve got two of them in
>> the NTP pool right now.
>>
>> Sent from my iPhone
>>
>
>
>
> I've been connecting a Parallax NEO-7M to a beaglebone green..
> GPS messages through the UART are easy.
>
> pps less so.. I'm sure it's a matter of correctly configuring and thrashing
> through the GPIO assignments with the capemgr - which interestingly has had
> two substantial versions - most of the online tutorials and material refer
> to the older one.
>
>
>
> ___
> 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] Power connectors continued

[Michael Wouters]

I've been caught by that one.

Someone used 240V IEC inlets as convenient 10A DC inputs to an oven in an
ion trap. Fiddling around in the back of the racks, I made the inevitable
mistake and Poof! there went $1000 worth of isotopically separated Yb 171.
A few years later, someone else did the same thing.

So yes, follow conventions!

Michael

On Fri, 23 Jun 2017 at 7:35 am, Orin Eman  wrote:

> On Thu, Jun 22, 2017 at 1:06 PM, Chris Albertson <
> albertson.ch...@gmail.com>
> wrote:
>
> >
> > A really dumb idea was this guy, I heard this story secondhand.  He used
> > A/C extension cords for speaker cables because they work well for that
> > purpose, but then someone plugged a speaker into a 120vac well outlet.
>  I
> > assume it made a load 60 Hz tone for a few cycles.Best to follow
> > industry conventions because that is what people expect.
> >
>
>
>  CQ magazine had an article where they did something similar and used a
> 120V extension cord for low voltage - 12V solar panels or some such
> project.  Accidently plug the cord into 120V and you'd blow your panels and
> radios up!  I didn't renew my subscription after that one.
> ___
> 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] GPS Antenna on Tower.

[Michael Wouters]

Try again ...,

Since 1cm of motion is equivalent to 30 ps, there's probably not much point
in putting your GNSS antenna on a geodetic monument if all you care about
is timing. But it does matter if you're trying to track continental drift.

Michael

On Tue, 20 Jun 2017 at 10:44 pm, Michael Wouters <michaeljwout...@gmail.com>
wrote:

> Since 1cm of motion is equivalent to 30ps, there's probably not
>
> On Tue, 20 Jun 2017 at 10:11 pm, Didier Juges <shali...@gmail.com> wrote:
>
>> If that is not time-nutty, I do not know what will :)
>>
>> On Jun 20, 2017 7:04 AM, "jimlux" <jim...@earthlink.net> wrote:
>>
>> >
>> > for geodetic measurements, they drill a hole down to bedrock, and run a
>> > pipe down to anchor the antenna to the bedrock.
>> >
>> > "All holes shall be drilled straight enough so that PVC casing can be
>> > installed in the top 15.5 ft of each hole, and that the steel pipe can
>> be
>> > freely lowered, not forced, for its entire 35 ft length."
>> >
>> > http://kb.unavco.org/kb/article/deep-drilled-braced-monument
>> > -overview-300.html
>> > http://www.scign.org/arch/sdb_monument.htm
>> >
>> >
>> > Google for Ken Hudnutt's or Frank Webb's papers
>> >
>> >
>> > or a 3m tall monument for a CORS station
>> >
>> > http://www.mwrtk.net/support_docs/corsinstallprocedures.pdf
>> >
>> > ___
>> > time-nuts mailing list -- time-nuts@febo.com
>> > To unsubscribe, go to https://www.febo.com/cgi-bin/m
>> > ailman/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] GPS Antenna on Tower.

[Michael Wouters]

Since 1cm of motion is equivalent to 30ps, there's probably not

On Tue, 20 Jun 2017 at 10:11 pm, Didier Juges  wrote:

> If that is not time-nutty, I do not know what will :)
>
> On Jun 20, 2017 7:04 AM, "jimlux"  wrote:
>
> >
> > for geodetic measurements, they drill a hole down to bedrock, and run a
> > pipe down to anchor the antenna to the bedrock.
> >
> > "All holes shall be drilled straight enough so that PVC casing can be
> > installed in the top 15.5 ft of each hole, and that the steel pipe can be
> > freely lowered, not forced, for its entire 35 ft length."
> >
> > http://kb.unavco.org/kb/article/deep-drilled-braced-monument
> > -overview-300.html
> > http://www.scign.org/arch/sdb_monument.htm
> >
> >
> > Google for Ken Hudnutt's or Frank Webb's papers
> >
> >
> > or a 3m tall monument for a CORS station
> >
> > http://www.mwrtk.net/support_docs/corsinstallprocedures.pdf
> >
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to https://www.febo.com/cgi-bin/m
> > ailman/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] Next Aug 21 eclipse and time flow

[Michael Wouters]

Apologies, I didn't read the paper carefully enough. The original claim
does appear to be for a comparison of like clocks eg Cs vs Cs, with a claim
of greater effects for a comparison of clocks in and out of the eclipse
path.

Cheers
Michael

On Mon, 29 May 2017 at 8:20 am, iovane--- via time-nuts 
wrote:

> On august 21 2017 a solar eclipse will sweep USA from coast to coast. A
> lifetime opportunity to do coordinated experiments to check this or that.
> One of the questions that doesn't have a final answer yet is whether or not
> solar eclipses could affect the flow of time. They exist conflicting
> reports: Negative:
> http://www.nature.com/nature/journal/v402/n6763/full/402749a0.html
> Positive: http://home.t01.itscom.net/allais/blackprior/zhou/zhou-1.pdf
>
> http://home.t01.itscom.net/allais/blackprior/zhou/zhou-2.pdfPersonally I
> believe that the positive results were due to spurious responses of the
> atomic clocks to something else than gravity, or the clocks failed for some
> reason (e.g. jumping crystals then steered), or lower quality clocks had
> been sold to China. Anyway the recorded data do show an anomaly.As far as I
> know, no atomic clock tests are planned anywhere for that circumstance, but
> sincerely I don't believe this is the truth.Maybe the US time-nuts
> community, using its plenty
>  of atomic clocks, could give the final answer doing tests during the
> above mentioned eclipse.US time-nuts, what about the idea of doing
> yourselves a large scale coordinated test? Or do you actually believe that
> this question is already definitively closed?(Even discovering that atomic
> clocks might respond to someting else than gravity would be of great
> interest).Antonio I8IOV
> ___
> 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] Next Aug 21 eclipse and time flow

[Michael Wouters]

The effect you're looking for depends on a comparison of two different
kinds of atomic clocks eg Cs vs H-maser so the maser comparison presumably
will be a null measurement.

But I see the path of totality passes a bit north of NIST Boulder and I'm
pretty sure they will notice if there is an effect ! ( I'm highly sceptical
there is one. Searches for exotic physics over the last three decades have
consistently turned up nothing. I did it myself at the beginning of my
career with the "fifth force", a composition-dependent, short range
gravity-like force. The positive results all turned out to have very subtle
classical physics explanations)

Cheers
Michael

On Mon, 29 May 2017 at 9:35 am, Jim Palfreyman  wrote:

> Personally I go with the Nature article. The other papers look like they
> are anomaly hunting because they have a known event.
>
> Having said that, we have two H masers at our observatory in Hobart and we
> have a system set up to measure their phase difference down to about 0.03
> ns. I will report back any anomaly.
>
> Did We, of course, are not in the path of the eclipse, however
> gravitationally
> there is still an alignment. Just through the Earth.
>
>
> Jim Palfreyman
>
>
> On 29 May 2017 at 08:17, iovane--- via time-nuts 
> wrote:
>
> > On august 21 2017 a solar eclipse will sweep USA from coast to coast. A
> > lifetime opportunity to do coordinated experiments to check this or that.
> > One of the questions that doesn't have a final answer yet is whether or
> not
> > solar eclipses could affect the flow of time. They exist conflicting
> > reports: Negative: http://www.nature.com/nature/journal/v402/n6763/full/
> > 402749a0.html Positive: http://home.t01.itscom.net/
> > allais/blackprior/zhou/zhou-1.pdf  http://home.t01.itscom.net/
> > allais/blackprior/zhou/zhou-2.pdfPersonally I believe that the positive
> > results were due to spurious responses of the atomic clocks to something
> > else than gravity, or the clocks failed for some reason (e.g. jumping
> > crystals then steered), or lower quality clocks had been sold to China.
> > Anyway the recorded data do show an anomaly.As far as I know, no atomic
> > clock tests are planned anywhere for that circumstance, but sincerely I
> > don't believe this is the truth.Maybe the US time-nuts community, using
> its
> > plenty
> >  of atomic clocks, could give the final answer doing tests during the
> > above mentioned eclipse.US time-nuts, what about the idea of doing
> > yourselves a large scale coordinated test? Or do you actually believe
> that
> > this question is already definitively closed?(Even discovering that
> atomic
> > clocks might respond to someting else than gravity would be of great
> > interest).Antonio I8IOV
> > ___
> > 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] calculating stats with gaps in the data

[Michael Wouters]

There are 'better' ways of handling gaps when calculating ADEV and
siblings. Patrizia Tavela has a nice method: you pad out the time series,
tagging missing points with NaNs say, and then if a difference contains a
missing data point, you drop it. It works very well. I expect this is in
Stable32. I think it's implemented in allantools. It's definitely
implemented in the Matlab functions I wrote (tftools on GitHub).

Cheers
Michael

On Fri, 26 May 2017 at 12:00 am, Tom Van Baak  wrote:

> Only Stable32 handles data gaps seamlessly. Give it a try (read the manual
> for details).
>
> But also ask yourself how much gaps matter. Yes, they affect the accuracy
> of your y-axis sigma scale and your x-axis tau scale. A few seconds every
> 30 minutes is, what, a 0.1% error? That's like one pixel in a ADEV plot;
> not significant.
>
> What I've done when I need a perfectly seamless data set is just
> interpolate for rare and obviously missing phase data points. That keeps
> the timescale intact. This is especially important if you plan to Fourier
> transform the data: under no circumstances do you want to slip a sample in
> that case.
>
> /tvb
>
> - Original Message -
> From: "jimlux" 
> To: "Discussion of precise time and frequency measurement" <
> time-nuts@febo.com>
> Sent: Thursday, May 25, 2017 6:11 AM
> Subject: [time-nuts] calculating stats with gaps in the data
>
>
> > I'm looking at the python AllanTools package.. does it deal with gaps in
> > the data series (e.g. I've got a series of phase and/or frequency
> > measurements, 1 per second, but there's gaps of a few seconds every 30
> > minutes or so)
>
> ___
> 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] Time Dilation tinkering

[Michael Wouters]

Hmm, it appears that Symmetricom has an interpretation from IATA which
classifies their rubidium-containing products as non-hazardous.

I went through all of this some time ago because we were shipping
rubidiums about domestically (Australia) and there was no permissible
maximum qty of rubidium allowed on a passenger aircraft. It doesn't
make sense: any event which might have caused exposure of the rubidium
in a clock to water, was likely rather more severe than the effects of
less than 1 gram of rubidium igniting. Hard to argue these things
though.

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] Time Dilation tinkering

[Michael Wouters]

Dear Chris,

I believe IATA prohibits the carriage of any quantity of rubidium on
passenger aircraft.
You have to complete a "Dangerous Goods Declaration" and it then has
to go by cargo aircraft.

Cheers
Michael


On Wed, Mar 22, 2017 at 1:12 PM, Chris Albertson
 wrote:
> "flight" there is the word.Why drive up a mountain?   Take the clock
> with you inside the pressurized cabin of a commercial airliner next time
> you are on one of those 10 hour trans=pacific flights.   You be taller then
> any mountain and it is actually cheaper then a weather balloon.
>
> Can you get a Rb clock past the TSA x-ray machine.   Maybe if you ask
> first.  There must be a way to hand cary specialized equipment.
>
>
>
> On Tue, Mar 21, 2017 at 7:03 PM, Tom Van Baak  wrote:
>
>>
>> But attached is one of the first plots where I put a SA.32m in a home-brew
>> vacuum chamber and pulled down to a few inches of Hg for a few hours to
>> simulate the low pressure of a flight up to 50 or 90,000 ft. For a high
>> altitude relativity experiment -- where you'd like your clock to remain
>> stable to parts in e-13 and not accumulate too many stray ns -- it's not a
>> good sign when your clock changes by 2e-11 (that's more than 1 ns per
>> minute) just because of ambient pressure changes.
>>
> --
>
> Chris Albertson
> Redondo Beach, California
> ___
> 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] Time Dilation tinkering

[Michael Wouters]

Yes, that's what I was quoted by the Microsemi agent and the price on
Mouser is similar.
The $1568 version was EOL'ed in December 2016; the more expensive unit is
the '2nd generation'.

Cheers
Michael

On Wed, 22 Mar 2017 at 9:06 am, jimlux <jim...@earthlink.net> wrote:

> On 3/21/17 1:40 PM, Michael Wouters wrote:
> > These are less stable than a rubidium eg tau=10e-11@1000s and monthly
> > ageing of 9e-10.
> > The price of these has gone up  too- they're now about US5000.
> >
>
> Really? That's a big increase.  I bought some last year (well, in
> December 2015) and they were $1568 ea.
>
> It was a pain to buy them because Microsemi fell off JPL's approved
> supplier 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] Time Dilation tinkering

[Michael Wouters]

These are less stable than a rubidium eg tau=10e-11@1000s and monthly
ageing of 9e-10.
The price of these has gone up  too- they're now about US5000.

Cheers
Michael

On Wed, 22 Mar 2017 at 7:03 am, Scott McGrath  wrote:

> Or perhaps use the Symmetricom CSAC ...
>
> Relatively expensive but might work
>
> > On Mar 21, 2017, at 8:08 AM, Attila Kinali  wrote:
> >
> > On Tue, 21 Mar 2017 13:38:51 +1100
> > Hugh Blemings  wrote:
> >
> >> This got me to wondering if a Rubidium based standard might do the trick
> >> - the Efratom SLCR-101s seem readily available for ~USD$200 mark.
> >
> > As TvB wrote, a single one will not do the trick. You will need
> > a stability 1e-14 @1d. IIRC most Rb standards floor out at 1e-12 to 1e-13
> > somewhere between 1k and 100k seconds. Even the Super-5065 has a floor
> > of about 3-4e-14 (unless our friends here improved on this already).
> >
> > There will be a few things that you will need to do, if you want to go
> > with Rubidiums:
> > 1) Stabilize or compensate for environmental effects (temperature, air
> pressure)
> > 2) Build ensembles of Rb clocks.
> >
> > The former is to prevent the ADEV from "turning upwards" again and
> > keep the Rb's as stable as possible as long as possible. I have no
> > experience how much this helps, but I suspect, with the correct modeling
> > that you could get the ADEV to be flat up to a day, maybe even two.
> > You will have to include aging and drift of the cell itself in the model.
> > This also means that you will have your Rbs running for a few
> weeks/months
> > prior to any measurement so that the aging settles down a bit.
> >
> > The ensemble is to get the ADEV down. Averaging of clocks with the same
> > noise decreases the ADEV by the square root of the number of clocks used.
> > If you are close to the ADEV you need, the averaging will help you
> getting
> > it further down. Unfortunately, getting from 1e-13 down to 1e-14 is
> > impractical as you'd need 100 clocks to average over But a factor
> > of 2 to 3 should be possible.
> >
> >
> > Alternatively, you can ask Oscilloquartz whether they let you borrow
> > two of their new OSA3300 for a publicity stunt :-)
> >
> >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.
> ___
> 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] Coming to a drive-way near you: Optical Lattice clocks

[Michael Wouters]

I don't think it is transported under power - it is run as a frequency
reference, not a time reference so there's no need to keep it running.
Optical clocks are difficult to keep running continuously, 60% ( best done
so far, if my memory can be trusted) uptime is considered to be very good.
So that means it's not very useful for time comparisons.

Cheers
Michael

On Sat, 25 Feb 2017 at 1:00 am, Bob Camp <kb...@n1k.org> wrote:

> Hi
>
> > On Feb 24, 2017, at 5:02 AM, Michael Wouters <michaeljwout...@gmail.com>
> wrote:
> >
> > On Fri, Feb 24, 2017 at 10:27 AM, Bob Camp <kb...@n1k.org> wrote:
> >> Hi
> >>
> >> I agree with their premise that to be useful you need transportable
> clocks. I’m not quite sure
> >> that something the size (and weight) of a pickup truck is really
> transportable. Yes one can
> >> move it around (unlike a small mountain)  …. Transporting something
> like that from here to
> >> Europe and back *would* make the charges FedEx comes up with on a  40Kg
> box look
> >> cheap though :)
> >>
> >> Bob
> >
> > I suspect that it's really only meant to be driven around to labs in
> > Europe with optical clocks, like LNE-SYRTE and NPL.
> > I think that you would repack it if you were shipping it overseas.
> >
> > My one experience of something remotely like this was delivery of our
> > frequency comb (two full-height 19 inch racks plus the laser on a
> > large breadboard) from Germany to Australia. It was all working the
> > same day it was unpacked. But no UHV system of course.
>
> It’s the things like keeping vacuum systems running that while it’s
> possible, is not trivial.
> I sort of wonder if “transportation” involves one person driving the truck
> and two people
> riding in back as “minders” for all the gear.
>
> This is indeed cool stuff. Their clock is amazing. I’d love to have one.
> It’s still a massive
> piece of gear.
>
> Bob
>
> >
> > The Chinese one is a bit simpler: it's a single-ion Paul trap, rather
> > than a lattice clock. Probably less control electronics are needed
> > too, so maybe it's a bit more mobile.
> >
> > 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.
>
> ___
> 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] Coming to a drive-way near you: Optical Lattice clocks

[Michael Wouters]

On Fri, 24 Feb 2017 at 9:00 am, Poul-Henning Kamp 
wrote:

> Have we talked about this yet ?
>
> https://arxiv.org/abs/1609.06183
>
> https://arxiv.org/abs/1607.03731
>
>
>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> 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.
>
There's a story over at Physics World that compares both systems:

http://physicsworld.com/cws/article/news/2017/feb/20/optical-clocks-hit-the-road

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] Coming to a drive-way near you: Optical Lattice clocks

[Michael Wouters]

On Fri, Feb 24, 2017 at 10:27 AM, Bob Camp  wrote:
> Hi
>
> I agree with their premise that to be useful you need transportable clocks. 
> I’m not quite sure
> that something the size (and weight) of a pickup truck is really 
> transportable. Yes one can
> move it around (unlike a small mountain)  …. Transporting something like that 
> from here to
> Europe and back *would* make the charges FedEx comes up with on a  40Kg box 
> look
> cheap though :)
>
> Bob

I suspect that it's really only meant to be driven around to labs in
Europe with optical clocks, like LNE-SYRTE and NPL.
I think that you would repack it if you were shipping it overseas.

My one experience of something remotely like this was delivery of our
frequency comb (two full-height 19 inch racks plus the laser on a
large breadboard) from Germany to Australia. It was all working the
same day it was unpacked. But no UHV system of course.

The Chinese one is a bit simpler: it's a single-ion Paul trap, rather
than a lattice clock. Probably less control electronics are needed
too, so maybe it's a bit more mobile.

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] 1PPS users?

[Michael Wouters]

One application is advanced network diagnostics eg cards like this:
https://www.endace.com/endace-dag-high-speed-packet-capture-cards.html

So for a 40 GbE card, time-stamping 1 kilobyte packets demands
sub-microsecond accuracy, if you want to compare at different points
in your network.

Cheers
Michael

On Mon, Dec 19, 2016 at 10:16 AM, Bob Stewart  wrote:
> One thing I've never really understood is who actually uses the high-quality 
> 1PPS output from a GPSDO.  I have spent a lot of time, effort, and money on 
> developing my GPSDO without a whole of thought to the user base.  It was just 
> a quest for the best result I could obtain with a particular technology.  The 
> frequency standard users was a no brainer.  Everyone who wants a frequency 
> standard eventually understands they need to get a GPSDO, or an Rb, or a Cs.  
> And that's all I thought I had: a good frequency standard.  And then Tom 
> prodded me a bit and showed me the shortcomings of what I was doing, and I 
> did something about it.  So, if an NTP user can get his time fix directly 
> from a noisy receiver, who actually needs a time-accurate, low jitter 1PPS 
> pulse?
> Bob - AE6RV
>  -
> AE6RV.com
>
> GFS GPSDO list:
> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
> ___
> 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] Sapphire oscillators

[Michael Wouters]

Dear Attila

You don't need a cryo-cooler, you can just use a cryostat if a break in
operation (when you top up the helium) is not a problem. We operated one of
the UWA CSOs like this as the flywheel for our Yb trapped ion frequency
standard.

A few other national standards labs use the CSOs - one for an ultra low
phase noise reference, another as the flywheel in their timescale
comprising fountains etc.

Cheers
Michael

On Thu., 10 Nov. 2016 at 11:48 am, Attila Kinali  wrote:

> On Thu, 10 Nov 2016 11:20:37 +1100
> Jim Palfreyman  wrote:
>
> > Anyone got any comments on this?
> >
> >
> http://www.theleadsouthaustralia.com.au/industries/technology/worlds-most-precise-clock-set-for-commercial-countdown/
>
> Cryogenic sapphire or whispering gallery mode oscillators have been around
> for quite some time. You basically have a piece of sapphire (aluminium
> oxide
> in crystaline form)[1] in a cavity[2,3], cool everything down to liquid
> helium temperatures and use this as an oscillator. There are two popular
> configurations, one is to use the sapphire as resonant element like in
> an LC or crystal oscillator, or more commonly, to use the sapphire as a
> filter element in Pound locking scheme[4].
>
> The short term stability of these oscillators is AFAIK unsurpassed
> and flat up to 1000-10'000s, but exhibits drift at longer taus[5].
>
> Their biggest problem is that they need a liquid helium cryo-cooler
> which causes vibrations that need to be carefully filtered out.
> This also makes them relatively large (fill between one and two 19" racks)
>
>
> Attila Kinali
>
> [1] http://www.uliss-st.com/uploads/pics/tech2.jpg
> [2] http://inspirehep.net/record/1244235/files/cavity.png
> [3] http://www.uliss-st.com/uploads/media/imgmedias.jpg
> [4] That's the (original) microwave variant of the Pound-Drever-Hall
> locking scheme, see
> https://en.wikipedia.org/wiki/Pound%E2%80%93Drever%E2%80%93Hall_technique
> [5] http://inspirehep.net/record/1409150/plots
> --
> 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.
>
___
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] Cs tube pics

[Michael Wouters]

> If i were able to build a working optical clock, i would just buy
> a frequency comb. The 10k€ for a comb would be cheap compared to the
> money spend on the rest of the clock :-)

Hmm, not sure what you're looking at, but I have a commercial erbium
fibre comb in my lab and it cost 250 000 Euro. There are two full
height 19 inch racks full of electronics. It has an extra output for
1000 to 2000 nm though, so you could probably knock 50K off the price
for that.

Another interesting data point: some people I know in a national
measurement lab built and sold a Cs fountain to another lab. The price
was US 2 million and I'm guessing that was "mates' rates".

Cheers
Michael




On Thu, Nov 3, 2016 at 8:13 AM, Attila Kinali <att...@kinali.ch> wrote:
> On Thu, 3 Nov 2016 07:42:13 +1100
> Michael Wouters <michaeljwout...@gmail.com> wrote:
>
>> One other vital component is the flywheel oscillator you need to take
>> advantage of the fabulous stability you now have at hand.We had a cryogenic
>> sapphire oscillator for our (microwave) clock.
>
> Yes, a lot of the optical clocks are using a hydrogen maser as local
> oscillator. Ie you need an atomic clock to build an atomic clock.
>
>
>> For an optical clock, you're also going to need a frequency comb to get
>> back into the RF domain.
>
> If i were able to build a working optical clock, i would just buy
> a frequency comb. The 10k€ for a comb would be cheap compared to the
> money spend on the rest of the clock :-)
>
> 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.
___
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] 12.6GhZ Yb clock - was Cs tube pics

[Michael Wouters]

Dear Bob,

The error signal (readout is optical, with a laser) you get from tuning the
microwaves from your synthesis chain to the 12.6 GHz hyperfine transition
in Yb is not continuous. There's a measurement sequence of state
preparation etc that means you only get an error measurement every 10 to
100 s. so you need a good flywheel in between.

Cheers
Michael

On Thursday, 3 November 2016, Bob Stewart <b...@evoria.net> wrote:

> Hi Michael,
> I've got a dumb question about the need for a really good flywheel
> oscillator for the 12.6Ghz Yb clock:  What is the signal that is locking
> that oscillator?  Is it a 1PPS, or is it something in the RF domain, such
> as 10MHz or higher?
> I still hope to make a modern version of the old water-hydrogen generator
> from the 40s or whatever it was.  But, my copious free time seems to be
> taken up now that I have the time to do it.
>
> Bob - AE6RV --
> ---
> AE6RV.com
>
> GFS GPSDO list:
> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
>
>   From: Michael Wouters <michaeljwout...@gmail.com <javascript:;>>
>  To: Discussion of precise time and frequency measurement <
> time-nuts@febo.com <javascript:;>>
>  Sent: Wednesday, November 2, 2016 3:42 PM
>  Subject: Re: [time-nuts] Cs tube pics
>
> I worked on a trapped ion frequency standard 20 years ago, a 12.6Ghz Yb
> clock. It's still in the lab across from me and looking at it, and the
> electronics, I think it is the sort of thing that a physicist might
> contemplate building in his/her garage but ...
>
> Building it took about 10 man years of concentrated effort so the time you
> would need for a project like this would be the killer, assuming you could
> buy the spectroscopic lasers and UHV equipment you needed at a price that
> didn't require refinancing your mortgage.
>
> One other vital component is the flywheel oscillator you need to take
> advantage of the fabulous stability you now have at hand.We had a cryogenic
> sapphire oscillator for our (microwave) clock.
>
> For an optical clock, you're also going to need a frequency comb to get
> back into the RF domain.
>
> Cheers
> Michael
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com <javascript:;>
> 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] Cs tube pics

[Michael Wouters]

I worked on a trapped ion frequency standard 20 years ago, a 12.6Ghz Yb
clock. It's still in the lab across from me and looking at it, and the
electronics, I think it is the sort of thing that a physicist might
contemplate building in his/her garage but ...

Building it took about 10 man years of concentrated effort so the time you
would need for a project like this would be the killer, assuming you could
buy the spectroscopic lasers and UHV equipment you needed at a price that
didn't require refinancing your mortgage.

One other vital component is the flywheel oscillator you need to take
advantage of the fabulous stability you now have at hand.We had a cryogenic
sapphire oscillator for our (microwave) clock.

For an optical clock, you're also going to need a frequency comb to get
back into the RF domain.

Cheers
Michael

On Wednesday, 2 November 2016, Attila Kinali  wrote:

> On Tue, 1 Nov 2016 09:10:25 -0700
> "Tom Van Baak"  wrote:
>
> > > I really would like to do that. But they are a tad bit expensive.
> > > Especially on this side of the big pond. If anyone is willing
> > > to part with a Cs standard and want to have it a good home, feel
> > > free to contact me :-)
> >
> > It's true that a cheap GPS receiver is more accurate long-term than
> > a surplus cesium standard, but you're right about the "just because"
> part.
> > To me at least, this time nut hobby is not so much about the pursuit of
> > accuracy as it is an appreciation for the variety, ingenuity and
> complexity
> > of timekeeping. In some cases "how it works" is far more interesting that
> > "does it work".
>
> I think, most of us are in it for the "how it works" and
> "how far can I push it". :-)
>
>
> > A used but known working cesium standard can be expensive, but like most
> of
> > you almost all my gear comes from eBay via automated daily keyword
> searches.
> > Many of my mil- or telecom-surplus FTS 4050 and HP 5061 were obtained for
> > just a couple hundred dollars. You may search for months or even years,
> but
> > amazing bargains show up. Not all of them work, of course, but the op/svc
> > manuals are superb, the design / construction is very repair-friendly,
> and
> > there's a weird group called time nuts with helpful advice.
>
> It still is prohibitevly expensive in Europe. There are much fewer
> Cs standards going around than in the US in the first place, and there
> is also less a tinkering mentality. Ie a lot of companies just say
> "it's broken, it's no use for anyone anymore, let's just scrap it" and
> thus a lot of stuff ends up in recycling instead of on ebay. Heck, a couple
> of years ago i got an 3458 because the company wanted to throw it away.
> Mind you, it was in full working condition, only the NVRAM batteries were
> low.
>
>
> I still would like to try to build my own atomic clock at some point,
> even if it would be a quite costly, and a many years project.
>
> IMHO the easiest to build would be an Rb or Cs vapor cell using either
> dual resonance or coherent population trapping. Cells can be bought
> for 300-500€. For a bit more you can get them made to spec. Machining
> a resonant cavity from aluminium is pretty easy and cheap these days,
> if one wants to go for the dual resonance. The biggest issue for both
> types would be the laser system. Either getting the laser diodes selected
> (makes them expensive) or build an external cavity for them (creates
> the need of a complex control system and not so simple mechanically).
> Putting all toghether would probably cost something in the order of
> 1000€ to 5000€.
>
> One up in difficulty would be a passive hydrogen maser. This requires a
> vacuum system and things like platinum leaks to generate atomar hydrogen
> and state selection magnets. If one knows glass blowing, part of it can
> be made using pyrex tubes, which simplifies some stuff (like keeping the
> state selection magnets outside the vacuum system). Also, the cavity
> needed would be quite big. A normaly used TE011 cavity is huge. One can
> load it with aluminia and get it down to 15-20cm diameter, but this
> requires
> crystaline aluminia to maintain low loss. Maybe one could use other
> resonating
> structures that are smaller, TE111 or loop-gap resonators have been
> proposed.
> The biggest cost here is definitely the needed vacuum system. Although
> the rough pumps are rather cheap (around 500-1000€ if one does not need
> fast pumping) and some of these actually end up on ebay without being
> destryoed by "testing", the high vacuum pumps (ion pumps, turbo pumps etc)
> are not cheap and need to bought new (the stuff you see on ebay are either
> systems that were removed from labs because they don't work anymore, or
> were destroyed by "testing" them in free air).
> An active hydrogen maser should not be that much more difficult. It mostly
> involves a low loss, correctly tuned cavity and low noise detection
> electronics.
> The input stream of hydrogen 

Re: [time-nuts] theoretical Allan Variance question

[Michael Wouters]

Dear Stewart

FWIW, if you do the experiment I suggested (TI measurement on
identical 10 MHZ etc) on a HP53132A counter, you get ADEV = 2.0x10^-10
at 1 second.

The manual says the LSD is 150 ps; when you include trigger errors, it
specifies a resolution of 300 ps. The 200 ps implied by the
measurement above is somewhere in between. The specs may be
conservative though.

As Bob Camp said, in Situation 2, you see the noise of the measurement system.

Cheers
Michael

On Sun, Oct 30, 2016 at 1:17 PM, Bob Camp  wrote:
> Hi
>
> Well, situation one:
>
> You have two perfect sources.
> Your measuring device is noiseless
> If your devices are in perfect sync, you get a series of zeros
> Your ADEV is zero
>
> Situation two:
>
> Same sources
> Noisy measuring device
> You get the standard deviation of the difference in measurements
> Your ADEV is simply a measure of the noise of the measuring device
>
> Situation three:
>
> Your sources are much worse than 1x10^-9 at 1 second
> Your ADEV is the proper number for your sources (or close to it)
>
> Situation four:
>
> The real world, you have a bit of each and you really don’t know
> what is what.
>
> Lots of possibilities and no single answer.
>
> Bob
>
>> On Oct 29, 2016, at 7:38 PM, Stewart Cobb  wrote:
>>
>> What's the expected value of ADEV at tau = 1 s for time-interval
>> measurements quantized at 1 ns?
>>
>> This question can probably be answered from pure theory (by someone more
>> mathematical than me), but it arises from a very practical situation. I
>> have several HP5334B counters comparing PPS pulses from various devices.
>> The HP5334B readout is quantized at 1 ns, and the spec sheet (IIRC) also
>> gives the instrument accuracy as 1 ns.
>>
>> The devices under test are relatively stable. Their PPS pulses are all
>> within a few microseconds of each other but uncorrelated.  They are stable
>> enough that the dominant error source on the ADEV plot out to several
>> hundred seconds is the 1 ns quantization of the counter. The plots all
>> start near 1 ns and follow a -1 slope down to the point where the
>> individual device characteristics start to dominate the counter
>> quantization error.
>>
>> One might expect that the actual ADEV value in this situation would be
>> exactly 1 ns at tau = 1 second.  Values of 0.5 ns or sqrt(2)/2 ns might not
>> be surprising. My actual measured value is about 0.65 ns, which does not
>> seem to have an obvious explanation.  This brings to mind various questions:
>>
>> What is the theoretical ADEV value of a perfect time-interval measurement
>> quantized at 1 ns? What's the effect of an imperfect measurement
>> (instrument errors)? Can one use this technique in reverse to sort
>> instruments by their error contributions, or to tune up an instrument
>> calibration?
>>
>> I'd be grateful for answers to any of these questions.
>>
>> BTW, thanks to whichever time-nuts recommended the HP5334B, back in the
>> archives; they're perfect for what I'm doing. And thanks to fellow time-nut
>> Rick Karlquist for his part in designing them.
>>
>> Cheers!
>> --Stu
>> ___
>> 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] theoretical Allan Variance question

[Michael Wouters]

Dear Stuart

In a perfect world, your TI measurements would have a uniform
probability distribution function with amplitude 0.5 ns and mean value
0 ns. At least, this is the kind of PDF you would assume for
"resolution error". For this distribution, ADEV is 0.5 ns.

I don't know the HP5334B, perhaps its effective resolution is a bit
poorer than 0.5 ns, which I assume is the displayed resolution ?

BTW, one way to remove instability of the DUTs from this kind of test
is to reference the counter to 5/10 MHz and then do your TI
measurement with the same 5/10 MHz input to each channel of the
counter.

Cheers
Michael

On Sun, Oct 30, 2016 at 10:38 AM, Stewart Cobb  wrote:
> What's the expected value of ADEV at tau = 1 s for time-interval
> measurements quantized at 1 ns?
>
> This question can probably be answered from pure theory (by someone more
> mathematical than me), but it arises from a very practical situation. I
> have several HP5334B counters comparing PPS pulses from various devices.
> The HP5334B readout is quantized at 1 ns, and the spec sheet (IIRC) also
> gives the instrument accuracy as 1 ns.
>
> The devices under test are relatively stable. Their PPS pulses are all
> within a few microseconds of each other but uncorrelated.  They are stable
> enough that the dominant error source on the ADEV plot out to several
> hundred seconds is the 1 ns quantization of the counter. The plots all
> start near 1 ns and follow a -1 slope down to the point where the
> individual device characteristics start to dominate the counter
> quantization error.
>
> One might expect that the actual ADEV value in this situation would be
> exactly 1 ns at tau = 1 second.  Values of 0.5 ns or sqrt(2)/2 ns might not
> be surprising. My actual measured value is about 0.65 ns, which does not
> seem to have an obvious explanation.  This brings to mind various questions:
>
> What is the theoretical ADEV value of a perfect time-interval measurement
> quantized at 1 ns? What's the effect of an imperfect measurement
> (instrument errors)? Can one use this technique in reverse to sort
> instruments by their error contributions, or to tune up an instrument
> calibration?
>
> I'd be grateful for answers to any of these questions.
>
> BTW, thanks to whichever time-nuts recommended the HP5334B, back in the
> archives; they're perfect for what I'm doing. And thanks to fellow time-nut
> Rick Karlquist for his part in designing them.
>
> Cheers!
> --Stu
> ___
> 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] Inexpensive Alternative to a 5120A

[Michael Wouters]

The Red Pitaya is a lower cost (but lower performance) alternative to
the USRP boxes.

I've implemented a RF phase meter using the RP and get about 1 ps time
resolution at an averaging time of 1 s.
The RP analog input side seems to be a bit noisy so loses a few bits.
There was some discussion about this on timenuts some time back.

Someone has implemented an SDR on the RP
http://redpitaya.com/red-pitaya-and-software-defined-radio/
 - this may be useable in the same way as described in the NIST paper.
It's on my list to try it out some day.

The summary is that if you only want to pay $400, rather than $40 000,
you have to do some/a lot of work.

Cheers
Michael

On Mon, Oct 10, 2016 at 10:16 AM, Bob Camp  wrote:
> Hi
>
>
>> On Oct 9, 2016, at 6:18 PM, Chris Albertson  
>> wrote:
>>
>> Likely the lowest cost way to get into that is with a TV tuner USB
>> dongle. They cost about $20.   People are able to get about 2.4 mega
>> samples per second.
>
> Except that you need about 30 mega samples ...
>
>
>> Not a lot of dynamic range but you can control
>> that.Use a mixer to move the signal  of interest into the range
>> the tuner can handle.   Tuniers typically tune from about 20Mhz to
>> 1Ghz or 2Ghz approximate.
>
> You also need a very specific dual ADC architecture as described in the 
> paper. Their
> hardware was > $1K and probably the only suitable system at that low a price.
>
> No free lunch :)
>
> Bob
>
>>
>>
>> On Sun, Oct 9, 2016 at 12:05 AM, Paul Boven  wrote:
>>> Hi Randal,
>>>
>>> On 2016-10-07 18:52:57, Cube Central wrote:

 Is there an alternative that someone could point me to that would cost
 only a couple hundred rather than (what I expect) is a couple thousand?  
 How
 would I go about gathering the data needed for these nifty ADEV graphs I 
 see
 floating about in here?
>>>
>>>
>>> People have reported (also on this list) that some SDR (software defined
>>> radio) hardware is quite capable of emulating a 5120/5125, and even going
>>> beyond it in performance.
>>>
>>> "Oscillator metrology with software defined radio, Sherman, J.A., Jördens,
>>> R." - arXiv:1605.03505 [physics.ins-det]
>>> https://arxiv.org/abs/1605.03505
>>>
>>> Regards, Paul Boven.
>>>
>>>
>>> ___
>>> 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.
>>
>>
>>
>> --
>>
>> Chris Albertson
>> Redondo Beach, California
>> ___
>> 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.

[time-nuts] NVS NV08C

[Michael Wouters]

(Restarting the thread with a more apposite topic name)

On Sun, Aug 14, 2016 at 12:47 PM, Mark Sims  wrote:

> The NVS NV08C GPS receiver module is a rather nice little 32 channel 
> GPS/GLONASS/SBAS receiver that has an output message that gives you the raw 
> satellite bit streams.  They can be had for around $60 bare module  ($120 on 
> a breakout board from sylphase.com).  They  also support carrier phase info, 
> sawtooth correction output, and up to 10 Hz navigation rates.
>
>
> Lady Heather now supports the NVS08C... it was a bit of a pain to do.   
> Several messages send values  (rather needlessly) in an 80-bit floating point 
> number format that most compilers do not natively support.  Lady Heather 
> converts those to standard 64-bit floating point values.  Their binary 
> message protocol is basically Trimble TSIP at 115,200:8:ODD:1 (with optional 
> support for 16-bit CRC's)

The NV08C also has an official  board
http://www.m2mconnectivity.com.au/technologies/gnss-gps/gnss-receivers/nv08c-csm-brd
for about AUD100.

We use these for GPS common-view time transfer (which needs the raw
data). There's some performance data here:
http://www.openttp.org/scripts/blog.php


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] NUT4NT: Four-channel All-frequency GNSS RF-to-Bits

[Michael Wouters]

This board just seems to be the RF front end for a GNSS receiver. You then
have to do the whole business of acquiring and tracking the code, and then
do the PVT solution, at which point you can make your own 1 PPS.

Cheers
Michael



On Sunday, 14 August 2016, Gregory Maxwell  wrote:

> On Thu, Aug 4, 2016 at 11:08 PM, Daniel Mendes  > wrote:
> >
> > A new interesting toy soon to be crowdsourced:
> >
> > https://www.crowdsupply.com/amungo-navigation/nut4nt
>
> A shame, it looks like it can be externally clocked, but I don't see a
> way to get in and measure a PPS signal.
>
> Considering the increasingly frequent jamming I see doing a multiband
> CRPA timing receiver sounds like a fun project; but I'm not quite
> seeing how to do really overkill timing with this device. :)
>
> I guess on the NT1065 you'd want use the clk with a counter to capture
> the position of a PPS or external reference with respect the the
> sample clock?... and hopefully the signal processing chain from clock
> to the ADC has a constant delay?
> ___
> 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] Shera revisted

[Michael Wouters]

The Red Pitaya uses a Zynq, and there's an (unofficial) SDR application
available to experiment with.

Cheers
Michael
On Thursday, 11 August 2016, Chris Albertson 
wrote:

> Thanks for pointing out the Zynq.  Wow you get a dual core ARM and an
> FPGA all in one package.   It seems overkill for a GPSDO but not the
> type you are making as you can transferring the time out of the GPSDO
> using PTP.
>
> The Zyng looks to the the perfect platform for low-cost SDR.
>
> On Wed, Aug 10, 2016 at 2:30 PM, Joakim Langlet
> > wrote:
> > Dear time-nuts,
> >
> > My name is Joakim Langlet (SM0OET) and I just recently joined this list.
> As
> > Brooks Shera was mentioned, I remembered that I was referenced in the
> > footnotes of the original article in the QST - July 1998. It feels almost
> > historical now. Brooks bought a few OCXOs from me.
> >
> > I am currently working on a GPS stabilized OCXO.
> > It is based on a Xilinx Zynq FPGA as the processor and counter
> arrangement.
> > The hardware is starting to take shape. The control voltage of a 20 MHz
> OCXO
> > is set by a DAC coupling from which I hope to set the voltage in very
> small
> > steps.
> > The OCXO has a CMOS level output which is converted to LVDS and is wired
> to
> > the FPGA board. The Xilinx Zynq take a minimum frequency of 19 MHz as
> input
> > to the PLL of the clock tile. My intention is to scale up the clock to
> some
> > where a bit over 200 MHz to be fed to the counters.The 1 PPS from the GPS
> > receiver is also fed into the FPGA to gate the counters.
> >
> > The reason for my choice of processor is that I want to run Linux on it
> in
> > order benefit from the large software base. Time distribution using PTPv2
> > and a nice web-application to visualize and control what is going on
> inside
> > is part of the intended concept.
> >
> > I still have a long way to the finish line but I will try to present some
> > results as I proceed.
> >
> > I am following what is written on this list with great interest. It feels
> > good to know that I am not the only nut 
> >
> > BR/
> > Joakim
> > ___
> > 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.
>
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
> ___
> 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] Oscillator Phase Noise: A 50-Year Review

[Michael Wouters]

On Sat, Aug 6, 2016 at 9:34 AM, KA2WEU--- via time-nuts
 wrote:

> Leeson produced a somewhat random selection of papers , omitting important
> things like the sapphire based best in the word . This was not even
> referenced  .

The reference [145] at the end of the sentence that mentions sapphire
oscillators also discusses a hybrid photonic-microwave oscillator that
incorporates a room-temperature sapphire oscillator so I think he
tried to cover both subjects with that single reference.

The paper has a misleading title. It suggests that it is a history of
the last 50 years, when it is about events roughly 50 years ago. The
abstract makes this clear though. So I didn't really expect to read
much about developments past 1970.

Cheers
Michael


On Sat, Aug 6, 2016 at 9:34 AM, KA2WEU--- via time-nuts
 wrote:
> Some of the cited references are poor, modern non-linear mathematic is kind
>  of omitted . After all the oscillator  phase noise speculation, I would
> have really liked to see at last a reference about the most modern
> measurements  techniques and it validation. How do you calibrate a phase 
> noise test
> system.
>
> Leeson produced a somewhat random selection of papers , omitting important
> things like the sapphire based best in the word . This was not even
> referenced  .
>
> I think he is really out of it .
>
> 73 de N1UL
>
>
>
> In a message dated 8/5/2016 7:11:18 P.M. Eastern Daylight Time,
> j...@miles.io writes:
>
>>
>> Very selected and incomplete references and the equally   important
>> question
>> of measurements strangely not  covered
>>
>> 73 de N 1  UL
>>
>
> I suppose he could  write an equally-lengthy article on measurements alone,
> but leaving out the  post-1970s history entirely was a little
> disappointing.  It was strange  to hit "ctrl-f Rohde" and see only one 
> reference in the
> bibliography.   Same for "Hewlett."  "Rubiola" brings up one hit (but no
> citations) and  "Stein" brings up none at all.
>
> -- john, KE5FX
> Miles Design  LLC
>
>
> ___
> 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] Using the HP 58503a to correct your PC clock

[Michael Wouters]

On Sat, Aug 6, 2016 at 6:41 AM, Attila Kinali  wrote:

> So, best you can hope for is an jitter of ~50us rms within the same
> city with _good_ network connections. Once the distance increases
> and especially if you get routers with conquestion inbetween, then
> the delay and its jitter rise quickly.

That pretty well agrees with my practical experience of NTP on
somewhat longer, uncongested links.
NTP servers separated physically by 1000-3000 km but perhaps 10
network hops had apparent offsets of about 100 us rms with respect to
each other.

Cheers
Michael

On Sat, Aug 6, 2016 at 6:41 AM, Attila Kinali  wrote:
> On Fri, 5 Aug 2016 21:35:05 +0200
> Magnus Danielson  wrote:
>
>> > From a "Time Nuts" point of view none of the above are even close to
>> > accurate clocks.  A microsecond is a very course and crude measure of
>> > time.  Pico and Femto seconds are were it gets interesting.
>>
>> Certainly. Look at White Rabbit, which really changes how PTP works.
>> It may not be pico second accurate, but you get pretty far with it.
>
> WR achieves sub-ns accuracy. Depending on the environment <200ps offset/skew
> are possible.
>
>> > Maybe someday NTP will have a time nuts level of accuracy.  the new up
>> > coming version, I hear will be using 64 bits to carry the factional part of
>> > a second.  That is truly nuts.
>>
>> Well, if NTP takes the main ideas from PTP and White Rabbit, maybe then.
>
> This wont help. The achievable accuracy is dictated by the measurement
> and the delay uncertainty. Even with network cards that support time stamping,
> you cannot hope to get better than 1/125MHz=8ns. Standard network cards
> will just trigger an IRQ at some point after reception and enqueuing of
> the packet. The IRQ is measured by the OS, which leads to uncertainties
> in the order of several us to a couple of 10s of us. If the card does DMA
> the packet directly into main memory, then this value is even more inflated.
>
> The network itself has a relatively high jitter. Assume 10s to 100s of us
> on a local network per switch. Once you pass a router, you can assume
> jitter in the order of a couple of 100us to a couple of ms per router.
>
> To illustrate this, here a few ping statistics (64byte, 1000 packets each):
>
> Local network, GBit/s, two level1 smart switches:
> rtt min/avg/max/mdev = 0.073/0.131/0.362/0.044 ms
>
> Two hosts in colo centers within the same city, same ISP, hence
> on the same "network" (ie no conguestion), 4 hops:
> rtt min/avg/max/mdev = 0.288/0.437/0.620/0.051 ms
>
> Two hosts in colo centers, within the same city, different ISP
> but with direct peering (ie no conguestion), 9 hops:
> rtt min/avg/max/mdev = 2.916/3.008/3.505/0.078 ms
>
> Two hosts in colo centers, one in Switzerland, one in Germany, 9 hops
> rtt min/avg/max/mdev = 12.636/12.947/28.943/0.609 ms
>
> These are all well connected machines, with "carrier grade" networks
> inbetween. No consumer internet connections with their huge delays
> and jitter.
>
> So, best you can hope for is an jitter of ~50us rms within the same
> city with _good_ network connections. Once the distance increases
> and especially if you get routers with conquestion inbetween, then
> the delay and its jitter rise quickly.
>
>
> 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.
___
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] Q/noise of Earth as an oscillator

[Michael Wouters]

On Wed, Jul 27, 2016 at 8:08 AM, Attila Kinali  wrote:

"I am not sure you can apply this definition of Q onto earth."

It  doesn't make sense to me either.

If you mark a point on the surface of a sphere then you can observe
that point as the sphere
rotates and count rotations to make a clock. If you think of just a
circle, then a point on it viewed in a rectilinear coordinate system
executes simple harmonic motion so the motion of that point looks like
an oscillator, so that much is OK.

But unlike the LCR circuit, the pendulum and quartz crystal, the
sphere's rotational motion does not have a
resonant frequency. Another way of characterizing the Q of an
oscillator, the relative width of the resonance, makes
no sense in this context.

It seems to me that the model of the earth as an oscillator is
misapplied and that the 'Q' is not a meaningful number.
I think the confusion arises here because of a conflation of a
rotation of the sphere (which marks out a time interval) with an
oscillation. Both can be used to define an energy lost per unit time
but the former doesn't have anything to do with the properties of an
oscillator.

Something else that indicates that the model is suspect is that the
apparently high 'Q' implies a stability which the earth does not have,
as Tom observes. Viewed another way, this suggests that the model is
inappropriate because it leads to an incorrect conclusion.

Time for bed. I'll probably lie awake thinking about this now :-)

Cheers
Michael

On Wed, Jul 27, 2016 at 8:08 AM, Attila Kinali  wrote:
> Hoi Tom,
>
> On Tue, 26 Jul 2016 12:36:37 -0700
> "Tom Van Baak"  wrote:
>
>> Among other things, the quality-factor, or Q is a measure of how slowly a
>> free-running oscillator runs down. There are lots of examples of periodic or
>> damped oscillatory motion that have Q -- RC or LC circuit, tuning fork,
>> pendulum, vibrating quartz; yes, even a rotating planet in space.
>
> I am not sure you can apply this definition of Q onto earth. Q is defined
> for harmonic oscillators (or oscillators that can be approximated by an
> harmonic oscillator) but the earth isn't oscillating, it's rotating.
> While, for time keeping purposes, similar in nature, the physical
> description of both are different.
>
> 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.
___
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] [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

[Michael Wouters]

I'd be interested to know how 10ns less latency is useful. AFAIK, a high
speed trading system consists of multiple processing nodes, which certainly
could have a 10ns accurate time reference eg via PTP, but latency and
jitter would limit time stamping of transactions to the microsecond level.
Unless of course, the critical bits are all running on dedicated hardware.

Cheers
Michael

On Tuesday, 26 July 2016, bownes  wrote:

>
> A second here or there is a very big deal to those of us in the financial
> and database worlds.
>
> Aside from the well known instances involving electronic trading I have
> customers fighting over cabinet positions and cable lengths to place
> processors closer to disk drives and on switch paths with 10ns less latency.
>
>
>
>
>
> > On Jul 25, 2016, at 16:57, Mark Sims >
> wrote:
> >
> > Apple's new file system timestamps files with nanosecond resolution.   A
> lot of Linux file systems also do that now.   The nanosecond ain't what it
> used to be...  I can imagine people wanting picosecond timestamps in the
> near future.  Who knows,  maybe we'll have something like NTP compensating
> for light-speed delay for the gap between the read/write heads and disk
> surface (assuming we still use heads and surfaces)  ; -)
> > 
> > Except that you still have the issue of “what time did this file get
> changed”. To most of us, that’s not really a big deal. A second either way
> … who cares.
> > ___
> > 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] LSEM (Leap Second Every Month)

[Michael Wouters]

Apropos Bob's comments, the problem of ambiguous timestamps during a
leap second, at least with current operating systems, is only made
worse by more frequent leap seconds.

Making critical systems run on a leap second free time scale like TAI,
for example, just shifts the problem to the interface between those
systems and the rest of the world. Admittedly, this interface may be
more tolerant of discrepancies.

Leap seconds have gotta go.

Cheers
Michael


On Fri, Jul 22, 2016 at 8:13 AM, Bob Stewart  wrote:
> But would it really solve your problems, Jim?  The problem is essentially 
> that periodically, there are two different clock times that represent the 
> same moment in time.  For telescopes, stock markets, spread spectrum, 
> time-based encryption, etc that's a big problem.  Would it not be better to 
> separate out those entities that are more dependent on precision sequence 
> than on clock time and accept that they are just going to be different?  
> Yeah, the talking heads on CNBC and Bloomberg would gravely announce that 
> today's stock market was opening a second later, but so what?  At least there 
> wouldn't be any more questions about exactly when transaction X occurred.
>
> Bob
>  -
> AE6RV.com
>
> GFS GPSDO list:
> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
>
>   From: Jim Palfreyman 
>  To: Discussion of precise time and frequency measurement 
>  Sent: Thursday, July 21, 2016 4:38 PM
>  Subject: Re: [time-nuts] LSEM (Leap Second Every Month)
>
> The idea is the same as my local telco and their main exchanges.
>
> Every month they walk up to the main circuit breaker and cut the power to
> the entire building. All the UPSs and diesel generators get tested in anger.
>
> This leap second solution is the best I've heard so far.
>
> Personally I now hate leap seconds because it ruins many hours of my
> observations at the radio telescope - but if this was implemented it would
> force the software problems to be fixed.
>
>
> Jim Palfreyman
>
>
> On 22 July 2016 at 06:01, Brooke Clarke  wrote:
>
>> Hi Tom:
>>
>> I like this idea.  I addresses the lesson from Y2K that something done
>> often works much better than something done only occasionally.
>> That's way you see the firetruck at the local store, because it's used all
>> the time and so is more likely to work when needed.
>>
>> --
>> Have Fun,
>>
>> Brooke Clarke
>> http://www.PRC68.com
>> http://www.end2partygovernment.com/2012Issues.html
>> The lesser of evils is still evil.
>>
>>  Original Message 
>>
>>> Hi Tom...
>>>
>>> Does your proposal allow for a Zero leap second, or does it require
>>> either plus or minus 1 to work? Seems like you could stay closer to the
>>> true value if you also have a zero option. Might also cause less
>>> consternation for some services, like the finance and scientific worlds,
>>> that seem to have critical issues when an LS appears.
>>>
>>> I like your point that by having it occur monthly it forces systems to
>>> address issues promptly, and maybe that's the argument for the non-zero
>>> option.
>>>
>>> Tom Holmes, N8ZM
>>>
>>>
>>> -Original Message-
>>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van
>>> Baak
>>> Sent: Thursday, July 21, 2016 1:28 PM
>>> To: Discussion of precise time and frequency measurement <
>>> time-nuts@febo.com>
>>> Cc: Leap Second Discussion List 
>>> Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
>>> December 31 this year
>>>
>>> Time to mention this again...
>>>
>>> If we adopted the LSEM (Leap Second Every Month) model then none of this
>>> would be a problem. The idea is not to decide *if* there will be leap
>>> second, but to force every month to have a leap second. The IERS decision
>>> is then what the *sign* of the leap second should be this month.
>>>
>>> Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
>>> UTC, not so much by rare steps but by dithering. There would be no change
>>> to UTC or timing infrastructure because the definition of UTC already
>>> allows for positive or negative leap seconds in any given month.
>>>
>>> Every UTC-aware device would 1) know how to reliably insert or delete a
>>> leap second, because bugs would be found by developers within a month or
>>> two, not by end-users years or decades in the future, and 2) every
>>> UTC-aware device would have an often tested direct or indirect path to IERS
>>> to know what the sign of the leap second will be for the current month.
>>>
>>> The leap second would then become a normal part of UTC, a regular monthly
>>> event, instead of a rare, newsworthy exception. None of the weird bugs we
>>> continue to see year after year in leap second handling by NTP and OS's and
>>> GPS receiver firmware would occur.
>>>
>>> Historical leap second tables 

Re: [time-nuts] How does sawtooth compensation work?

[Michael Wouters]

Hello Michael
> Thinking out loud, I wonder how bad L1-only, post-processed, would be for 
> time-nuts use? Especially with a timing-grade antenna (e.g. the common 
> Trimble Bullet). Dual frequency is great when your receiver has the potential 
> to move, you have to resolve carrier phase ambiguity quickly, or you don't 
> have a reference station (CORS) nearby. (O.T. I was out hiking in Washington 
> state recently, and *accidentally* happened upon my local CORS station, so I 
> guess that's no issue for me :-)). But for many time-nuts, I wonder how badly 
> a timing-grade antenna, something with raw carrier phase output (which you 
> get very cheaply these days), and a stable enough local clock to allow you 
> average out local weather.
>

There was a related discussion a month ago
https://www.febo.com/pipermail/time-nuts/2016-June/098484.html
and I posted a plot
https://www.febo.com/pipermail/time-nuts/attachments/20160616/cb2801b0/attachment.png
which might be helpful.

As you can see, the improvement from raw 1 pps to a full carrier-phase
solution with IGS rapid orbits and clock solutions is not enormous,
just a factor of 4 in stability. BIPM does a bit better with TAI PPP,
eg ftp://ftp2.bipm.org/pub/tai/publication/timelinks/taippp/1606/
maybe 30% or so. (To be completely fair, the raw 1 pps is from a $10K
GPS receiver with a very good sawtooth correction so there may be a
bit more of an improvement at averaging times less than 1000 s or so)

There are a few more plots of L1 receiver performance at:
http://www.openttp.org/scripts/blog.php

> For time-nut use, I don't see any harm in using post-processing for 
> evaluation/measurement of clocks.

This is exactly how most of the clocks contributing to UTC are linked
together across the world.

Cheers
Michael

On Wed, Jul 20, 2016 at 9:41 AM, Michael  wrote:
> Thanks Tom, Bob, and Mark (wrote my response to Tom first, but didn't hit 
> send)!
>
> I've actually been collecting some *ancient* dual-frequency geodetic gear to 
> play with, some of which have external clock inputs (or should be hackable). 
> I've read a lot, but I wasn't sure what people were typically referring to on 
> this list. Thanks for the overview...that helps me connect the dots between 
> the time-nuts and survey/geodetic GPS worlds.
>
> For time-nut use, I don't see any harm in using post-processing for 
> evaluation/measurement of clocks. Won't get you something usable in 
> real-time, for sure, but if you're already collecting weeks of data, don't 
> see any harm in waiting for precise orbit and clock solutions to become 
> available for post processing. And it might tell me how far off you are in a 
> 24-hour PPP solution. Which I guess means you'd need to be very stable in the 
> <=24hr region.
>
> Thinking out loud, I wonder how bad L1-only, post-processed, would be for 
> time-nuts use? Especially with a timing-grade antenna (e.g. the common 
> Trimble Bullet). Dual frequency is great when your receiver has the potential 
> to move, you have to resolve carrier phase ambiguity quickly, or you don't 
> have a reference station (CORS) nearby. (O.T. I was out hiking in Washington 
> state recently, and *accidentally* happened upon my local CORS station, so I 
> guess that's no issue for me :-)). But for many time-nuts, I wonder how badly 
> a timing-grade antenna, something with raw carrier phase output (which you 
> get very cheaply these days), and a stable enough local clock to allow you 
> average out local weather.
>
> I guess while it's fascinating to me...wonder if it has any use in practice 
> compared to a simple, autonomous, real-time, L1-only receiver? I mean, I'm 
> interested in measuring my local tropospheric and ionospheric delays. But 
> then again, I am an aspiring time-(and maybe GPS)-nut :).
>
> Michael
>
>> Hi Michael,
>>
>> About #3 below...
>>
>> There are dozens of technical papers about all this in the PTTI, FCS, UFFC, 
>> EFTF journals. Google for words like: GPS carrier-phase dual-frequency 
>> time-transfer geodetic-receiver IGS precise point positioning PPP
>>
>> I don't have a link to a handy 1-page summary, but someone else on the list 
>> might. Otherwise skim the first ten papers you find and you'll pick up the 
>> concepts of high-precision time transfer.
>>
>> The basic idea is that high-end geodetic-grade receivers often have an 
>> external 10 or 20 MHz clock input (and maybe no internal clock at all). You 
>> give it your best lab clock and all then all GPS signal processing and SV 
>> measurements are based on your fancy clock. The output of the receiver is a 
>> stream of these measurements, not necessarily a physical 1PPS or 10 MHz (as 
>> with a GPSDO).
>>
>> So you can see there's no such thing as sawtooth error here, because you're 
>> not transferring some internal clock to some external clock via a TIC; there 
>> is only the one clock; your clock.
>>
>> All this measurement data is then post-processed, hours 

Re: [time-nuts] Good GPSDO on eBay?

[Michael Wouters]

"Full tested by Agilent 53132A with US-012 option and Ex-ref from
trimble thunderbolt
GPSDO."

I think what the seller saying is that the counter was externally
referenced to the Thunderbolt for the frequency measurements that they
state.

Cheers
Michael

On Sun, Jul 10, 2016 at 10:58 AM, Charles Steinmetz
 wrote:
> Richard wrote:
>
>> This looks like a good beginner's GPSDO on eBay: 172148560746
>>
>> "This is GPS Disciplined Clock made with trimble GPSDO Board.Full tested
>> by Agilent 53132A with US-012 option and Ex-ref from trimble thunderbolt
>> GPSDO."
>>
>>   The seller says it has a sine wave output and is accurate from
>>   10e-11 to 10e-12.
>>
>> Any thoughts?
>
>
> It is very hard to say exactly what you will get, because the seller (who
> uses a dozen or more different ebay IDs) seems to change the design every
> time the wind shifts.  But typically they are FLLs (frequency locked loops),
> not genuine PLLs (phase locked loops), and have a small frequency offset
> because the design does not address some systemic issues of FLL design.  It
> is unlikely to deliver better than 10e-11 performance with any certainty.
>
> In addition to that, if  "Ex-ref from trimble thunderbolt GPSDO" is supposed
> to make a buyer think it will have the best Trimble OCXO (P/N 37265), the
> one that was in the Trimble Thunderbolts of list legend, that is almost
> certainly false.  It may have a Trimble-branded OCXO, but even if it does it
> will be one of the many lesser part numbers.
>
> To me, the attempts to mislead buyers is enough, by itself,  to rule out
> dealing with that seller, under any of his ebay IDs.
>
> Best regards,
>
> Charles
>
>
>
> ___
> 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] Cable length calibration

[Michael Wouters]

As a practical matter, in the lab we seldom need a cable delay
measured to better than +/- 0.5 ns, which we usually do as a time
interval measurement, with a 1 pps into a tee on channel A of a TIC
and then the cable from the tee to channel B.

For cables up to 40 m or so, just measuring the physical length is  as
accurate (experimentally determined!).

A while back, EURAMET ran a pilot where a few lengths of cable were
circulated amongst a number of NMIs who then had to measure the
delays. The reported scatter was about +/- 1 ns, as I recall. This
mainly came down to differences in test signals, trigger levels etc.

Cheers
Michael


On Fri, Jul 1, 2016 at 7:03 AM, Dr. David Kirkby (Kirkby Microwave
Ltd)  wrote:
> On 30 June 2016 at 09:19, Scott McGrath  wrote:
>
>> If the nominal velocity of propagation is known and length is known delay
>> is easily determined mathematically
>>
>
> Except that coax does not have a uniform impedance or velocity factor. Both
> will vary as a function of position and frequency. How relevant this is
> depends on the accuracy you require, but since it is time-nuts, it is
> reasonable to assume that such a simplistic method is not of the standard
> expected on time-nuts.
>
> Dave
> ___
> 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] GNSS antenna delays

[Michael Wouters]

The discussion about antenna cable delays made me think of the issue of the
antenna delay. An antenna typically has a bandpass filter and amplifier so
there clearly is some non-negligible delay associated with this.

The issue is usually sidestepped by calibrating the delay of
receiver+antenna (against what? A calibrated receiver + antenna from
the BIPM of course...)

But sometimes, after calibration, an antenna in the field has to be
replaced with a different antenna and the original calibration is
invalidated. It then becomes necessary to expand the uncertainty of the
delay.

I did read a NIST paper where they described measuring the delay by
physically disassembling the antenna so that they could feed signals
directly to the electronics. Delays like 30 ns were measured, I think.
Myself, when changing antennas I have seen steps like 10 ns.

Does anyone have any data points to add to this ?

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] Impact of GPS antenna height measurments

[Michael Wouters]

Tom Van Baak said:

"This note is just a plea not to apply the speed-of-light number or
the "nanosecond a foot" rule-of-thumb out of context."

It works reasonably well as a rule of thumb. It's an upper limit  but
if you wanted to refine it a bit, divide by two. The average value of
sin(x) on [0,pi/2] is 2/pi ie about 1/2.

This agrees quite well with the results of the post-processing I
described earlier.

Cheers
Michael


On Tue, Jun 28, 2016 at 8:49 AM, Tom Van Baak  wrote:
>> So to travel 22 meters is about .000,000,073 Seconds.  Or 73 nanoSecond.
>
> Hi Gary,
>
> I want to echo what Bob just wrote. People get carried away with "a 
> nanosecond is a foot" and think it applies 100% to GPS timing and position, 
> or in this case, elevation errors.
>
> Equating 22 m with 73 ns, or equating 1 foot with 1 ns is only true in the 
> impossibly rare case of one satellite directly above you. In reality, 1) most 
> of the time the SV are further down and so the error is reduced by 
> sin(angle). And, 2) the GPS timing solution is typically based on lots of 
> satellites, not just one, and so the effects of position error is further 
> reduced by the ensemble mean.
>
> An accurate position is desirable. No question about that. This note is just 
> a plea not to apply the speed-of-light number or the "nanosecond a foot" 
> rule-of-thumb out of context.
>
> /tvb
>
>
> - Original Message -
> From: "Gary E. Miller" 
> To: "Mark Barettella via time-nuts" 
> Sent: Monday, June 27, 2016 12:31 AM
> Subject: Re: [time-nuts] Impact of GPS antenna height measurments
>
> Yo Mark!
>
> On Sun, 26 Jun 2016 09:02:55 -0400
> Mark Barettella via time-nuts  wrote:
>
>> I
>> estimate my antenna’s actual height at about +5 m high and the gps
>> indicates -17 m.
>
> Others have covered some obvious details.  Different ellipsoids,
> long term surveying, etc.
>
>> My question is will this adversely influence the
>> accuracy of the gpsdo output?
>
> Depends on how accurate you need.  I'll assume your estimate is perfect,
> which is that your GPS is reading off by 22 meters.
>
> The speed of light is  299,792 kilometers/second.
>
>
> All else being equal, does a constant 73 nanoSec matter to you?
>
> For comparision, a Trimble RES SMT 360 only promises 15 nanoSec (1 sigma).
>
> If all you want is a stable frequency from your gpsdo then the offset
> is not relevant.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>  g...@rellim.com  Tel:+1 541 382 8588
>
>
>> ___
>> 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] Impact of GPS antenna height measurments

[Michael Wouters]

Poor coordinates for the antenna couple into the apparent distance to
a satellite in such a way that the error in the distance tracks a
parabola-shape as the satellite rises and descends, with a
corresponding error in the apparent satellite time. At any instant,
the combination of N satellites then leads to an apparent GPS time
with a mean offset roughly equal to position error, and peak to peak
scatter in the satellite times  equal to the position error as well.

The offset isn't a problem, unless you care about time of day. How the
noise feeds into your GPSDO depends on the time constant of the servo.

I tried a simple numerical experiment, where I post-processed raw code
measurements from a timing receiver for different antenna heights,
comparing the results with those for its true position, known with an
accuracy of a few cm. The output of this calculation is a CGGTTS
time-transfer file, where the satellite time is averaged over 780 s.
For a 15 m error in height, at my latitude (30 deg) the offset is
about 28 ns and the peak to peak scatter is about 50 ns. If you then
try to do what the GPS receiver does, ie take an average of the
satellites, you get a peak to peak noise of about 10 ns.

I plotted the TOTDEV of this noise.

As you can see, at about 1000 s, the instability is about 10^-12,
averaging down to about 10^-13 at one day.
This does not  compromise a GPSDO's frequency stability at these
averaging times. At shorter averaging times there may be a problem
though, depending on the time constant of the GPSDO, and the stability
of its oscillator.

Cheers
Michael



On Sun, Jun 26, 2016 at 11:02 PM, Mark Barettella via time-nuts
 wrote:
> Using auto survey mode my gps antenna height is significantly off.  I 
> estimate my antenna’s actual height at about +5 m high and the gps indicates 
> -17 m.
> My question is will this adversely influence the accuracy of the gpsdo 
> output?  Would there be any benefit to adjust this manually via the scpi 
> commands?
>
> Thanks,
>
> Mark
>
> Windows 7 Pro SP1  64 bit
>
> GPScon-JLT v 2.007
>
> Fury firmware rev. 1.22 w/ M12M upgrade
>
> PCTEL 8171D-HR-DH-W antenna
> ___
> 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]

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 

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 <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
> <javascript:_e(%7B%7D,'cvml','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 m

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 <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
> <javascript:;>> 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.
> &

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.

Re: [time-nuts] Ublox Neo-6M time error.

[Michael Wouters]

The local clock bias value reported by the Res T is the difference between
the receiver's clock and the reference time scale ( GPS or UTC). You need
it to correct the raw pseudo ranges reported by the receiver, which are
with respect to the receiver's clock.

Cheers
Michael

On Wednesday, 1 June 2016, Mark Sims  wrote:

> I had two machines running Lady Heather with the singing chime clock mode
> enabled (that plays a chant from the Missa Assumpta on the quarter hours).
>
> One machine was connected to a Ublox Neo-6M receiver and another to a
> Z3801A.   I noticed that the two machines sang their jaunty monk tunes
> offset by around one second.  Since a man with two singing GPS clocks never
> knows what time it is,  I replaced the Z3801A with a Jupiter-T and the two
> clocks were still out of sync.   Finally I tried  Motorola M12+ and UT
> receivers and the same thing happened.  It looks like the Ublox time is
> ahead by a second compared to all the other receivers.   I then specified a
> -1 second "rollover" correction to the Ublox machine and the two clocks
> sang in perfect harmony.   Has anybody noticed such behavior with other
> receivers?
>
> BTW,  note that the Ublox binary time message has a "fractional
> nanoseconds of the seconds field" (+/- 500,000 nanoseconds) correction that
> must be applied to the hrs:min:secs values (which I am doing).  The
> fractional time offset forms a sawtooth with around a 120 second period.
> Attached is a GIF... white is the nanosecond fractional time offset.
> Magenta is the receiver estimate of its time error (both in nanoseconds).
> The Trimble Resolution-T receivers report a similar "local clock bias"
> value, but they don't seem to document what it actually is...
>
>
>
>
___
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] Commercial software defined radio for clock metrology

[Michael Wouters]

> As we are doing a similar desgin
> also using a Zynq 7010 I would appreciate if you could elaborate
> a bit what made the FPGA too small for your application.

It wasn't too small, I just had to  think about just how much
filtering I was using. "It was a struggle" probably overstated the
situation.

The main limitation is number of DSP slices (80 for the Zynq7010)
rather than general FPGA resources.
Most of these are used by the CIC+FIR decimation and this is largely
because I am working with 64 bit data so that each filter stage needs
twice as many DSP resources as you would for say 32 bit data (where
the 48 bits each MAC has might be enough to get by with).

This may be overkill in some applications. The original application
for this was in tracking phase in a laser heterodyne interferometer
where phase rollovers during long measurement times were undesirable.
So for other applications eg a 10 MHz phase comparison where frequency
differences are quite small, the data width could be dropped
significantly.

Cheers
Michael



On Sat, May 28, 2016 at 3:11 PM, Attila Kinali <att...@kinali.ch> wrote:
> On Sat, 28 May 2016 12:08:18 +1000
> Michael Wouters <michaeljwout...@gmail.com> wrote:
>
>> I also have been looking at low-cost SDR hardware for T measurements
>> and have made an RF phase meter based on the Red Pitaya. The
>> performance of this was not as good as I was hoping for: the
>> fractional frequency resolution of this is about 10E-12 at 1 second
>> averaging time. An earlier implementation on fairly ordinary NI
>> hardware (14 bit 100 MHz ADCs) did better than 10E-13. Part of the
>> problem seems to be that although the RP ADC is 14 bits, the effective
>> number of bits is really only 10, according to a study I read (ENOB
>> for the NI ADCs is specified as 12). The RP is a bit constrained for
>> DSP resources too - it was a struggle to squeeze in the decimation
>> filters.
>
> This does not really surprise me. The Red Pitaya has not been done
> by someone who knows how to do a low noise design.
>
> Unfortunately, there are no schematics of the board available
> (why someone would keep these secret when everything else is
> open source is beyond me), but from what is known:
> A dual 14bit 125Msps ADC (LT2145) that are fed by an Opamp
> (seems to be an LTC6403) to get a differential signal out of
> the signle ended input. There is an quite high impedance input
> divider stage (500k to 1M resistors!).
>
> But the biggest problem of the board is, that the ADC is right
> next (as in ~2mm distance) from the Zynq FPGA+CPU SoC.
> No matter how well you "shield" the ADC, this alone will eat up
> quite a bit of the ADC's performance.
>
> As for the FPGA size, it's supposed to be a 17k LUT type. It's not
> the biggest FPGA on the market, but that should be quite a bit of
> resources. So I am a little bit surprised that you had trouble to
> fit in the decimation filters. As we are doing a similar desgin
> also using a Zynq 7010 I would appreciate if you could elaborate
> a bit what made the FPGA too small for your application. As this
> would mean that we have to potentially redesign the board.
>
>
> Attila Kinali
>
> "schematics" (aka extended block diagram) of the red pitaya prototype:
> https://dl.dropboxusercontent.com/s/jkdy0p05a2vfcba/Red_Pitaya_Schematics_v1.0.1.pdf
>
> Close up pictures:
> http://imgur.com/a/AuYWf
>
>
> --
> 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] Commercial software defined radio for clock metrology

[Michael Wouters]

The following may be of interest to those playing with low-cost SDR hardware:

I also have been looking at low-cost SDR hardware for T measurements
and have made an RF phase meter based on the Red Pitaya. The
performance of this was not as good as I was hoping for: the
fractional frequency resolution of this is about 10E-12 at 1 second
averaging time. An earlier implementation on fairly ordinary NI
hardware (14 bit 100 MHz ADCs) did better than 10E-13. Part of the
problem seems to be that although the RP ADC is 14 bits, the effective
number of bits is really only 10, according to a study I read (ENOB
for the NI ADCs is specified as 12). The RP is a bit constrained for
DSP resources too - it was a struggle to squeeze in the decimation
filters.

Cheers
Michael

On Sat, May 28, 2016 at 10:17 AM, Bruce Griffiths
 wrote:
> On Thursday, May 26, 2016 06:40:26 PM Bob Camp wrote:
>> Hi
>>
>> Very interesting paper, thanks for sharing !!
>>
>> One question:
>>
>> In many DMTD (and single mixer) systems, a lowpass and high pass filter are
>> applied to the signal coming out of the mixer. This is done to improve the
>> zero crossing detection. It also effectively reduces the “pre detection”
>> bandwidth. My understanding of the setup in your paper does not do this
>> sort of filtering. It simply operated directly on the downconverter signal.
>>  Is this correct? I may have missed something really obvious in a quick
>> read of the paper…..
>>
>> Thanks!
>>
>> Bob
>
> All the filtering and down mixing is done in the digital domain.
> Anitialiasing filters in front of the ADCs are also be required.
>
> A 2  (or more) receive channel SDR board would be a nice tool to use for this
> provided the FPGA is large enough.
>
> Bruce
>
>>
>> > On May 25, 2016, at 12:01 PM, Sherman, Jeffrey A. (Fed)
>> >  wrote:
>> >
>> > Hello,
>> >
>> > A recently published paper might be of interest to the time-nuts
>> > community. We studied how well an unmodified commercial software defined
>> > radio (SDR) device/firmware could serve in comparing high-performance
>> > oscillators and atomic clocks. Though we chose to study the USRP
>> > platform, the discussion easily generalizes to many other SDRs.
>> >
>> > I understand that for one month, the journal allows for free electronic
>> > downloads of the manuscript at:
>> > http://scitation.aip.org/content/aip/journal/rsi/87/5/10.1063/1.4950898
>> > (Review of Scientific Instruments 87, 054711 (2016))
>> >
>> > Afterwards, a preprint will remain available at:
>> > http://arxiv.org/abs/1605.03505
>> >
>> > There are commercial instruments available with SDR architecture
>> > under-the-hood, but they often cost many thousands of dollars per
>> > measurement channel. In contrast, commercial general-purpose SDRs scale
>> > horizontally and can cost <= $1k per channel. Unlike the classic
>> > dual-mixer time-difference (DMTD) approach, SDRs are frequency agile. The
>> > carrier-acceptance range is limited not by the sample clock rate but by
>> > the ADC's input bandwidth (assuming one allows for aliasing), which can
>> > be many times greater. This property is an important feature in
>> > considering the future measurement of optical clocks, often accomplished
>> > through a heterodyne beatnote (often at "practically any" frequency
>> > between ~1 MHz to 500 MHz) with a femtosecond laser frequency comb. At
>> > typical microwave clock frequencies (5 MHz, 10 MHz), we show that a stock
>> > SDR outperforms a purpose-built DMTD instrument.
>> >
>> > Perhaps the biggest worry about the SDR approach is that fast ADCs are in
>> > general much noisier than the analog processing components in DMTD.
>> > However, quantization noise is at least amenable to averaging. As you all
>> > likely appreciate, what really limits high precision clock comparison is
>> > instrument stability. In this regard, the SDR's digital signal processing
>> > steps (frequency translation, sample rate decimation, and low-pass
>> > filtering) are at least perfectly stable and can be made sufficiently
>> > accurate.
>> >
>> > We found that in the studied units the limiting non-stationary noise
>> > source was likely the aperture jitter of the ADC (the instability of the
>> > delay between an idealized sample trigger and actuation of the
>> > sample/hold circuitry). However, the ADC's aperture jitter appears highly
>> > common-mode in chips with a second "simultaneously-sampled" input
>> > channel, allowing for an order-of-magnitue improvement after
>> > channel-to-channel subtraction. For example, at 5 MHz, the SDR showed a
>> > time deviation floor of ~20 fs after just 10 ms of averaging; the
>> > aperture jitter specification was 150 fs. We also describe tests with
>> > maser signals lasting several days.
>> >
>> > Best wishes,
>> > Jeff Sherman, Ph.D.
>> > 
>> > National Institute of Standards & Technology
>> > 

[time-nuts] GPS week rollover and time of day

[Michael Wouters]

Earlier this year, a venerable VP Oncore in one of our systems started
outputting a time of day which was 1024 weeks in the past. This was
presumably because it had some reference time in its firmware which it
was using to resolve the n*1024 weeks ambiguity in broadcast GPS time,
and it was now more than 1024 weeks past that reference time. In this
case, the receiver still worked fine otherwise.

I have since come across some manufacturer's advisories stating that
some of their products will cease to function because of this problem
- it is not clear whether this is the receiver itself or the product
based on the receiver.

I would be interested to know if anyone else has run across the week
rollover problem, or has seen any advisories about anticipated
problems.

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] I thought GPS repeated every 12 hours (-2 minutes)

[Michael Wouters]

> Multipath on GPS normally requires a couple of things:
>

> 3) The signal path length has to be close enough that the normal firmware 
> does not reject
> the solution.
>

Expanding on this a bit, because it's relevant to the "aircraft
causing multipath" question, the pseudo random noise ranging method
allows discrimination in the time domain against sources of multipath
further away than 300 m at worst, and much better in practice.

At the L1C 1 MHz chip rate, the correlation function for the received
PRN is zero more than 1 us == 300 m away. In practice, you're
digitizing much faster than 1 MHz and you can use a more closely
spaced set of correlators, perhaps improving by a factor of 10.

This doesn't work though when a reflection is the only signal you are
seeing,  as in Bob's point (1).

(The effect of multipath when there is a line of sight signal also
visible is to distort the correlation function, which is triangular in
the ideal case. This introduces errors into the interpolation used to
improve the resolution of the PRN ranging.)

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] laser as clock source

[Michael Wouters]

(replying to myself here) ... one other way to use a laser as a clock
is to use a pulsed laser like a frequency comb, where the pulse period
is locked to an external reference like a Cs. A system like this has
been used for synchronization along a particle accelerator beamline,
to give one example.

Cheers
Michael


On Sat, May 7, 2016 at 6:05 PM, Michael Wouters
<michaeljwout...@gmail.com> wrote:
> Dear Ilia
>
> Emission of light is a quantum mechanical process. It is fundamentally
> statistical in nature and as someone commented earlier, makes a good
> random number generator. Here's one, for example:
>
> http://www.nature.com/articles/srep10214
>
> If you attenuate any light source, lasers included, to the point that
> you can count individual photons, it will just be noise.
>
> Your professor is right about a laser having a narrow linewidth
> compared to other sources. Its essential property though is that its
> light is coherent. When viewed as a particle (photon), this means that
> the wave functions of the photons are phase coherent. When viewed as
> an electromagnetic wave, this means that there is phase coherence in
> the electromagnetic wave.
>
> Here's a simple picture that may help:
>
> A laser consists of some active medium, usually placed in an optical
> resonator to increase the overall gain of the lasing process. You
> 'pump' the medium, putting energy into it via an electric current, a
> flashlamp, or another laser. Excited atoms start to emit this absorbed
> energy  via spontaneous emission - this is random and is not laser
> light. However, there is another process that takes place (this is one
> of Einstein's insights), stimulated emission. A photon passing by an
> excited atom will cause that atom to de-excite (with a certain
> probability), emitting a photon whose wave function is coherent with
> the incident photon. These photons circulate around the cavity,
> causing other phase coherent photons to be emitted, in a kind of
> avalanche - this is the laser light. You make one part of the cavity
> slight transparent so that some light leaks out for you to use.
>
> Imagine now that your active medium only has a few atoms in it,
> randomly scattered along the length of the cavity. As a photon travels
> along the cavity, the photons that are caused by stimulated emission
> will be emitted at random times determined by their random positions
> (and you don't have to make any assumptions about probabilistic
> emission to see this). The light that we see coming out of the cavity
> is therefore emitted at random times.
>
> You may be thinking, OK that's a gas laser where the atoms are moving
> around. What about a solid state laser like a diode laser ? The
> crystal is of course not perfect, but really it comes down to my
> initial statements that emission and absorption of light is a
> probabilistic process. So the circulating photon effectively causes a
> sequence of emissions that are random in time.
>
> The only way to use a laser as a clock is to lock it to some reference
> like an atomic transition or stable cavity and then use that as source
> to heterodyne other lasers suitably close in frequency with, or to
> lock an optical frequency comb to it, which transfers the optical
> frequency back into the RF domain.
>
>
> Cheers
> Michael
>
>
> On Sat, May 7, 2016 at 3:14 PM, Ilia Platone <i...@iliaplatone.com> wrote:
>> Wait... no telescopes, very close distances...
>>
>> only a laser, with a photon limiter like a dark window, "close" like 10mm or
>> so... just the space required for the laser optics plus the "limiter", and a
>> photon counting detector that can be an APD or a PMT, it depends on the size
>> required and scale of integration.
>>
>> The "idea" came because my professor told me that laser is a light source
>> composed by a limited number of harmonics, so close the ones as some nm
>> wavelengths, to get these lights can be directional and manouverable: if
>> these should be the carachteristics of lasers (a laser expert can correct
>> me), photons emitted by this type of light source should hit the detector at
>> a constant rate. The (very dark) limiter serves to regulate the photon flux
>> so a very limited number of photons reach the sensor part.
>>
>> The question was if the photodetector could use the individual photon
>> detection as clock tick, and if these ticks can be regular in frequency.
>> Many have replied that it would be noisy: phase noise? I don't think a
>> single photon can cause AM noise, because I was talking about single photon
>> pulses into the photon counting region, not into the analog region. Please
>> cor

Re: [time-nuts] laser as clock source

[Michael Wouters]

Dear Ilia

Emission of light is a quantum mechanical process. It is fundamentally
statistical in nature and as someone commented earlier, makes a good
random number generator. Here's one, for example:

http://www.nature.com/articles/srep10214

If you attenuate any light source, lasers included, to the point that
you can count individual photons, it will just be noise.

Your professor is right about a laser having a narrow linewidth
compared to other sources. Its essential property though is that its
light is coherent. When viewed as a particle (photon), this means that
the wave functions of the photons are phase coherent. When viewed as
an electromagnetic wave, this means that there is phase coherence in
the electromagnetic wave.

Here's a simple picture that may help:

A laser consists of some active medium, usually placed in an optical
resonator to increase the overall gain of the lasing process. You
'pump' the medium, putting energy into it via an electric current, a
flashlamp, or another laser. Excited atoms start to emit this absorbed
energy  via spontaneous emission - this is random and is not laser
light. However, there is another process that takes place (this is one
of Einstein's insights), stimulated emission. A photon passing by an
excited atom will cause that atom to de-excite (with a certain
probability), emitting a photon whose wave function is coherent with
the incident photon. These photons circulate around the cavity,
causing other phase coherent photons to be emitted, in a kind of
avalanche - this is the laser light. You make one part of the cavity
slight transparent so that some light leaks out for you to use.

Imagine now that your active medium only has a few atoms in it,
randomly scattered along the length of the cavity. As a photon travels
along the cavity, the photons that are caused by stimulated emission
will be emitted at random times determined by their random positions
(and you don't have to make any assumptions about probabilistic
emission to see this). The light that we see coming out of the cavity
is therefore emitted at random times.

You may be thinking, OK that's a gas laser where the atoms are moving
around. What about a solid state laser like a diode laser ? The
crystal is of course not perfect, but really it comes down to my
initial statements that emission and absorption of light is a
probabilistic process. So the circulating photon effectively causes a
sequence of emissions that are random in time.

The only way to use a laser as a clock is to lock it to some reference
like an atomic transition or stable cavity and then use that as source
to heterodyne other lasers suitably close in frequency with, or to
lock an optical frequency comb to it, which transfers the optical
frequency back into the RF domain.


Cheers
Michael


On Sat, May 7, 2016 at 3:14 PM, Ilia Platone  wrote:
> Wait... no telescopes, very close distances...
>
> only a laser, with a photon limiter like a dark window, "close" like 10mm or
> so... just the space required for the laser optics plus the "limiter", and a
> photon counting detector that can be an APD or a PMT, it depends on the size
> required and scale of integration.
>
> The "idea" came because my professor told me that laser is a light source
> composed by a limited number of harmonics, so close the ones as some nm
> wavelengths, to get these lights can be directional and manouverable: if
> these should be the carachteristics of lasers (a laser expert can correct
> me), photons emitted by this type of light source should hit the detector at
> a constant rate. The (very dark) limiter serves to regulate the photon flux
> so a very limited number of photons reach the sensor part.
>
> The question was if the photodetector could use the individual photon
> detection as clock tick, and if these ticks can be regular in frequency.
> Many have replied that it would be noisy: phase noise? I don't think a
> single photon can cause AM noise, because I was talking about single photon
> pulses into the photon counting region, not into the analog region. Please
> correct me if I'm wrong.
>
> Ilia.
>
>
> Il 05/05/2016 21:22, Hal Murray ha scritto:
>>
>> jim...@earthlink.net said:
>>>
>>> Well, in deep space optical comm, we send many photons with a laser, and
>>> we
>>> use pulse position modulation at the receiver detecting single  photons
>>> (or
>>> "few photons"), by which we can send "many bits/photon"  (e.g. if you
>>> have
>>> 256 possible time slots in which the photon can  arrive, you have 8 bits/
>>> photon)
>>
>> Neat.  Could you please say a bit more.
>>
>> What sort of distance?  Bandwidth?  Error rate?
>>
>> How big is the laser and telescope?   What sort of optics on the receiver?
>> How hard is it to point the receiver in the right direction?  How hard is
>> it
>> to point the transmitter telescope?  ...
>>
>> How does the receiver get timing?
>>
>>
>
> --
> Ilia Platone
> via Ferrara 54
> 47841
> Cattolica (RN), 

Re: [time-nuts] synchronization for telescopes

[Michael Wouters]

On Thu, May 5, 2016 at 4:53 AM, jimlux  wrote:
> On 5/4/16 11:52 AM, Ilia Platone wrote:
>>
>> You got it, however: It only matters relative time. Start and Stop times
>> will be known, and that is solved.
>> Someone has proposed using TV or other broadcasting carrier as reference
>> clock: this can be another very cheap solution. There are many AM
>> stations near the places we chosen, and these can be used.
>
>
> AM stations are nice, because it's ground wave, so the propagation is
> reasonably stable, but the frequency is on the order of 1 MHz (and not very
> stable in a time-nuts sense).  if your two sites are 2km apart, in the worst
> case, that's a time difference for your AM signal of 6 microseconds.  I'm
> not sure what the phase noise on an AM transmitter is at 160kHz out from the
> carrier, but it could be pretty bad and not affect the audio quality on
> someone's car radio.

Has anyone thought out how you calibrate out the electronic delays in
such a system ?
My picture is that you bring a station close to your master so that
you can physically measure the distance between the phase centres of
the two antennas since I think that the phase centre of the antenna
has to be reference point of each system. I am not a radio person: can
the phase centre be defined (and kept constant in different
environments) to within say 10 cm, particularly at 300 m-ish
wavelengths ?

Also, isn't the problem of calculating the delay between two stations
more complicated than just knowing the separation of the two antennas?
You need to know where the transmitter is (just like in GPS) to the
same accuracy. You might need a network of stations to pin all this
down properly.


Cheers
Michael

> TV intended for simulcasting is MUCH better (because the digital receiver
> needs to see the multiple arriving signals as if they were multipath
> scattered versions of a single signal).
>
> If you have line of sight to a TV station, I would think this could be quite
> good, and it's up around 100 MHz.  The period is 10ns (or 10,000 ns, 1E7
> ps).  You want 100ps kind of timing, that's measuring the phase of the TV
> signal to 1 part in 100,000, which is challenging, but not impossible.
>
___
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] Optical transfer of time and frequency

[Michael Wouters]

Not stable enough unfortunately. An ageing rate of a few parts in 10^12 per
day is typical, which translates to 100 ns. You could be brave and model
that as linear frequency drift to predict the time offset to the required
0.5 ns or so but I suspect that it could be a very frustrating exercise. We
operate a large number of rubidiums and sudden changes in frequency are
quite common.

Cheers
Michael.

On Thursday, 5 May 2016, Hal Murray  wrote:

>
> t...@leapsecond.com said:
> > Any of these methods is going to be a challenge, given their 500 ps
> > requirement and their $2k budget.
>
> How stable are surplus rubidium oscillators?
>
> How close could you get if you brought two of them together, compared
> phase,
> drove them to the site for a nights work, drove them back to the same
> location and compared the phase again.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> 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] synchronization for telescopes

[Michael Wouters]

Dear Attila

On Tue, May 3, 2016 at 10:05 PM, Attila Kinali  wrote:

>I have some numbers of an project of the ETH that did use standard
>LEA-6T recording the phase data and got in the post processing
>to an uncertainty of <4mm averaging over several hours. Translating
>that to timing resolution would mean an uncertainty of less than 13ps.
>Of course, this number is completely theoretical, but it shows that
>it should be possible to go below 1ns in time resolution, if the
>phase data could be related to a stable reference oscillator in
>post-processing and if the offsets between the different receiver
>and antenna combinations are calibrated out.

There are  differences between solving for position and solving for  time.

In the case of position, it's constant so you can average over long
times. In the case of time, you can't assume this and long-term
averaging is not reasonable. So position uncertainty does not
translate directly to time uncertainty (although it probably tells you
about the precision of the individual measurements).

The other key difference (and difficulty) is in your statement "if the
phase data could be related to a stable reference oscillator in
post-processing". In the case of position, the solution is for a point
in space. In the case of time, you have to relate it to the output of
some physical clock.

In the case of a single frequency receiver, the measurements are made
with respect to the internal TCXO, which is operated much like the
software clock in eg the Linux kernel clock. You then have to know the
(continuously varying) offset between this clock and the receiver's
reference timescale, the offset between the nominal output 1 pps and
the reference time scale in some cases, and the sawtooth correction,
to finally relate the raw measurements to your external clock.

Several people have mentioned that there are some low-cost receivers
which apparently allow for an external oscillator. This may result in
improved time-transfer operation but the key question is the
relationship between the output 1 pps and the 1 pps derived from the
external oscillator - it is not obvious that this will be constant
between eg power cycles of the receiver. This is something you have to
test for.

> That's why I'm proposing timing receivers. They are the ones that have
> the additional software and hardware bits which allow to relate an
> external oscillator to the satellite phases.

I think we're talking about the same thing here. By 'geodetic receiver' I meant:
L1/L2 + carrier phase measurements + externally supplied 10 MHz and 1 pps.
This is the typical kind of receiver installed at an IGS station, with
the external clock a Cs or H-maser. They cost around $10-$15K.

> I don't know what resolution the LEA family offers there, but the
> spec of the protocol defines a 1ps resolution in the data. So I would
> guess that the phase data resolution is probably in the order of 10-100ps.

Coincidentally, I am currently writing software so that I can test the
LEA-8MT for GPSCV time-transfer. This is code-based, in the usual way.
I will be doing a comparison of a number of different single-frequency
receivers for time-transfer - this may be of interest to the time-nuts
community because the testing platform is all open source
(www.openttp.org) .

This whole discussion has been very useful  because it has alerted me
to an interesting application for post processed timing!

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] Fw: Optical transfer of time and frequency

[Michael Wouters]

One other possibility occurs to me that might be doable with surplus
gear and sticks to the  budget. Instead of using WR, give up on
getting time of day and just send a 1 kHz pulse stream in each
direction. Each station then measures against its own GPSDO clock
using a standard/homebrew TIC and records the difference. This is
ambiguous modulo 1 ms but this is trivially resolved using GPS. You
also probably know the distance between the stations to much better
than 1 ms = 300 km :-) . You then post-process but this can be done
with very little latency if you're keen.

Cheers
Michael

On Mon, May 2, 2016 at 1:44 AM, Tom Van Baak  wrote:
>> Has anybody experienced with free-space optical gigabit Ethernet
>> links? I am curious about whether the transceivers have a fixed
>> latency or at least a latency one can easily quantify online. This is
>> the trickiest part for adding WR support on top of a given physical
>> layer.
>
> Hi Javier,
>
> When searching this topic I ran across a commercial laser solution:
>
> http://www.laseroptronics.com/products.cfm/product/27-0-0.htm
> http://www.laseroptronics.com/index.cfm/id/57-66.htm
> http://www.laseroptronics.com/index.cfm/id/57-69.htm
> etc.
>
> But, according to /57-67.htm it "starts" at $15k per node. Plus there's the 
> cost of all the WR pieces, assuming the two are even compatible. So this is 
> vastly above the ~$2k budget mentioned by OP. I also assume OP is not ready 
> to embark on a one-off, multi-man-year R project.
>
> This particular issue -- how to synchronize (or, at least phase compare) 
> multiple oscillators by a two-way laser link over a few km to within 500 ps 
> -- is really quite interesting. It would, for example, allow me to do live 
> monitoring of 5071A Cs time dilation on my next mountain-valley relativity 
> experiment.
>
> /tvb
> ___
> 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] synchronization for telescopes

[Michael Wouters]

Attila,

I don't think a cheap receiver like a LEAxxx will quite get you there.

On Mon, May 2, 2016 at 1:10 AM, Attila Kinali <att...@kinali.ch> wrote:
> Moin,
>
> Let's quickly recap what the requirements are and what has been discussed
> so far:
>

> What I think has the best chances of success is to use an Rb frequency
> standard at each site instead. This will give you a stable reference
> frequency which will allow you to average the data from the GPS module
> to find the precise time in the prostprocessing.
>
> As a GPS module, I would either use an LEA-M8F or a LTE-Lite. The LEA has
> an frequency/phase input which which an external reference can be measured.
> the LTE-Lite supports using an external oscillator. What you definitely
> need is to get the satellite phase data ouf of the module to relate
> the phase differences between the modules local oscillator to the satellites
> and from there to the other locations.
>

> This should bring you at least down to a 1ns uncertainty level
> (after calibration). Judging from Michael Wouters said, probably
> close to 200-300ps.
>

The number I quoted is for high quality geodetic receivers. There are
crucial differences between these and the cheap receivers in regard to
time-transfer. The first is how you relate your external clock's 1 pps
to GPS time.

 For a geodetic receiver, this is 'simple' - it takes a 1 pps and 10
MHz that it locks to and does a one-off pps sync to. The code and
phase measurements are then reported with respect to this clock. For
some receivers, there will be an internal delay that depends on the
phase relationship between the 10 MHz and 1 pps so you have to control
that.

For cheap receivers, with no external oscillator, the connection
between your clock and GPS time is more complicated. You normally set
the GPS receiver's reference time to be GPS. Code measurements are
then reported with respect to a software GPS clock, based on the
receiver's XO. It's a software clock because the XO isn't steered. The
receiver then outputs a 1 pps (which you can then measure with respect
to but with the limitation that the receiver can only place this pps
modulo the period of its internal clock, resulting in the usual
sawtooth. The receiver outputs a sawtooth correction which allows you
to reduce the sawtooth in post-processing, with varying degrees of
success. Of course you can average, but being confident that you have
eliminated bias at the level of a few hundred ps may be tricky.

Some aspects of this may eg the sawtooth be improved by using an
external oscillator but I don't have any experience of this.

The other important difference is the resolution of the receiver's
measurements. A cheap receiver reports the code measurements at
relatively coarse resolution, sometimes a few ns, whereas a geodetic
receiver reports at much higher resolution. If you had a cheap
receiver, the code measurement resolution is seldom specified so you
would have to test candidate receivers.

I have many years of raw code measurement data from many identical
receivers operating on baselines of a few km up to 20 km. I will try
to have a look later this week to confirm/deny/make ambiguous what I
said above.

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] Using lasers for data transmission

[Michael Wouters]

Dear Ilia

On Sun, May 1, 2016 at 6:40 PM, Ilia Platone  wrote:
> The problem would be modulating a 10GBASE-T signals into a single laser
> beam, and demodulating it using (I think) an APD.
>

The White Rabbit cards use SFP (small form-factor pluggable) lasers
that plug into the card. These incorporate both the laser(s) (there
can be an uplink and downlink laser) and APD. Modulation in these
devices is simply by varying the current. This puts a frequency chirp
on the laser which exacerbates dispersive effects. You can do better
with an electro-optic device like a Mach-Zehnder intensity modulator -
but this isn't necessary.

> except the one depending on light travel, that shouldn't be a problem if
> using White Rabbit, there could be some problem with the modulating and
> transmitter/receiver delay response times.

I remember reading that the SFPs are a source of jitter but
nonetheless, sub-ns timing is achievable.

> I mean that lasers offer 100ps rise time, and the APDs I found offer 5ps
> rise time, these must be multiplied by all the wires that GigE needs, which
> should be 4 pairs if I remember correctly, and some are bi-directional, plus
> the modulation process.
>
> Ilia.
>

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] Optical transfer of time and frequency

[Michael Wouters]

On Sat, Apr 30, 2016 at 6:14 AM, Magnus Danielson
 wrote:
> Well, giving the conditions mentioned, doing ranging codes such as those
> used by GPS is very easy and cheap. Doing this in bidirectional isn't too
> hard. Doing a suitably high chip-rate should cost very little.

I've done two-way time-transfer over optical fibre using exactly this
technique. The TDEV is about 1 ps for tau>1s. Not so cheap, about 25K
euro per node (20K signal processing - NI FPGA, 2K laser and power
supplies, 1K detector, 1K RF electronics) in my setup, but that cost
could be greatly reduced since a $100 OEM FPGA could do the signal
processing (I've already done work on this but currently looking for
motivation to finish it off) and a simple, intensity-modulated laser
would probably be fine. A 2K euro budget would be a challenge though.

> The two-way time-transfer is relatively easy, but you will need to do some
> calibration to get the precision needed.
>

At first glance, I would think that you should be able to define the
optical RX/TX path to within 10 cm without any trouble and that gives
you 300 ps accuracy. Even on fibre links, I don't think anyone would
claim an accuracy of better than a few hundred ps.

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] Optical transfer of time and frequency

[Michael Wouters]

So why not do White Rabbit free space ?

Cheers
Michael

On Sat, Apr 30, 2016 at 4:04 AM, Paul Boven  wrote:
> Hi everyone,
>
> On 04/29/2016 03:28 PM, Magnus Danielson wrote:
>>
>> Phase/time transfer over fiber is shaping up, but White Rabbit is
>> starting to grow up and more reports for long distances is showing up.
>> ETFT is one of the placces to check for reports.
>
>
> And the White Rabbit workshops, with the presentations online:
> http://www.ohwr.org/projects/white-rabbit/wiki/Mar2016Meeting
>
> I happen to be working on time transfer via White Rabbit. The White Rabbit
> standard proscribes the use of 1000Base-Bx10 (10km reach bi-directional)
> SFPs, but it turns out to work just fine with longer reach SFPs. However,
> there are several effects that limit the accuracy that you can get on longer
> links:
>
> * Dispersion of the fiber (as the lasers change temperature, their
> wavelength changes, and they experience a slightly different index of
> refraction, hence propagation speed.
>
> * Change in index of refraction in the fiber itself. The propagation speed
> of both the uplink and downlink wavelength change, in absolute sense but
> also their ratio changes. This is something the WR protocol can't
> detect/correct for.
>
> There are several people working on these issues, trying to improve both the
> calibration and stability even further.
>
> Regards, Paul Boven.
>
>
> ___
> 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] Optical transfer of time and frequency

[Michael Wouters]

On Fri, Apr 29, 2016 at 1:18 PM, Bruce Griffiths
<bruce.griffi...@xtra.co.nz> wrote:
> Quoting Michael Wouters: "According to this,
>
> http://www.nist.gov/manuscript-publication-search.cfm?pub_id=912449
>
> there are many practical challenges  with a one way free-space optical link."
> That paper indicates that  one way transfer with noise of a few picosec 
> should be feasible using an IR laser.

Oh, yes I see in Fig 2b that the short term, one-way noise is ca. +/-
5 ps. And probably with temperature measurements, the long term
variation could be compensated.

But we still don't know if there is line of sight.

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

[Michael Wouters]

According to this,

http://www.nist.gov/manuscript-publication-search.cfm?pub_id=912449

there are many practical challenges  with a one way free-space optical link.

They were, however, aiming for much higher stability than is needed here.

There are a lot of ideas being tossed around here. It would probably
help to focus the discussion a bit if we knew:
(1) The budget (presumably small)
(2) Site constraints - is there line of sight, is it really impossible
to run a fibre (I know trenching costs are high but a fibre strung
along a fence with some UV protection might be acceptable in this
application)
(3) What expertise there is that can be drawn upon

Cheers
Michael


On Fri, Apr 29, 2016 at 11:11 AM, Bruce Griffiths
 wrote:
> One advantage of a free space optical link for this application, is that most 
> of the factors that produce severe attenuation of the optical signal also 
> preclude observation of the stellar sources as well. Thus the link only needs 
> to work well under near ideal conditions.Increasing the aperture of the 
> transmit and receive optics reduces the required transmitter power and the 
> associated safety hazards of the transmitted optical beam.
> Bruce
>
>
> On Friday, 29 April 2016 1:02 PM, Bruce Griffiths 
>  wrote:
>
>
>  If you add a small beam expander, then there should be few safety issues.In 
> this case a laser beam power of a few (1??) mW may suffice.Similar collection 
> optics at the receiver will also be required. One can use small telescopes 
> for this purpose. I've used an eyepiece with a 12" (305mm) dobsonian to 
> produce a 300mm diameter beam from a green laser pointer. You shouldn't need 
> to go quite that far though.
> Bruce
>
>
> On Friday, 29 April 2016 12:01 PM, Attila Kinali  wrote:
>
>
>  On Thu, 28 Apr 2016 23:22:24 +0200
> Attila Kinali  wrote:
>
>> > Thanks Attila, I know how to build a transmitter and a receiver, and now
>> > is more clear the system you designed. But as I will propose this system
>> > to an astro club, and in this astro club there's the possibility that
>> > not all would have a radio license, I need something "free-to-play", if
>> > it concern.
>>
>> Ok.. that's quite some constraint. This rules out any kind of transmission.
>
>
> Here another crazy idea:
>
> If you can ensure line of sight between stations, you can use a
> laser link between them. Modulate the laser with an RF signal in the
> 10-100MHz range. Use this on the receiver side to lock the OCXO.
> Proceed as before...
>
> This approach should be fairly simple to build, but needs some care
> to ensure that you are not endangering anyone with the laser beam.
> Other than that, you don't need a license for running such a system.
> There have been hobbyist laser communication links around for a couple
> of years, though i would advise to check the designs carfully as some
> of them have EMI and other problems that the original designers and users
> didn't care about.
>
>
> 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.
>
>
>
> ___
> 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

[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] 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] suitable statistics for measurements with gaps

[Michael Wouters]

The technique used for dealing with gaps is really about handling random
gaps in an otherwise uniformly sampled sequence. The idea is that you take
your sequence, pad it out with the missing data (tagging those points with
a NaN or whatever) and then when you're computing ADEV, if a data triplet
is missing a point(s), you simply drop it from the summation.
This works nicely for ADEV and TOTDEV but not so well for MDEV.

There are a couple of implementations of this around: allantools (Python)
and tftools (Matlab/Octave) are at least two on GitHub.

Cheers
MIchael

On Sunday, 24 April 2016, Attila Kinali  wrote:

> Hoi Jim,
>
> On Fri, 22 Apr 2016 06:39:07 -0700
> jimlux > wrote:
>
> > But what about when the observations have gaps? Say you're measuring the
> > frequency of a spacecraft oscillator, and you can only see it for 8
> > hours a day?  the description of the frequency variation at a time
> > difference of 24 hours is useful, even if the integration time for each
> > measurement is, say, 1000 seconds.
>
> I recently stumbled over a paper by Sesia and Tavella[1] that might
> be of use. I didn't read it yet, so I cannot say anything about its
> content but that it covers gaps in ADEV data for space clocks.
>
>
> Attila Kinali
>
> [1] "Estimating the Allan variance in the presence of long periods of
> missing data and outliers", by Sesia and Tavella, 2008
> http://stacks.iop.org/Met/45/S134
>
> --
> 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] Lady Heather coming soon to a Linux box near you...

[Michael Wouters]

One simple trick I have used many times is to split the TX pin from the GPS
receiver - ntpd really only needs to receive. Some ntpd refclock drivers
will attempt to configure the receiver but if you can ensure that ntpd is
getting the messages it needs, then all should be fine. Otherwise, hack the
code!

Cheers
Michael

On Saturday, 23 April 2016, Chris Albertson 
wrote:

> The install is easy as NTP comes with most Linux distributions.  So it
> would likely already be there and all you do is edit the .conf file
> Again the problem with LH is that it and NTP both want access to the
> GPS' serial port.
>
> NTP can be configured to NOT require access to the GPS' serial port
> but if you do that NTP will not know the time of day.  It WILL know
> when the seconds click over because of the PPS.   Not a bad problem as
> getting the time of day from some other source to within a few tens of
> milliseconds is easy.
>
> On Fri, Apr 22, 2016 at 6:20 AM, paul swed  > wrote:
> > Chris,
> > Quite the good point on the TBolt overkill and power. But the whole
> reason
> > for LH is to monitor an operating TBolt so a great use for something
> > already sucking power is a NTP server.
> > As I recall there was work using the Pi 1 to make a ntp server and that
> > could use a simple gps receiver dedicated to the system. Its installation
> > was pretty simple.
> > Interesting project and simply hope the install is dumb simple and
> stupid.
> > Regards
> > Paul
> > WB8TSL
> >
> > On Fri, Apr 22, 2016 at 2:01 AM, Chris Albertson <
> albertson.ch...@gmail.com >
> > wrote:
> >
> >> Neither of those two programs require much in the way of CPU power and
> >> the Pi 3 is a very powerful computer.  The Pi 3 could be doing several
> >> additional things all at once.  I doubt NTP and LH together would use
> >> 10% of the Pi 3's CPU.
> >>
> >> The problem is that I think BOTH NTP and LH will want to communicate
> >> with the T-bolt's serial port.  You'd have to figure out  way around
> >> that.  They both can't have exclusive access.   One way might be
> >> software like gpsd to make the GPS available via a socket interface to
> >> multiple users another way would be to configure NTP to use the "atom"
> >> reference clock.  This just uses a PPS only and not the serial port.
> >> But then NTP would need another clock to "number the seconds" which
> >> could be another NTP server out on the Internet.
> >>
> >> My opinion is that a Thunderbolt is over kill for NTP.  Not only that
> >> but it uses a lot of power.  Better to use a tiny, low power GPS
> >> receiver for NTP.  It runs 24x7 so it adds up.
> >>
> >> On Thu, Apr 21, 2016 at 3:09 PM, Mark Sims  > wrote:
> >> >>Would there be enough horsepower for a Pi 3 to run Lady Heather and
> act
> >> as a stratum 1 NTP server?
> >> > I suspect so,  the PI3 has quad core 64-bit capable 1.2GHz processor.
> >> The PI3 seems to be about 50% faster than the PI2.   It also runs about
> >> code about as fast as a 2 GHz Pentium 4.   But the ethernet interface is
> >> via a USB bridge (or maybe some other serial interface on the PI3).  Not
> >> the best way to do things...  Also,  the current PI Linux distros are
> all
> >> 32-bit.
> >> > I have the sound file issue worked out (system() a background shell
> that
> >> invokes aplay).  My old code left off the & on the shell command and it
> was
> >> not returning until the sound finished... d'oh
> >> > I also have the PI color issue resolved...
> >> > Now to finish up the serial port init code...  Oh,  and also the
> >> ethernet socket code...
> >> > I'm picking up one of those 7" PI LCD screens tomorrow...  should make
> >> for a nice package.  But they cost twice what the PI does...
> >> >
> >> >
> >> > ___
> >> > 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.
> >>
> >>
> >>
> >> --
> >>
> >> Chris Albertson
> >> Redondo Beach, California
> >> ___
> >> 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.
>
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
> ___
> 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] Trimble SMT 360

[Michael Wouters]

Dear Bob

( I shouldn't write email while walking around doing the housework!)

The possibility of other constellations causing a problem was one of the
things I checked, running it in GPS only mode. No improvement.

Cheers
Michael

On Wednesday, 20 April 2016, Bob Camp <kb...@n1k.org> wrote:

> Hi
>
> Actually there is one other possibility:
>
> If you have more than one “system” enabled *and* it’s doing “all in view”
> *and* it’s applying that
> to the timing *and* the population in view changes significantly … (whew !)
>
> As the solution pops between GPS and Glonass, you will get a time shift.
> Since it’s a “which one
> is right?” sort of thing … Trimble probably does not want to get into the
> debate. They would love
> to sell stuff to everybody.
>
> Bob
>
>
> > On Apr 19, 2016, at 3:32 PM, Logan Cummings <logan.cummi...@gmail.com
> <javascript:;>> wrote:
> >
> > Hi Michael, Bob,
> >
> > I had been very curious about this myself - the new ICM SMT 360
> > modules at first glance seem like a great deal - < $50 and 10MHz TCXO
> > disciplining built right in.
> >
> > I came across this paper which compares the older (GPS-only) ICM SMT
> > to a LEA-6T - the Trimble fares poorly in their testing.  The graphs
> don't
> > show an issue quite like yours Michael, so I'd be curious about the line
> of
> > questioning Bob brings up, how many satellites are being used by the
> > receiver - say in GPS-only mode?
> >
> > http://www.imeko.org/publications/tc10-2013/IMEKO-TC10-2013-028.pdf
> >
> >Does anyone else have comparative experience with the new SMT modules
> > from Trimble? RES or ICM?
> >
> > Thanks,
> > -Logan
> >
> > On Tue, Apr 19, 2016 at 4:01 AM, Bob Camp <kb...@n1k.org <javascript:;>>
> wrote:
> >
> >> Hi
> >>
> >> The two plots shown appear to be identical. If they are actually two
> >> different
> >> runs, the problem repeats very closely.
> >>
> >> If the GPS is not in position hold *and* the antenna is less than ideal
> -
> >> That’s
> >> the sort of thing you may see. Essentially it’s got two locations it
> >> “thinks” are
> >> correct. Another possibility is a position hold situation with a very
> low
> >> satellite count.
> >> As a single observed satellite goes in and out of multi path, the
> solution
> >> goes all over the place.
> >> Again, you need a challenged antenna for this to happen. Pretty much all
> >> of this
> >> would be apparent from the normal messages out of the part.
> >>
> >> Bob
> >>
> >>
> >>
> >>> On Apr 18, 2016, at 10:13 PM, Michael Wouters <
> michaeljwout...@gmail.com <javascript:;>>
> >> wrote:
> >>>
> >>> Does anyone have  experience with the Trimble SMT 360 ?
> >>>
> >>> I bought some of these four or five months after they were released.
> >> During
> >>> testing, the 1 pps output evidenced a problem, as shown in the attached
> >>> plot (the 1 pps is being measured against a Cs  beam standard), which
> is
> >>> not sawtooth-corrected. While there are longish periods of nominal
> >>> operation, the receiver seems to hop between two solutions.  This
> >> behaviour
> >>> is well out of specification.
> >>>
> >>> When I contacted Trimble support, they said that the firmware in the
> >>> receivers was very early, and replaced the receivers. However, the
> >> problem
> >>> was still evident with the new firmware. Trimble did not respond to
> >> further
> >>> emails.
> >>>
> >>> I tried many things to isolate the problem, including restricting the
> >>> receiver to GPS-only but I was unable to make an improvement.
> >>>
> >>> I would like to know if anyone else is operating an SMT 360 and if they
> >>> have seen any similar behaviour.
> >>>
> >>> Cheers[image: Inline image 2]
> >>> Michael[image: Inline image 1]
> >>> ___
> >>> time-nuts mailing list -- time-nuts@febo.com <javascript:;>
> >>> 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 <javascript:;>
> >> 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 <javascript:;>
> > 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 <javascript:;>
> 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] Trimble SMT 360

[Michael Wouters]

Dear Bob,

Sorry, the two plots are identical; it was a drag and drop fumble.

I should have given more detail - "tried many things" included running the
receiver in position hold ( which is the default ) and free run. The
receiver was being logged during operation and always claimed 5 to 10 SVs.
The antenna is roof-mounted with an excellent view of the sky. I tried
multiple antennas just in case, added a bit of gain, tried multiple SMT
360s, compared with other receivers in the lab ( Resolution T, Javad,
Septentrio, VP Oncore) ...

Another thing I didn't mention was that I tried it on a GPS simulator,
except with a position in the Northern hemisphere ( I'm in the South ) and
it worked fine for 12 hours. I wasn't sure what to make of this but decided
to stop spending my time on this because it was really Somebody Else's
Problem to solve.

In the end, I decided to use another receiver for my application ( GPS
common view, for which we'd been using the Resolution T previously ) but
now that that's almost done, I thought I'd have another look at the the SMT
360 problems.

Cheers
Michael

On Tuesday, 19 April 2016, Bob Camp <kb...@n1k.org> wrote:

> Hi
>
> The two plots shown appear to be identical. If they are actually two
> different
> runs, the problem repeats very closely.
>
> If the GPS is not in position hold *and* the antenna is less than ideal -
> That’s
> the sort of thing you may see. Essentially it’s got two locations it
> “thinks” are
> correct. Another possibility is a position hold situation with a very low
> satellite count.
> As a single observed satellite goes in and out of multi path, the solution
> goes all over the place.
> Again, you need a challenged antenna for this to happen. Pretty much all
> of this
> would be apparent from the normal messages out of the part.
>
> Bob
>
>
>
> > On Apr 18, 2016, at 10:13 PM, Michael Wouters <michaeljwout...@gmail.com
> <javascript:;>> wrote:
> >
> > Does anyone have  experience with the Trimble SMT 360 ?
> >
> > I bought some of these four or five months after they were released.
> During
> > testing, the 1 pps output evidenced a problem, as shown in the attached
> > plot (the 1 pps is being measured against a Cs  beam standard), which is
> > not sawtooth-corrected. While there are longish periods of nominal
> > operation, the receiver seems to hop between two solutions.  This
> behaviour
> > is well out of specification.
> >
> > When I contacted Trimble support, they said that the firmware in the
> > receivers was very early, and replaced the receivers. However, the
> problem
> > was still evident with the new firmware. Trimble did not respond to
> further
> > emails.
> >
> > I tried many things to isolate the problem, including restricting the
> > receiver to GPS-only but I was unable to make an improvement.
> >
> > I would like to know if anyone else is operating an SMT 360 and if they
> > have seen any similar behaviour.
> >
> > Cheers[image: Inline image 2]
> > Michael[image: Inline image 1]
> > ___
> > time-nuts mailing list -- time-nuts@febo.com <javascript:;>
> > 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 <javascript:;>
> 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] Trimble SMT 360

[Michael Wouters]

Does anyone have  experience with the Trimble SMT 360 ?

I bought some of these four or five months after they were released. During
testing, the 1 pps output evidenced a problem, as shown in the attached
plot (the 1 pps is being measured against a Cs  beam standard), which is
not sawtooth-corrected. While there are longish periods of nominal
operation, the receiver seems to hop between two solutions.  This behaviour
is well out of specification.

When I contacted Trimble support, they said that the firmware in the
receivers was very early, and replaced the receivers. However, the problem
was still evident with the new firmware. Trimble did not respond to further
emails.

I tried many things to isolate the problem, including restricting the
receiver to GPS-only but I was unable to make an improvement.

I would like to know if anyone else is operating an SMT 360 and if they
have seen any similar behaviour.

Cheers[image: Inline image 2]
Michael[image: Inline image 1]
___
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] Where does the source time for GPS come from?

[Michael Wouters]

Dear Sean,

The USNO is the main source of precise time in the US via the GPS system.
It has an ensemble of caesium clocks and hydrogen masers in Washington that
it uses as the reference to provide corrections for the clocks that are
onboard each of the GPS satellites. These corrections are broadcast
continuously via the GPS system.

What your boss is referring to is Coordinated Universal Time (UTC), the
international time standard. National labs which operate atomic clocks
compare their clocks using a variety of methods and send these to the BIPM,
which makes a weighted average of the all of the participating clocks (for
stability) and combines the ten or so primary frequency standard
evaluations (for accuracy) to finally get its best estimate of what one
second is. Each participating lab is then told what the difference between
its clock and UTC is.

USNO participates in UTC and keeps within tens of ns of UTC.

You can find the monthly reports in Circular T.

NIST also maintains an ensemble of atomic clocks and contributes to UTC.
However, in addition to commercial caesium beam standards and hydrogen
masers, they have several primary frequency standards, in particular,
caesium fountains.


Regards
Michael

On Wednesday, 13 April 2016, Sean Gallagher  wrote:

> I recently wrote a paper for school on precision time and from my research
> it seems that the US Naval Observatory is the main source of time for the
> United States. So I would assume that this is also true for the Master
> Control Station in Colorado and that they get their source time from the
> Observatory as well? I emailed the GPS.gov site and got an answer that they
> do indeed have clocks there but he was unsure of their source time because
> he was the webmaster for the site and so is not intricately tied in to the
> system.
>
> What's throwing me off though is that my former boss wrote up something
> for work where he states that the satellites get their time from BIPM? He
> is older and wiser than I am but I think that at this point I have probably
> done more research on it all so that's why I am not accepting his word
> immediately but also not writing it off.
>
> NIST is another option but it appears as if they are more about research
> correct?
>
> Respectfully,
>
> Sean Gallagher
> Malware Analyst
> 571-340-3475
> ___
> 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] Precise Time transfer and relative position over a short baseline

[Michael Wouters]

Dear Bruce

Posted too hastily ...

Since you don't care about absolute time, maybe using identical receivers
you might be able to get a few hundred ps synchronization using a PPP
solution,  for example.

Attached is 6 months of data for two Javad receivers, with daily PPP
solutions. The antennas for these receivers are separated by about 400 m.

Cheers
Michael

On Mon, Apr 11, 2016 at 3:00 PM, Bruce Griffiths  wrote:

> There is a proposal to use multiple light bucket style optical telescopes
> to do Intensity stellar Interferometry over short baselines (up to perhaps
> 1km  or so) by using independent clocks to time tag photon  arrivals. store
> the time tags and process the data off line. Depending on the time tag
> resolution there is a need to measure the time differences between the
> independent clocks to an accuracy in the 1ns to 100ps range. Is there a
> better way of doing this other than using geodetic grade GPS receivers
> capable of GPS carrier phase measurements?Since the local clock flywheel
> oscillators will need to not deviate by more than 100ps or so over the
> several minutes required to perform the carrier phase averaging what sort
> of clock will be suitable apart from a good rubidium standard with a
> cleanup oscillator?
> NB Running fibres or coax between the telescopes isnt an option.
>
> The relative positions of the telescopes has to be known to within a cm or
> so for this to work.
> 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.
>
___
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] Precise Time transfer and relative position over a short baseline

[Michael Wouters]

Dear Bruce

I think it will be very difficult to achieve synchronization at the level
you want using GNSS signals. The BIPM would only claim 2 ns accuracy for
calibration of the delays in a GNSS receiver plus antenna. When you process
carrier phase data, you typically see jumps at the day boundary of the
order of 1 ns, reflecting uncertainties in the model. There's  some
reduction in ionospheric noise and systematics because you would be
operating almost zero-baseline eg two identical receivers in our lab track
each other at the level of 100-200 ps, but again, calibration of absolute
delays below 1 ns is hard.

If you really can't use cables then you might consider free space signals
like a laser beam or microwaves. There is plenty of literature about free
space optical links. One example of a microwave timing link is
http://www.locata.com/wp-content/uploads/2015/09/USNO-Wide-Area-Wireless-Network-Synchronization-Using-Locata-ION-Publication-9-20-2015.pdf

On Mon, Apr 11, 2016 at 3:00 PM, Bruce Griffiths  wrote:

> There is a proposal to use multiple light bucket style optical telescopes
> to do Intensity stellar Interferometry over short baselines (up to perhaps
> 1km  or so) by using independent clocks to time tag photon  arrivals. store
> the time tags and process the data off line. Depending on the time tag
> resolution there is a need to measure the time differences between the
> independent clocks to an accuracy in the 1ns to 100ps range. Is there a
> better way of doing this other than using geodetic grade GPS receivers
> capable of GPS carrier phase measurements?Since the local clock flywheel
> oscillators will need to not deviate by more than 100ps or so over the
> several minutes required to perform the carrier phase averaging what sort
> of clock will be suitable apart from a good rubidium standard with a
> cleanup oscillator?
> NB Running fibres or coax between the telescopes isnt an option.
>
> The relative positions of the telescopes has to be known to within a cm or
> so for this to work.
> 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.
>
___
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] Unix equivalent of Windows RbMon app for PRS10 monitoring

[Michael Wouters]

Dear Mike,

I have a Perl script and a C++ application that may be of use. The Perl
script logs continuously, but is mainly for logging TT? responses. The C++
application is used interactively. Either could be modified to do what you
want.

Take a look at:

https://github.com/openttp/openttp/blob/develop/software/gpscv/common/bin/prs10log.pl

and

https://github.com/openttp/openttp/tree/develop/software/gpscv/common/prs10c

The Perl script depends on a library:

https://github.com/openttp/openttp/blob/develop/software/system/src/TFLibrary.pm

Cheers
Michael


On Wed, Apr 6, 2016 at 7:13 PM, Mike Cook  wrote:

> Before I start re-inventing wheels, has anyone got a non-graphical
> interface to the PRS10.
> Specifically, I want to log over time any/all the data points seen on the
> RbMon output, though it would be nice to have a curses version of the
> window.
>
> I have got a sniffer on the link and interaction looks simple enough.
>
> RbMon just executes a cmd? followed by 0x0d (CR)  for each of the values
> in turn and formats the returned data.  Not all data values are requested
> each cycle as some are unchanging. The PRS10 does not appear to send
> unrequested data.
>
> Any input appreciated.
> regards
>
> "If you don't know what it is, don't poke it."
> Roger Bacon
> ___
> 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] Reliability of atomic clocks

[Michael Wouters]

Dear Paul,

You are probably thinking of one of these:

Chadsey et al “Maintenance of HP5071A frequency standards at
USNO” in Proc. 29th PTTI, p49-60 (1997)

Chadsey “An automated alarm program for HP5071A frequency
standards” in Proc. 31st PTTI, p649-655 (1999)

Brock et al “End-of-life indicators for NIMA’s high-peformance
cesium frequency standards” in Proc. 34th PTTI, p117-125 (2002)

Cheers
Michael

On Mon, Mar 28, 2016 at 1:50 AM, paul swed  wrote:

> I do not have it but I stumbled into it on the internet. There was one
> paper it was military, naval observatory or NIST and it did indeed show
> failure rates of cesiums of the reference that were owned and it must have
> been 30-50 of them.
> I remember it showed failures of units over years.
> Since it did not at all addres my need I did not keep it.
> Regards
> Paul
> WB8TSL
>
> On Sun, Mar 27, 2016 at 7:53 AM, Attila Kinali  wrote:
>
> > Moin,
> >
> > Maybe someone here can help me.
> > I am looking for data on the reliability of atomic clocks.
> > I.e. how often and, if possible, how they fail.
> >
> > Unfortunately, if I google for reliability then all that pops up
> > are descriptions of the accuracy and stability of atomic clocks.
> > If I go for MTBF I only get two papers from the 70s that tackle
> > the problem in general, without giving any data.
> >
> > Does someone know where I could find current data about MTBF and
> > failure modes of atomic clocks? Given the number of 5071's installed
> > in labs, there must be at least some data on them
> >
> >
> > 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.
>
___
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] Standard Room Calibration Procedure

[Michael Wouters]

Dear Luciano

I run a T calibration laboratory.

It sounds like what you're after is a Test Method (TM), which we use as
part of our quality system. Any accredited calibration laboratory will have
documents like this. They vary greatly in their detail according to the
needs of each laboratory, and may refer to specific instruments and
detailed use of in-house software. You would probably have to synthesize
something that fitted your needs from a number of TMs. Our TMs are
proprietary documents so I can't just give you a copy, sorry.

The TM's do not specify a recalibration interval. This is up to the
customer, since this is a decision that they need to make on the basis of
the accuracy they require. The national accreditation body may have
recommendations about recalibration interval. Nearly everything we
calibrate is done once per year.

In our own lab we have caesium beam standards. Since these participate in
UTC they are continuously calibrated but we have other procedures to assure
correct operation such as continuously intercomparing the clocks and
automated logging, analysis and reporting of clock operating parameters.

Best regards
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.