Frequency measurements with oscilloscope - what accuracy to expect?

[Alex Nikitin]

The one thing that it a mystery is why my scope, which is supposed to handle 1PPM accuracy, measured some 2000 PPM error in the oscillator frequency.

Most likely it is the limit of the scope's accuracy when measuring frequency from the acquired waveform. The vertical resolution is limited (8-9 bits) and the amplitude errors will translate into timing errors when frequency is calculated. A hardware counter uses an analogue trigger so the timing resolution is much (thousands of times) better. There are ways to improve the accuracy of the scope for that kind of a measurement, however even a half-decent frequency counter will always give a more consistent and accurate result.

Cheers

Alex

[John_ITIC]

I tried the cursor approach but the resolution of the scope screen does not allow me to place the cursors with more than about 0.5 ps resolution. I also played around with averaging (256 waveforms) and infinite persistence and the period of the oscillator seems to be spot on (25ns). With the built-in measurements (frequency and period jitter), the scope shows a too low frequency, although a 'mode' (statistically) that is very close to 40.000MHz. Turning off the averaging shows lots of noise, which could be related to the probe ground lead inductance picking up noise from a nearby switched mode regulator. I will study the problem in more detail, try better probe ground attachment etc.

I did today bought (Ebay) a HP 53131A Frequency Counter with 3GHz (030) and High stability OCXO (010) options. I also bought (Ebay) a FE-5680A Rubidium standard so I can make sure the scope and frequency counter shows correct frequency/time. The scope was (supposedly) calibrated when I bought it (6 months ago) but I'm not sure about the frequency counter.

[John_ITIC]

Okay, I now think I know what is going on. I have about 5% power supply noise that is affecting the oscillator in the form of phase jitter. My Agilent scope has a cool feature that allows me to display the trend of the frequency jitter. The first attached scope screen shot shows the oscillator frequency in the upper waveform and the frequency jitter trend in the lower waveform. The lower waveform shows that the total jitter frequency spikes to around 1.85 MHz p-p every 14.5us. I then measured the 1V8 power rail (2nd attached screenshot), which confirms that the 1.8V power rail has about 171mV p-p noise every 14.5us (80 kHz). This works out to 5% p-p, while the datasheet for the IC says less than 10%. The jitter trend feature of the Infiniium was very helpful in figuring this out. This is discussed in this Agilent document: http://cp.literature.agilent.com/litweb/pdf/5989-4198EN.pdf

When designing this board, I likely incorrectly assumed that as long as the p-p noise spec is met for the analog oscillator/PLL IC pins are met, it was okay to tie the analog and digital power rails together rather than separate with ferrite bead. I now suspect that the PSRR of the oscillator is not very good and that a re-spin of the board is needed to create a separate analog power rail.

This opened up a new research area so I'm now side-tracked with some in-depth study of crystal oscillators, circuit noise and the finer details of analyzing jitter with Agilent scopes!

[Kleinstein]

How good the frequency measurement is with the scope depends on the software and the waveform. In principle the hardware could allow for really good frequency measurements, possibly even better than many counters. A DSO input stage can very well be superior to the comparator input stage of a counter - especially if the signal is a sine or similar and not a steep digital one.
The 8 Bit vertical resolution could be used for extra interpolation to get timing way better than sampling rate and good / adaptive suppression of noise. So even relatively noisy signals are not such a problem.

I did frequency measurements with not so perfect signals (decaying sine with sometimes quite some noise) with a digitizer card. Though not that great hardware the frequency resolution was really good often limited by the signal source and the crystal used. Even a version for a sound-card could give 8 digits in 1 second at 1 kHz (sine). Easy to see warmup drift of crystals / generators.

For analyzing a PLL a spectrum analyzer would be the instrument of choice - though expensive. Some basic function could be done through the FFT function of some DSOs.

[John_ITIC]

For analyzing a PLL a spectrum analyzer would be the instrument of choice

Thanks all for your input. I have now cleaned up the power supply and I no longer have any deterministic jitter caused by power supply switching noise. However, when measuring jitter on my oscilloscope (now halved from before so clearly improved by cleaner power) it is still higher than I "think" the datasheet for the IC specifies. I say "think" because the specs are not actually there for the internal oscillator, only for an optional external oscillator that can be used instead of the on-chip oscillator with an external XTAL. I'm trying to confirm with the chip vendor what the acceptable phase noise of the internal oscillator is but so far I have not received any final word on this (web based support is very slow). I'm therefore continuing my independent research to figure out if my phase noise seems "ball-park" acceptable.

I have analyzed the oscillator output with my HP 8590B spectrum analyzer. The clock is at 40.00 MHz and there are no spurious signals. However, the phase noise seems too high. I have measured and calculated-95 dBc @ 10 MHz, which apparently is not too stellar. Other numbers for "commodity" oscillators state around -120 dBc @ 10KHz. The noise floor of the 8590B is at -80dBm and the clock signal is at -7.7dBm. Lab setup and SA results per attached picture. Note that the minimum resolution bandwidth of the 8590B is 100 KHz so I'm doing a correction per the below paper: http://www.crystek.com/documents/appnotes/impactultralow.pdf

I'm not sure whether the normalization from dBc/1000 hz to dBc/hz in the article is correct (subtract 10 log (RBW)). Can anyone confirm that my phase noise measurement is correct?

Thanks,
/John.

[John_ITIC]

Also, I'm seeing multiples of my 40 MHz oscillator frequency on the SA. I assume this is some normal side-effect of how the oscillator is designed on-chip? The answer surely is in my books but perhaps someone could clue me in?

In the attached image, the 40 MHz clock is to the left and then there are multiples at these frequencies"

80 MHz -55 dBm
120 MHz -60 dBm
160 MHz -65 dBm
200 MHz - 58 dBm
240 MHz -65 dBm
280 MHz - 58 dBm
320 MHz -65 dBm
360 MHz -61 dBm
400 MHz -62 dBm
440 MHz -60 dBm
480 MHz -63 dBm

After this the multiples seem to taper off. Is this typical of crystal oscillators?

Thanks!

[nctnico]

Those are the harmonics and pretty much to be expected. What does the oscillator's datasheet say about 2nd and 3rd harmonics?

[John_ITIC]

Those are the harmonics and pretty much to be expected. What does the oscillator's datasheet say about 2nd and 3rd harmonics?

But a sine-wave doesn't have harmonics (unless imperfect)? Is this explained by how the oscillator is implemented? Or, is it the PLL, which generates the 250MHz clock, that feeds back these harmonics into the oscillator clock?

The datasheet doesn't say anything regarding oscillator performance. It only says: "connect a crystal with 50 PPM frequency tolerance/stability". The oscillator is only used internally by this chip so they likely figure nobody needs to know the required phase noise. At this point, I don't know whether the crystal is not good enough, if the oscillator is not good enough. I will have to wait to hear back from the vendor what the phase noise requirements are.

[vk6zgo]

"Only God can make a tree"---------the same would seem to go for perfect crystal oscillators .

50 to 60 dB down on the fundamental is not marvellous,but it's not unusual,either.
A LPF or a resonant circuit at 40MHz will soon attenuate those harmonics into the noise floor.

[rf-loop]

But a sine-wave doesn't have harmonics (unless imperfect)?

I do not know any real world sinewave what is perfect. Perfect sinewave exist only in theory books.

Yes, it can be more or less pure but never perfect. There do not exist perfect square wave, not perfect produced sine. Many (even good) RF signal generators have this amount of harmonics.
Also in practice there is not perfect accurate frequency or perfect accurate time.

[nctnico]

Those are the harmonics and pretty much to be expected. What does the oscillator's datasheet say about 2nd and 3rd harmonics?

But a sine-wave doesn't have harmonics (unless imperfect)? Is this explained by how the oscillator is implemented? Or, is it the PLL, which generates the 250MHz clock, that feeds back these harmonics into the oscillator clock?

I doubt it is the PLL. The harmonics can be caused by cross-over distortion in the 40MHz clock. As vk6zgo wrote commercial RF generators usually don't produce a perfect sine wave either (some have 2nd order harmonics at -30dB referenced from the fundamental frequency). It shouldn't be a problem for the PLL because it only locks to the fundamental frequency which basically means it is -sort of- filtering the harmonics away from it's input.

[G0HZU]

Can anyone confirm that my phase noise measurement is correct?

There are various issues with the way you have tried to measure the phase noise but none of it really matters because the noise performance of the 40MHz oscillator is going to be much, much better than the converter section of the HP8950 analyser. So you are only going to 'self measure' the noise performance of the analyser and not the oscillator.

Even a fairly basic LC oscillator at 40MHz can be built that would achieve a ballpark -140dBc/Hz at 10kHz offset. Your analyser is probably limited to measuring about -95dBc/Hz phase noise at a 10kHz offset.

If we ignore this for a moment I'll list some of the other issues with your measurement process and I'll assume that you are (now) trying to 'self measure' the noise performance of the analyser. You have selected the peak detector and used a standard marker in an attempt to measure noise. This is going to introduce system errors because the peak detector can't represent noise accurately and also the log amp in the analyser won't respond to noise correctly. You ultimately want to measure/predict the rms voltage in a 1Hz BW and the peak/envelope detector and the log amp can't do this without some additional correction factors. These correction factors for the detector, the log amp and the chosen RBW filter are included for you in the 'noise marker' function in your analyser (assuming it can do this as I've not used the HP8590 model) and this gives you a more accurate reading of noise in a 1Hz BW. It isn't as simple as doing 10*log(BW) to get a correct reading of noise power in a 1Hz BW because of the need to (also) correct for the detector and the log amp issues and the noise marker is designed to include all these fudge factors.

Also, you have tried to measure noise in the bottom box on the analyser display where the log amp will be out of spec anyway. Normally you are supposed to adjust the ref level to bring the noise at least 10dB (prefer 14dB) above the bottom of the display. Also you ideally need to select a lower RBW filter here but I'm not sure if your HP8590 has the option for a lower RBW?

You can fix some of the above errors/issues by selecting the 'noise marker' function in the analyser but you also need to get the noise inside the log range of the analyser and this means getting it up maybe 14dB above the bottom of the display.

But your analyser's first LO is going to be way too noisy to allow you to measure a decent 40MHz crystal oscillator at 10kHz offset. Probably by 40dB.

[G0HZU]

FWIW your harmonic distortion measurement plot may be prone to a fair degree of measurement uncertainty because the HP8590 doesn't boast a very good 2HI spec.

You appear to be putting -18dBm into the first mixer (- 8dBm via the internal 10dB attenuator) and this will self generate a 2nd harmonic inside the first mixer at a level that may be able to interact and ultimately introduce some uncertainty in the measurement.

Ideally, you are supposed to make sure that any self generated harmonic distortion is 15-20dB LOWER than the distortion you are trying to measure/display. Otherwise you can get a false reading on the analyser that might be higher than reality or maybe a lot lower than reality. If you obey the 15dB rule you can manage the uncertainty down to about a dB or so.

The 2HI spec for your analyser seems to be quite poor but  I suspect that the typical performance will be a lot better than this published data. But even if this is the case you may be outside the recommended 15-20dB margin.

It's worth getting to know the distortion limits of a spectrum analyser and these limits will be different for different parts of the frequency range. This is where there is no substitute for experience when using a particular model of spectrum analyser. I'm not familiar with the typical 2HI performance of the HP8590 at 40MHz so I can't advise if you are breaking the 15dB rule or not.


To put this into some perspective you ideally need to get the internally generated harmonic distortion 20dB lower than the 'genuine' distortion level of the device under test because you can then get the uncertainty effect it introduces down to about +/-1dB.

If you obey the 15dB rule I think you get within about +/- 1.8dB for the uncertainty of the displayed harmonic but that is just an approximation

[John_ITIC]

You can fix some of the above errors/issues by selecting the 'noise marker' function in the analyser but you also need to get the noise inside the log range of the analyser and this means getting it up maybe 14dB above the bottom of the display.

But your analyser's first LO is going to be way too noisy to allow you to measure a decent 40MHz crystal oscillator at 10kHz offset. Probably by 40dB.

Thank you for the information; it is much appreciated since I'm mainly a digital engineer venturing into the RF world by necessity!

I was not aware of the "noise marker" function but I tried it and now get -107 dBm @ 10KHz offset from the carrier (see attached). I played around with the reference level and attenuation but the same -107 dBm is reported. Based on various information from newer Agilent spectrum analyzers, they all seem to have a inherent phase noise level of about the same -105 dBm (the worst -89 dBm and the best around -132 dBm).

In order to additionally pull the signal out of the instrument's noise level, could I connect an external pre-amplifier such as the HP 8447D? It is supposed to give 25dB gain from 100 KHz to 1.3 GHz. Or is there something else in the spectrum analyzer that contributes to phase noise except the general "noise level" of the SA? I may not be able to measure down to -140 dBc/hz but, perhaps, I can get half-way there without having to buy a new SA...

I also found this detailed description from Agilent regarding the "noise marker" functionality: http://www.keysight.com/main/editorial.jspx?cc=US&lc=eng&ckey=703435&nid=-11143.0.00&id=703435

EDIT: I'm not sure if I can measure the 10 KHz phase noise directly like done above. The -107 dBm is not in relation to the carrier (40 MHz clock) but an absolute value so if I subtract the signal level of the carrier (around 7dBm) I get around -100 dBc. But I'm not sure if I can do the subtraction since the carrier power level is measured with a different RBW (100 KHz minimum) and via standard marker.

[joeqsmith]

Maybe you will find these helpful.

[G0HZU]

The high phase noise of the local oscillator in the analyser will be the issue here. By the time your crystal oscillator signal has passed through the RF converter section of the analyser and it reaches the detector section in the analyser it will have adopted the same (much higher) noise characteristic as the local oscillator in the analyser.

Very few spectrum analysers will be able to measure a decent 40MHz crystal oscillator at 10kHz offset because they will all suffer from this issue to some degree. You would ideally need to use something dedicated to phase noise measurement like an E5052A signal source analyser and these are very expensive!

One cheaper way around this is to mix your 40MHz crystal signal with a known ultra low phase noise source such that the mixer output produces a signal that is 10kHz away from the centre of a narrow crystal filter.

This way you can dodge the effects of the noisy LO in the HP8590 analyser and just measure the chunk of noise you are interested in. Obviously you also need to know the carrier power in order to calculate dBc/Hz but this can be done by shifting the mix such that the carrier passes through the crystal filter.

I've not explained this very well but this is a way to measure devices with ultra low phase noise 'on the cheap' if you don't mind a fair bit of uncertainty in the measurement

In the image below I'm showing the phase noise from a (noisy) Agilent ESGD sig gen compared to the stored trace of a much cleaner signal source. I've used a narrow 10.7MHz crystal filter to attenuate the carrier part of the signal by about 60dB but NOT the wanted chunk of noise 5-10kHz away. This method dodges the limitation of the phase noise of the analyser to a significant degree.

The cleaner sig gen is the lower noise trace. It's about 45dB better than the ESGD and the noise marker says -146dBm/Hz at an offset of a few kHz.

I can't remember how I set this test up but I probably set the test signal at +4dBm power level so that the (4dB?) loss in the crystal filter meant that the noise marker reading is close to being correct in terms of dBc/Hz because 4 - 4 = 0..

Hope this makes sense, but the HP8566B analyser used in this test probably only has about -100dBc/Hz phase noise at 5kHz offset (at 10.7MHz) yet by using a crystal filter to null the reciprocal noise from its local oscillator it can measure down another 46dB lower.
The ESGD sig gen has a phase noise level of about -100dBc/Hz typical and you can see how high this noise appears with this method. It's trace is stored as the higher plot and it is over 45dB higher than the low noise LC oscillator. You can 'see' the response of the crystal filter in the noise plot of the ESGD sig gen and this helps demonstrate how this system works. The carrier on the right is about 60dB lower than it should be because it is attenuated by the crystal filter.

[John_ITIC]

Thank you Gentlemen. I think it is fair to say that I'm going too much into detail in the oscillator quality and that the issue I'm trying to solve is somewhere else. Essentially, I have trouble with data lock on a USB 3.0 PHY and I was trying to find out whether a jittery clock was to blame. If the phase noise level is so low that a standard spectrum analyzer cannot measure it then I suspect it is good enough. However, what's good enough is not easy to know since no data from the chip vendor's datasheet. I'm also afraid that going to "method 2" and mix with known good reference clock and measure the difference is too much of an effort at this point. I will have to prove that the current clock is no good before I go down that route!

One thing I'm considering trying is to swap out the current +/- 50 PPM crystal to a +/- 10 PPM one. Would this have any effect on the phase noise or is the PPM number merely related to long-term stability and frequency accuracy? Or would a +/- 10 PPM crystal generally have better phase noise characteristics?

[G0HZU]

I don't know what type of circuit your oscillator uses so I can't comment but I don't think you will see a significant difference.

One other cheapo option is to mix two of these 40MHz oscillators together and look at the audio beat/difference frequency on a PC sound card.

If you have a significant issue with low frequency warble in this oscillator (maybe due to power supply issues?) then you would see this easily on a PC running some spectrum analyser software. The beat frequency between the two oscillators only has to be a few kHz and presumably this oscillator can be nudged a few kHz away from 40MHz?

You would get a fairly decent realtime display of any warble effects and you could store and replay the results as a wav file.

The other option is to explore the jitter analysis options that are available with your scope series? I'm definitely NOT an expert in this area as I've only used an Infiniium 80404B a few times but these do offer some advanced jitter analysis options?

[G0HZU]

The other option is to look at the 250MHz oscillator when locked to the 40MHz oscillator because any close in phase noise in the 40MHz reference will get multiplied by 20*logN (=16dB?) at the 250MHz oscillator.

[John_ITIC]

Thanks. I tried looking at the 250 MHz clock but it has spread spectrum enabled so looks terrible (picture attached)! I will have to remove the chip, rework the BGA site (add a 5 mil trace to strap differently, fix up solder mask, reball the IC, reflow it back) to try without SSC.

My scope does have all the advanced jitter measurements options. I will read in on this too to see if I can use it to get finer details. One thing I'm unsure about is a spec in the PHY datasheet that says that if an external oscillator it used (optional via pin strap) it should have the below specs. It seems reasonable that, when using the internal oscillator (with external XTAL), the specs should be similar.

I have attached screenshots of the frequency and period jitter of the 40 MHz oscillator. This is after the 1.8V switched power supply was replaced by a quiet external P/S. The PHY also has a 1.1V switched voltage rail but the SA only showed a 5uV spur at the switching frequency so I doubt any phase noise is due to the 1.1V switching noise. I could try to put in an additional 1.1V external P/S...

Edit: One thing that confuses me is that the below specs state "Reference clock jitter 50 psec (absolute p-p)". Peak-peak jitter includes random jitter, which by nature is unbounded. Therefore, it seems impossible to meet a 50ps TJ requirement. My scope (see attached image) shows the total p-p jitter to be 272 ps. The Std Dev. value is under 50ps (33ps) so perhaps should be used? I find the terminology and various measures confusing. How to interpret the below oscillator specs and compare with what I see on my scope?

5.2 Clock Source Requirements
5.2.1 Clock Source Selection Guide
Reference clock jitter is an important parameter. Jitter on the reference clock will degrade both the
transmit eye and receiver jitter tolerance no matter how clean the rest of the PLL is, thereby impairing
system performance. Additionally, a particularly jittery reference clock may interfere with PLL lock
detection mechanism, forcing the Lock Detector to issue an Unlock signal. A good quality, low jitter
reference clock is required to achieve compliance with supported USB3.0 standards. For example,
USB3.0 specification requires the random jitter (RJ) component of either RX or TX to be 2.42 ps (random
phase jitter calculated after applying jitter transfer function - JTF). As the PLL typically has a number of
additional jitter components, the Reference Clock jitter must be considerably below the overall jitter
budget.

5.2.2 Oscillator
If an external clock source is used, XI should be tied to the clock source and XO should be left floating.
Table 5-1. Oscillator Specification
PARAMETER MIN TYP MAX UNITS CONDITION
Frequency tolerance ±50 ppm Operational temperature
Frequency stability ±50 ppm 1 year aging
Rise/Fall time 6 nsec 20% - 80%
Reference clock RJ with JTF (1 sigma)(1) (2) 0.8 psec
(1) Sigma value assuming Gaussian distribution
(2) After application of JTF

Copyright © 2010–2012, Texas Instruments Incorporated DESIGN GUIDELINES 29
Submit Documentation Feedback
Product Folder Link(s): TUSB1310A
TUSB1310A
SLLSE32E –NOVEMBER 2010–REVISED JULY 2012 www.ti.com

Table 5-1. Oscillator Specification (continued)
PARAMETER MIN TYP MAX UNITS CONDITION
Reference clock TJ with JTF (total p-p)(2) (3) 25 psec
Reference clock jitter 50 psec (absolute p-p)(4)
(3) Calculated as 14.1 x RJ + DJ
(4) Absolute phase jitter (p-p)

5.2.3 Crystal
Either a 20-MHz, 25-MHz, 30-MHz, or 40-MHz crystal can be selected. A parallel, 20-pF load crystal
should be used if a crystal source is used.
Table 5-2. Crystal Specification
PARAMETER MIN TYP MAX UNITS CONDITION
Frequency tolerance ±50 ppm Operational temperature
Frequency stability ±50 ppm 1 year aging
Load capacitance 12 20 24 pF
30 DESIGN GUIDELINES Copyright © 2010–2012, Texas Instruments Incorporated
Submit Documentation

[nctnico]

Does USB3.0 allow spread spectrum clocking?
In the past I had a problem with a USB2.0 PHY which got a clock which wasn't stable (too much frequency wander) enough so I'd look in that direction first.

[bson]

The 40MHz reference clock may itself be a red herring; it could still have a significant amount of coupled RF noise riding on it that causes jitter in the first-order PLL it drives.  You might not see this noise when it drives a 50ohm load like the SA since its source (coupling) is much higher impedance.  What if you add something like a 330R load-side termination near the PLL input pin for the reference clock?

[John_ITIC]

Yes, USB 3.0 supports SSC as do all newer serial protocols such as SATA and SAS. I suppose wander would show up on the spectrum analyzer similar to spread spectrum clocking?

I have difficulties adding resistors to the oscillator but since this is per IC vendor's design spec it seems reasonable that the XTAL and load caps should be sufficient for the chip to work.

I today received my HP 53131A frequency counter. Both PHY oscillators are too high by 28 vs. 34 PPM but would be within spec since the PHY datasheet states the crystal should have +/- 50 PPM frequency accuracy/stability. I'm still somewhat disappointed that the 40MHz oscillator clock is off by 1,365 Hz per the attached picture. Would a +/- 10 PPM version of the crystal tighten this up? I'll order a few to try this out.

[nctnico]

Can you disable the spread spectrum clocking just to try? It seems unlogical to me to hunt for a small offset in a base clock (40MHz) while the resulting clock moves several MHz continuously.

[John_ITIC]

Can you disable the spread spectrum clocking just to try? It seems unlogical to me to hunt for a small offset in a base clock (40MHz) while the resulting clock moves several MHz continuously.

Yes, but it is not easy. I have to remove the BGA chip, rework one pad to connect somewhere else, re-ball the IC and reflow again. I may go down that route if all else fails.

Note that I have SSC enabled on both PHYs and one PHY consistently can lock onto the USB 3.0 data. The other one (which has the slightly higher frequency) cannot. If SSC was to blame, I would assume non of the PHYs could data lock. I usually look for differences and the only thing I can see here is the slightly higher frequency of the oscillator of the non-working PHY.