EEVblog #683 - Rigol DS1000Z & DS2000 Oscilloscope Jitter Problems

[nuno]

Or is there a special settings that is needed in order to reproduce the jitter?

Some reports seem to indicate it is rise-time related. Mine was sub 20ns I think.

I don't see the 5us issue (signal is the same at -5us, 5us or 0us) in a (cal certificate issued 13 May 2014) DS1104Z-S (00.04.00), using the internal siggen's square wave (15MHz), which has 10ns raise/fall times (as measured by the scope). Tried hold off from 16ns to >200ns. Same results for sine wave @ 20MHz. The internal siggen only does 5Vpp; what is the amplitude of your test signal? Seems you have the channel on 10V/div but the wave takes lots of divs.

[rs20]

I know there's been little to no discussion of the dual-slope triggering "bug" mentioned in the video, but I just wanted to point out that this is not a bug at all, rather an artefact caused by trigger holdoff working correctly.

So I put together a quick little video explaining how trigger holdoff causes the observed behaviour -- and I also show how holdoff (even the default, minimum setting) could cause real confusion even if you're using normal edge triggering. This is not Rigol specific, this applies to any scope (with a trigger). With the DS2202 @ factory default settings, these problems could potentially (in admittedly somewhat contrived circumstances) bite you at frequencies as low as 5 MHz.



Why do the DS1000Z and DS2202 behave differently in the EEVBlog video? Because the default(=minimum) holdoff of the DS1000Z, 16ns, is less than the 100ns of the DS2202. 16ns fits inside a 20 MHz pulse (25 ns), 100ns does not. Neither is right nor wrong, and both can be configured to behave as desired.

[tom66]

Hmm, isn't this just a characteristic of any delayed trigger on any oscilloscope?

I had an old HP 54501A. 10MSa/s ADC. As the trigger delay increased, jitter increased. It made anything more than about 1ms completely unusable on continuous trigger mode.

This makes sense, as the distance from the trigger point increases, the jitter becomes a sum of all previous samples. At 1GSa/s, 5 microseconds is 5,000 samples. For a jitter of ~5ns, the per-sample jitter would have to be ~1ps.

To me, that sounds completely reasonable...

Does my reasoning sound right?

[siggi]

Here's an idea.
The AC trigger jitter could come about if the averaged (DC level) of the input signal is discarded after each acquisition, as it well might be in a digitial trigger system. In this case, the DC level would be offset slightly on each acquisition, depending on how the aquisition start time "beats" against the signal being measured.

This can probably be measured and quantified by modulating the duty cycle of the signal being measured, as the frequency of the jitter ought to go down by the duty cycle - the odds of starting a capture off on the wrong foot decreases with the duty cycle. Modulating the duty cycle of a gated signal should work too, and by setting the gate frequency and/or scope holdoff, it should be possible to set up such that the jitter dissappears by providing a DC signal for the scope to measure at the start of each acquisition.

If this is in fact the issue, then the fix ought to be relatively straightforward software fix - just a matter of keeping the last aqcuisition's DC level around for the next cycle.

[rs20]

Does my reasoning sound right?

Some jitter is theoretically expected, but nowhere near as bad as shown in Dave's video. Also, it's not standard jitter, because the problem is present at 5, 15, and 25 us, but not at 0, 10, 20, etc. This doesn't fit your description at all.

But more to the point, it's just the sheer amount of jitter that is completely unacceptable, and way worse the comparable scopes or what should be easily achievable.

Here's an idea.
The AC trigger jitter could come about if the averaged (DC level) of the input signal is discarded after each acquisition, as it well might be in a digitial trigger system. In this case, the DC level would be offset slightly on each acquisition, depending on how the aquisition start time "beats" against the signal being measured.

A very plausible idea. I like it 

[c4757p]

Yes, I believe it does. This whole thing seems blown a bit out of proportion to me... Jitter is always pretty bad when you go off-trigger.

Consider: yes, it looks worse on the DS1000Z/DS2000, but these scopes also have a significantly better graded-intensity display, requiring them to capture significantly more samples and combine them into a screenful. That's naturally going to appear to amplify the jitter.

Sounds reasonable to me.

Here's an idea.
The AC trigger jitter could come about if the averaged (DC level) of the input signal is discarded after each acquisition, as it well might be in a digitial trigger system. In this case, the DC level would be offset slightly on each acquisition, depending on how the aquisition start time "beats" against the signal being measured.

Though, that also sounds plausible. Hmm... the fact that the 10us period seems to remain constant at different signal frequencies might suggest that the level is being averaged over a fixed number of samples rather than a single cycle.

[kwass]

I performed a self-cal yesterday, makes no difference.

I had also performed a self-cal some time before that (within 24 hours) as part of my review video.

I just did a self-cal on my 1054z and also found no change to the jitter problem.  The jitter also increases gradually as the delay is moved from 0 to 5us then decreases from 5us to 10us, etc..   It's linear with about 1.5ns of jitter per 1us of delay.

Firmware: 00.04.01.SP2
Board: 0.1.1

[marmad]

Major problem discovered 2 years after one of the most popular scope (DS2XXX) was released.
Apparently, nobody uses AC coupling trigger mode these days 

We've been talking about problems with AC-coupling the trigger over at the DS2000 review thread for over 2 years now (check out the bug list). Few of us original owners use that setting because of this - and I've never found a single instance in my use of the DSO in that time where I needed it.

[siggi]

Here's an idea.
The AC trigger jitter could come about if the averaged (DC level) of the input signal is discarded after each acquisition, as it well might be in a digitial trigger system. In this case, the DC level would be offset slightly on each acquisition, depending on how the aquisition start time "beats" against the signal being measured.

Though, that also sounds plausible. Hmm... the fact that the 10us period seems to remain constant at different signal frequencies might suggest that the level is being averaged over a fixed number of samples rather than a single cycle.

That's an interesting thought, very plausible, and can be tested by sweeping the frequency of the input signal.
If this is the case,then  whenever the input signal is an integer multiple of the "settling" time, the jitter should vanish. It should then be possible to multiply the input signal by any integral value, without causing the jitter to re-appear.

[TMM]

Yes, I believe it does. This whole thing seems blown a bit out of proportion to me... Jitter is always pretty bad when you go off-trigger.

The thing is that jitter on all of the other scopes in Dave's video were at least an order of magnitude better than the 1000Z series, even ye-olde DS1052E. What makes it worse is that Rigol are yet to acknowledge that a problem exists and the problem seems to be subject to variation from unit to unit. If some people have no jitter, i have 8ns and someone else has 20ns, what's the chance that there are units out there that do 50ns? 100ns? There's not much point having a 100MHz scope if a 100MHz signal turns into a complete blur (or has a significant phase offset from the actual signal when you single shot) at every multiple of 5us from the trigger point.

It's not bad enough on my unit that i would bother seeking a replacement, but it is bad enough that Rigol need to acknowledge that there is a problem and work out what is causing it so they can either fix it or ensure that it is kept to a manageable level in future units.

I performed a self-cal yesterday, makes no difference.

I had also performed a self-cal some time before that (within 24 hours) as part of my review video.

I just did a self-cal on my 1054z and also found no change to the jitter problem.  The jitter increases with increasing input frequency and is not too bad below 1MHz -- unnoticeable at 100KHz.  The jitter also increases gradually as the delay is moved from 0 to 5us then decreases from 5us to 10us, etc..    (I used an Siglent SDG1025 for my testing.)

Firmware: 00.04.01.SP2
Board: 0.1.1

Are you sure that the jitter is decreased with frequency, or simply that it is harder to observe nanosecond jitter on signals that have a very low slew rate? See my post - Reply #168. Obviously it is hard to observe 10ns of jitter on a 100KHz sine wave because when you adjust the horizontal offset to 5us and zoom in to 5ns/division the signal is almost a horizontal line. Add 10ns of jitter to that and it still looks like a thin horizontal line. Also it is almost impossible to trigger with nanosecond accuracy on a signal with such a low slew rate, due to vertical noise.

If i set my function generator to 100KHz square wave (fast rising/falling edges), adjust the horizontal offset to 5us and zoom in to 5ns/div i get a sharp falling edge that moves left and right in a sine fashion at about a 1Hz repetition rate. This indicates to me that the jitter is not random and is caused by a clock frequency modulation effect around 100KHz give or take 1Hz, or some multiple of 100KHz.

Edit: the modulation frequency must be 100KHz because if i set my signal to 200KHz i see two rising edges moving with opposite phase, and at 300KHz i get 3 falling edges moving 120deg out of phase with each other, 400KHz = 4 edges, and so forth.
At 99,999.3Hz there is no observed jitter as falling edge occurs in the same place on every capture. A 100KHz frequency modulation of the sampling clock also aligns with the observation that it only occurs at multiples of 5us from the trigger.

[Codemonkey]

FWIW, I have a DS1104Z, Software version 00.04.00 (hardware version not shown). I don't see the jitter at all when playing with the delayed trigger:

I do see jitter when using AC coupled trigger but given that I've never used that mode I'm not really all that fussed about it.

(I don't have a sig gen so used a 44MHz crystal oscillator as a source)

[nixfu]

I did not expect anyone to so badly confuse AC trigger coupling with AC input coupling. I'm pretty sure I showed I was suing the trigger menu more than once in the video, and mentioned it was trigger coupling.

Well, to be fair the menus look nearly identical between the trigger AC setting and the input AC coupling.  They are both that first menu item on the right hand side of the screen. 

[g0hjq]

I've got a 2 week old DS1074.

I cannot find any sign of the 5uS jitter problem using an external Siglent SDG1020 at 10MHz.

It does suffer from the AC TRIGGER issue. I can't think of many circumstances where I would need to use AC triggering, so aren't really concerned about it.

Software version is 00.04.01.SP2, and board version is 0.1.1

[megajocke]

Basically, AC trigger coupling allows to keep trigger level at the same spot when signal reference level is moved up and down. I do not see how this could be used on or apply to digital scope.

I find AC trigger coupling useful to be able to keep the trigger level at the same point in the varying part of a waveform while changing the DC-offset. This applies to a digital scope as much as to an analog one.

I used it just a few days ago (on an Agilent scope) when looking at the clipping chacteristics of a class D amplifier by feeding the input a sine wave which I manually varied the DC offset of. Using the AC trigger mode, the scope kept triggering as I varied the offset over the full input range of the amplifier without having to twiddle the trigger level knob. Because I was able to keep the inputs DC-coupled I could see at what voltage the amplifier clipped among other things.

It's not an audio-related application, by the way. O0

[Fagear]

I have my DS2072A and DS4024 for the review, so I've checked both of them.
But I have no proper signal generator now, all I have is breadboard with ATmega8 outputting 2 MHz square wave via PWM. And this ATmega is running from internal 8 MHz clock (not even from crystal), so it is "completely unstable". And can not be trusted.

DS2000A:
Problem #1 (5us huge jitter): can't confirm or decline (because of unstable signal source)
Problem #2 (AC coupled trigger huge jitter and offset): confirmed, bug is present
Problem #3 (dual slope trigger): not confirmed, works fine; it's actually the holdoff that confuses things, but there is nothing wrong with it
Problem #4 (only DC-coupled EXT trigger): confirmed, it works only with DC coupling; UI does not affect performance.

DS4000:
Problem #1 (5us huge jitter): can't confirm or decline (because of unstable signal source)
Problem #2 (AC coupled trigger huge jitter and offset): confirmed, but in a strange way... occurs when trigger level is around 0 V and on certain time bases
Problem #3 (dual slope trigger): not confirmed, works fine
Problem #4 (only DC-coupled EXT trigger): not confirmed, works fine, and problem #2 disappears at the same time!

Also I've spotted that hardware frequency counter go wild synchronous with AC coupling of the trigger. When it measures frequency of the same channel that it's  triggering of.

I've shot a video about it with all demonstrations. It is rendering now, and I am working on Russian->English translation of subtitles for it...

[David Hess]

Hmm, isn't this just a characteristic of any delayed trigger on any oscilloscope?

I had an old HP 54501A. 10MSa/s ADC. As the trigger delay increased, jitter increased. It made anything more than about 1ms completely unusable on continuous trigger mode.

This makes sense, as the distance from the trigger point increases, the jitter becomes a sum of all previous samples. At 1GSa/s, 5 microseconds is 5,000 samples. For a jitter of ~5ns, the per-sample jitter would have to be ~1ps.

To me, that sounds completely reasonable...

Does my reasoning sound right?

Except for how jitter adds your reasoning is right but the magnitude and peculiar behavior of the jitter in this case indicate that something wrong.  Long term jitter is not just simple addition of the jitter from individual cycles.

The jitter on a digital delayed timebase is the addition of the trigger jitter and the long term, not short term, clock jitter.  1ns of jitter over 5us is 200ppm which is terrible and these oscilloscopes are displaying several times that.  I ran the same test on my 2440 and the peak-to-peak jitter out to 500uS (as high as I could go at 2ns/div) was about 350ps which almost doubles the specified maximum trigger jitter of 200ps and is within its delayed timebase total jitter specification of 400ps.  That comes out to 0.7ppm combined trigger and timebase jitter over a period of 500us which seems about right to me although I do not know how much of the clock jitter came from my signal source and how much came from the oscilloscope.  The other oscilloscopes which Dave tested in his video also displayed insignificant jitter at 5us and beyond.

Even if the Rigol just had excessive long term jitter for whatever reason, that it decreased to a minimum and the expected jitter at 10us and multiples of 10us after that indicates that something other than just high long term jitter is occurring.

The problem also cannot be excessive trigger jitter which would change depending on the transition time of the trigger edge because that would be constant and not decrease with longer delays.

Yes, I believe it does. This whole thing seems blown a bit out of proportion to me... Jitter is always pretty bad when you go off-trigger.

The jitter should be worse but not this much worse and it should not get better with longer delays.

Consider: yes, it looks worse on the DS1000Z/DS2000, but these scopes also have a significantly better graded-intensity display, requiring them to capture significantly more samples and combine them into a screenful. That's naturally going to appear to amplify the jitter.

Without intensity grading multiple acquisitions the jitter is still there but is more difficult to see; the edge of the delayed waveform would look like it is jumping horizontally.  Intensity grading, variable persistence, and envelope detection make it easier to see.

[David Hess]

If i set my function generator to 100KHz square wave (fast rising/falling edges), adjust the horizontal offset to 5us and zoom in to 5ns/div i get a sharp falling edge that moves left and right in a sine fashion at about a 1Hz repetition rate. This indicates to me that the jitter is not random and is caused by a clock frequency modulation effect around 100KHz give or take 1Hz, or some multiple of 100KHz.

Edit: the modulation frequency must be 100KHz because if i set my signal to 200KHz i see two rising edges moving with opposite phase, and at 300KHz i get 3 falling edges moving 120deg out of phase with each other, 400KHz = 4 edges, and so forth.
At 99,999.3Hz there is no observed jitter as falling edge occurs in the same place on every capture. A 100KHz frequency modulation of the sampling clock also aligns with the observation that it only occurs at multiples of 5us from the trigger.

I worried that this weird jitter problem with a peak at 5us and a null at 10us was just an artifact of using a DDS or synthesized signal generator but Dave ruled that out when he tested other oscilloscopes which did not display the problem.

[wn1fju]

As others may have observed, I'm certainly seeing a vast difference with the 5 us jitter when I switch signal sources.  With my HP 3314A function generator set to a 10 MHz sinewave, I'm estimating about 3 minor ticks of jitter (at the min 1104Z horizontal time/div) with the 5us delay.  When I switch the source to the ovenized 10 MHz oscillator in my HP 5335A counter, the jitter reduces to about 1-1/2 ticks.  With zero delay, both sources I estimate to be about 1-1/4 ticks (as best as I can guess).  This is all with the 1104Z set to 5 sec of persistence.  So it would seem that the accrued jitter in the source over a 5 us interval has some bearing???

[i4004]

kinda recapping it...

I did not expect anyone to so badly confuse AC trigger coupling with AC input coupling. I'm pretty sure I showed I was suing the trigger menu more than once in the video, and mentioned it was trigger coupling.

Well, to be fair the menus look nearly identical between the trigger AC setting and the input AC coupling.  They are both that first menu item on the right hand side of the screen.

nope, one menu has 3 menu items (ending with "gnd") another 4, and not ending with "gnd" item...and that is exactly how i figured instantly that it's not input coupling thing, because dave was obviously not using the coupling menu. i was like "what's that menu he's using anyway", and then went back into video, and heard him explain it was trigger menu, and that was it....

going back a bit with reported thing no1 ( thing no.2 (ac coupled trigger) we already removed as being important...albeit it's still interesting is it digital or analog...different hardware revisions having it (ie newer scopes) kinda suggest they won't be able to resolve it via firmware update(?) ):

1- if you can't use 5us(or ms), you can use 10, glass is half full again! 
2- if you can miss this jitter, you're probably blind.
3- simillar to trigger ac coupling issue (usefulness/uselessness), what's the point of moving trigger horizontally so much off the screen? i mean i won't really be able to see more of a waveform no matter where i put the trigger, i have those 480pixels and that's it....
(this scope needs hdmi output and 1080p support...then they could even remove the lcd screen alotogether....    )
didn't play with timings too much, but if you first need to squeeze the waveform in order to move it fast enough later (to move it by amount of 5)...meh....

the more one looks at this problem, the more it reminds to 'no-trigger curiosity', although this is a real bug, but not that damaging to scope usage.
would be cool for rigol to fix it, but how many of us would run into this issue, and how exactly/why (talking now about 'time jitter' issue).

i'll do some measurements to see if moving trigger horizontally just off the screen reveals the bug, and  if not....i'll just stop worrying... 

the third issue (which deosn't really exist) was already explained by rs20 here:
https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg551012/#msg551012

[c4757p]

I worried that this weird jitter problem with a peak at 5us and a null at 10us was just an artifact of using a DDS or synthesized signal generator but Dave ruled that out when he tested other oscilloscopes which did not display the problem.

Dave didn't rule anything out with the other oscilloscopes, because he tested them at the same points. If they also exhibit this behavior, why should it happen at the same point in time as it does on the Rigol? That will be a function of the sampling design, most likely.

[JonR]

First off, Hi all, first post for me.

My 1054Z arrived yesterday a few hours before Dave's video

Lots of intersting information in this thread, will have to re-read thoroughly later. Looking after my kids today however I found some time for a tinker with the AC coupling jitter issue

I took the trigger output of the 1054z and looped it back up the clacker of chan2 while still triggering off chan 1 which was being fed by a function gen.

There were some intersting observations.

1. The trigger edge on CH2 (blue) always begins between ~352ns and ~360ns after the trigger indicator**
2. In DC trigger coupled mode, the CH1 (Yellow) output from sig gen is always steady, however the trigger edge jitters between 352-360ns..
3. In AC trigger coupled mode, the CH1 output from the sig gen always jitters, but the trigger edge is steady*

*Except at 12MHz and at 24MHz (+/- ~2MHz) where both the CH1 sig gen source and the CH2 trigger edge are jittering. But interestingly, not by the same offset when played back from a recording.

**I confirmed this by connecting the trig out of the 1054z into the ext trig input of my old 1052E and fed both with the same input. Sure enough, a trig offset of ~352ns was required on the 1052e to align the edges of a 10HZ square wave. Looks like the trigger hardware takes  between 350-360ns to process an incoming waveform so must need to compensate for this variance when displaying the waveform on the screen (assuming the trig out is good). /shrug

I have attached some pictures.

The source into CH1 (yellow) of the 1054z is a sinewave from a Rigol DG1022, is DC coupled with BW off.

Triggering is on CH1, Edge, Up slope, Normal sweep.

I did also notice that in the Rigol specs for the 1000Z series the pulse width range has a minimum of 8ns, which may also come into play here. Not sure, but it's right in my 352-360 ish range.

What does this all mean in terms of hardware/software? No idea! I'm just a beginner at electronics, however I thought I'd throw this in.

I don't think this is ever going to be an issue for me in reality. I never used AC triggering until this came up, however now that I know about it I'll probably find a use now

Jon

[HexfeT]

My trigger offset jitter problem no changing by offset value. 5,10,15,20,25us... always there, and same.

[i4004]

and if you put the generator freq. exactly to 21mhz, not 21.0017?

seems to be getting progressively worse in your case, more you move it from centre, more jitter it gets...at 15us it's even starting to change the amplitude of the signal...

btw. you're using 1x probe on 20mhz signal, and that probe (if it's rigol default probe) doesn't have that bandwidth, so you would be using 10x in that case anyway...

[David Hess]

As others may have observed, I'm certainly seeing a vast difference with the 5 us jitter when I switch signal sources.  With my HP 3314A function generator set to a 10 MHz sinewave, I'm estimating about 3 minor ticks of jitter (at the min 1104Z horizontal time/div) with the 5us delay.  When I switch the source to the ovenized 10 MHz oscillator in my HP 5335A counter, the jitter reduces to about 1-1/2 ticks.  With zero delay, both sources I estimate to be about 1-1/4 ticks (as best as I can guess).  This is all with the 1104Z set to 5 sec of persistence.  So it would seem that the accrued jitter in the source over a 5 us interval has some bearing???

Assuming that the clock jitter from the source and clock jitter from the oscilloscope uncorrelated (*), the displayed waveform will show the root sum of squares of the jitter from both sources so to make this measurement, the long term jitter over the period of interest from the signal source needs to be low.  In general any crystal oscillator should work but some synthesized or DDS sources may have problems at certain output frequencies.

If the measurement is made using peak-to-peak jitter, then they will directly add but this does not change the requirements on the source.

(*) Agilent made some DSOs which modulate the sampling clock to deliberately prevent accidental correlation between the sample rate and input signal but this is compensated for before the waveform is displayed so it is transparent to the user and the results look like any other DSO with a uniform sampling clock.  Correlation between the signal and sampling clock prevents equivalent time sampling for operating correctly.

I worried that this weird jitter problem with a peak at 5us and a null at 10us was just an artifact of using a DDS or synthesized signal generator but Dave ruled that out when he tested other oscilloscopes which did not display the problem.

Dave didn't rule anything out with the other oscilloscopes, because he tested them at the same points. If they also exhibit this behavior, why should it happen at the same point in time as it does on the Rigol? That will be a function of the sampling design, most likely.

While this is possible, I think he would have noticed and told us if there was excessive jitter at points other than 5us on the other oscilloscopes.  I assume he left it out of his video for brevity and because there was nothing to see.

I would consider it very odd if a Tektronix or Agilent oscilloscope displayed this behavior since one of the advertised applications for their DSOs is measuring long term jitter.  Users may not commonly use low end Rigol oscilloscopes for long term jitter analysis but they sure use Tektronix and Agilent oscilloscopes for it and a problem like this would have been noticed.

[David Hess]

1. The trigger edge on CH2 (blue) always begins between ~352ns and ~360ns after the trigger indicator**

Thanks for sharing this and your other results.

I did not know the trigger output delay was that long but I expected about that much jitter.  Rigol only discusses using the external trigger output to verify the waveform acquisition rate and for automation and not for precision timing or triggering.

2. In DC trigger coupled mode, the CH1 (Yellow) output from sig gen is always steady, however the trigger edge jitters between 352-360ns..
3. In AC trigger coupled mode, the CH1 output from the sig gen always jitters, but the trigger edge is steady*

They may only be related by a common processing clock inside the FPGA.  This does point toward an FPGA programming problem causing the AC trigger coupling jitter which can be updated through firmware.  I doubt anything can be done about the jitter or delay in the external trigger output and I am not sanguine that the jitter at a delay of 5us can be repaired easily.

*Except at 12MHz and at 24MHz (+/- ~2MHz) where both the CH1 sig gen source and the CH2 trigger edge are jittering. But interestingly, not by the same offset when played back from a recording.

There is likely a corner case where the external trigger output jumps between its two extreme positions.

**I confirmed this by connecting the trig out of the 1054z into the ext trig input of my old 1052E and fed both with the same input. Sure enough, a trig offset of ~352ns was required on the 1052e to align the edges of a 10HZ square wave. Looks like the trigger hardware takes  between 350-360ns to process an incoming waveform so must need to compensate for this variance when displaying the waveform on the screen (assuming the trig out is good). /shrug

I would be carefully paranoid about relying on low jitter from the external trigger input but the 1052e is an older design and probably works fine.

I did also notice that in the Rigol specs for the 1000Z series the pulse width range has a minimum of 8ns, which may also come into play here. Not sure, but it's right in my 352-360 ish range.

This probably provides insight into the clock frequency used inside the FPGA for processing the trigger.