I'm writing a proposal for a system wherein the customer will give us a clock and a 1 PPS pulse, both LVDS, both derived from a GPS receiver.
They don't seem to know what will be the exact timing between the 1PPS pulse and the clock. Poking around a little, it seems like this is seldom specified.
If the clock were, say, 100 MHz, would I expect a non-ambiguous edge timing of the 1 PPS relative to the clock, and would I expect exactly
100,000,000 clocks per tick, forever? "NO" would be an ugly answer to either question.
The danged proposal has to be done on Sunday.
--
John Larkin Highland Technology, Inc
lunatic fringe electronics
Check the FPGA news group -- your FPGA guy asked and the best answer of the lot was that the typical timing jitter of the 1PPS pulse is 50ns. This is consistent with the typical positional accuracies for GPS, given that GPS treats positions and times as more or less the same thing.
So, no, no, and sorry.
Just to make your life even more joyful, if that 1PPS edge is coming from where I think it is (that is -- if it's coming from the same solution that's giving the position), and if the receiver is in an environment that's subject to multipath reception, then it'll be subject to occasional jumps of 100m/c or more, whatever that works out to*.
I worked on a car-mounted GPS project where, depending on where the satellites were in the sky, driving by a cliff could cause the apparent position of the vehicle to jump a distance on the order of the distance from car to cliff. Even going under trees will cause the position reading to get scrambled before the receiver stops working entirely; I assume that if the 1PPS isn't filtered in any way it'd do the same thing.
So, if the thing is on a ground vehicle that's driving anywhere but in the middle of the open desert (or ocean), you can expect jumps fairly often. If the thing is on a building with an antenna that's not the highest thing around, then you can expect jumps less often, but you may still see them either from satellites moving around (they tend to do that) and their signal bouncing off of buildings, or during times when there's not a lot of satellites up there when reflection off of a car or plane may be temporarily stronger than the "real" signal.
Depending on the needs of your customer, I'd suggest that a simple phase- lock between their supplied 100MHz clock and their 1PPS, to generate your own stabilized 1PPS clock, would be a good approach. With no frequency error to worry about you could just feed an integrator with the error between the incoming 1PPS pulse and your regenerated version -- then run everything off of your regenerated version. (I've done this sort of stuff before for genlocking video systems, so if you guys don't want to reinvent that wheel you can call me).
100m/c = 300ns? -- yup, that sounds right.
--
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work! See my website if you're interested
http://www.wescottdesign.com
The "clock" that drives the 1PPS signal will be something inside the GPS receiver (it's a synchronous machine). And, you have no way of knowing *which* clock it may use to generate that signal -- or the relationship between that clock and the "clock" that they are providing to you. Do they specify a rise/fall time for the signal? (i.e., you may discover that the variability in the rise/fall time precludes it being accurate to one "clock" cycle!)
E.g., when I worked with LORAN (predates GPS by a few decades), our receivers were synchronous (microprocessors) yet the RF signals that we were tracking were asynchronous (wrt *our* clock). So, "staying still", you'd expect to encounter a one clock jitter in the signals you were sampling.
OTOH, if you looked at them over a period of 10 GRI, they were "spot on".
Your "safe" solution is not to specify anything in terms of "one 1PPS cycle". Or, relate it to something that *they* control on which you can base your implementation.
Really depends on the clock source from the customer.
I've seen 10MHz gps disciplined clocks and some with 10MHz and 100MHz. The 1PPS output edge to the UTC second will likely be > 10ns. Check the MicroSemi web site for the GPS clocks. For 10Mhz output your question about 10,000,000 clocks / 1PPS pulse may be accurate. The edge of the 1PPS would not likely exactly match the
10MHz clock edge but would be within the clock by some +/- X ns with X < 100. I think I read once that one of the MicroSemi clocks the 10MHz edge would be +/- 80ns of the UTC second clock.
tf.nist.gov/general/pdf/2297.pdf
This one is rather old but talks about timing using GPS and WASS
I guess the question is what do you need to do with these two signals? For some applications the relative timing won't matter while for others it will.
The customer is giving us a higher frequency clock, plus the 1 PPS.
I've scoped a lot of GPS receiver manuals, and most are silent about the possible phase relationship, and even about simple stuff like rise/fall times. Some talk about slipping cycles, some talk about jitter on the PPS, but it's not very helpful. I get the general impression that the 1 PPS and the clock output are natively asynchronous.
--
John Larkin Highland Technology, Inc
lunatic fringe electronics
Exactly my proposal. Watching here and there I really wonder why you are not yet on the list. The list is filtered by hand to keep the S/N high. Latency can be a few hours. There is a huge archive that can be searched.
And unless someone has made sth. special, the frequency and the pps are asynchronous in the short term. In cheap receivers the 1pps is nothing but a processor port bit.
There are lots of skilled amateurs who've written about locking to GPS modules' 1pps output. Several made careful measurement of the 1pps' jitter, phase, etc. of various GPS modules.
Google (I used ixquick.com) "gpsdo 1pps"
Brooks Shera was the first:
formatting link
Here's a link to several others' projects:
formatting link
More resource links:
formatting link
Certain GPS modules' 1pps outputs were *much* better than others, and many of the best would output 10MHz, clean.
This is typical JL stuff. He gives us a tiny piece of the problem and how it is so difficult to solve without giving us enough info to understand why it is a problem. So how can anyone advise him on a solution?
The 1 PPS signal and the 100 MHz clock may or may not be synchronized in a useful way. But this may or may not be a problem depending on how they are being used. Until we know that, we can't know how to solve design a solution.
"The Jupiter-T module made by Navman (originally Conexant) has an output at 10kHz ?locked? to GPS time. Initially I was sceptical thinking it probably only consisted of 10,000 pulses per second - which could have been no better than the 1 PPS signal itself in the short term. However, after making extensive measurements, came to the conclusion it really was quite a respectable signal - in particular I could not detect any discrete sidebands at sub Hz frequencies."
(I think I have some of those Jupiter GPS modules in the dungeon somewhere. )
------
There are several articles over at NIST, e.g.
formatting link
The Use of GPS Disciplined Oscillators as Primary Frequency Standards for Calibration and Metrology Laboratories
I didn't see him say that. He said he is *provided* a 100 MHz clock and a 1 PPS signal both from a GPS and he is asking if they *are* locked. I don't know what he needs the 100 MHz for or what he is using the 1 PPS for. He may need to generate his own 100 MHz clock slaved to the 1 PPS if that is what he needs, but I can't tell. Or he may need to condition the 1 PPS to sync it with the 100 MHz clock, I can't tell that either.
As I mentioned in another post, a friend designed a 1 PPS generator for the Naval Observatory. It conditioned the internal 1 PPS from the system 1 PPS, all clocked by the 100 MHz from an atomic clock. This 1 PPS signal from this atomic clock was supplied to the Kalman filter to be part of the time standard the Naval Observatory provides. If this is what John needs I can put him in touch with my friend. I expect he can either help him or design this part of John's circuit for him. Why reinvent the wheel?
I didn't see where John said he was getting a 100MHz clock. He's getting
1pps and "a clock," and doesn't know their relationship.
And it seems that relationship matters to him, from which we infer that... it matters. :-)
One main reason for re-inventing wheels is when the existing wheels don't fit your application. Otherwise we'd all be driving around on 3' stone wheels and riding skateboards with iron-rimmed wooden ones...
But let's not confuse "building a purpose-fit wheel" with re-inventing. ISTM John's doing the former (though may morph to the latter, depending).
Not exactly. My customer is giving me ca 100 MHz and 1 PPS, derived from GPS, and I wanted to know if they will be coherent. The customer isn't sure, since he'll get the signals from *his* customer. If they were coherent, we could do things like verify that coherence as a diagnostic.
The answer is that they could well be incoherent; a GPS clock and the GPS 1PPS seem to be independently derived. Some people regenerate the clock from the 1 PPS, which makes them coherent, but that probably invokes a phase noise penalty on the clock. It's hard to lock a 100 MHz OCXO to a jittery 1 PPS pulse.
I'd better hedge the options in my proposal (without looking too ignorant) and force them to make some decisions.
You'd almost think that the prime intent of GPS was something other than a free frequency standard.
I thought so. I can't discuss the ultimate application, one reason being that my customer won't reveal it. We can only guess.
I ignore Ricky. He's not interested in electronics; like Sloman and Fields and AW, his only function here is to be obnoxious.
--
John Larkin Highland Technology, Inc
lunatic fringe electronics
This guy's QEX article says there's 1uS jitter on the 1pps--
formatting link
But lots of guys precision-lock to that, they just use a big flywheel on the VCO, with various schemes for locking faster / better / etc.
That NIST article I linked suggests NOT using VCO, but a free-running OCXO instead, driving a DDS to make the phase / frequency corrections. More stable.
I was briefly interested in super-accurate time references, but passions fade...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.