Measuring Jitter on a (1pps)clock signal without special kit?

[max_torque]

I've got a GPS module that has a 1pps output, and i'd like to be able to measure the jitter on that output, but i haven't got any special kit to do that?  WHat is the simplest way to get an idea of the jitter?

Best i can think of a use a basic micro with a xtal oscilator, and use it to count a timer incrementing during each 1pps segment.  But how do i know which device is causing the jitter?  The Micro or the Gps?

I'm sure there is a clever way to do this, i just can't quite think of it at the moment...... 

[electr_peter]

To measure clock output jitter accurately you need to have higher precision clock signal. Precision of reference clock should be 5-10 times better than what you are measuring.

In your case, GPS 1pps is reasonably (it depends on your application) accurate, especially long term. I am not so sure about short term accuracy, other forum members have more expertise in GPS and clocks. This puts high burden on measuring technique and equipment.

Best i can think of a use a basic micro with a xtal oscilator, and use it to count a timer incrementing during each 1pps segment.  But how do i know which device is causing the jitter?  The Micro or the Gps?

Suggested approach could work if your reference clock would be much more accurate than clock under measurement. Otherwise you do not know which error are you measuring.
Have a look at Dave's video to get some ideas about clocks #61 https://www.youtube.com/watch?v=0UksWKuVFFo and #235 https://www.youtube.com/watch?v=I55uLRRvLCU

[max_torque]

WHat about if i measure the single 1pps source simultaneously with multiple other "clocks" ?  I know that for each pulse, the 1pps signal will be the same, and so differences in counts for each clock must be the jitter in those clocks, rather than in the 1pps signal?  Anyone know how to do the maths to work out how many clocks i'd need for a given level of accuracy etc??

[Rick Law]

WHat about if i measure the single 1pps source simultaneously with multiple other "clocks" ?  I know that for each pulse, the 1pps signal will be the same, and so differences in counts for each clock must be the jitter in those clocks, rather than in the 1pps signal?  Anyone know how to do the maths to work out how many clocks i'd need for a given level of accuracy etc??

That wont work.  You are assuming that the other clocks are statistically distributed around the correct time, and there is no reason to believe that is true.  They could all be off in the same way, or 2/3 is fast and 1/3 is slow.  You don't know the sample, so you wont know the true time.

[hamster_nz]

What level of jitter are you expecting to measure?  I had a look and found this: http://g3zjo-radio.blog.co.uk/2013/11/30/gps-modules-accuracy-and-1pps-17144143/

Given that a 'bad' unit might have 30us of jitter (yes, I know, that is bad!, with a reasonable stable xtal osc you should be able to deduce how much jitter you don't have.

For example, count a xtal osc over 10 seconds, using the GPS PPS as a reference (assuming that it has long term stability). At the same time count how many pulses are between each PPS pulse. If you do this often enough I am sure you will find the the OSC is pretty stable (+/- maybe the LSB count). If you find that your count between between PPS pulses varies it must be due to jitter in the PPS signal.

You might not measure jitter in a good module, but you should be able to measure the jitter in a bad one.

[max_torque]

I have no idea what amount of jitter the module may have on it's 1pps output, as i can't find that specification recorded anywhere!

The module is the A2200a:

A2200a GPS

It obviously has an integral controller, which will be generating the 1pps signal, and the jitter on that output will depend upon how important the designers of the system thought that output was.  ie, the jitter on that output will depend upon the possibly the frequency stability of the devices oscilator, but probably more critically on the program flow, where more "Important" tasks being done by the controller will delay the 1pps output pin setting routine possibly?

[linux-works]

brute-force method (probably not so easy to do) is to run a very high frequency pulse train into a counter and do the division once the gate has closed on that 1pps pulse, to see how many 100mhz or even 1ghz pulses made it thru.

there are probably many tricks to pulling this off.  I know of very few and have not done this myself (but have wanted to).  one thing I could think of is to run a stable clock and slice off parallel 'sub clocks' from that so that at any given clock pulse, 10 or 100 (etc) sub-pulses are created at evenly spaced intervals (like a freq multiplier).  that would be the master clock to count pulses during that 1sec time.

then, you need to be able to count at that rate.  it will take a lot of digits in a (diy?) counter, then you'll have to get that value and run it thru a cpu to divide it.

but this still has the problem that SOME master clock as to be a good clean known source that is low jitter, else nothing you will do will give you the accuracy you are probably looking for.

[hamster_nz]

brute-force method (probably not so easy to do) is to run a very high frequency pulse train into a counter and do the division once the gate has closed on that 1pps pulse, to see how many 100mhz or even 1ghz pulses made it thru.

there are probably many tricks to pulling this off.  I know of very few and have not done this myself (but have wanted to).  one thing I could think of is to run a stable clock and slice off parallel 'sub clocks' from that so that at any given clock pulse, 10 or 100 (etc) sub-pulses are created at evenly spaced intervals (like a freq multiplier).  that would be the master clock to count pulses during that 1sec time.

then, you need to be able to count at that rate.  it will take a lot of digits in a (diy?) counter, then you'll have to get that value and run it thru a cpu to divide it.

but this still has the problem that SOME master clock as to be a good clean known source that is low jitter, else nothing you will do will give you the accuracy you are probably looking for.

I've done exactly that - a GPS referrenced 100MHz freqency counter, and the count was stable at flicking between 15,999,651 and 15,999,650 as you would expect (until I heat/cool the XTAL). So combined jitter in both sources must be less than 62.25 ns, assuming that the jitter in the XTAL and GPS signals are uncorrolated.

See http://hamsterworks.co.nz/mediawiki/index.php/Frequency_counter for details.
 

[max_torque]

Interesting^^^ Thanks!

I'd guess, that the jitter on the gps 1pps output changes in a fairly short term fashion, whereas perhaps the jitter on say an temp stabilised oscillator changes in the long term?

So,  perhaps that does mean that using a fast enough clock to count has some merit?  Then the problem becomes how to SIMPLY count say a 100MHz clock that is gated by the 1pps signal?   

[linux-works]

I wonder if anyone does this: the goal is to know the -exact- time that a pulse has changed states.  we know its 'very close to 1second' and using that, you could have a high freq signal generator send out pulses 'just before' the expected 1sec time and let it run for just a bit after.  that way, you are trying to shoot at the crossing point with 'micro polling', so to speak, and it may be an optimization to start the counting right before the expected 1sec mark than to count at high freq the whole time.

this could possibly help with overflows on your counter.  suppose you could start at halfway thru; you'd have half the counts to accumulate.  suppose you started 9/10 thru; you'd have even less counts to accumulate.

so, I'm wondering if there is a trick that could be done using this kind of scheme.

(just thinking aloud.  I have not done this experiment before but it does sound interesting as a measurement challenge).

[ejeffrey]

In general, counter overflow is not a problem.  Adding extra bits to a counter is easy.  What is hard is making the reference frequency fast enough to get the desired resolution.

There are two common methods for getting pulse timing resolution much finer than your base clock.  The first one is time-to-amplitude conversion.  When the first event happens, you start a constant current source to charge a capacitor.  Stop charging at the next iteration of your base clock.  Now, the capacitor has a voltage proportional to the fraction of a cycle your test signal lead the base clock.  Do the same thing at the end.  The time interval is T_clk * (N + (Vcap1 - Vcap2)/Vref).

The other way is to use two clocks running at slightly different frequencies.  You start one at the beginning pulse and one at the end pulse, then wait until the have a coincidence.  This acts like a 'verneir scale' to measure the time difference more accurately.

[retrolefty]

How about just using two of the same GPS modules and take their PPM outputs to an exclusive-or gate and look at the output of the gate with a scope?

[linux-works]

The other way is to use two clocks running at slightly different frequencies.  You start one at the beginning pulse and one at the end pulse, then wait until the have a coincidence.  This acts like a 'verneir scale' to measure the time difference more accurately.

but now, you have TWO clocks that add to the uncertainty, no?  even if one is rock solid perfect, the other one may not be.  seems you traded one variable for two, now (?)

would those 2 clocks be harmonically related or would you want them to be a non-multiple of the first one?  if one is related to the other, then you could have one source creating 2 clock outputs, but I'm not sure that's helpful.

I like the idea of charging a cap and measuring it at the end of the interval.  you have problems with that, to handle, though: accurate measurement, slight variation from the real 'freeze' time to the time you aquire the voltage and measure it.  what I like about this is that there are no clocks; you simply start charging a cap at the start of the 1sec cycle and then immediately measure it at the end (or, if you want to use discharge instead of charge, do the opposite).

now, how repeatable will the charging of the cap be?  the cap will show 'wear' over time and so, will this be precise enough long-term?  the cap timing may vary as it goes from cold to warm.  surrounding temperature will also cause data variation.  psu has to be very clean and volt meter has to be very accurate and stable.

[jpb]

I'm working (very slowly) on a GPSDO and have been looking at the jitter on the 1pps signal from my GPS module.

What I do is use an OCXO from e-bay which I've tuned by using it as a reference on my counter (a TTi 930) and adjusting it to measure the 1pps from the GPS (over the maximum 100 sec gate) at 1Hz (or more precisely I use the period measurement).

I've then been looking at the jitter on the 1PPS by triggering my scope with the 1pps and looking at the phase of the 10MHz signal from the oscillator. My scope can save 1024 such waveforms in the history and I then (very tediously) save each one to my computer where I use code I've written to get the phase and convert it to jitter. (I should add that I fit a line to phase vs time to allow for the OCXO frequency not being quite 10MHz.)

Of course there could be some jitter associated with the 10MHz from the OCXO but I think this is very much less than the GPS 1pps jitter which is typically in the range of +/- 10 nsecs or less.

If you have a scope that can write data to the pc directly in less than a second then it would be a lot less tedious than saving the history as individual files as I have to do.

I'm at work at present so can't post any of my results to show what I mean.

The theory behind my approach is that the 10MHz OCXO will tend to drift slowly given that its frequency differs slightly from 10MHz and the bulk of the random phase shift each second comes from the 1pps from the GPS.

The other important information I get from this is the relative frequency of the OCXO to a greater accuracy than my 10 digit counter can give me from the slope of the graph.  Generally I get this more accurately by triggering every 10 seconds or even every 30 seconds and thus covering a much longer time period with my 1024 screen shots.

Edit/Addition :
Here are some sample results - the first shows the raw phase including the OCXO frequency error and drift, the second shows the remaining jitter when a quadratic is fitted to model the OCXO variation.

[David Hess]

I have made this very measurement on a Garmin GPS18-5 down to the nanosecond range and could see the GPS reference oscillator change frequency with temperature.  All you need is a universal counter with whatever single shot resolution you desire.  2 nanoseconds down to 50 picoseconds or so is common.  I have a Racal-Dana 1992 but HP makes a number of them like the 5334 and 5335.