[time-nuts] Re: NTP server source needed

[Forrest Christian (List Account)]

Time machines makes a similar box.

However, one would expect that with that many devices at a site one could
find a couple of devices which could run a ntp server along with their
normal workload.

On Thu, Apr 21, 2022, 2:23 AM Paul Watts  wrote:

> Long time lurker, first time poster.
>
> In the past, I've purchased the LeoNTP server to act as a local time server
> on my work network. Unfortunately, those NTP servers aren't available to
> order.
>
> I'm in need of two - three more NTP servers for various locations.
>
> Do any of you have an alternate NTP server recommendation?
>
> 1. I'd like to keep the price less than $1,000. The Leo's were a great,
> self contained choice at less than $400.
> 2. Support for IPv4 is required and IPv6 is desired. The main shortcoming I
> have with the Leo's is no support for IPv6.
> 3. I'll serve about 150 clients per site from a given NTP server. My NTP
> clients are a combination of Windows and Linux computers along with various
> types of network gear (Cisco, Palo Alto, Aruba, Juniper). The Leo's don't
> even breathe hard at that level.
> 4. No PTP support is required. My timing needs are IT related - log
> consistency, security protocol requirements, etc.
> 4. I'm not interested in building and using something like a Raspberry Pi.
> I'll be sending these to remote sites and don't want to worry about issues
> like memory card failures and the hobbyist feel of many Pi cases and
> cooling options. That's fine for my home but not for work.
> 5. Availability is important.
>
> Any suggestions are welcome.
>
> Thanks,
>
> Paul Watts.
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send
> an email to time-nuts-le...@lists.febo.com
> To unsubscribe, go to and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an 
email to time-nuts-le...@lists.febo.com
To unsubscribe, go to and follow the instructions there.

[time-nuts] Re: Odd Request: WTB Lathe.

[Forrest Christian (List Account)]

I know your request was a bit off topic,  but it has me intrigued.

Is the need for a higher end lathe related to improving accuracy on your
"pendulum project"?

I've always been intrigued by the timekeeping accuracy of a pendulum.   It
seems like there are so many things that could affect its accuracy that it
should never work.   Yet it does, at a far better accuracy than I would
expect.

So I'm curious what you're working on.

On Wed, Jan 12, 2022, 11:45 AM Dan Kemppainen  wrote:

> Hi All,
>
> This is maybe an odd request for this list, so I'll keep it short.
>
> A pendulum project has me pushing the limits of my current lathe. So I'm
> staring to shop around for a higher end tool room type precision lathe.
> Hardinge HLV-H, Monarch 10EE, etc.
>
> If by chance anyone has a lathe that would be for sale, please let me
> know. In the MI, WI, MN area.
>
> Also, please reply directly off list. This is way off topic for this
> list as is.
>
> Thanks!
> Dan
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send
> an email to time-nuts-le...@lists.febo.com
> To unsubscribe, go to and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an 
email to time-nuts-le...@lists.febo.com
To unsubscribe, go to and follow the instructions there.

[time-nuts] Re: 20210423: Introduction and Request for Spirent GSS4200 User Manual / Help

[Forrest Christian (List Account)]

I have used GPS-SDR-SIM with good results.

It's an open source tool that will generate the right files to be able to
generate simulated GPS signals using many of the open source SDR platforms
including HackRF.  It uses the publically available ephermis files along
whith desired receiver position data to generate the "RF" output files.

My experience has been that clocking the sdr with a output from a
disciplined source results in the 1pps from a typical GPS receiver
remaining at the same relative phase during the entire playback, for a
definition of same which was good enough for my purposes.

Two notes:

This is gps only,  no other constellations.  Would love someone to write a
similar tool for other constellations.

Several platforms are supported, some are dirt cheap.  I used HackRF
because I already had one.   Not sure about any of the others.

On Sat, Apr 24, 2021, 11:56 AM Lux, Jim  wrote:

> On 4/24/21 10:31 AM, Andrew Kalman wrote:
> > Hi Paul.
> >
> > Yes, I've been on this same journey. After I learned (somewhat unrelated)
> > that one is supposed to have an FCC license to rebroadcast GNSS signals
> > (e.g. via a repeater inside a lab, makes eminent sense), I started
> thinking
> > more about GNSS simulators and how they might be added to my company's
> > workflow. So I bid on a couple of units, got them for pennies on the
> > dollar, and started messing with them in the hope of ending up with an
> > ATE/rack-type setup that I can build into a nearly automatic test &
> > validation suite.
> >
> > Let's say I was much more successful with the Spectracom/Orolia GSG-5
> than
> > with the Spirent GSS4200 ... In the case of the GSG-5, it's really just a
> > question of how many options you can afford -- the rest is all there, you
> > don't need a support contract, it's all easily accessible in the unit
> > itself, and as long as the Internet exists the GSG-5 will probably keep
> > working (it gets time, ephemeris and almanac data from servers -- it can
> > simulate stuff NOW (wth the right options), not just in the past and
> > future). The GSS4200 is about 10-15 years older, and it shows (in terms
> of
> > ease-of-use), along with how Spirent chose to monetize their users /
> > subscribers. Also, the GSG-5 adds things like interference to the signals
> > (all for a price, of course). IOW, the newer units (at least, from
> > Spectracom was XL Microwave is now Orolia) are a whole lot easier to use
> > ... but they come at a price. It's an interesting business.
> >
> > I will say that the build quality of the Spirent is very good. I have not
> > opened up the GSG-5, just did a calibration and it was very close.
> >
> > I'm a little bit surprised that there is not an open-source, SDR-based
> GNSS
> > simulator (at least, one I could find).
>
>
>
> Not much demand, I suspect.  I seem to recall a GNSS generator that was
> open source about 5-10 years ago, but I can't find it now.
>
> The record/playback boxes are actually pretty simple - just a single bit
> in many cases. After all, a lot of the receivers use a single bit input,
> because the signal of interest is below the thermal noise floor.
>
> The real challenge isn't the SDR part (a USRP would work just fine as
> long as you get a daughter card that supports L-band) - it's the
> "scenario building" which requires simulating the orbits of the GNSS
> satellites, simulating the track of the receiver, calculating the time
> delays (including iono and tropo effects), and generating the PN codes
> appropriately.
>
> Each of those isn't too tough, but putting it all together is quite
> challenging, and, apparently, it's not "dissertation topic" suitable
> (which is where a lot of niche SDR stuff comes from).
>
> A *real* challenge is that to do it right, you need very good orbit
> propagators - if you're looking to simulate nanosecond scale
> phenomenology, you need to be able to generate orbit behavior on a few
> cm or better sort of uncertainty.  For some applications (differential
> GPS, RTK surveying) you could probably get away with something that's
> not perfect, but doesn't have problems for YOUR specific application.
> But it wouldn't be a generalized box.
>
> One strategy we've used at JPL is to have the fancy expensive box
> generate the signals for a scenario, and record them with a much cheaper
> record/playback box, then use the playback for testing.
>
> Right now, my project (SunRISE mission) is working on how to generate
> realistic test signals for a space interferometer - Where we need to
> generate signals that can be received, and the output of the receiver
> fed into GIPSY-X for post processed precision orbit determination.
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send
> an email to time-nuts-le...@lists.febo.com
> To unsubscribe, go to and follow the instructions there.
___
time-nuts mailing list -- 

Re: [time-nuts] Brand new OCXO/TCXO reccomenations

[Forrest Christian (List Account)]

Some of these sites already have a internet-connected temperature sensor on
a PCB inside a unvented plastic (electronics) enclosure inside the outdoor
weatherpoof metal enclosure.  With just a quick look, I found one which
slewed from 21C to 65C over 2 hours within the last couple weeks.   I don't
have enough data from that day to tell how much of that 44C was during a
short period - I only have the two samples 2 hours apart.

It's amazing how quickly though a bit of sun on a grey metal box will heat
the box insides up.  Cooling is a lot slower though.

I will say though that the idea of adding some thermal mass/insulation
around the oscillator to reduce the temperature change during holdover is
something I'm going to investigate.

On Fri, Sep 25, 2020 at 3:50 AM Hal Murray  wrote:

>
> > 1) In an unconditioned/semi-conditioned space.   The ambient temperature
> can
> > slew 20*C easily over the holdover period.   (Think sun hitting an
> outdoor
> > enclosure first thing in the morning - the ambient temperature tends to
> rise
> > quickly).
>
> It would be interesting to get some data on that.  Clouds blocking the sun
> or
> holes in the cloud cover would be a variation.
>
> If the sun hits the enclosure, how long does it take the air inside to
> heat up
> and then how long does it take the gear inside to warm up?
>
> One of the classic tools for problems like this is to attach a big blob of
> stuff to the crystal to dampen thermal changes.  When you design your test
> setup, can you leave room for a brick and collect data with and without
> when
> you toss it into the freezer?
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>


-- 
- Forrest
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Brand new OCXO/TCXO reccomenations

[Forrest Christian (List Account)]

I accidentally only replied to an off-list reply with the following
information.   It was also meant to go to the entire list:

  Let me clarify here a bit:

The application is:

1) In an unconditioned/semi-conditioned space.   The ambient
temperature can slew 20*C easily over the holdover period.   (Think sun
hitting an outdoor enclosure first thing in the morning - the ambient
temperature tends to rise quickly).   The overall temperature range is -40
to +60C, although those edges are rarely hit, and usually only when
fans/heaters fail (more typical is 0-50C).

2) I need to stay within a 'few' microseconds of UTC alignment.   No it
isn't specced better than that.  4-5 uS is probably a good target.
However, 10uS is probably ok and 30uS has been shown to not cause a lot of
problems.  Beyond that things get bad fairly quickly.   Nominal 1PPS UTC is
coming from a GPS receiver.   The application is ok with a uS or so of
cycle-to-cycle jitter.

3) 10 minutes would be a good target.   Longer is better, like in any
holdover.

My basic math has been:   5 uS over 10 Minutes is ~8ppb.(5uS/600).
If I can tolerate worst-case of 30uS, then I can get away with 50ppb.

The implementation idea today is to clock a FPGA with an appropriately
stable clock, then do either a 1Hz PLL or some other similar arrangement in
the FPGA designed to track the GPS 1PPS when it's operational, or switch to
holdover when it's not.   I don't particularly see a good reason to
discipline the oscillator when I can effectively measure it's frequency in
the FPGA - If I know the measured frequency of the oscillator is
10.033425 Mhz, I can output the 1PPS every 1003.3425 cycles, with
each 1PPS aligned to the next clock edge.   The jitter introduced by this
method isn't going to be a problem in this application.   Or put
differently:  I'm not steering the oscillator, I'm steering the divider in
the FPGA.

So my spec when I get right down to it is that I could tolerate a clock
source which is fine with a worst-case drift of 50ppb over 20*C, but I
would be more comfortable with something close to 10ppb.

I note that Abracom and probably others make TCXO's which are rated at
50ppb over their entire temperature range, and the charts show that  I
probably can expect better than that over almost any given fairly narrow
temperature range - and the lower power and ease of use are very much
plusses.   But, they cost more than an low-end OCXO.

The main disadvantage of the OCXO's is the higher power needs.   And my
tendency to say 'well, I've already got a OCXO in the circuit, maybe we
should go up to the expensive parts...

I apologize for the softness of the specs here and (even worse) in my
original message.  Right now I'm sort of just playing with the 'is this
doable for a reasonable cost, and what are the cost/benefit tradeoffs'
game.   And trying to get something I can play with and throw into the
"environmental chamber" (aka converted old freezer) for testing.


On Wed, Sep 23, 2020 at 6:20 PM Forrest Christian (List Account) <
li...@packetflux.com> wrote:

> I'm hoping some of the list are familiar with the newer
> currently-available oscillators available from the distributors.
>
> Some background:
>
> I'm starting to play with a short-term 1PPS holdover application, mainly
> to cover up brief GPS signal loss events (a few minutes at most).
>
> Since I may at some point want to make numerous copies of this, I'd rather
> start with a new oscillator as opposed to digging through the junkbox or
> buying surplus.   Lower cost (<$100 ideal, lower is even better) and power
> consumption is good.   My short-term stability requirements indicate to me
> that I'm probably looking for an OCXO instead of a TCXO, although it looks
> like some of the best TCXO's out there are in the range which will work in
> most cases (50ppb over temperature (or better)).
>
> I suspect I'm going to handle the holdover in a FPGA.  As such, I don't
> think I'm going to bother trying to voltage control the oscillator.  Seems
> like it will make the overall circuit simpler and I don't have to worry
> about a whole bunch of control circuit temperature compensation.
>
> I've dug through enough datasheets at this point, my eyes are glazing
> over.   I also know that the spec sheets are only part of the story when it
> comes to oscillators.  I also have found over the years that often the part
> I'm looking for (that 20ppb Temperature-stable TCXO for a reasonable price)
> exists if you know the vendor to look at...
>
> So any specific recommendations or pointers toward a brand/type would be
> appreciated.
>
> --
> - Forrest
>


-- 
- Forrest
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

[time-nuts] Brand new OCXO/TCXO reccomenations

[Forrest Christian (List Account)]

I'm hoping some of the list are familiar with the newer currently-available
oscillators available from the distributors.

Some background:

I'm starting to play with a short-term 1PPS holdover application, mainly to
cover up brief GPS signal loss events (a few minutes at most).

Since I may at some point want to make numerous copies of this, I'd rather
start with a new oscillator as opposed to digging through the junkbox or
buying surplus.   Lower cost (<$100 ideal, lower is even better) and power
consumption is good.   My short-term stability requirements indicate to me
that I'm probably looking for an OCXO instead of a TCXO, although it looks
like some of the best TCXO's out there are in the range which will work in
most cases (50ppb over temperature (or better)).

I suspect I'm going to handle the holdover in a FPGA.  As such, I don't
think I'm going to bother trying to voltage control the oscillator.  Seems
like it will make the overall circuit simpler and I don't have to worry
about a whole bunch of control circuit temperature compensation.

I've dug through enough datasheets at this point, my eyes are glazing
over.   I also know that the spec sheets are only part of the story when it
comes to oscillators.  I also have found over the years that often the part
I'm looking for (that 20ppb Temperature-stable TCXO for a reasonable price)
exists if you know the vendor to look at...

So any specific recommendations or pointers toward a brand/type would be
appreciated.

-- 
- Forrest
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] eLORAN will be on the air GRI 99600

[Forrest Christian (List Account)]

I probably need to clarify where I'm coming from in relation to my previous
message.

I have a fair bit of background in dealing with using GPS clock sources for
synchronization at communication sites.   Many of these sites are lucky to
have a rubidium oscillator in place for holdover, although some do (usually
the larger ones).  And we're talking about thousands and thousands and
thousands of these sites.

Where I was coming from is that at these sites, GPS can be a challenge -
it's in a narrow band, very low signal, and, at least from my worldview, it
seems like GPS interference is becoming more prevalent instead of less.
 As a result, whether terrestrial or via satellite, it would be nice to
have a second alternative in a different band where one could obtain a
reasonably aligned 1PPS (+-1uSish).

I'm hopeful that eLORAN will result in this result.   I'm also curious
about the GPS L5 signal once it becomes operational since that is far
enough away frequency wise that one would hope that it wouldn't be affected
by the same interference source.

On Thu, Aug 6, 2020 at 6:19 PM jimlux  wrote:

> On 8/6/20 4:28 PM, Forrest Christian (List Account) wrote:
> > If you look at generally-available GNSS PNT solutions, you'll find a few
> > failure modes:
> >
> > 1) Loss of a satellite (or two).   This is why the constellations have
> more
> > satellites than is strictly necessary, so not a big deal.
> >
> > 2) Loss of control/failure in the control system/constellation wide
> > software failure, aka the recent Galileo failure.   This is why you have
> > multiple GNSS constellations.
> >
> > 3) Ground based interference (jamming, spoofing), etc.This is why you
> > need a terrestrial backup, which doesn't really exist.
> >
> > For timing, I wouldn't be opposed to someone flying (or adding a payload
> > to) a couple of geostationary satellites which live in a separate band
> from
> > GNSS.  It would be interesting to be able to put up a small satellite
> dish
> > and get a highly reliable and hard to interfere with timing alternative
> to
> > GNSS.I know there are two way time transfer options out there, I'm
> more
> > thinking basically a fixed-location cesium clock in the sky.
> >
>
> Well, the GPS folks found that a Rb works better than a Cs, and both
> need ground monitoring and updating.
>
> One could rent a Single Channel Per Carrier transponder slot on a GEO
> satellite, feed a carrier derived from your ensemble of clocks to the
> uplink, and there you go.
>
> My google-fu is failing and I can't find even a rough cost for such a
> service.  Maybe something like $50k/month? $600k/year.
>
> That 600k would probably buy you *one* space qualified Rb oscillator of
> "good enough" performance, maybe.   USOs like used on GRAIL were
> $1M/each sort of items in qty 4. And then you need some TWTAs to amplify
> the signals for transmission - those are also pretty pricey.
>
> And then the launch cost.. I happen to know (because I just bought it at
> work) that you can push about 100-120kg to a GEO+1000km orbit for right
> around $10M.  Rocketlabs might do 20-30kg to a similar orbit for half that.
>
>
> All in all, I suspect that there are better uses of the $50M it would
> cost - You could buy a LOT of Cesium clocks for terrestrial use.
>
> If you're willing to do CSAC level performance, and you're willing to
> have it be in LEO, so you see it a couple times a day for 20 minutes,
> and you're willing to do some design and fab in your garage - under $5M.
>
> Look up CHOMPTT  - CSAC and optical links.
>
>
> https://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=4407=smallsat
>
>
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>


-- 
- Forrest
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] eLORAN will be on the air GRI 99600

[Forrest Christian (List Account)]

If you look at generally-available GNSS PNT solutions, you'll find a few
failure modes:

1) Loss of a satellite (or two).   This is why the constellations have more
satellites than is strictly necessary, so not a big deal.

2) Loss of control/failure in the control system/constellation wide
software failure, aka the recent Galileo failure.   This is why you have
multiple GNSS constellations.

3) Ground based interference (jamming, spoofing), etc.This is why you
need a terrestrial backup, which doesn't really exist.

For timing, I wouldn't be opposed to someone flying (or adding a payload
to) a couple of geostationary satellites which live in a separate band from
GNSS.  It would be interesting to be able to put up a small satellite dish
and get a highly reliable and hard to interfere with timing alternative to
GNSS.I know there are two way time transfer options out there, I'm more
thinking basically a fixed-location cesium clock in the sky.

But, a good quality terrestrial option would be useful too.

On Thu, Aug 6, 2020 at 3:40 PM Bob kb8tq  wrote:

> Hi
>
> > On Aug 6, 2020, at 4:40 PM, jimlux  wrote:
> >
> > On 8/6/20 9:17 AM, Taka Kamiya via time-nuts wrote:
> >> Someone in this thread mentioned "at least 2 satellite time and
> frequency solutions" exists already.  I only know of GPS (GNSS)
> constellations.  What's the other?
> >
> > Transit?
> >
> > I don't believe they are still operational, though.
> >
> >
> > I wonder if one might be able to pick up time/frequency from a
> commercial TV broadcast transponder.  The transponders on the satellite are
> typically bent pipes (for C-band anyway), I would assume that the uplinks
> may or may not have stability comparable to terrestrial broadcast.
> >
> > One problem is, of course, that the satellites aren't in a stable
> location (at least on a "meters" scale) - but one could certainly do
> "common view" kinds of time transfer.
>
> Another couple of “up in the air” question:
>
> Some of the systems transmit “stand alone” signals in each of two or three
> different bands. Does each
> band count as a separate time source?
>
> If you know your location already, each sat in these systems can be a time
> source all by it’s self. Do they
> each count?
>
> I guess is depends a lot on just how you look at redundancy ….
>
> Bob
>
>
> >
> >
> >
> >
> >> ---
> >> (Mr.) Taka Kamiya
> >> KB4EMF / ex JF2DKG
> >>   On Thursday, August 6, 2020, 12:01:27 PM EDT, paul swed <
> paulsw...@gmail.com> wrote:
> >>Magnus
> >> Its honestly by luck that I know anything. From the bits I have read
> Europe
> >> seems far closer to eLORAN then we are. Perhaps 6 months ago the US
> >> performed a series of tests 2 eLoran solutions and something like 6 or
> more
> >> satellite solutions. I know the old Iridium satellites were in the tests
> >> and some other LEO satellites.
> >> But thats about it.
> >> What we need is a cheap SDR LORAN C sniffer. Low power runs 24 X 7 and
> >> turns a LED on if the stations active.
> >> Oh well another project in the someday pile.
> >> Regards
> >> Paul
> >> WB8TSL
> >> On Thu, Aug 6, 2020 at 2:42 AM Magnus Danielson 
> wrote:
> >>> Hi Paul,
> >>>
> >>> I only ask as you seem to track this thing the best here on time-nuts,
> >>> as far as I have seen, such that it is your emails that keeps me best
> up
> >>> to date with the progress.
> >>>
> >>> Cheers,
> >>> Magnus
> >>>
> >>> On 2020-08-05 19:21, paul swed wrote:
>  Hi Magnus been a while since have emailed.
>  Its one site that was a test transmitter. Its in New Jersey, USA.
>  The goal of the testing I believe is to establish the viability of an
>  alternate PNT reference to GPS. Additionally the ability to
> communicate
>  some level of message broadcast. This should be identical to
> proposals I
>  have heard of in Europe.
>  But I have no direct relationship to any of this. Like you, a very
>  interested observer and hope that eLORAN wins the battle.
>  Unfortunately there are many alternate proposals such as using other
>  satellites. Hmmm if I wanted to advance my career in the Air Force or
> >>> Space
>  Force (Yes thats actually real now).
>  Would I select the lowly reliable as heck eLORAN at sub $100 M/year to
>  operate. Or the glorious space based proposals in $B region. Never
> mind
>  that at least 3 countries now have demonstrated killer satellites.
>  Sorry for that editorial.
>  Regards
>  Paul
>  WB8TSL
> 
>  On Wed, Aug 5, 2020 at 11:04 AM Magnus Danielson 
> >>> wrote:
> 
> > Hi,
> >
> > Do you know that they would do test with two actual transmitter
> sites?
> >
> > Cheers,
> > Magnus
> >
> > On 2020-08-05 16:00, paul swed wrote:
> >> Hello to fellow time nuts.
> >> Warm up those old Austrons. eLORAN out of New Jersey has been on the
> >>> air
> >> intermittently prior to a test run next week. Due 

Re: [time-nuts] eLORAN will be on the air GRI 99600

[Forrest Christian (List Account)]

We seem to be going through another stage in our technological evolution
right now as far as redundancy goes.

To explain what I mean:

A long time ago things were so unreliable that everyone knew that you
needed two systems, even if one was the watch in your pocket and a compass
and sextant for PNT.

As technological systems got better and better somehow we forgot this
lesson.   GPS is so reliable that people don't even think about the
possibility that it might go away, so we got complacent about maintaining
the old systems to maintain a backup.  Things like LORAN C were cut for
'cost savings' reasons, since why keep a backup for a system that never
fails?  I can't fault the logic, assuming one buys the perfect
reliability premise (no I don't buy this as at all).

Recently it's become obvious there are lots of ways that our technology can
fail.   Not just GPS but I could cite other examples not relevant to this
list.   So we've now entered the phase where we're trying to figure out
what to do to regain the capabilities we carelessly discarded in the past
based on a false premise of the new stuff being perfectly reliable.

Fortunately for PNT, the US government definitely signaled that the
redundancy must be ground-based when they passed the "National Timing
Resilience and Security Act".  So hopefully we don't have to worry about
the second system being space-based.  Heck, we already have at least 2
space-based alternatives in orbit.

They were supposed to get this in place within 2 years, which I think means
the end of 2020 if I'm reading the dates right.   Since it's already
August, I doubt they'll meet the deadline.  Hopefully, with the testing
they're doing, it won't be much longer.

On Wed, Aug 5, 2020 at 4:15 PM paul swed  wrote:

> Jim
> Thanks for the insights. Oh I am not selling it for emp. I am simply saying
> no would be general wants a rusty old steel tower as a career booster. I
> remember when LORAN C was shut down the president said he was saving $36M a
> year. Thats drop in the old bucket. I also remember the LORAN C antennas on
> mobile tower sites for timing along with GPS.
> Thanks again Jim.
> Fire up that LORAN C receiver and see what you can hear.
> Regards
> Paul
>
> On Wed, Aug 5, 2020 at 5:41 PM jimlux  wrote:
>
> > On 8/5/20 12:40 PM, Tom Knox wrote:
> > > Hi Paul and Magnus;
> > > Not to mention one space EMP would kill all the Sat systems, where a
> > ground base system even if affected would be easy to access for repair.
> >
> > The vulnerability of GNSS systems to EMP attacks is not all that high -
> > GPS is, after all, a DoD essential system, and lives in a ridiculously
> > high radiation environment in MEO - They're also hard to neutrons (based
> > on published specs for components in the GNSS satellites).
> >
> > In most scenarios, LEO satellites get hammered, MEO and GEO not so much.
> >
> > https://apps.dtic.mil/dtic/tr/fulltext/u2/a531197.pdf
> >
> > "GPS and GEO satellites are threatened only by the very high yield (~ 10
> > Mt) detonations of our trial set."
> >
> > I'll note that the largest the US has detonated in space are the Teak
> > and Orange shots 3.8Mt (at <100km), and only Starfish Prime (1.4Mt) at
> > 400km cased significant problems.
> >
> > The usual "use case" for EMP is to affect aircraft and ground based
> > assets, and the burst height is low (so the air around the burst is
> > denser - more particle interactions = more current = more field) -
> > conversely, this reduces the flux at 20,000 km (where GPS is) and
> > 36,000km (GEO)
> >
> > Ultimately, it's that your victim is a Long, long ways away from
> > whatever the phenomenon is.
> >
> > I've been doing a lot of analysis on EMI/RFI effects on precision timing
> > in GEO+1000km - we are looking at bursts from the sun, and timing it
> > with GNSS satellites.  Things that I agonized over (high power shortwave
> > broadcasters radiating 500kW into a 24dBi curtain array) in my LEO
> > satellite at 500km just become a non-issue at 37,000 km.  Inverse square
> > law really helps.
> >
> >
> > Anyway, that DTIC report will give you plenty to geek out over.
> >
> >
> > Yes, there would be significant disruption in timing accuracy due to the
> > ionized particles - I'm not sure if dual frequency would be enough to
> > compensate.
> >
> >
> > I think alternate timing and nav systems are good idea, but selling it
> > as "GPS will be knocked out by EMP" isn't going to get you very far.
> >
> >
> > > Cheers;
> > >
> > > Tom Knox
> > >
> > > act...@hotmail.com
> > >
> > > "Peace is not the absence of violence, but the presence of Justice"
> Both
> > MLK and Albert Einstein
> > >
> > > 
> > > From: time-nuts  on behalf of paul
> > swed 
> > > Sent: Wednesday, August 5, 2020 11:21 AM
> > > To: Discussion of precise time and frequency measurement <
> > time-nuts@lists.febo.com>
> > > Subject: Re: [time-nuts] eLORAN will be on the air GRI 99600
> > >
> > > Hi Magnus been a while 

Re: [time-nuts] GPS antenna splitter recommendation?

[Forrest Christian (List Account)]

I'll second this thought.

I've got one of the symmetricom-branded distribution amplifiers in use here
and it's worked like a charm.   Unfortunately it only works with GPS L1.
 GALILEO seems to be at least mostly in it's passband, GLONASS is not.

As the bands I've needed have started to increase, I'm now trying to figure
out how I'm going to bring in a wider swath of bands.   I've been going to
ask a similar question to the original poster, but with the idea of what
options are out there for a wider bandwidth.   As a result I'm reading this
thread with interest since it seems that a lot of the answers would be
suitable for what I'm hoping to do as well.


On Thu, Apr 30, 2020 at 2:51 PM Bob kb8tq  wrote:

> Hi
>
> The original splitters mentioned most certainly do *NOT* short the DC to
> ground.
> I have used those splitters for decades to power GPS gear. We have used
> them
> in production for runs of thousands of parts ….
>
> Before anybody goes off and spends $1,000 on a splitter, think very hard
> about
> what bands you will need it for over the next few years …. also what
> levels and
> what antenna voltages. This stuff does change and that’s a lot of money to
> sink
> in something that may be a boat anchor in a couple years.
>
> Bob
>
> > On Apr 30, 2020, at 4:36 PM, Arthur Dent 
> wrote:
> >
> > Most of the regular splitters first mentioned are basically transformers
> > with one side if each winding connected to the case ground so they don’t
> > work because they short out the 5 VDC on the receiver’s antenna coax. You
> > have to be aware of the D.C. voltage to power the antenna plus have fake
> > antenna load resistors on the other ports to prevent error messages.
> >
> > The cheapest non-powered splitter is probably the F connector Steren
> 4-way
> > 2.4Ghz splitter made for TV use at $6-$9 each (like eBay # 254474121010).
> > Their model 201-234 passes 1 port and couples the other  3 ports with
> > capacitors. I found I could just pry the back cover off the splitter and
> > solder a 200-330 ohm resistor across each isolated outputs to prevent the
> > receivers on those ports from giving an open antenna alarm. Those
> receivers
> > would still work without the resistors but I couldn’t stand the error
> > message so I installed the load resistors.
> >
> > Mini-Circuits has made dedicated GPS splitters that have built-in amps to
> > compensate for losses and the ones I have work quite well. The 5 port one
> > has a Lucent part number and was made for Telco use with 2 power ports
> and
> > 3 isolated ports to which I added 280 ohm resistors. You will find these
> on
> > eBay occasionally for far less than the HP versions.  One of my GPS
> > antennas goes to a WR Incorporated 8-way externally powered splitter with
> > load resistors built in.
> >
> > So there are a number of options for GPS splitters but they may not be
> that
> > common. However, just today I bought another of the 5 port Mini-Circuits
> > ones on eBay so they do turn up.
> >
> >
> https://oi906.photobucket.com/albums/ac262/rjb1998/GPS%20splitters%202_zpspobtp7cf.jpg
> >
> >
> https://oi906.photobucket.com/albums/ac262/rjb1998/GPS%20splitters_zpsbitr26xx.jpg
> > ___
> > time-nuts mailing list -- time-nuts@lists.febo.com
> > To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> > and follow the instructions there.
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>


-- 
- Forrest
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Soldering small stuff...

[Forrest Christian (List Account)]

So a couple of notes from here:

I solder 0.5mm pitch TQFP's on a fairly regular basis with just a
reasonably-sized chisel tip and plenty of flux.   I often will end up with
just a bit at the end of surplus which wick will pull off.I actually
have done this on the bench with a $100 hakko FX601 and a questionable
tip.  So nothing to worry about.

As my eyes have aged, I don't see small things or far away things all that
well.   I have discovered a slightly overpowered set of reading glasses are
perfectly adequate to look at a fine pitched TQFP to determine if there are
bridges.   I do have a couple stereo microscopes available to me, but I
typically prefer the glasses unless I need to look very closely at the work.

On Sun, Apr 26, 2020 at 12:28 AM Charles Steinmetz 
wrote:

> Burt wrote:
>
> > I have an AM-SCOPE 7-35 magnification stereo microscope. I also have an
> > OptiVisor with a 5x stereo lens that my son gave me about 10 years ago.
> > As nice as the microscope is, I generally wind up using the OptiVisor.
>
> Optics:
> OptiVisors are *great*.  But there are lots of poor-quality imitations
> out there.  Accept no substitutes!  Buy Genuine Donegan OptiVisors
> *only*, with "DA-" series glass lens plates (blue lens frames) -- *not*
> the "LX" series with acrylic lenses in clear lens frames.
>
> The one drawback of OptiVisors is that if you want higher power you have
> to settle for reduced working distance.  At some point, I don't really
> want my face that close to the hot iron and solder vapors.  For
> soldering, I find the DA-5 lens plate (2.5x at 8" working distance) is
> my practical limit.  A good stereo microscope (with reduced-power barlow
> lens) solves this problem.
>
> BTW: Even 7x is *way* too much power for comfortable use as a soldering
> magnifier, IMO. You might want to try a 0.2x to 0.3x Barlow lens, such
> as the AmScope model SM03, which could make the experience much nicer.
> And possibly some lower-power eyepieces.
>
> So:  How about a wearable version of the stereo microscope (best of both
> worlds)?
>
> Those are called "surgical loupes."  And they are a pure joy to use.
> Once you try a pair of properly fitted and collimated surgical loupes,
> you will never go back to anything else for soldering small parts.
>
> However: surgical loupes are moderately to very expensive, and it's hard
> to economize by buying used because they really need to be fitted and
> adjusted by an optician who knows what (s)he is doing or you may have
> eyestrain using them.  If you are optically knowledgeable and can figure
> out the misalignments for yourself (say, if you have sucessfully
> collimated a few pairs of binoculars), it is possible to self-fit them.
>   *Note* that the collimation problem arises with stereo microscopes as
> well -- many of the old venerable models you find used (B, AO) are
> badly out of alignment.
>
> Soldering:
> Finally, there is no need to flood IC pins with so much solder that you
> need solder braid to remove it.  The secrets are (1) use the right iron
> tip (a flat or slightly concave bevel tip is one of the best, but a
> spade will work); (2) keep the tip surgically clean; (3) keep the tip at
> the right temperature; and (4) use quality solder with plenty of flux.
> To see it done right (in less than 3-1/2 minutes), watch:
>
> 
>
>
> Best regards,
>
> Charles
>
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>


-- 
- Forrest
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

[time-nuts] Buying and using used Cesium Beam Standards

[Forrest Christian (List Account)]

I noted Skip Winthrow's message about the listing of a Cesium standard on
eBay.

I've had some questions generally about these used standards for some time
now, figured this was a good time to ask them.

So let's assume I buy a used unit in working condition.   I get it here, it
works fine, and everything is up to spec.   Let's also assume that I really
only need it operational a week or two a couple of times a year during
periods I'm doing measurements that require the stability of the Cesium
standard.

What is the best way to improve the odds that this used gear is
working properly when I need it?   I'm asking primarily because I know that
the cesium tube itself wears out, and replacing the tube does not often
make financial sense.   I guess I'm asking is if the 'wearout clock' on the
tube stops if the unit is powered off and is on the shelf, or if there's
something else one does to extend the life of these units.

All of the other questions I have are probably more in the category of "I'm
not sure what questions to ask".   I've owned/used/fixed a fair bit of used
test equipment over the years, but this seems to be in an entirely
different category.  I've never had any experience with these at all, so if
anyone would like to pontificate with any wisdom or experience in the
basics of acquiring and using a Cesium standard I'd appreciate it.

-- 
- Forrest
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] u-Blox ZED-F9T block diagram or timing knowledge available here?

[Forrest Christian (List Account)]

For a few grand you can get an off the shelf fs740 or something similar,
probably with a rubidium timebase.  But I get the impression this is more
of a learning experience.

One thing which it took me a while to wrap my head around is that for
frequency, sawtooth error generally dissappears for a lot of definitions of
reasonable accuracy.  You're averaging for such a long period that what
seems like horrible accuracy is very usable.

Hopefully some of the more experienced time nuts will correct the following
if my math is faulty.

For instance say your gps 1PPS source is accurate to +-1uS.  Over 1 second
this is 1e-6.  But over 1000 seconds this is 1e-9.  Over 10 seconds
you're at 1e-11.   For a 10MHz clock adjusted using this long of averaging,
this error is only +-.0001Hz

Of course this is somewhat simplified and the devil is in the
implementation details.

 As I'm sure others will point out, if you're using certain receivers, then
sawtooth correction data is available to you which will enable further
correction, which makes the internal clock frequency which the 1PPS edges
are aligned to less of interest as the receiver outputs both the 1PPS and
data indicating how far the receiver believes the 1PPS edge is out of
alignment with ideal.

On Mon, Jan 6, 2020, 6:07 PM Tim S  wrote:

> Hi, first time poster, just getting into the time rabbit-hole.
>
> I'm looking at building my own 10MHz double-oven + Rubidium standard
> for home-lab use, and I wanted to investigate GPS disciplining.  I read
> some remarkable work using Jupiter engines and a simple N/1000 and PLL, but
> with those receivers becoming much more outdated and higher precision GPS
> receivers now fairly cheap - I thought I'd try something new from uBlox to
> not repeat prior efforts.  I've gone all through every resource I can find
> online and on the uBlox forums, but there is a general lack of public
> information about the time and clock features of the u-Blox F9 engine.
>
> Suffice it to say, there is a section in the integration manual where
> they elude the 1PPS signal is set to the closest one of 1023 edges - which
> seems to suggest a possible sawtooth phase noise creation.  Talking with a
> person "clive1" on the uBlox forum it sounds like the internal GPS engine
> >>MAY<< now running at 384MHz there sounds like a possibility to align a
> 1PPS edge to a much finer resolution clock which is closer tied to the GPS
> solution and thus less digital divider phase noise might be possible.
>
> Does it sound like I'm way out in left field here?  Anyone have the
> luxury of more insight into the construction of the uBlox F9 GPS engine?  I
> don't mind spending a few grand on some factory new components to get a
> decent 10MHz standard, but I'm less interested in doing so if I'm not going
> to understand what's going on inside.
>
> Thanks in advance for responses,
>
> -Tim Strommen
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Difference in antennas

[Forrest Christian (List Account)]

Like many things, price does not necessarily reflect a better antenna,
however there are differences between antennas.

One difference is in the quality of the filters in the antenna itself.
 This matters more when one is mounting an antenna at a communications site
than say at a home timing lab.  If you're at a site with a lot of RF noise,
if the antenna can pre-filter this out this will help the GPS receiver
dramatically.   I just pulled the spec sheet for one that I'm familiar with
and the filter in this one drops signals outside the GPS band by 65dB at
the band edges.

Another difference is the robustness of the higher end units, including
surviving nearby lightning strikes, operating at a wider voltage range, etc.

I'm not enough of a time-nut (yet) to be able to tell you if there is some
subtle difference between the antennas which would matter once you get to
some level of precision I don't have to deal with yet.

I've personally had good luck with the PCTEL/maxrad timing
reference antennas (GPS-TMG series).  I usually have been able to pick them
up off of ebay for not a lot of money.   These also seem to be often
re-sold with a lucent or symmetricom label or some other company's label on
them, mainly because they seem to be a supplier to all of these providers.
 I don't seem to recall ever having one of this type fail.That can't be
said of other ones I've bought from random no-name suppliers.


On Thu, Nov 21, 2019 at 12:00 AM Taka Kamiya via time-nuts <
time-nuts@lists.febo.com> wrote:

> I have been looking antennas.  Prices seem to range less than 30 dollars
> to more than 500 dollars.  Some are 20db gain and some are 40 db gain.
> Some are specified as marine use only.  Some are specified as timing use.
> Some doesn't say anything at all.  Power supplies are different.
> Other than obvious, antenna is an antenna, isn't it?  It captures L1
> signal, amplify it and send it down the coax.  What makes one more costly
> than others?  What makes one timing antenna and one navigation antenna?  It
> doesn't make sense to me.
>
> I did some simple experiment with 26db, 40db, and magnetic stick on type.
> I didn't really see significant difference.  Signal level itself even
> wasn't all that different.  I have nearly a clear sky view 360 degrees
> above 30 degrees above horizon.  In some directions, clear view to
> horizon.  My feed is Timewave type.  So It may not be the best but nearly
> ideal.
>
> Can someone shed light on this topic?  (of course, I know some antenna has
> integrated receiver.  I am not talking about those)
>
> ---
> (Mr.) Taka Kamiya
> KB4EMF / ex JF2DKG
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>


-- 
- Forrest
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Capturing NMEA and TICC timestamp data in time-correlated way?

[Forrest Christian (List Account)]

Just to let everyone know what I ended up doing and seems to be working for
me...

I grabbed a raspberry pi.  Hooked up the TICC via USB to it.
I also hardwired my TTL-level NMEA serial output to the serial input on the
raspberry pi's header.

I wrote a tiny script which sets up both serial ports, then uses cat to
pipe them through ts (as suggested by another poster, thank you!), and then
writes them out to a separate file for each serial port, so I have a TICC
and a NMEA file, with each line being timestamped.

The advantage of this is that I can set it on the bench and it will happily
run for some time without worrying about windows doing an update or similar.

This seems to be working for me.   I also wrote a couple of python scripts,
the main one being one which extracts a Channel A and a Channel B timestamp
file suitable for timelab from each of the files.If I see an oddity I
now have enough data to be able to track the oddity back to a specific
period of time in the NMEA file.  Has already helped quite a bit as I now
don't have to wonder if this was a GPS signal event or something else.

I'll probably spend some time in a couple of days writing another chunk of
python which will extract relevant data from both the TICC and NMEA files
and then try some adjustments of the TICC data based on the NMEA data.

On Tue, Sep 17, 2019 at 8:01 AM Hal Murray  wrote:

>
> > I can capture the NMEA data and the TICC data - this is not a problem.
> >  But I'd really like to be able to capture both datasets in some sort of
> > time-correlated way, so I can easily post-process the TICC data using the
> > quantization error data.   I can probably throw something together in
> Python
> > or C to do this, but before I went through the effort, I figured I would
> ask
> > if there is a standard tool I haven't been able to find yet which is in
> > common use.
>
> How accurately do you want to stamp the NMEA data?  If the time on your PC
> is
> good enough, then software will work.  If you can feed a PPS to both the
> TICC
> and your PC, then you can get accurate timings on a second signal to the
> TICC.
>
> With a good PPS, ntpd should hold the time on a PC better than a ms.
>
> You don't actually need good time on the PC, or a good PPS.  All you need
> is a
> signal that is ballpark of once a second that you can feed to both the PC
> and
> TICC.  You can use the PPS capture on the PC to tell you when it arrives
> without using it to control the time.
>
> If you want more accurate timings on the NMEA data, I think you will need
> to
> build something to indicate the start of the NMEA data clump and feed that
> signal to the TICC.  The idea is to turn a long burst of transitions into
> a
> single pulse so you don't swamp the TICC.
>
> [It might just work.  I'm assuming the TICC will be overloaded by the NMEA
> bit
> stream, but it will probably get the first bit and lots of others.  You
> can
> throw away the others.  Has anybody tried something like this?]
>
> You could do it in hardware with a retrigerable one-shot.  This assumes
> that
> the characters come out back-to-back, no extra time between them due to
> software being busy doing something else.  Set the one-shot for a bit
> longer
> than a character time and trigger it from the serial data stream.  That
> will
> give you an output pulse a bit longer than the NMEA burst.  You can feed
> that
> to the TICC.
>
> If your geek hat is on, you will have to subtract off the delay through
> the
> one-shot.
>
> (I'm thinking of one-shots because I was working with a FatPPS recently.
> 74LS123  Thanks John.)
>
> If you prefer software, you can do it with your favorite tiny PIC or AVR
> size
> chip.  That will probably add several cycles of jitter.  I'd have to look
> at
> the data sheets carefully to work out the details.
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>


-- 
- Forrest
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Sawtooth Error Correction, WAS: Capturing NMEA and TICC timestamp data in time-correlated way?

[Forrest Christian (List Account)]

Let me see if I can give this a go.   Some of this will likely be
oversimplified and not exactly accurate.  Consider this a simplified 101
level class taught by an assistant and not the professor.

Most GPS receivers with 1PPS outputs are only able to align the 1PPS to the
nearest edge of some internal clock.   In addition, in most GPS receivers,
that internal clock is not synchronized to the 1PPS signal in any way.

For instance, if you had a crappy GPS receiver which only had a 1MHz clock,
the GPS receiver could only align the 1PPS output to the nearest uS (1 /
MHz), and since the timing signal from the Satellites are much better than
this, the 1PPS won't actually be aligned as closely as the GPS receiver
knows it could be.   For instance the GPS might pick a particular edge of
the 1Mhz clock, but it's also going to know that it really wanted to output
a certain amount of time before or after that specific pulse.   This data
is what is being output as correction data.

So, the GPS receiver in effect is saying 'I did the best I could outputting
the pulse, but if I could have, I would have outputted the pulse this
amount of time earlier or later'.   Not all GPS receivers support providing
this information, but at least some that do send it in NMEA between the
pulses.  Note that at least some of the GPS receivers also tell you in
advance of the errant pulse so one could correct it in real time.(I'm
hedging a bit about how many receivers do this, as I don't have enough
experience with enough different receivers to know how many do or don't).

The term 'sawtooth' comes from how the uncorrected error looks when you
measure the 1PPS signal.   Generally the error will start out really low
(or negative) then grow until it has reached a point where one clock worth
of phase drift has accumulated, then the GPS will say 'oh, it's better to
use the next pulse', at which point the error will immediately return to
the low point since all of the accumulated phase error has been removed by
outputting on the next clock.  Thus a sawtooth...  slope from low to high,
then an immediate drop.   Note that the phase drift can also go the other
way, so it starts high and then goes low.   And, sometimes you'll see the
direction of the phase drift change as the GPS clock changes frequency
slightly.  That's what causes the hanging or suspension bridges.   If you
find a graph of this online, you'll see the sawtooths are going one way on
one side of the bridge, and the other way on the other side.

On Sun, Sep 15, 2019 at 5:21 AM Andrew Kohlsmith (mailing lists account) <
akli...@mixdown.ca> wrote:

> I’m interested in learning more about how this sawtooth comes about, how
> it’s predicted (so you can correct for it) and so on. Are there
> approachable documents/sites/source with this information? I’m still a
> time-nuts newb.
>


-- 
- Forrest
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] PRS-10 Missing SP values in Appendix A.

[Forrest Christian (List Account)]

I really think we're on the same page.

Appendix A in the PRS-10 manual lists a set of recommended divider settings
such that you can select values for the divider to add a bit more or less
frequency offset so that you can bring the 10Mhz Oscillator into lock at
10Mhz regardless of what the Rb frequency turns out to be (within reason).
 This was the goal of this exercise since my PRS-10 had apparently aged
enough that it needed this tuning to be able to lock without everything
being at the extreme edge of configurable values.

The divider values in the officially released PRS-10 manual range wildly
from a low of 1466 to a high of 7187.   This is an enormous range,
resulting in output frequencies ranging from 6.82KHz to 1.39KHz.   This is
fine, assuming the rest of the loop is designed to handle this range (which
I'm assuming it was at least at some point).   However, in my unit, the
divisor programmed into the unit turned out to not be in Appendix A.
Instead it was a multiple of 3 from the stated value of row 52, which is
one of the lower values (2038).   It would make sense to me that it would
be more consistent to ensure all of the divisor values are within a
reasonable range, say from 3600 to 7200, resulting in output frequencies of
2.78Khz to 1.38Khz.   This appears to be what happened with my unit - the
value I found programmed into the unit was 6096, which is in this higher
range.

Like I mentioned before, I suspect someone at SRS figured out that they
could improve performance by moving the lower dividers up to a higher,
consistent, range, and as a result,  units are programmed with a higher
divider value than is stated in Appendix A.  Whether they made analog
changes at the same time, I have no way of knowing.

In my case, I only had to move one step in the table, which changed the
divider from the programmed 6096 value to 5971, resulting in an output
frequency change from 1.64KHz to 1.67KHz.   This isn't a big change so I
doubt that I'm going to bump into any issues as a result.

On Sat, Sep 14, 2019 at 3:01 PM Bob kb8tq  wrote:

> Hi
>
> Page 19 in the 145190 data sheet sends you off to a bunch of app notes
> about
> designing the rest of the circuit. If the reference frequency used does
> not match
> what the loop filter is designed for, things will not go well. Spurs and
> damping are
> both dependent on things matching up.
>
> Bob
>
> > On Sep 13, 2019, at 7:01 PM, Forrest Christian (List Account) <
> li...@packetflux.com> wrote:
> >
> > I suspect someone figured out some of the side effects what you're
> > describing and adjusted the divisors to better match across all rows.  I
> > just wish SRS would have updated the manual if it was them.
> >
> > In my device, the R,N,A values were 6114,3456,29.   The R,N,A values in
> the
> > table in the docs on row 52 are 2038,1145,31.   For the discussion below,
> > I'm just going to focus on R since the others are effectively related.
> >
> > The R values 'around' row 52 are 6400,4219,6257,2038,5971,3933 and 5828
> > (rows 49 through 55).It seems logical to me to use 6114 as the R
> > divisor for row 52 instead of 2038 because the resulting frequency is
> > closer to the rest of the values in the table.   The highest value I can
> > quickly see is 7258 and the lowest is 1180.   That is quite a range in
> > output frequencies to deal with.   If you take the lower values and
> > multiply them by a integer multiple so that everything is within a
> narrower
> > range then I'd expect it would be easier to deal with the side effects
> of a
> > now more consistent divided frequency while still permitting the finer
> > resolution afforded by a larger divider value.  If this is the case, I'd
> > also expect the 1180 'lowest value' to have been multiplied by either 4
> or
> > 5 instead of just 3, and the other lower values in the table to have been
> > multiplied by an appropriate range to end up closer to 6000.
> >
> > Just to add another piece to the big-picture puzzle, the following is
> from
> > the manual:
> >
> > "The gain of U400’s phase detector may be set (coarsely) by the CPU, and
> it
> > is adjusted to maintain roughly the same PLL damping factor as divisors
> are
> > changed. This loop has a very low natural frequency (about 10 r/s) and a
> > damping factor which ranges from 0.84 to 1.19."
> >
> > U400 is the same MC145190 which is doing the division.   So it sounds
> like
> > they're compensating for some of the effects by configuring the phase
> > detector differently depending on the divisor values.
> >
> >
> > On Fri, Sep 13, 2019 at 11:00 AM Bob kb8tq  wrote:
> >
> >> Hi
> >>
> >> Ummm ….. e ……
&

[time-nuts] Capturing NMEA and TICC timestamp data in time-correlated way?

[Forrest Christian (List Account)]

One of the GPS modules I'm currently playing with outputs quantization
error data in the NMEA data.

I can capture the NMEA data and the TICC data - this is not a problem.
 But I'd really like to be able to capture both datasets in some sort of
time-correlated way, so I can easily post-process the TICC data using the
quantization error data.   I can probably throw something together in
Python or C to do this, but before I went through the effort, I figured I
would ask if there is a standard tool I haven't been able to find yet which
is in common use.

So, what is typically used to capture both the NMEA data, and the phase
data in a useful way for post-processing?

-- 
- Forrest
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] PRS-10 Missing SP values in Appendix A.

[Forrest Christian (List Account)]

I suspect someone figured out some of the side effects what you're
describing and adjusted the divisors to better match across all rows.  I
just wish SRS would have updated the manual if it was them.

In my device, the R,N,A values were 6114,3456,29.   The R,N,A values in the
table in the docs on row 52 are 2038,1145,31.   For the discussion below,
I'm just going to focus on R since the others are effectively related.

The R values 'around' row 52 are 6400,4219,6257,2038,5971,3933 and 5828
(rows 49 through 55).It seems logical to me to use 6114 as the R
divisor for row 52 instead of 2038 because the resulting frequency is
closer to the rest of the values in the table.   The highest value I can
quickly see is 7258 and the lowest is 1180.   That is quite a range in
output frequencies to deal with.   If you take the lower values and
multiply them by a integer multiple so that everything is within a narrower
range then I'd expect it would be easier to deal with the side effects of a
now more consistent divided frequency while still permitting the finer
resolution afforded by a larger divider value.  If this is the case, I'd
also expect the 1180 'lowest value' to have been multiplied by either 4 or
5 instead of just 3, and the other lower values in the table to have been
multiplied by an appropriate range to end up closer to 6000.

Just to add another piece to the big-picture puzzle, the following is from
the manual:

"The gain of U400’s phase detector may be set (coarsely) by the CPU, and it
is adjusted to maintain roughly the same PLL damping factor as divisors are
changed. This loop has a very low natural frequency (about 10 r/s) and a
damping factor which ranges from 0.84 to 1.19."

U400 is the same MC145190 which is doing the division.   So it sounds like
they're compensating for some of the effects by configuring the phase
detector differently depending on the divisor values.


On Fri, Sep 13, 2019 at 11:00 AM Bob kb8tq  wrote:

> Hi
>
> Ummm ….. e ……
>
> The divisors run down to an output port. There has to be a filter at that
> port to
> knock down the noise and make the loop close properly. When you multiply
> the
> divisors by three, you cut the frequency at that port by three. You also
> have a
> significant impact on the control loop…..
>
> Probably a good idea to make sure your board has the “normal” components on
> it that correspond to the numbers in the manual. There may have been a
> running
> change at some point that is not reflected in the doc’s.
>
> Bob
>
> > On Sep 13, 2019, at 12:12 AM, Forrest Christian (List Account) <
> li...@packetflux.com> wrote:
> >
> > Mainly wanting to post this to the list so it will end up in the
> archives.
> >
> > So I decided to give calibration/adjustment of my bench PRS-10 a go.
> >
> > What I discovered is that on my particular unit, the frequency was enough
> > off that in order to bring it close to spec, I had to adjust the Mag
> Offset
> > to the lower end of it's range (2300), and even then the set frequency
> was
> > lower than I would have liked.
> >
> > According to the section of the manual under the SP command, if the Mag
> > Offset is at the end of it's range, you can change the frequency
> > synthesizer's parameters by querying the existing SP? settings, finding
> the
> > row in Appendix A which corresponds to those values, then changing the SP
> > value up or down a step (by using the values in the table row just above
> or
> > below the value).
> >
> > In my unit, the SP value set (6114,3436,29) were not anywhere to be found
> > in Appendix A.
> >
> > After some digging, and reading the manual, I discovered that these
> values
> > are used to configure the  MC145193 inside the PRS-10.   Specifically the
> > first value (R) is used to divide the 10Mhz output.   The second two
> values
> > (N, A) are used to divide 359.72Mhz (which is related to the Rb
> > frequency).   This second divisor is calculated by (N*64+A).  The
> resulting
> > two divided down signals will be very close in frequency, and the
> > difference is used to stabilize the oscillator.
> >
> > After some more work, I discovered that the divisor values currently in
> my
> > oscillator were actually exactly 3 times the value of row 52, that is
> > 6114/3=2038 and (3436*64+29)/3=(2038*64+31).   Since it's only the ratio
> > between the divisors which matter, I'm assuming someone at some point
> > decided to use the higher division ratio for some reason.  Not sure if
> this
> > was at SRS or in the field.
> >
> > After discovering this, I followed the procedure to move the SP values by
> > one row in the table, and everything s

[time-nuts] PRS-10 Missing SP values in Appendix A.

[Forrest Christian (List Account)]

Mainly wanting to post this to the list so it will end up in the archives.

So I decided to give calibration/adjustment of my bench PRS-10 a go.

What I discovered is that on my particular unit, the frequency was enough
off that in order to bring it close to spec, I had to adjust the Mag Offset
to the lower end of it's range (2300), and even then the set frequency was
lower than I would have liked.

According to the section of the manual under the SP command, if the Mag
Offset is at the end of it's range, you can change the frequency
synthesizer's parameters by querying the existing SP? settings, finding the
row in Appendix A which corresponds to those values, then changing the SP
value up or down a step (by using the values in the table row just above or
below the value).

In my unit, the SP value set (6114,3436,29) were not anywhere to be found
in Appendix A.

After some digging, and reading the manual, I discovered that these values
are used to configure the  MC145193 inside the PRS-10.   Specifically the
first value (R) is used to divide the 10Mhz output.   The second two values
(N, A) are used to divide 359.72Mhz (which is related to the Rb
frequency).   This second divisor is calculated by (N*64+A).  The resulting
two divided down signals will be very close in frequency, and the
difference is used to stabilize the oscillator.

After some more work, I discovered that the divisor values currently in my
oscillator were actually exactly 3 times the value of row 52, that is
6114/3=2038 and (3436*64+29)/3=(2038*64+31).   Since it's only the ratio
between the divisors which matter, I'm assuming someone at some point
decided to use the higher division ratio for some reason.  Not sure if this
was at SRS or in the field.

After discovering this, I followed the procedure to move the SP values by
one row in the table, and everything seems to have re-centered itself.

Hope this helps someone...  Even if it's me in the future if I have to do
this again.

-- 
- Forrest
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] TAPR TIC Upgrade?

[Forrest Christian (List Account)]

The TICC uses an Arduino mega clone, not a Raspberry Pi.

My understanding is that most of the magic happens on the shield board not
in the processor - the processor is just there to capture the data from the
shield and format and report it via the serial port.

On Wed, Aug 14, 2019 at 12:10 PM Perry Sandeen via time-nuts <
time-nuts@lists.febo.com> wrote:

> Yo Bubba Dudes!,
> I've just purchased a TAPR TIC module.  Now the new Raspberry Pi Model B
> has just been released.
> So my question is would there be any worthwhile advantage to replacing the
> TAPR unit with the new Model 4B?
> Regards,
> Perrier
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>


-- 
- Forrest
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Recommendations for time beginner?

[Forrest Christian (List Account)]

Long winded answer to your question:

I'm sort of an "Advanced beginner" time-nut or maybe a bit beyond that.

In relation to your question:  It really depends on your goals.   The
following is a high level overview of your options, and is intentionally
lacking and/or simplifying some details.   There are lots of twists and
turns one can go down on each of these options.  And there's a few spots
which I'm making generalizations which may or may not be exact.

In the way of "precision" 10Mhz clock sources, I have 2 thunderbolts, a
PRS-10 rubidium oscillator, and a BG7TBL GPSDO.  Oh and a couple/few OCXO's
which are undisciplined.   I want a cesium clock but haven't happened to
end up with one yet.

You're somewhat familiar with the thunderbolts, let me compare the others
first.

The OCXO's are undisciplined, but aren't that bad of a 10Mhz reference.
 Especially if you can trim them to a good quality reference - such as your
thunderbolt.   Depending on your needs, this might be good enough for you.
Generally, once the OCXO is warmed up you can adjust it to match the
reference, then as long as it isn't shut off it should stay very close to
the same frequency.  Of course it will drift over time and perhaps as a
result of other external forces (temperature, humidity, voltage, vibration,
etc).   Of course you can then re-trim it to the right frequency.  How much
and how often you need to do this will depend on the oscillator.   A
surplus OCXO can be had for well under $100.   A good quality pre-aged
surplus one is likely better than a new out of the box one (even of the
same time).   Other members of the list have much more experience with
which are the best, but I personally have found that the oscilloquartz ones
are typically acceptable for my needs.

A rubidium oscillator is like an OCXO on steroids.   But if you think of it
as a very very very low drift OCXO then you've probably got the right
idea.  For comparison a good OCXO will drift in a day about the same as a
rubidium will drift in a year.   You can often get a Stanford PRS10 in good
condition for around $250 or so.  The challenge is that any atomic clock
has a certain limited life due to the physics package "wearing out" in some
form or another, so it's a bit higher risk than just buying a good quality
OCXO.

Before I get to the GPSDO's let me mention about the relative ease of
trimming the above two types of references.  If you have a two channel
oscilloscope, it is rather easy to trim these.  You plug the reference
clock into one channel, set the scope to trigger off of that channel (so
the waveform is stable).   Then you plug the clock you are trimming into
the second channel.  You then adjust or 'trim' the oscillator until the
waveforms do not move (or beat) in relation to each other.

If you don't have a two channel oscilloscope, there are other ways to do
this as well.

Now back to the GPSDO's.

The thunderbolt you have is a OCXO 'disciplined' by the GPS's 1PPS output.
 It's the same as trimming the OCXO on a continual basis such that the OCXO
output always has 10 million cycles per 1 second.   There are other GPSDO's
that use other types of oscillators as well (rubidium, vcxo, etc). The
method of trimming the oscillator varies from GPSDO to GPSDO, but the
effect is typically the same: that is to adjust the 10Mhz output to
something close to 10Mhz.

As I mentioned I have a trimble thunderbolt and a BG7TBL GPSDO.   The
BG7TBL GPSDO is a GPSDO designed by a Chinese ham, and each edition seems
to be a little different, typically using a u-blox GPS receiver and
seemingly whatever surplus OCXO they can get their hands on.   Mine happens
to have a russian OCXO in it.  The quality of these seem to be rather good,
although there is a bug which affects mine and other earlier ones which
cause the long-term frequency to be very slightly off.  The very slightly
off means it runs at ~9.9 Mhz instead of 10Mhz.I beleive that

There are other designs out there as well from other vendors.   A search on
a certain popular auction site for "GPSDO" reveals a lot of options.   I've
had discussions with a couple of people who have compared several of these
and apparently the consensus is that they're typically all decent for
general use, and some are better than others, but none that they've tried
are especially bad.  Certainly they should be good enough for a reference
clock for most people.   If I didn't have a collection of oscillators
already I'd probably pick up 1-2 of these of varying types.   Maybe a
thunderbolt and one of these.

One final caveat, which may or may not be applicable to you:   In some
applications, certain types of noise can be a problem.   Depending on how
you're using the clock you may actually find that a disciplined oscillator
is not the right solution.   Generally I'm timestamping events and I'm more
interested in stability instead of precision.  So, even if the frequency of
my clock source is off by 1-2% it isn't a big 

[time-nuts] Logging and correlating NMEA messages with TICC timestamp

[Forrest Christian (List Account)]

I have a couple of GPS receivers I'm experimenting with that I've been
using a TICC to gather timestamps of the 1PPS output to ascertain
their relative quality.

In the process of doing this, I've discovered that some of the 1PPS
outputs are not as stable as I'd like them to be.  For instance, the
one currently on my bench emits stuff like this every once in a while:

330364.902989667231 chA
330365.582893064933 chA
330365.584094826326 chA
330365.902989679840 chA

Note the 2 inserted pulses between the two correct ones.

I'd like to be able to look at a log of the GPS NMEA output at the
appropriate time for this and other events to determine if they
correspond to some sort of GPS event.In addition, I'd like to
gather the phase correction data (aka quantization error) from the GPS
(and which is spit out in a NMEA sentence as well) in a way that is
correlated to the TICC timestamp it goes with.

I know I can hack together something in python or similar to open both
ports and log them together using a common timestamp.  But this also
seems like something which is probably being done regularly in time
labs around the globe so there's likely some tool to do this that I'm
unaware of.

So I guess I'm asking what everyone else is using to gather both
timestamp data and NMEA data in a correlated way

Thanks for any input.

-- 
- Forrest

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] generalization of three cornered hat

[Forrest Christian (List Account)]

I apologize if the following isn't helpful.   I'm still getting my
head around all of the details of statistical analysis of clocks so
I'm not 100% sure this matches what you're asking for, but I figured
it might be helpful so...

A portion of the document at https://tf.nist.gov/general/pdf/1288.pdf
might be helpful. In Section XV on the page labeled 2588 and
subsequent pages it describes the AT1 algorithm which is used by NIST
to mathematically combine N clocks into a single Virtual Ensemble
clock using averaging and weighting of the clocks.   As a side effect
the algorithm provides a method to determine the quality of each clock
for the purpose of increasing or decreasing the weight each clock is
given when computing the Ensemble clock.  Not sure if this matches
your needs, but it seems like it might be close.

In searching for the above document I also found
http://www.nict.go.jp/publication/shuppan/kihou-journal/journal-vol50no1.2/0501.pdf
which contains summaries not only of AT1 but also other algorithms.

On Sat, Jun 15, 2019 at 5:08 PM jimlux  wrote:
>
> I found a lot of references to estimating the uncertainties in
> measurements derived with three cornered hat.   What about for arbitrary
> N sources and N(N-1)/2 pair-wise measurements?  There must be some magic
> term to search for.
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.



-- 
- Forrest

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Garmin GPS12XL V3.51

[Forrest Christian (List Account)]

I realize that this doesn't help old receivers, but I'm sort of
surprised that this wasn't addressed as the GPS system has had various
additions made to it such as WAAS.  Even 3-4 bits allocated to this
purpose in one of the datastreams would move us out beyond any
reasonable expectation of the life of the current GPS protocol.

Does anyone know if any of the global GNSS alternatives (aka GLONASS,
etc.) have similar limitations?

On Tue, Apr 9, 2019 at 7:01 AM Tom Van Baak  wrote:
>
> > There's another relatively simple clue in the old GPS signal: the leap
> > second count! A device manufacturer could teach it what the leap second
> > count was at manufacturing time, and how to predict a lower bound on the
> > leap second count in the future (with a suitable safety margin / fudge
> > factor) which should allow it to live a bit more than 20 years.
>
> The idea was proposed 20+ years ago, Trimble even has a patent on it. Details 
> here:
>
> http://leapsecond.com/notes/gpswnro.htm
>
> But it turns out not to work. Earth rotation is too difficult to predict 20, 
> 40, or 60 years into the future. There was talk that the GPS receiver 
> failures in 2015 were related to this algorithm. Look for any threads with 
> subjects like: TS2100, TymServe 2100, 1995 rollover, Trimble ACE, Heol Design 
> in:
>
> http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2015-May/
> http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2015-June/
>
> /tvb
>
> - Original Message -
> From: "Tony Finch" 
> To: "Discussion of precise time and frequency measurement" 
> 
> Sent: Tuesday, April 09, 2019 4:08 AM
> Subject: Re: [time-nuts] Garmin GPS12XL V3.51
>
>
> > Leo Bodnar  wrote:
> >
> >> Assume that the device does not have any reliable long term non-volatile
> >> memory that you can update.
> >
> >> In the absence of any clues your only reliable piece of knowledge is
> >> that the cold start date is somewhere after the date of manufacturing
> >> or, most often, firmware compilation date.
> >
> > There's another relatively simple clue in the old GPS signal: the leap
> > second count! A device manufacturer could teach it what the leap second
> > count was at manufacturing time, and how to predict a lower bound on the
> > leap second count in the future (with a suitable safety margin / fudge
> > factor) which should allow it to live a bit more than 20 years.
> >
> > Tony.
> > --
> > f.anthony.n.finchhttp://dotat.at/
> > Gibraltar Point to North Foreland: Northeasterly 5 or 6, occasionally 7 in
> > south. Moderate. Showers at first in south. Good, occasionally moderate at
> > first.
> >
> > ___
> > time-nuts mailing list -- time-nuts@lists.febo.com
> > To unsubscribe, go to 
> > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> > and follow the instructions there.
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.



-- 
- Forrest

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] PRS-10 Warm-up Time, Calibrating/Adjusting, and long-term poweron

[Forrest Christian (List Account)]

of accuracy “on the shelf / power off” pretty much forever and 
> ever. In fact,
> it’s a pretty good bet that it will hold 10X this accuracy for quite a long 
> time. You probably
> should warm it up for a day or so if you are after 0.02 ppb.
>
> Calibration wise, the “easy” way to do it depends a lot on what you have to 
> do the measurement.
> If you have a TICC (sounds like you do) - use it. You can also use a scope or 
> a more
> conventional counter.
>
> If you are going after 0.02 ppb, you would want to set the unit to 0.002 ppb. 
> That gives you
> 90% of the budget for things like temperature drift and aging. Indeed you 
> might want to go
> to a tighter number …. this is Time Nuts after all.
>
> 0.002 ppb is 2 ns over 1,000 seconds. It’s 200 ns over 100,000 seconds. 
> (Amazing how that
> works :) ). Is your TBolt PPS good to 2 ns? Probably not. Is it good to 200 
> ns? most certainly.
> Since 100,000 seconds is just over a day, that makes for a fairly easy 
> adjustment process.
> Look at it once a day and tweak it. After a while it will not need tweaks any 
> more.
>
> The advantage of a “long term” adjustment like this is that it also takes in 
> the temperature
> swings in your lab over a one day period. At the 0.002 ppb level, they will 
> be the dominant
> part of what you see. Will you get to the 0.002 ppb level? It depends a lot 
> on just how stable
> your particular unit is and how drafty your lab is.
>
> Running any sort of electronics gear 24 hours a day is a risk. It may wear 
> out, it may cause
> a fire, it may be fine … who knows. It also pulls power and you pay the 
> electric company for that.
> It’s generally cheaper / safer to turn stuff off if it is only going to be 
> used rarely.
>
> Lots of fun !!!
>
> Bob
>
> > On Mar 8, 2019, at 3:18 AM, Forrest Christian (List Account) 
> >  wrote:
> >
> > Hopefully you'll all grace me with a few answers to a beginner
> > time-nut question or two.
> >
> > I have a PRS-10 I've never used other than to power it on with a
> > recently-acquired heatsink and verify that it seems to operate
> > correctly and that the operational parameters don't seem out of
> > tolerance.   I would like to use this in the near future as a 10Mhz
> > reference for a TAPR TICC which I'd like to use to measure the jitter
> > performance of the PPS output of various consumer GPS receivers, the
> > goal being to end up with a jitter histogram.
> >
> > So three interrelated questions:
> >
> > 1) Assuming the PRS-10 has been off for a long time, how long should I
> > plan on leaving this on for the 10Mhz to stabilize?   I see the
> > longest warmup time on the spec-sheet is 7 minutes -  although this
> > seems a lot shorter than I'd likely use in real life,  I'm also not
> > sure if there's much benefit to an excessively longer warmup time
> > (like days), would like opinions on this.
> >
> > 2)  Longer-term I'd like to use the 1PPS output from a Trimble
> > Thunderbolt to calibrate the PRS10 and adjust if necessary just to
> > trim out any aging drift on the PRS10.  Initially I thought I was
> > going to discipline the PRS10 on a continual basis with the
> > Thunderbolt using the PPS input on the PRS10, but I've recently
> > realized that leaving the PRS10 on permanently might not be the best
> > option (see Question 3).   So I'm looking for opinions on how to keep
> > the PRS10 calibrated/adjusted.  I.E. trim with the trimmer, adjust
> > using digital commands, etc.
> >
> > 3) As implied in #2, I was originally planning on leaving the PRS10 on
> > a continuous basis.   I've read a couple of things which imply that
> > there is little benefit to doing so, and that every hour it's on
> > consumes the lamp life.   Assuming I only need the highly stable PRS10
> > source every few months for things like jitter measurements on 1PPS
> > sources, is there any benefit to leaving the PRS10 on?
> >
> > --
> > - Forrest
> >
> > ___
> > time-nuts mailing list -- time-nuts@lists.febo.com
> > To unsubscribe, go to 
> > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> > and follow the instructions there.
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.



-- 
- Forrest

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] NIST time and frequency seminar - 11-14 June in Boulder, CO

[Forrest Christian (List Account)]

I'm actually debating on whether to attend this or not.   I really
need to understand a lot of the things related to time and Frequency
better, and it looks like this covers pretty much all of the bases.
The price, although high, isn't out of the range of expectations for
this type of workshop.

For those who have attended in the past, I'd appreciate it if someone
could characterize how much underlying time and frequency knowledge is
needed to be able to at least follow along.  Based on Tom's
description and the topic titles in the agenda, I suspect that I'll be
better than ok, but it is $1900 and I'd really hate to show up and
find out that I'm lost 30 seconds into the first session on the first
day.


On Sat, Feb 16, 2019 at 12:09 AM Tom Van Baak  wrote:
>
> >> https://www.nist.gov/news-events/events/2019/06/2019-nist-time-and-frequency-seminar
> >
> > Mother of God, John, what makes this meeting worth the price?
>
> Hi Bill,
>
> Yes, it sounds high but perhaps not out of line for multi-day professional 
> conferences / seminars these days. True, you have to factor in Denver flights 
> and Boulder hotels. But when you consider where it's held and who's speaking 
> and how long it lasts, it starts to look like something between a bargain and 
> a worthy bucket list item. NIST takes T seriously; this is not some sort of 
> cheap corporate or product marketing show.
>
> Look over the agenda and note both the wide range of topics covered and the 
> personnel doing so. The sessions tend to be very high quality. A portion of 
> attendees are the kind sent by their companies to "learn about time & 
> frequency" this week, so as a practicing time nut you are well above that. On 
> the other hand, NIST keeps the conference current and practical and detailed 
> so even the most seasoned time nut will learn a great deal. You may also meet 
> lifelong contacts. I have attended and highly recommend it.
>
> If it's just registration price that keeps an energetic curious time nut from 
> attending let me know. In years past I've recommended NIST allow a limited 
> time nut discount and that's worked. Let me know off-list if this is 
> something you'd like to be considered for.
>
> /tvb
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.



-- 
- Forrest

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

[time-nuts] Thunderbolt+PRS10+TAPR/TICC

[Forrest Christian (List Account)]

I am wanting some general advice on the following:

I currently have among my timing-related devices a couple of Trimble
Thunderbolts (a silver one w/ the inbuilt power supply and a gold flat
one), a PRS10, and a TAPR/TICC.

My current end goal is to use these to get an idea of the quality of the
1PPS output from various consumer (not timing) GPS receivers.   My thought
is to clock the TAPR/TICC from the PRS10, and then just capture the
relative timestamp of each 1PPS from the GPS receiver.   Using this, I
think I should be able to at least get a relatively good histogram of the
1PPS nanosecond phase error, and analyze the number of outliers/missing
pulses.  Possibly do some other analysis, but that would be a bonus.   Feel
free to correct my terminology if I've mangled it horribly.

My current plan is to mount one of the thunderbolts (probably the silver
one for electrical and mechanical reasons) and the PRS10 in a good quality
heatsink benchtop instrument case, and power it from a 24V charger+battery
array and leave it on permanently.  When not in use for the measurement
above, I'd just leave the 1PPS from the thunderbolt connected to the PRS10
and use that to discipline the PRS10 and use the outputs from the PRS10 for
day-to-day use.

However, when I'm doing the 1PPS measurement described above, it seems to
me that it is probably best for the PRS10 to be freerunning, to avoid any
contamination of the measurement by the PRS10 being disciplined.  (Feel
free to correct me if I'm wrong)

So my question is if the above seems like a reasonable course of action?
I also am curious about the best way to switch the PRS10 from disciplined
to freerunning/holdover to avoid any contamination from the disconnection
of the Thunderbolt.

Any other suggestions/hints for doing this type of measurement would be
helpful.   Assume I know just enough to be dangerous.

Thanks,

-forrest
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] GPIB interfaces these days

[Forrest Christian (List Account)]

I use a national instruments PCI-GPIB card in a Windows 10 PC, works just
fine.   Usually can find them <$100 on eBay.

I've also used a HP/Agilent 82357A (or B) which does USB-GPIB for those
cases when you need it for a laptop or something else without a pci or pcie
slot.

I understand the USB ones in particular are prone to being counterfeited,
but evidently most of the counterfeit ones work even though they're not
original HP/Agilent.

There are various other options out there, for instance prologix (and
possibly others) make a GPIB-ETHERNET converter which will convert GPIB
instruments to network instruments.



On Fri, Nov 2, 2018 at 2:05 AM Rex  wrote:

> So I've got some test equipment devices (mostly HP) with GPIB (or
> actually HPIB) connectors. Also a few others as non-HP stuff.
>
> Mostly I have talked to them with a NI GPIB card in a PCMCIA slot in a
> laptop. Works great but the small notebook PC I have with a PCMIA slot
> is from the early 2000's and I'm worrying what if it dies. It is running
> XP but usually not on the internet.
>
> I also have a couple very early aluminum case Prologix USB interfaces
> that I haven't tried to use in 10 years. I think I remember hearing
> these early ones had some issues, and I'd have to dig to re-learn how to
> talk to them.
>
> So I haven't looked at GPIB interface devices in a long time but I'm
> getting a bit paranoid about the good NI PCMCIA card in a very old PC.
>
> I don't remember seeing much discussion about this lately.
>
> Is there anything new I should look at. I would have thought there might
> be something with Arduino or maybe Ras Pi by now, possibly needing some
> interfacing hardware, but I'm not aware of anything.
>
> So, any advice from the group?  Old or new. Are my very old Prologix
> interfaces still worth looking at?
>
> -Rex
>
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>


-- 
*Forrest Christian* *CEO**, PacketFlux Technologies, Inc.*
Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602
forre...@imach.com | http://www.packetflux.com
  

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Programmable clock for BFO use....noise

[Forrest Christian (List Account)]

Would a mems oscillator such as a dsc6183 possibly work for you?  I'm
uncertain if the characteristics of a mems oscillator is compatible with
your application.

For odd frequencies I often head toward a mems oscillator since many can be
programmed to any reasonable frequency.   For example one can buy dsc6183
blanks and use a programmer to program it to your desired frequency.

The dsc61xx series happens to be one time programmable so you only get one
shot at it per blank.  The programmer is relatively inexpensive, but might
be more than one would want to pay for a one off.  I have found that having
a collection of blanks and a programmer is very useful since it allows me
to generate any frequency oscillator I need.

There are other mems oscillator models out there, with various specs and
programming (or not) options.






On Fri, Sep 14, 2018, 11:16 AM  wrote:

> Off topic for this list, but you guys are experts in oscillator noise!
>
> Playing with some mechanical filters.  Need USB and LSB crystals for the
> BFO.  No one seems to make crystals anymore, especially in the 253 KHz
> range!
>
> Looking at the DigiKey Cardinal programmable oscillators.  Cheap and
> available: CPPC1LZ A5B6
>
> Anyone have an idea how noisy these would be after a division by 4 to get
> them in range?
>
> Thanks,
>
> N0UU
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] PLL/GPSDO/etc learning resources for mere mortals

[Forrest Christian (List Account)]

Thanks to everyone who has responded so far.

My underlying interest is learning about 1PPS holdover methodologies in the
presence of environmental changes (think outdoor day/night temperature
cycles).  My thoughts are that there are two ways that seem obvious to me
to implement a temperature-stable holdover:

1) Discipline an OCXO using some sort of control loop to a known frequency
(using an appropriate GPS receiver) and divide that down to 1 Hz.   This
solution has large parts in the analog domain, with a bit of a PID or other
similar control loop implemented in a micro, and the divider perhaps in a
FPGA or implemented with standard logic.  The challenge seems to me to be
how to temperature stabilize the entire DAC chain without putting it all in
an oven - on the other hand, it seems that this might not be quite as
critical as I think it is, due to the relatively limited frequency control
range of many OCXO's in comparison to the voltage range of that signal. But
I just don't know enough to be able to say for sure.  I probably need to
get a few surplus (or new) OCXO's and play with them.

2) Use a non-disciplined OCXO as a temperature-stable clock and feed this
clock into a FPGA where one could implement a 1Hz PLL or similar.   It
would seem to me that even measuring the OCXO's average frequency over a
long period using a GPS 1PPS source as a gate would get me somewhere toward
where I am headed, but I'm guessing that there's a lot of complexity I'm
not aware of.

I realize that a lot of what I just mentioned above contains a lot of
naivete.  I'm sort of at the stage that I sort of know what building blocks
I might be able to use (and perhaps these aren't even the right blocks),
but need to understand more about the internal workings of each.   There's
also the distinct possibility that I'm missing key building blocks that I
don't even know exist (or that they're needed).

I'm going to dig through "Deans Book" and see about obtaining a non-scarily
priced copy of the Phase Lock Techniques by Gardner.   Both seem like
excellent resources that will take me some time to digest.  Any other
suggestions would be happily received.

On Mon, Sep 3, 2018 at 12:49 AM, Hal Murray  wrote:

>
> li...@packetflux.com said:
> > I'm trying to fill in some gaps in my knowledge about PLL's, GPSDO's,
> etc.,
> > with the goal to eventually implement some of these either in a
> > microcontroller or fpga or some combination thereof.
>
> An FPGA is unlikely to be the way to go for a GPSDO.  There is lots of
> time to
> do it in software and the tools for micros are generally easier to work
> with
> than FPGA tools.  (But if you like FPGAs, don't let me scare you away.)
>
> One thing to keep in mind for GPSDOs is that the time constants for
> filters
> are very long relative to what is reasonable to build with Rs and Cs that
> are
> readily available.  The usual way to go is a D/A connected to a micro.
> That
> moves the filter time constant into software.  Thus you will see lots of
> discussion on this list about which D/A to use.  Generally, you would like
> more bits than you can get.  For a one-off project, you can trade a
> reduced
> tuning range for better resolution if you are willing to use a pot (or
> soldering iron) for the coarse adjustment, aka the high bits on the tuning
> range.
>
> Another thing to add to your list is hanging bridges and sawtooth
> correction.
>
> Another magic term associated with PLLs is PID controller - Proportional,
> Integral, Differential.  You may find some web articles that tell you
> enough
> to be helpful without using complicated math.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/
> listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>



-- 
*Forrest Christian* *CEO**, PacketFlux Technologies, Inc.*
Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602
forre...@imach.com | http://www.packetflux.com
  

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

[time-nuts] PLL/GPSDO/etc learning resources for mere mortals

[Forrest Christian (List Account)]

I'm trying to fill in some gaps in my knowledge about PLL's, GPSDO's, etc.,
with the goal to eventually implement some of these either in a
microcontroller or fpga or some combination thereof.

My problem is that the resources I've found either are very basic -
oriented toward just the high level understanding of what these are and the
basics of how they work (what I already know), OR are very math dense and
impenetrable to mere mortals - essentially oriented toward people who
already know what they're doing and who have the magic decoder ring as to
what the formulas are used for.

I'm hoping to find something which will help me bridge the gap.   Any ideas
where I should look?

-- 
*Forrest Christian* *CEO**, PacketFlux Technologies, Inc.*
Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602
forre...@imach.com | http://www.packetflux.com
  

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.