Hey Scope Experts...Can You Help? Is my Rigol DS4024 sweep behavior normal?

[Paul Price]

Can any digital scope expert help me? After looking at specs for scopes for several weeks I finally narrowed my choice for my limited budget to a Rigol DS4024.  This is my first digital scope. But what I got is not what I expected!
Would I have got a better scope, seen more realtime-like performance from a used Tektronix TDS3014 I could have bought?

I am new to digital scopes, but have a lot a experience with analog. Just got a Rigol DS4024 and I am surprised how it works.

For instance,
If I trigger the scope at a scan speed of 200mS/div using Norm or Auto Trigger with just 30-150mS bursts of 60Hz sinewave using fingertip to probetip on Chan A only as a signal generator to display 8-div of sinewaves, I notice that  the displayed waveform updates the last display without wiping it out to a flatline(even though I have set no storage functions). The last triggered sweep remains visible and the screen does not refresh to a flatline.

Question 1: is this always normal...shouldn't the last trace vanish according to persistence setting? Do all DSO behave like this?

In any case, at 200mSec/div the scope clearly shows the progress of the scan and I can see realtime what is going on...no problem!

But then, when I set the scope to 100mS/div:
Trig Holdoff is at 100nS, Persistence is set to Min.

Now, the display only updates only very late in the 14-div scan  (or if I keep my finger on the probe for a continuous signal) it is not updated until the scan is complete. It is only then I see a snapshot of the entire scan suddenly appear, but I see only a flatline during the scan, no scan progress is visible. (This effect is most noticed at a scan speed of 100mS/div and seems to be less and noticed as i get to 2mS/div,  and at scan speeds faster than that, the delay time for a screen update is not noticed.) Again, all storage functions have been turned off!

Is this "only after scan does display refresh" effect also seen on other DSO scopes (like a Tek TDS3014 at 100mS/div)?

Secondly, at 100mS/div, the scope messages "WAIT"(blinks once a sec) indicating ready to trigger, then "TD" (when I touch the probe tip and trigger) and then the scope sometimes takes more than several second until "WAIT" flashes again.

How can this behavior live up to the 100000 waveforms/sec display update rate that is specified for this scope?

Finally, sometimes this scope progresses from "WAIT" flashing to "TD" (triggered) to "RUN" and remains in this comatose  non-triggering state for several seconds!  Is this normal for all DSO scopes?

In general,  What would I see this if I had purchased an older Tektronix TDS3014 instead?

What scopes around this price range offer a better realtime display, performance?

 I am very interested to have a scope for all reasons, something I can work with observing the very slow to the very fast!

[tom66]

Not sure about your first question, but

Now, the display only updates only very late in the 14-div scan  (or if I keep my finger on the probe for a continuous signal) it is not updated until the scan is complete. It is only then I see a snapshot of the entire scan suddenly appear, but I see only a flatline during the scan, no scan progress is visible. (This effect is most noticed at a scan speed of 100mS/div and seems to be less and noticed as i get to 2mS/div,  and at scan speeds faster than that, the delay time for a screen update is not noticed.) Again, all storage functions have been turned off!

This is normal. The scope creates the previous time data by synchronising the capture buffer with the actual time it happened. Zero seconds in the middle, negative time in the past. The scope uses the rolling buffer to fill in the past information, but that can start at any time before the trigger, so the information can't be shown in real time (it would not line up properly.) Note that even when there appears to be no trigger there is one -- the auto trigger which is present when no ordinary trigger is generated.  To get the screen to roll slowly, you simply need to move the trigger position to the far left. Every digital scope I've had does this: from the HP 54501A, to the Rigol DS1052E, to my uni lab's Agilent scopes.

[jpb]

If you look at Agilents app note on wave forms per second:

http://cp.literature.agilent.com/litweb/pdf/5989-7885EN.pdf

you'll see that at lower time bases the wave form update rate is set by the scan rate so the 1,000,000 wfms per sec rate is irrelevant.

An analogue scope shows the scan as it happens, digital scopes read the data at high speed into memory and this is transferred to the screen but this tends to be done only when the data for the whole screen is available. On my scope (a WaveJet) if I set a very slow time base it will wait until the new screen is ready before updating. The exception is if I set rolling mode where the trace starts from the right of the screen and then scrolls across. This makes sense as more recent time is on the right of the screen. It's been a long time since I used an analogue scope so I can't remember how that used to scan I guess it should be the same, right to left.

The screen itself on a digital scope is memory - as on a pc - so naturally it stays as it was until actively replaced. On an analogue scope there is no memory, if the input is removed the scan will go flat waiting for new input. On a digital scope the screen memory will sit unchanged until there is a fresh lot of data to replace it. I think this is pretty universal for digital scopes.

So at 200msec/div it will take at least 2 seconds for the screen to be refreshed, it won't try to re-trigger until it has completed the first screens worth. If there is nothing to trigger off at the end of 2 seconds it will wait until there is. For the screen to go flat you'd need to set auto-trigger and zero input.

[Paul Price]

I think both your comments seem at first to make sense, andI thank those who have made comments, but the fact remains that at 200mS/div the scope clearly follows in realtime as it displays the progress of the scan from the leftmost graticule point(where I have located the trig.) and continues in this way to the end of the scan.

 My question is why doesn't this behavior remain the same at 100mSec/div to 5mS/div scan rates?

[vlf3]

This down-load pdf, should answer your question e.g. Deep Memory...

http://cp.literature.agilent.com/litweb/pdf/5989-4501EN.pdf

As a counter to the above link, this has more information to ponder...

http://www.tmworld.com/design/manufacturing/4389565/Oscilloscope-memory-depth-when-bigger-is-not-always-better

[Galaxyrise]

Slightly tangential to the question, but have you tried "roll mode"?

[Paul Price]

Thanks to the person suggesting above to try ROLL MODE, but this feature is available on the DS4024 scope only from 200mS/div and slower sweep speeds.
 
I am having trouble working at 100mS/Div to 2mS/div.

[Paul Price]

Many thanks to VLF3 for the links about large memory scopes and I read these carefulliy, but these articles don't seem to explain how the scope works so well in realtime at 200mS/div but not at 100mS/div scan rates. According to the articals presented, the scope should have greater problems at slower sweeps.

I am having trouble seeing realtime data display update at 100mS/div to 2mS/div sweep rates, and not at 200mS/div rates.

[Paul Price]

Thanks to JPB for trying to help. It gives me some insight into the overall behavior of DSO scopes as to their behavior in just overwriting a persisted last triggered image.  I would say that it would be smarter, to prevent accidently misreading a "ghost" trace that could result in catastrophe in some situations. If a trace is to remain on the screen it violates the rules of the persistence settings otherwise offered, this could lead to dangerous situations. The display should display nothing when nothing is to be displayed!

What I do see is a flatline durng the scan...this is misleading...looks like nothing is happening during the total time of a sweep, could be observed as 1.4 critical seconds of blackout occuring in some ciritical or dangerous experiment or test or other mission-crtical observation!

This idea of keeping on display the last trace triggered is misleading, and so it is possibly dangerous and thus this seems tp be poorly adopted as a convention in DSO operation. It should only be allowed and selectable as an option, not as a indelible feature. A DSO like the DS4024 scope has a persistence setting, why not allow the user to always use it?

In regard to the infinite persistence of the last triggered sweep display, and it is by convention, unavoidable that a "ghost" display is to be retained on the screen forever until another trigger wanders by, why should it not almost immediately turn color form the red, blue, violet and green, to a very contrasting one...why not the color = white, a perfect ghost's color!


I would point out to JPB that no analog scope has a Roll Mode that sweeps from; right to left that I am aware of.

[vlf3]

I would ask other users of this model to report on this condition, to see if they have the same problem !... is it possible you have a software fault ?

[Wuerstchenhund]

As a counter to the above link, this has more information to ponder...

http://www.tmworld.com/design/manufacturing/4389565/Oscilloscope-memory-depth-when-bigger-is-not-always-better

Be careful with that article, as the title is deceiving. It essentially concludes that a scope with less memory but with Agilent's high wfm/s rate MegaZoom ASIC is much better than a certain other scope (Tek?) which has more memory but a much lower wfm rate. This has nothing to do with memory at all. It's Agilent's marketing spin trying to make their scope look better than a competitor's scope.

Agilent makes great products but their marketing tactics are more and more often becoming at least 'questionable'.

[jpb]

I would point out to JPB that no analog scope has a Roll Mode that sweeps from; right to left that I am aware of.

I've never really thought about this before but my memory was that analogue scopes sweep from left to right which of course makes sense as the latest time point (the most recent) is where the trace actually is.
With a digital scope the data as displayed is pre-measured, that is points only appear as measured data (as apposed to an analogue scope where the point appears and then reacts to input), so DSOs have to sweep backwards which does look a little odd. Given the slow speed of roll mode it would be quite easy for the manufacturers of DSOs to simulate the analogue approach and I'm surprised this isn't done but I suppose as it stands it is more like an analogue chart recorder.

Paul, the persistence of trace happens also in an analogue scope via the phosphor and in fact such screens were used as memory in very early computers. The big difference that you have highlighted is that  DSOs operate in whole screens (except in roll mode). This is only really a problem between Roll mode and say 10ms/div where the screen is replaced in 1/10 second.
On the WaveJet the Roll mode will go down to 50msec/div which is 2 screens a second, the next time base down is 20msec/div which is 5 fps refresh.

So on the WaveJet it is not a problem. It seems to be a problem with the Rigol having 200msec/div lowest roll mode time setting which leaves a gap.

[Galaxyrise]

I hadn't noticed that roll mode stopped at 200ms/div! It's almost certainly not a coincidence that the sweep behavior in Y-T changes at the same time. 

Back to one of your original questions:

"Question 1: is this always normal...shouldn't the last trace vanish according to persistence setting? Do all DSO behave like this?"

The digital screen isn't faded in real time like a CRT phosphor would.  I don't think any DSO or DPO emulate the phosphor decay like that, though I can really only speak to the one I own (DS2000 series.)  Nothing fades out, it is just replaced by newer data when new data is available.  This is true even at the 200ms time base: the old data stays there at the same intensity until the "trace" replaces it with new data.  Then there's a triggering delay, and it repeats.  Note that if the trigger is in the center, you have to wait for 7*200ms before it can start triggering since you've asked for 7*200ms of pre-trigger data.  If you put the trigger to the extreme left of the waveform, you'll start seeing new data much sooner.

Perhaps it would help you to see what happens when persistence is actually turned up. On the DS2000 scopes, there's only two phases of fading: "In the most recent waveform" and "In a previous waveform".  Here's a nice example (from page 65 of marmad's massive DS2000 thread) As your scope is from the same Ultravision line, I suspect it works the same:

How can this behavior live up to the 100000 waveforms/sec display update rate that is specified for this scope?

That rate isn't for every configuration of the scope; it's the maximum update rate. And when you think about it, you can't have a waveform that represents 1.4s and generate more than one of those in a second  

My question is why doesn't this behavior remain the same at 100mSec/div to 5mS/div scan rates?

Potentially it is just a UI choice in the firmware, as 100ms/div still seems like a pretty slow trace to me.  However, there will be a technical limit at some point. At the smaller time scales, the display gets updated during the "dead time" while sampling isn't occurring, so the display doesn't have to keep up.  Only the triggering and storage mechanisms need to keep up.  There is going to be some threshold where the display can't update the trace fast enough while sampling, and the scope won't be able to support roll mode or a real-time trace at those time scales.

The display should display nothing when nothing is to be displayed!

There is the previous waveform to display The alternative would be to flash the previous waveform and then display black.  It's not the same as the analog scope, which sits blank until triggered, and then you immediately start to see the trace crawl across once triggered.

If you're looking for the same kind of visual cue, then check the upper left of the screen. In the screenshot above, you can see it display "T'D".  It'll show "Wait" when the previous waveform is displayed and it's waiting for a trigger. Once it triggers, that corner will update to "T'D", and then once the waveform is captured the screen will change and it'll fall back to "Wait".

I admit, I do find 100ms/div a bit awkward to work at.

[ChrisMH]

I have a DS4024.

In Auto mode, using your method of touching your fingertip to the probe, mine does indeed return to a "flat line" after removing my finger.  At 200 ms/div it takes a little bit of time for the entire screen to refresh, but it does return to just showing a little bit of noise.

In Norm mode, the scope will trigger when I touch my finger to the probe, but does not return to zero input when I remove my finger. 

Both of these are as I would expect.  Auto mode displays waveform updates continuously, even in the absence of a trigger, so you would expect it to return to zero input.  Norm mode only updates the waveform displayed when there is a trigger, so when you remove your finger the last captured waveform will appear on the screen until the scope is triggered again.

Chris

[The Electrician]

Secondly, at 100mS/div, the scope messages "WAIT"(blinks once a sec) indicating ready to trigger, then "TD" (when I touch the probe tip and trigger) and then the scope sometimes takes more than several second until "WAIT" flashes again.

Do you by any chance have your memory depth set to 140 M samples?  If so, try setting it to 14 k samples and see what happens.

[Ruben57]

I just picked up a DS4024 and came across this thread while Google searching for a different problem that I am having with this DSO (trial options just expired prematurely overnight. Didn't even get a chance to try them). I know I'm a bit late entering this subject but I thought it was worthwhile adding to it anyhow.

I did some experimenting and I would have to agree with Paul Price, something is clearly wrong with the DS4024 at slow time base settings between 199ms and about 1ms (firmware 00.01.00). I also found a bug that causes the waveform display to glitch/crash while investigating this.

After noticing this odd behaviour, I compared the behaviour to other different DSOs that I have here, a LeCroy Wave Surfer 434, Fluke 199C, Agilent DSO1024A and an ancient Gould DSO400. I set them up on the bench and fed the same signal to them. It was an interesting comparison.

At a time bases up to 200ms, all the DSOs more or less displayed the same sweep characteristics, as would be expected. The sweep starts at the left and is drawn across the screen to the right then repeats. At a time base of 100ms, the same sweep characteristics can be seen on all these DSOs with the exception of the DS4024. At 100ms the display appears to update in just under a second, so the waveform is not swept (or drawn across the screen) rather the entire screen is updated approximately every second. It also appears to have a relatively large dead zone at that time base as well.

The DS4024 starts to catch-up with the other DSOs at a time base of 5ms. At 1ms the DS4024 appears a fraction faster at updating the screen compared to the Fluke 199C and all these DSOs appear indistinguishable at 500us and above.

It looks to me as though there is a bug in the firmware relating to these slower time base settings. I sincerely doubt that it should be considered as normal behaviour.

As far as the bug/glitch in the display, I found that if the horizontal triggerr position was set at particlar points that the waveform display would either disappear or glitch (only part of it would be shown and it would flicker, as well as not update with the incoming signal). It doesn't matter what the signal is or what trigger settings are used. The bug occurs at all time bases between 1ks to 200ms, however, I am only listing some of them below.

Time Base   ->   Horizontal Trigger position

10s       Between 70.670s and 70.870
9s         Between 63.570s and 63.870s
8s         Between 56.570s and 56.770s
7s         Between 49.470s and 49.670s
6s         Between 42.370s and 42.570s
5s         Between 35.37s and 35.470s
4s         Between 28.270s and 28.39s
3s         Between 21.190s and 21.270s
2s         Between 14.122s and 14.180s
1s         Between 7.060s and 7.082s
500ms   Between 3.532s and 3.542s
250ms   Between 1.766s and 1.776s
200ms   Between 1.412s and 1.416s

It is easy to spot the pattern above. That is how I actually found most of these glitch zones, I noticed the pattern after finding 3 glitch zones.

I don't think it is a coincidence that the odd looking sweep starts at a time base of 199ms and that the display glitch/bug only occurs up to 200ms. Interestingly, the cutoff for Roll mode is 200ms as well.

Also, if delayed sweep is turned on when the glitch occurs, the waveform is displayed however it doesn't represent the incomming signal. Likewise, if the vertical position is adjusted then the display glitches further.

If the memory depth is manually changed to 14kpts (only 14kpts, other depths still glitch) then the display sweeps as it normally would.

I am very interested to know if the above behaviour also occurs on the Rigol DS2000 series, and if others who have a DS4000 series can replicate the above behaviour as well. I doubt that these issues are only on my particular DS4024.

Although I don't normally use these slow time bases, it would be good if Rigol were to address these issues. As it is, the 100ms time base is absolutely useless for anything other than a single triggered sweep. I wouldn't even rely on it for a repetitive signal, it is that pathetic.

For those who would disagree, then all I can say is that you need to actually see it first-hand to understand how bad it really is.