New Rigol DS1054Z oscilloscope

[Divine_Evil]

HEEEEEEEEEEEEEEEEEELP!


Disclamer: I tried posting this about 30 minutes ago, but for some reason my post is not showing up.

Anyway I am having major issues after I updated to the newest firmware (00.04.04.00.07)

After doing a self-cal as mentioned in the upgrading procedures. Whatever signal I try to measure with the scope I get a 50Hz "over 100V" sine wave... Which looks a lot like mains.



In the picture above CH1 is connected to a 40MHz clock signal on the board I am debugging. And I am pinching CH2 probe against my thumb...

I tried multiple self-cals, downgrading to  00.04.03.01.05 didn't go through and reseting to factory settings. Non of it worked... Any ideas?

[evava]

Have you tried cal signal of your scope?
Can you give us picture of that cal signal?

[Divine_Evil]

Have you tried cal signal of your scope?
Can you give us picture of that cal signal?

Fixed it... Turns out it wasn't anything with the scope... or firmware.

I also changed the power extension cord (it's a power splitter as well). I guess it wasn't  making good connection and/or some hell of a noise was picked up from somewhere... Just replaced the power splitter with the old one, and voila. Everything is back to normal!

P.S. After that I remembered Dave made a video about such noise over the powerline...

[heatbreak]

In the digital realm and oscilloscope's "bandwidth" has very little relation to the frequency of the signal you're looking at.

eg. Imagine you have a single rising edge on screen - that's a 0Hz signal.

On a 100MHz 'scope the trace will rise in half the time that it takes on a 50Mhz 'scope and that's a big difference.

We're only talking about 2x speed improvement so 5 nSec vs 2.5 nSec?  All of the timing specs I've worked with (in embedded software) are in units of uSecs.  And I do not design nor implement my software to have tolerances in the tenths of nSecs.  So an extra 2.5 nSecs buys me nothing.  I can see that you probably would want the best speed possible if you're designing a microcontroller system from scratch.  But if you're in that situation, you'd probably want something much higher than 100 MHz.  For me (and probably most hobbyist) whom will most likely only use the scope to troubleshoot serial buses, GPIO controlled devices, then the difference between a 50 MHz and a 100 MHz is minimal.

If you're doing digital work and basing a purchasing decision on that rather than bandwidth and number of channels then you're doing it wrong.

Me? I say 4 channels/100Mhz/Serial decoders is a minimum requirement for digital/microcontroller work.

I really don't care what brand you buy, but: Make a shortlist based on that specification then compare prices. Now consider if moving the trace up and down a bit faster is worth that much money.

Do a search for "Rigol 1054z problem" on youtube and watch NatureAndTech's video and see if you'd want to live with that kind of lag.  I don't feel serial decoder is a must have because after all, all serial protocols are asychronous so once you capture one transaction waveform manually and examined and debugged it to make it work, then all subsequent transactions will work.  What's the point of having a decoder to tell me what my data is?  It's nice to have, but not really needed at lease at the software development role.  Plus having a serial decoder won't remove the requirement of manually inspecting the transaction waveforms especially if you're doing bit banging.

My list looks like this
1. 4 channels
2. 50 MHz minimum.  100 MHz ideal.
3. Deep capture memory depth (none of that Tek 12.5K point crap)
4. Robust.

[Sredni]

Fixed it... Turns out it wasn't anything with the scope... or firmware.

I also changed the power extension cord (it's a power splitter as well). I guess it wasn't  making good connection and/or some hell of a noise was picked up from somewhere...

What you saw is usually associated with missing ground in the power cord.
I would not call 100+ volts "noise" :-)

[Assafl]

I watched NatureAndTech's rant video and have to agree with all of his findings - but not his conclusion:
* The main issue is lag. Lag is still there - but they have changed it so the trace markers reposition much quicker after the knob is rotated (almost instant) - before the trace gets moved (which still takes time). So you can eye the move pretty well.
* I use Tek probes. They are better than the Rigol ones.
* I replaced the fan with a quieter one.
* The rotary knob irks me less than others. Can be a usage pattern difference, a mental threshold issue, or that once I know it can be solved (replace the encoder) - I fret it less.
* IMHO the Teal and Blue are vastly different. Perhaps a green color blindness makes them look alike?
* I have other Irks - like the slow saving of screenshots to USB memory (I love to annotate debugging or problem resolution sessions, and screenshot a lot - and that drives me nuts sometimes).

The conclusion I disagree with - "completely useless???" - perhaps "completely (or very) annoying" would be more apt.

Kind of funny he also uses it in other videos and here: <iframe width="854" height="480" src="https://www.youtube.com/embed/aiIr3j_EyLY?list=PL5zLSmFo0HELyDnrxbC2tEjSeAl0KaYM0" frameborder="0" allowfullscreen></iframe>

I guess that as a tool - it packs a lot of capability - but the price hit is with efficiency. It is not a very efficient to use scope. Were I to use it for work - depending on the type of work - of course - it may not be up to the job. But as a home lab having the extra features at an affordable price makes sense.

There are many users of this scope that don't feel the same about it as NatureAndTech. And some that do. They might all be wrong or not.
It really doesn't matter. Pick the one you like and be happy!

[tggzzz]

In the digital realm and oscilloscope's "bandwidth" has very little relation to the frequency of the signal you're looking at.

eg. Imagine you have a single rising edge on screen - that's a 0Hz signal.

On a 100MHz 'scope the trace will rise in half the time that it takes on a 50Mhz 'scope and that's a big difference.

We're only talking about 2x speed improvement so 5 nSec vs 2.5 nSec?  All of the timing specs I've worked with (in embedded software) are in units of uSecs.  And I do not design nor implement my software to have tolerances in the tenths of nSecs.  So an extra 2.5 nSecs buys me nothing.  I can see that you probably would want the best speed possible if you're designing a microcontroller system from scratch.  But if you're in that situation, you'd probably want something much higher than 100 MHz.  For me (and probably most hobbyist) whom will most likely only use the scope to troubleshoot serial buses, GPIO controlled devices, then the difference between a 50 MHz and a 100 MHz is minimal.

Spoken like a true softie

100MHz was barely adequate for digital logic in the 1970s, and speeds have increased a little since then. Even jellybean logic parts have setup and hold times of ~1ns and propagation times of ~2ns.

More important at any speed is the "signal integrity", i.e. does the analogue signal stay within the limits that will enable the receiver(s) to correctly interpret it as a digital signal. The success/failure of that is dependent on external noise, crosstalk, layout and decoupling, and the transition time. The period is completely unimportant.

Sanity check: what effect will a 6" wire have on a signal?

Summary: if you have well behaved signals the you might not need a 100MHz scope. But if something isn't working, how will you distinguish between a logic fault and a signal integrity problem?

[rstofer]

In the digital realm and oscilloscope's "bandwidth" has very little relation to the frequency of the signal you're looking at.

eg. Imagine you have a single rising edge on screen - that's a 0Hz signal.

On a 100MHz 'scope the trace will rise in half the time that it takes on a 50Mhz 'scope and that's a big difference.

We're only talking about 2x speed improvement so 5 nSec vs 2.5 nSec?  All of the timing specs I've worked with (in embedded software) are in units of uSecs.  And I do not design nor implement my software to have tolerances in the tenths of nSecs.  So an extra 2.5 nSecs buys me nothing.  I can see that you probably would want the best speed possible if you're designing a microcontroller system from scratch.  But if you're in that situation, you'd probably want something much higher than 100 MHz.  For me (and probably most hobbyist) whom will most likely only use the scope to troubleshoot serial buses, GPIO controlled devices, then the difference between a 50 MHz and a 100 MHz is minimal.

If you're doing digital work and basing a purchasing decision on that rather than bandwidth and number of channels then you're doing it wrong.

Me? I say 4 channels/100Mhz/Serial decoders is a minimum requirement for digital/microcontroller work.

I really don't care what brand you buy, but: Make a shortlist based on that specification then compare prices. Now consider if moving the trace up and down a bit faster is worth that much money.

Do a search for "Rigol 1054z problem" on youtube and watch NatureAndTech's video and see if you'd want to live with that kind of lag.  I don't feel serial decoder is a must have because after all, all serial protocols are asychronous so once you capture one transaction waveform manually and examined and debugged it to make it work, then all subsequent transactions will work.  What's the point of having a decoder to tell me what my data is?  It's nice to have, but not really needed at lease at the software development role.  Plus having a serial decoder won't remove the requirement of manually inspecting the transaction waveforms especially if you're doing bit banging.

My list looks like this
1. 4 channels
2. 50 MHz minimum.  100 MHz ideal.
3. Deep capture memory depth (none of that Tek 12.5K point crap)
4. Robust.

You should realize that a 50 MHz square wave running into a 50 MHz scope will display as a sine wave.  There is just not enough bandwidth to allow the 3rd, 5th, 7th ... harmonics.  Even a 25 MHz square wave will look odd because there isn't enough room for the odd harmonics.

The point is, you may or may not be able to see exactly what a signal looks like or where it is switching.  This gets particularly important with clocked protocols like SPI.

I like the SPI decoding on the 1054Z.  I know it is only decoding what is on the screen but with a 1 MHz clock, I can get 12 bytes across the screen with perfect decoding.  No, I can't decode the Library of Congress from the buffer.  I have printf() for that kind of nonsense.  Once I have a set of functions that correctly transfers data, I will probably not be using the scope on those signals again.  But I need to see the setup time on CS', I need to understand the relationship between MOSI & MISO edges versus CLK.  In fact, I want to use the cursor to measure the setup and hold times just to be certain I am in spec.  Partly because 1 MHz is terribly slow and I'll eventually want to kick it up to 10 MHz or higher.

I bought my 1054 SPECIFICALLY for the 4 channels.  I actually gave up bandwidth over my Tektronix 485 which can do 350 MHz.  Four channel decoding of SPI is EXACTLY why I bought the thing.  I am working with the W5500 TCP/IP chip and everything is transferred over SPI.  Faster is better than slower...

[heatbreak]

Spoken like a true softie

100MHz was barely adequate for digital logic in the 1970s, and speeds have increased a little since then. Even jellybean logic parts have setup and hold times of ~1ns and propagation times of ~2ns.

Precisely my point.  If you're gonna do hardware design, you probably want something better than 100 MHz.  What I'll mostly do is to interface say something like a Raspberry PI, Arduino, Beagle Board or what not to external peripherals like ADCs, DACs, cameras, LCDs, LEDs, etc..  I won't be designing my own Raspberry PI nor any of the external peripherals.  So we're talking about serial bus and GPIO debugging mostly.  Max SPI speed is 4 MHz, UART you'll be mostly be under 1 MHz, hack even DVD video is only like 9 Mbps.  So a 50 MHz is fully capable of debugging all these things over a serial bus.

Don't get me wrong, I'd delighted to get a 100 MHz scope, but if I have to choose between a slugish/buggy 100 MHz and a fluid/robust 50 MHz, I think I will choose the 50 MHz.

[heatbreak]

You should realize that a 50 MHz square wave running into a 50 MHz scope will display as a sine wave.  There is just not enough bandwidth to allow the 3rd, 5th, 7th ... harmonics.  Even a 25 MHz square wave will look odd because there isn't enough room for the odd harmonics.

The point is, you may or may not be able to see exactly what a signal looks like or where it is switching.  This gets particularly important with clocked protocols like SPI.

I like the SPI decoding on the 1054Z.  I know it is only decoding what is on the screen but with a 1 MHz clock, I can get 12 bytes across the screen with perfect decoding.  No, I can't decode the Library of Congress from the buffer.  I have printf() for that kind of nonsense.  Once I have a set of functions that correctly transfers data, I will probably not be using the scope on those signals again.  But I need to see the setup time on CS', I need to understand the relationship between MOSI & MISO edges versus CLK.  In fact, I want to use the cursor to measure the setup and hold times just to be certain I am in spec.  Partly because 1 MHz is terribly slow and I'll eventually want to kick it up to 10 MHz or higher.

I bought my 1054 SPECIFICALLY for the 4 channels.  I actually gave up bandwidth over my Tektronix 485 which can do 350 MHz.  Four channel decoding of SPI is EXACTLY why I bought the thing.  I am working with the W5500 TCP/IP chip and everything is transferred over SPI.  Faster is better than slower...

I don't remember when was the last time I had to look at anything higher than 4 MHz.  But yeah if you're gonna be interface to something like the W5500 at full Ethernet speed, then you're probably gonna need something higher than 100 MHz.  But you can still use your 50 MHz scope.  Just write the code to work at 10 Mhz, then when you're ready, just cut all the setup time and clock by 8 and you've got 80 MHz.  It's not ideal, but should be workable.  But if I need ethernet in my project, then I'll probably start with a Raspberry PI and work with Linux.  But at Ethernet speed, even 100 MHz is not enough.

I think you have already agreed with my statement that the serial decoder not much of use when you said "In fact, I want to use the cursor to measure the setup and hold times just to be certain I am in spec.".  If you have to measure the waveform with the cursor, then why do you still need to use the decoder?  I have worked with quite a few people over the years and with one exception one time when some guy brought in an expensive logic analyzer with build in SPI decoder and we played with it a little like a toy, I have not see a single person use any serial decoder ever.

[Karel]

* I have other Irks - like the slow saving of screenshots to USB memory (I love to annotate debugging or problem resolution sessions, and screenshot a lot - and that drives me nuts sometimes).

Why don't you connect the scope directly to your pc instead of using a usb-pen?
That works much faster. Screenshots are saved on the pc almost instantly.
No need to hassle with a usb-pen.

Were I to use it for work - depending on the type of work - of course - it may not be up to the job. But as a home lab having the extra features at an affordable price makes sense.

I can't imagine a professional who uses a scope in this priceclass at work.
Imho, this is a scope for hobbyists for use at home.
Nothing wrong with that.

[tggzzz]

Spoken like a true softie

100MHz was barely adequate for digital logic in the 1970s, and speeds have increased a little since then. Even jellybean logic parts have setup and hold times of ~1ns and propagation times of ~2ns.

Precisely my point.  If you're gonna do hardware design, you probably want something better than 100 MHz.  What I'll mostly do is to interface say something like a Raspberry PI, Arduino, Beagle Board or what not to external peripherals like ADCs, DACs, cameras, LCDs, LEDs, etc..  I won't be designing my own Raspberry PI nor any of the external peripherals.  So we're talking about serial bus and GPIO debugging mostly.  Max SPI speed is 4 MHz, UART you'll be mostly be under 1 MHz, hack even DVD video is only like 9 Mbps.  So a 50 MHz is fully capable of debugging all these things over a serial bus.

Don't get me wrong, I'd delighted to get a 100 MHz scope, but if I have to choose between a slugish/buggy 100 MHz and a fluid/robust 50 MHz, I think I will choose the 50 MHz.

If you wish to continue to snip and ignore points about signal integrity, then that's your choice.

Quoting a digital signal speed in MHz "Max SPI speed is 4 MHz" is revealing, and indicative.

There is a lot of difference between something capable of basic visualisation of UART/SPI/GPIO levels (a 10MHz scope would suffice), and a 50/100NHz scope.

[Fungus]

I don't remember when was the last time I had to look at anything higher than 4 MHz.

Equating signal bitrate to oscilloscope bandwidth after reading the last couple of pages tells us something.

Just write the code to work at 10 Mhz, then when you're ready, just cut all the setup time and clock by 8 and you've got 80 MHz.

Also: Believing that digital signals aren't affected by the pieces of wire they have to travel down...they just arrive, right? If the code is correct, that's all that matters. 

 

[tggzzz]

I don't remember when was the last time I had to look at anything higher than 4 MHz.

Equating signal bitrate to oscilloscope bandwidth after reading the last couple of pages tells us something.

Just write the code to work at 10 Mhz, then when you're ready, just cut all the setup time and clock by 8 and you've got 80 MHz.

Also: Believing that digital signals aren't affected by the pieces of wire they have to travel down...they just arrive, right? If the code is correct, that's all that matters. 

 

Just so.

Except I'd add that the digital signals are only found in femtoamp and photon counting systemsl  other examples welcomed Apart from that, nature (and electric signals) is analogue.

[pascal_sweden]

You could use a "microprocessor brake" to slowdown your system during debugging phase.

Similar as what was possible with the "Amiga Bremse" from Rex Datentechnik to slow down the Motorola 68000 microprocessor in the Commodore Amiga 500 computer
http://www.bigbookofamigahardware.com/bboah/product.aspx?id=1704

I actually have this product, but have never found the time up to now to test it on my Amiga 500

[borjam]

Also: Believing that digital signals aren't affected by the pieces of wire they have to travel down...they just arrive, right? If the code is correct, that's all that matters. 

Depends on what you are debugging. If you are paying attention to software maybe you don't need to look into signal integrity unless you see something really odd.

[tggzzz]

You could use a "microprocessor brake" to slowdown your system during debugging phase.

Similar as what was possible with the "Amiga Bremse" from Rex Datentechnik to slow down the Motorola 68000 microprocessor in the Commodore Amiga 500 computer
http://www.bigbookofamigahardware.com/bboah/product.aspx?id=1704

I actually have this product, but have never found the time up to now to test it on my Amiga 500

I have no idea whether such systems work, but they are irrelevant to the prime use case where scopes are necessary: signal integrity. Why? Because they cannot change the source of many intermittent and hard to find problems, the edge rate.

After you have used a scope to ensure signal integrity, you might as well use a logic analyser to look at the digital signals. Note that logic analyers are much cheaper, have more channels, better triggering and filtering, and are faster than "equivalent" scopes.

Use the right tool for the job at hand.

[Fungus]

Depends on what you are debugging. If you are paying attention to software maybe you don't need to look into signal integrity unless you see something really odd.

How will you figure out the right pullups for your I2C bus just by paying attention to the software?

If your pullups are very borderline then a device might work on the bench but fail intermittently when you move it to production.

[heatbreak]

If you wish to continue to snip and ignore points about signal integrity, then that's your choice.

Quoting a digital signal speed in MHz "Max SPI speed is 4 MHz" is revealing, and indicative.

There is a lot of difference between something capable of basic visualisation of UART/SPI/GPIO levels (a 10MHz scope would suffice), and a 50/100NHz scope.

I will mostly use off the shelf modules, ie Arduinio and its shields etc, so signal integrity should not be an issue.  But even a 50 MHz scope is capable of troubleshooting "signal integrity" for a 10 MHz signal no?  I don't know how a 100 Mhz one is much better than a 50 MHz one.  Slightly better, but you'll still leave wanting more.

Ok.  So you have all convince me to maybe spend more $ to get a 100 or even a 200 MHz one.

[canibalimao]

If you wish to continue to snip and ignore points about signal integrity, then that's your choice.

Quoting a digital signal speed in MHz "Max SPI speed is 4 MHz" is revealing, and indicative.

There is a lot of difference between something capable of basic visualisation of UART/SPI/GPIO levels (a 10MHz scope would suffice), and a 50/100NHz scope.

I will mostly use off the shelf modules, ie Arduinio and its shields etc, so signal integrity should not be an issue.  But even a 50 MHz scope is capable of troubleshooting "signal integrity" for a 10 MHz signal no?  I don't know how a 100 Mhz one is much better than a 50 MHz one.  Slightly better, but you'll still leave wanting more.

Ok.  So you have all convince me, maybe I spend more $ to get a 100 or even a 200 MHz one.

I'm not an expert, far from that, but I'll give you my 2 cents also.

I'm finishing my EE course and I've allways used 50 or 75MHz scopes. Never needed more than that. Now I'm leaving University, so I decided to buy a scope to have at home to use in my arduino-like projects. I've chosen this DS1054Z and I still haven't found any issue with the "very limiting" 50MHz bandwidth.
But, even if I find that I need 100MHz, where's the problem? I can always hack the firmware and unlock that feature...

For the ~400€ I paid for it, I can't ask more and I think that I didn't need to spend more than this.

[Fungus]

I will mostly use off the shelf modules, ie Arduinio and its shields etc, so signal integrity should not be an issue.  But even a 50 MHz scope is capable of troubleshooting "signal integrity" for a 10 MHz signal no?

More or less.

I don't know how a 100 Mhz one is much better than a 50 MHz one.

Two words: "Square edges".

Square waves, single rising edges, anything with a square corner is made up of an infinite series of frequency components.

A 10Mhz square wave shown on a 50Mhz scope will only have the first and second harmonics intact, the third will be attenuated by 3dB and the fourth harmonic will be almost gone.



Only two-and-a-bit harmonics is a serious distortion of the input signal. Not square at all. A 50Mhz 'scope simply cannot display a 10MHz square wave properly even with perfect, inductance-free wires and connections (which don't exist).


On a 100Mhz 'scope you'll have the third, fourth and fifth harmonics intact, plus some of the sixth. That's not a small difference from a 50MHz 'scope, it's huge.

PS: And in reality a hacked DS1054Z has about 130MHz bandwidth (measured) so you'll have all of the sixth harmonic and a lot of the seventh. And that's why we like them, slightly sluggish vertical movement notwithstanding. $400 for that much bandwidth and four channels is something that can't be ignored.

As I said earlier: Find that performance from other manufacturers and compare the price. If slightly faster controls is worth that much to you, go ahead...

We don't put up with the DS1054Z's idiosyncrasies because we're ignorant, unrefined clods who don't appreciate the finer things in life like you do. We put up with them because we can have a decent 'scope plus a whole lot of other toys besides - $600-$800 buys a lot of other stuff.

[rstofer]

I think you have already agreed with my statement that the serial decoder not much of use when you said "In fact, I want to use the cursor to measure the setup and hold times just to be certain I am in spec.".  If you have to measure the waveform with the cursor, then why do you still need to use the decoder?  I have worked with quite a few people over the years and with one exception one time when some guy brought in an expensive logic analyzer with build in SPI decoder and we played with it a little like a toy, I have not see a single person use any serial decoder ever.

Dropping CS' is a separate line of C that occurs before spi.write() because the datafield can be arbitrarily long.  Same with raising CS'.  There's not much chance I can violate the setup and hold times using C but it's good to measure anyway.  It sometimes happens that the SPI gadget is still shifting when CS' is raised.  Since I didn't write the mbed SPI library, I don't know whether they waited for transmission of the last byte to be complete or returned after the last byte was stuffed in the shift register.

I didn't use the cursors to check the SCK MOSI or MISO, I just shifted the traces up over the SCK so I could check the edges and verify I was in mode 0.

Another gotcha with C is using bitfields.  They aren't guaranteed to be in any particular alignment within an unsigned char and that can make a HUGE difference (easily discovered by decoding the SPI string) when writing the 3rd byte of the W5500 command.  I had to scrap that idea.  But I WANT bit fields!  So, I'm looking at coding the thing in Ada.

But, you're right, for your needs the more responsive controls are the deciding factor.  I simply don't care about the HMI.  I don't spend nearly as much time twiddling the knobs as I do analyzing the screen display.  And I didn't want to spend much money on a digital scope...

[heatbreak]

Two words: "Square edges".

Square waves, single rising edges, anything with a square corner is made up of an infinite series of frequency components.

A 10Mhz square wave shown on a 50Mhz scope will only have the first and second harmonics intact, the third will be attenuated by 3dB and the fourth harmonic will be almost gone.

Only two-and-a-bit harmonics is a serious distortion of the input signal. Not square at all. A 50Mhz 'scope simply cannot display a 10MHz square wave properly even with perfect, inductance-free wires and connections (which don't exist).

On a 100Mhz 'scope you'll have the third, fourth and fifth harmonics intact, plus some of the sixth. That's not a small difference from a 50MHz 'scope, it's huge.

PS: And in reality a hacked DS1054Z has about 130MHz bandwidth (measured) so you'll have all of the sixth harmonic and a lot of the seventh. And that's why we like them, slightly sluggish vertical movement notwithstanding. $400 for that much bandwidth and four channels is something that can't be ignored.

As I said earlier: Find that performance from other manufacturers and compare the price. If slightly faster controls is worth that much to you, go ahead...

We don't put up with the DS1054Z's idiosyncrasies because we're ignorant, unrefined clods who don't appreciate the finer things in life like you do. We put up with them because we can have a decent 'scope plus a whole lot of other toys besides - $600-$800 buys a lot of other stuff.

According to Agilent http://cp.literature.agilent.com/litweb/pdf/5989-5733EN.pdf, the rule of thumb is f(bw) = 5 * f(clk) to get the 5th harmonic.  So a 50 Mhz is fully capable of capturing the 5th harmonic of a 10 MHz signal.  A 50 Mhz scope is also capable of capturing a rise time of 38 nSecs with 3% error or 26 nSecs with 10% error.  This is fully capable of measuring most, if not all, setup/clk time of a 10 MHz signal for home use.

For commercial use, then I def want something even higher than 100 MHz.

[Fungus]

According to Agilent the rule of thumb is f(bw) = 5 * f(clk) to get the 5th harmonic.

Nope. 5 * f(clk) is only the second harmonic.

f(clk) is the base frequency

3*f(clk) is the first harmonic

5*f(clk) is the second harmonic

7*f(clk) is the third harmonic

etc.

[heatbreak]

Nope. 5 * f(clk) is only the second harmonic.

f(clk) is the base frequency

3*f(clk) is the first harmonic

5*f(clk) is the second harmonic

7*f(clk) is the third harmonic

etc.

So you're saying the Agilent doc is wrong?