PLL tricks

It probably won't slip more than 100 ns, but it will also likely not be constant.

If the time source is a Symmetricom XLi series or similar (I think, you mentioned something about "symetrix" somewhere), then the PPS will likely be internally synchronized to the 10 MHz.

From the Symmetricom XLi datasheet: "1PPS output accuracy: 30 ns RMS,

The XLi (as well as any decent timing receiver of modern vintage) should be able to provide sawtooth correction, but the sawtooth correction is usually provided over a RS-232 serial link as a data value (offset of last PPS pulse to the true second instant).

This means, the phase relationship between the PPS signal and the true time will be variable (a sawtooth) and you'll have to account for that post-factum, by evaluating the message data sent over the serial link.

Again, "Sawtooth Correction" is a very common topic on the Time Nuts mailing list. The people over there deal with GPS timing receivers on a daily basis and some of them have developed sophisticated correction algorithms for the various "gotchas" that these receivers (no matter how expensive) have. It might be a good idea to search the mailing list archive for sawtooth related topics. Maybe someone of those guys is even using a timing receiver of the exact same type as you'll have to use.

Regards Dimitrij

That isn't the PD. He said he wanted a PD with 1 ps of jitter. He has a PD with 1.4 ps of jitter... I'm just sayin'

I'd be willing to bet that most DDS chips are FPGAs or CPUs where you can do whatever you like.

Am 16.09.2014 um 17:27 schrieb John Larkin:

Rene Tschaggelar from Switzerland.

Looks like his website is slowly decomposing. But I have no right to complain.

Gerhard

I believe he doesn't really care about the "exact" position of the 1 pps. As he has said he is using the 1 pps to establish the "time" relative to the 10 MHz. The 99% is interesting. If that really is correct and 1 in 100 is outside the 100 ns window, he may have to add some circuitry in the FPGA to ignore errant 1 pps pulses. That should be easy enough. Just requiring three consecutive errors in a row will reduce the chance of a errant resync to better than once a week. Making that number 5 anomalies makes for an errant resync once in 300 years.

Only the single clock errors need to be ignored. If the 1 pps is many clock cycles out it is either noise or someone pulled the cable off.

A friend designed something vaguely like this for the Naval Observatory. It received a 100 MHz clock from a new atomic clock and a 1 pps from the Kalman filter they used to average all the various clock sources. It then produced a 1 pps that was fed into the filter as this atomic clock's 1 pps.

According to these graphs, the old Oncore VP had a 9.54 MHz oscillator, and its sawtooth *could* jump more than 100 nanoseconds between one sample or the next on occasion (not often but it did happen).

This matches my own experience, using an Oncore UT+ in a GPS-disciplined frequency-locked 10 MHz oscillator project, and that of another developer with whom I've traded code and ideas. Both of us have noticed occasional one-sample "slips" in the Oncore GPS timing, which causes a substantial hiccough in the frequency lock. I think that may be what you'll see in the data for 9/9/14 at

where you can see the frequency error (purple) and the VXCO control voltage (green) bounce around.

The later Oncore M12+ has a higher-speed LO clock and it looks as if its worst-case sample-to-sample jitter would be under 50 nanoseconds. Modern timing-grade GPS receivers are probably quite a bit better.

On 16/09/14 17:27, John Larkin wrote: [..]

Nope, not me. Rene Tschaggelar perhaps?

Jeroen Belleman

Careful with that Si550!

I've used that one, and when running at a constant frequency, it has indeed very low phase noise, put it seemed to have one major WTF when it comes to frequency tracking. See below for details...

The thing internally uses a programmable PLL that runs around several GHz. The exact value is not specified, and it's not fixed anyway.

The PLL parameters are programmed by SiLabs in the factory, that's what allows the parts to be made to order within a week to any imaginable center frequency with 5 decimal digits precision.

The PLL is locked to an internal crystal oscillator, but the crystal itself is NOT pullable in an "analog" way. Instead the "VCXO" control voltage input internally goes to an ADC, is digitized (no, they don't specify at how many bits resolution), and then some logic digitally calculates the correction values to the PLL registers and adjusts the running PLL. They don't specify directly how many times per second that adjust rate is, but their maximum specified modulation rate of 10 kHz means that the adjust rate is 20k updates per second or thereabouts. (As I remember, John was not pleased with a prospective 80k rate...)

Now to the "WTF".

When the digital RF PLL in that Si550 is "updated" with a new ADC value, it seems to do that in a rather strange way. The update rate is not externally visible and the module was a pig to debug, so I did not find out what exactly happened in there, but the outside observable effects suggested that the PLL update was sometimes happening unpredictably. It seemed that, if the update happens at the wrong moment, the PLL can hit a glitch - like issuing an uncontrolled cycle or skipping a cycle (not sure which one of them it was).

Whatever it was, it was big enough of an issue to sometimes cause the internal DLL in a Xilinx FPFA to lose sync and spit out a number of uncontrolled cycles into the FPGA logic. When the Si550 control voltage was held constant (shorted to a fixed voltage), that never happened, but when the Si550 was being actively controlled, the resulting clock from it would sometimes (semi-regularly) throw a wrench in the FPGA. The FPGA was processing video, and the result was loss of framing. In the end, I fixed this by putting an analog 1:1 PLL (just to clean the artifacts) between the Si550 and the rest of the circuitry (2 FPGAs and DSPs). The analog PLL tracked the frequency and it did not pass through the glitches, so the solution worked (at the expense of an additional PLL).

This adventure was some 4 years ago, so SiLabs may have fixed the Si550 by now, who knows. Or it could have been something entirely different (although difficult to imagine what exactly). In any case, before using it in an application that is sensitive to absolute timing, it may be a good idea to run a test with full scale modulation and watch carefully.

Regards Dimitrij

I'm afraid I can't read your schematic. How are the FETs connected to the transformer? It looks like all the gates, all the drains and the two coils of the transformer are all shorted together.

Opps, make that all the gates and all the sources...

Coincidence: I sold the Naval Observatory a bunch of VME fanout modules, for shooting the 1 PPS stuff around.

Way to move the goal posts, guy. You're just blowing smoke at this point.

Cheers

Phil Hobbs

No, those *are* the goal posts. Otherwise why use the ECL at all?

Am 16.09.2014 um 19:25 schrieb Kevin Aylward:

A working Q of 100 is way too much.

The filter performance is important. For one, you have the varicap/inductor series resonance that is in series to the crystal. It is needed to implement the tuning voltage input.

Then you need a LC resonance to select the proper overtone of the crystal. The sweet spot for crystals is at 3-10 MHz, and even 10 MHz crystal ovens often contain overtone crystals with the fundamental at 3.333 MHz. At 100 MHz there are no alternatives to overtones.

Those extra thin etched inverted mesa crystals often mentioned here are completely fragile and have ridiculous Q. Close to the carrier, Q is the only thing that counts wrt phase noise.

SC cut crystals also have an additional resonance 14% higher than their intended series frequency and that must be suppressed.

And C0, the capacitance of the holder and the crystal seen as just two plates with something in between, piezo effect ignored, must be compensated with a parallel coil at >= 50 MHz. You never get a real valued series resonance otherwise.

So, there are always a lot of inductor resonances involved in a quality crystal oscillator.

Enrico Rubiola describes in his book how the size of an object has influence on its phase noise. That can be seen in microwave transistors (faster = smaller = more 1/f noise, fight back with paralleling) or in crystals (faster = smaller = more noise, fight back with overtones), and my 20 parallel op amps belong to this area also.

Rubiola is required reading.

There are no crystals up there. Whispering gallery mode saphires, maybe. And the product of f and Q in crystals is constant.

Yes, you can multiply it up, and close to the carrier there will be no problem. But for every f*10, the noise floor will rise by 20 dB. And when you have multiplied up to 10 GHz, the carrier will stand

You can have filters in an intermediate stage like in the HP8662A that has crystal filters at 160 MHz and SAWs at 640 MHz in its reference chain.

Or you can build an xtal oscillator at 100 MHz, use its low noise floor and lock it to a 10 MHz reference that is really clean close to the carrier, so you get the best of both worlds.

GPS receivers seldom have extra class crystal oscillators. They take their bragging rights from the long term stability of the airborne, eeh, vacuum borne Cs clocks.

I really would like to hear that 30 dB/decade is perfectly normal. The designer of a very well known low noise op amp found it at least remarkable (in my battery test results).

regards, Gerhard

You're just being thick then. Try plugging those numbers John gave for the FPGA into the same math I just went through. Doesn't give the same results at all, and in addition there's the huge drift.

It's the VCXO output that matters.

Cheers

Phil Hobbs

Of course it is the VCXO output that matters. I'm just showing that the spec John gave was 1 ps jitter on the PD which is not what he is getting.

I looked up the particular GPS module I was dealing with. It has a

This is implied by the +/- spec, but since the 1PPS output goes on the

The user guide also gives a plot of the actual quantization error of the 1PPS output relative to a cesium clock, and it runs about +/- 21 ns. There is also a plot after applying the correction supplied over the serial data, which brings the error down to the +8/-5 ns range. The serial data is a 32-bit floating-point number, and the documentation says it is in seconds, but I recall it being in something else, probably nanoseconds.

There was a newer module from the same company with a faster clock - about 16 MHz - which reduced the claimed error to +/- 15 ns. The graphs show an actual error in about that range, and about +5/-5 ns after correction. The docs for that module say the correction value is in nanoseconds, which agrees with what I remember.

The modules we were using didn't have a 10 MHz output, so I don't know how that usually relates to the 1PPS output. I *did* have to make sure the correction was being applied to the 1PPS output in software, because that was used to steer a very much faster counter (hundreds of MHz).

I understand the larger problem, but I don't know enough to suggest a good solution to it. I just wanted to point out that if you need better than a few dozen nanosec accuracy on the 1PPS signal from the GPS module, applying the correction is probably a good idea.

Another random thing I'll throw in here: if you are getting any time-of-day data from the GPS receiver, either directly or through somebody else, you might like to know that about once every 18 months or so, it will tell you 23:59:58... 23:59:59... 23:59:60... 00:00:00. That :60 will confuse your software if it isn't expecting it. (It's also possible for it to skip 23:59:59, but that hasn't happened yet.)

Matt Roberds

Honestly, Rick, is chewing on people's ankles like this the most interesting thing you can find to do?

Cheers

Phil Hobbs

And what's the problem with that?

Jamie