Jump to content

Making a GPS locked 1,000,000 pulse per second


hamster

Recommended Posts

I had some spare time the other night, and connected the pulse per second output of a GPS module to a BASYS3, and then worked of the world's worst GPS disciplined 1MHz source - maybe better described as 1,000,000 pulses per second, because of jitter in the output.

http://hamsterworks.co.nz/mediawiki/index.php/GPSDO

It would be an interesting project for somebody to rework/extend this, add CORDIC sine function and an DAC, to make a GPS referenced sine wave generator.

Link to comment
Share on other sites

@hamster,

This is the kind of project that gives me heartburn. I really want it to be all true. On one hand it's an interesting idea that a lot of people have thought of and it comes from a usually reliable source. On the other hand the commentary uses a lot of technical jargon that is, well, bothersome. Terms like "GPS disciplined", jitter, etc. shouldn't be thrown around lightly. There's a reason why no one sells $10 "GPS disciplined" clock sources with certified jitter and accuracy specifications.

The text says that "my FPGA board's onboard 100MHz oscillator is 100,000,800 Hz". I'm not sure how you are measuring that but I am sure that it isn't that all the time, at any instant or over any particular interval. You board's 100 MHz oscillator frequency has age, temperature, and voltage dependent characteristics on top of the  initial error.

You also say that "with the PPS input the 1MHz input goes from 1,000,008Hz down to 1,000,000Hz +/- ~0.5Hz". How was that measured? Do you have a NIST (I don't know what the NZ standards bodies are ) calibrated frequency counter?

Using the term jitter doesn't really mean anything. There are a lot of specific ways to view jitter, and a lot of types of jitter. Maybe it's me but I get an uncomfortable feeling when I read the word being used generically, especially when it's prefaced with the word 'absolute'.

I think that the idea is interesting but the presentation might be misinforming. I'm not even sure that you have the right to claim "world's worst GPS disciplined 1MHz source".

Still, it's an interesting idea that I haven't seen presented before. I just have the feeling that it's all a lot more complicated than how you present it.

Link to comment
Share on other sites

@zygot,

The project @hamster mentions above isn't really all that hard to do--I have one of my own.  I use mine to calculate the absolute time of a disciplined counter within my own design.  In my case, I've measured my Basys3 oscillator's frequency against the PPS to be slightly lower than 100MHz, but memory escapes me regarding just how close it is.  (It was better than 100ppm as I recall, but that's being conservative)

Such a counter could easily be multiplied by a frequency and then used as a phase index for a GPS synchronized audio output as @hamster suggests.  While such an output would be better than a tuning fork, that doesn't really answer your question above.

Properly answering the question would require a well disciplined OCXO or better--something I don't have.  (I'm not even sure I could properly engineer the power rails for such an oscillator ...)

Measuring time or frequency accuracy is tricky, especially since truth can be so hard to come by.  After getting some counsel, I discovered that it's often done by comparing a timing measure against itself some time later.  In my case, I compared my counter against the PPS one second later to see how close I was.  Given my measures, I could regularly predict the next PPS within about half a microsecond or better.  This was a bit of a surprise for me, since I was hoping for 10ns or better, but without better tooling I can't tell if it's the PPS or the local clock that's responsible for not doing better.  (The simulation achieved much better than 10ns resolution ... :D )  I suspect the local on-board oscillator.

Dan

Link to comment
Share on other sites

4 hours ago, D@n said:

Measuring time or frequency accuracy is tricky, especially since truth can be so hard to come by

Yeah, that's what's stuck in my craw. I was able to put off mentioning my feelings about this post until today. It's been too long since I made a credible attempt at any sort of jitter analysis but I still have the after-taste of it being quite hard. I'm sure that there are labs that can properly characterize this kind of thing but they have very expensive equipment and timing sources plus a lot more accrued experience than I'll ever have. My only real point is that I feel very uncomfortable about coarse treatment of a complicated subject in the absence of a very knowledgeable moderator.

Still, it's one of those ideas that are hard  to get out of one's head... like certain jingles or pop tunes of yore.

So... wouldn't be interesting to have, say 4, PPS sources and compare outputs... you know, if one can figure out how to do that meaningfully. I still wouldn't want to be making any claims. Perhaps it's just so late that most of my brain has gone to sleep...

Link to comment
Share on other sites

On 9/27/2018 at 4:19 AM, hamster said:

the world's worst GPS disciplined 1MHz source - maybe better described as 1,000,000 pulses per second, because of jitter in the output.

Makes perfect sense, putting a simple PLL around a PLL. At frequencies approaching DC, jitter is unbounded - the clock edges just wander away, proportionally to the frequency offset. Done correctly, you'll eliminate the constant term and effectively put a null into the jitter spectrum at 0 Hz. Order of infinity reduced by one ? Mission accomplished.

Improving the "inner" PLL at higher frequencies is intuitively impossible, the on-board oscillator is already the best we've got to turn a low frequency into a higher one.

A random reference: Figure 3.6 here and the text below ("Noise at offset frequency outside the loop bandwidth is passed to the PLL output.")

Your "loop bandwidth" can't be higher than the comparison frequency, which is limited to 1 Hz from the GPS reference.

What you could do is use a better "loop filter": What will happen in your implementation is that the periodic 1 Hz update has periodic spectral replicas at n*1 Hz (probably on a 1/n slope) that will appear in the output spectrum: Obviously, the output frequency is updated at a 1 Hz rate. Those changes are not smooth, so they create harmonics at n*1 Hz. This is what the "loop filter" is needed for.

Link to comment
Share on other sites

BTW, you can do square-to-sine conversion by a simple cascade of numeric integrators.

The output is frequency dependent but since the frequency variation you expect is in the ppm range, this is manageable.

I posted an OK-ish rail-to-rail (!) DAC here . Verilog unfortunately, but it's only a few lines of code. Measurement results and discussion are here.

Link to comment
Share on other sites

10 hours ago, zygot said:

So... wouldn't be interesting to have, say 4, PPS sources and compare outputs... you know, if one can figure out how to do that meaningfully. I still wouldn't want to be making any claims. Perhaps it's just so late that most of my brain has gone to sleep...

For one of my projects I did something very similar years ago.  I had four clock sources and one PPS source.  I then counted the number of clock ticks between PPS events.  Much to my surprise, all four clocks adjusted their speed together over the course of several minutes, suggesting that the PPS was .. less than perfect.

In the end, I think I knew less about what was going on than when I started: "The man with two watches never knows what time it is."

Dan

Link to comment
Share on other sites

>> together over the course of several minutes, suggesting that the PPS was .. less than perfect.

this may just be a consequence of the loop bandwidth I mentioned earlier. The loop filter must achieve huge suppression for the 1 Hz update interval plus loop stability. It's long ago and I'd have to read up on "exotic" loop filters but what I've seen so far was low order. Even though PLL settling time was a real headache up to the point of using multiple PLLs when we couldn't tune them fast enough.

I remember one reference (most likely it was the NI sync framework for PXI instrumentation) that mentioned PPS settling times in the 1/2 hour range.

The obvious question is, why don't they use a more intelligent algorithm but I suspect a linear PLL is as good as I can get for normal distributed noise, which seems safe to assume for steady-state operation.
"Clever" algorithms (think "median", sign clipping or the like) may have an advantage only if I can't rely on the error being Gaussian.

 

Link to comment
Share on other sites

@xc6lx45,

I must not have been clear.  In the multiple system test, I just counted clocks between PPS values--there was no official "loop".  Alternatively, you might say that the "loop" had infinite bandwidth.  I expected some noise.  I didn't expect it to be correlated.  A noisy PPS might cause them to be correlated, as might other conditions (common power supply, temperature, etc.)

The earlier post above, where I revealed < 1us performance, discusses the results of a proper loop filter.

Dan

Link to comment
Share on other sites

On 9/30/2018 at 8:01 AM, zygot said:

@hamster,The text says that "my FPGA board's onboard 100MHz oscillator is 100,000,800 Hz". I'm not sure how you are measuring that but I am sure that it isn't that all the time, at any instant or over any particular interval. You board's 100 MHz oscillator frequency has age, temperature, and voltage dependent characteristics on top of the  initial error.

I can at least offer you one answer... In a seperate test, 3,684,732,345,578 cycles of the FPGA's 100MHz clock passed over 36,848 (second intervals (a little over 10 hours). That is an average of 100,000,877 cycles per second.

The distribution of counts ranged from 100,000,489 to 100,001,193, which is +/- 352 counts, which when graphed look very much like a normal distribution. 90% of counts fell between 100,000,715 and 100,001,010

If we can assume and that the start and end pulse were +/- 400 counts (4us) the maximum worst-case error will be 800 counts, which has little impact on the average frequency of 100,000,877 Hz during the time I was collecting data.

I am sure that the reference signal generated by this design is very poor, it will have many terrible attributes. But I am sure that when it comes to measuring the passage of time it will be far better than the on-board crystal oscillator, which is off by around 8.77 parts per million at standard lounge conditions.

 

Link to comment
Share on other sites

On 9/30/2018 at 3:03 PM, zygot said:

Yeah, that's what's stuck in my craw. I was able to put off mentioning my feelings about this post until today. It's been too long since I made a credible attempt at any sort of jitter analysis but I still have the after-taste of it being quite hard. I'm sure that there are labs that can properly characterize this kind of thing but they have very expensive equipment and timing sources plus a lot more accrued experience than I'll ever have. My only real point is that I feel very uncomfortable about coarse treatment of a complicated subject in the absence of a very knowledgeable moderator.

Still, it's one of those ideas that are hard  to get out of one's head... like certain jingles or pop tunes of yore.

So... wouldn't be interesting to have, say 4, PPS sources and compare outputs... you know, if one can figure out how to do that meaningfully. I still wouldn't want to be making any claims. Perhaps it's just so late that most of my brain has gone to sleep...

Interestingly enough I do have four different GPS modules sitting on my bench at the moment. I may just try that if I get enough spare time...

Link to comment
Share on other sites

4 hours ago, hamster said:

In a seperate test, 3,684,732,345,578 cycles of the FPGA's 100MHz clock passed over 36,848 (second intervals (a little over 10 hours

I can believe that you counted x number of clock periods. I can believe that you did this over a specific number of time intervals. So far so good. What I'm a bit suspicious of is that every one of those time intervals were 1.0000000000 second +/- 0 seconds, or that the average of all of those intervals was exactly that number. Averaging lots of stuff over very long periods can provide some useful information... and lots of incorrect assumptions.

Most of what I want to do in an FPGA is concerned with intervals of a tiny fraction of a second. What's important is the repeatability and stability of a clock over this small interval or even from one rising_edge to the next rising_edge.

As to locking a garden variety clock module to a precise very stable external source, I 'd say this. If we could have, say 4, prototypes 100 feet apart, and each locked to that source, and each putting out a different source pulse, say 1.652 ms 10 times a second, whose rising and falling edges were within, say 100ps, then we could have something pretty interesting and useful.

Link to comment
Share on other sites

48 minutes ago, D@n said:

Last time I checked, such a capability was controlled under ITAR.

While I'm sure that there are restricted applications for such a system I am also sure that quite a few technology sectors in physics, agriculture, automotive and other fields are interested in and are patenting such things. As far as I know basic thought experiments, other than perhaps in cryptology, are still legal to perform. That's not to say that if I create a piece of hardware and publish it that someone in a governmental agency who thinks that such a technology has national security implications won't pay me a visit and co-opt and become it's new owner. ( I can think of a few stupid, though innocent enough, open source projects from around the world have been quashed in recent memory).

My purpose in setting admittedly very stringent capabilities was two-fold:

  • Make the reader think about what it takes to produce much less measure and verify those claims ( typical self-driving vehicles use 60+ GHz radar, very expensive lasers systems are certainly applicable)
  • Point out the complexities of drawing conclusions about what use this line of thought might be for any particular application.

Still, I can think of, and have created, less ambitious synchronized multi-board systems that are useful and don't represent a technological security threat.

 

Link to comment
Share on other sites

Just to get you guys down to earth: Sync'ing a free-running clock to a reference has been a textbook problem for a long, long. Long time. The words "QPSK" or "Software Radio" can get you in trouble with export control, basically anything but whipped cream. Maybe even that in countries where cows are holy.  It's just ridiculous ?

-------

A few of the questions raised above clear themselves easily if I remember that the power spectrum of a (jitter) signal is the Fourier transform of its autocorrelation. Or something like that. Don't quote me.

In plain words, the low-frequency-heavy jitter "signal" tends to change slowly, "correlates with itself" up to fairly long time intervals. That's why I see little absolute jitter (in seconds) looking at nearby edges, but it gets worse with increasing distance.

It may be entertaining but it is ultimately pointless to discuss high frequency PLL performance (such as the randomness of adjacent clock edges) when the discussion is about a 1 Hz low-frequency reference.
If I cut through the smokescreen, it all comes down to the simple fact (e.g. Leeson's equation) that I need something better than the on-chip VCO ("higher Q"). Something that does a better job in turning a low frequency into a higher one. Otherwise there is nothing we can do about PLL jitter at higher "frequencies" (in terms of jitter spectrum or autocorrelation of the jitter time signal).

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...