Most (Digital-)Scopes are freezing while vertical adjustement...

[nctnico]

What the Rigol seems to be doing is wait until the DSO thinks the user is done adjusting the vertical position for so long that it is perceived as lag.

I don't know if this comes into play, but the fact that its acquisition is more than the one screenful (to support the zoom-out...) probably slows down its retrigger quite a bit.

No. Acquisition can be cancelled/halted/stopped at any point. There is no reason to wait for a full acquisition when a parameter changes. R&S -for example- does handles this just fine. There really isn't any magic involved in an acquisition system. It is an ADC, memory and a counter that serves as a memory pointer

[bdunham7]

No. Acquisition can be cancelled/halted/stopped at any point. There is no reason to wait for a full acquisition when a parameter changes.

Of course the acquisition can be stopped and restarted, but it has to complete the subsequent acquisition process before the data can be processed and displayed, no?  And it has to acquire half a buffer, then start looking for a trigger, then acquire the second half after the trigger, then process and display. 

[nctnico]

No. Acquisition can be cancelled/halted/stopped at any point. There is no reason to wait for a full acquisition when a parameter changes.

Of course the acquisition can be stopped and restarted, but it has to complete the subsequent acquisition process before the data can be processed and displayed, no?

No. Acquisition is interrupted and whatever is in the buffer gets displayed. That is how R&S works.

[2N3055]

What the Rigol seems to be doing is wait until the DSO thinks the user is done adjusting the vertical position for so long that it is perceived as lag.

I don't know if this comes into play, but the fact that its acquisition is more than the one screenful (to support the zoom-out...) probably slows down its retrigger quite a bit.

No. Acquisition can be cancelled/halted/stopped at any point. There is no reason to wait for a full acquisition when a parameter changes. R&S -for example- does handles this just fine. There really isn't any magic involved in an acquisition system. It is an ADC, memory and a counter that serves as a memory pointer

Acquisition doesn't even stop. Triggering does. You keep repeating how it works but it is not like this. There are much more details than ADC, memory and memory pointer.
First you have digital triggering. That works on a deep pipeline. Some scopes have qualified triggers so even deeper nested pipeline. There are measurements and math, some of which are on full buffer and accelerated by FPGA. Then there is a display rendering engine, with persistence and intensity calculation. Most of that stuff is also at least partially accelerated (we are dealing with 100s of MB of data in single buffer). And there is also hardware zoom mode.. Moving trigger point outside the screen means all the data in between has to be kept.
etc etc... Add digital channels to the confusion. Also trigger interpolation and readjustment.... Channel skew and readjustment of those.
etc etc...

[nctnico]

Doesn't matter for the discussion. Point is that acquisition can be stopped at any point and if there is something to be displayed, it can be displayed to give the user feedback that something actually has changed using the new setting. There really is no need to make this discussion any more complex than that. This is not DSO design class, this is DSO use class. How a DSO works internally is likely different for each manufacturer so going into design details is just pure speculation.

[bdunham7]

No. Acquisition is interrupted and whatever is in the buffer gets displayed. That is how R&S works.

I don't see how that helps.  I'm not even sure what it means.  Presumably the only time any of these issues matter would be unusual situations, like a low repetition rate signal and a long acquisition.  So some half-eaten acquisition not referenced to a trigger point doesn't seem useful except to give the scope a 'live' feel for those with some sort of OCD over 'lag'.  A briefly frozen previous complete acquisition, lined up with the trigger seems to be a much more useful thing to have displayed.

I see now that I misinterpreted the original complaint--vertical position vs scale--but I still think it is a non-issue.  If your signal is varying that wildly, IMO the thing to do is zoom out a bit, not frantically twiddle the knobs. 

[nctnico]

It purely is a user interface design issue indeed. But in user interface design land lag is something people really obsess over. Just watch the TV series 'halt & catch fire' (supposedly about the founding of Compaq) or more recently 'the playlist' (about the creation of Spotify). In both series user interface lag is a source of serious obsession and frustration for several of the characters.

[2N3055]

No. Acquisition can be cancelled/halted/stopped at any point. There is no reason to wait for a full acquisition when a parameter changes.

Of course the acquisition can be stopped and restarted, but it has to complete the subsequent acquisition process before the data can be processed and displayed, no?

No. Acquisition is interrupted and whatever is in the buffer gets displayed. That is how R&S works.

So like Joe said, you put scope to 1s/div, and as soon as you move trace with a knob what happens:

1:  Immediately erases the screen and starts from left side again with changed vertical position.
or
2: Immediately stops the horizontal trace scan  and lets you move what was on the screen up and down. Once you stop, it resets and starts from the left.
or
3: It lets you move trace up and down while simultaneously keep scanning to the right like nothing is happening (except vertical movement, of course)

Thank you.

[bdunham7]

In both series user interface lag is a source of serious obsession and frustration for several of the characters.

Although I'm a pretty deliberate sort of machine operator in general, I don't like input lag any more than anyone else.  I just don't perceive the issue we're talking about as input lag.

[JPortici]

No. Acquisition can be cancelled/halted/stopped at any point. There is no reason to wait for a full acquisition when a parameter changes.

Of course the acquisition can be stopped and restarted, but it has to complete the subsequent acquisition process before the data can be processed and displayed, no?

No. Acquisition is interrupted and whatever is in the buffer gets displayed. That is how R&S works.

So like Joe said, you put scope to 1s/div, and as soon as you move trace with a knob what happens:

1:  Immediately erases the screen and starts from left side again with changed vertical position.
or
2: Immediately stops the horizontal trace scan  and lets you move what was on the screen up and down. Once you stop, it resets and starts from the left.
or
3: It lets you move trace up and down while simultaneously keep scanning to the right like nothing is happening (except vertical movement, of course)

Thank you.

FWIW, Tek Does (3) in the 2.5kS scopes, But trigger is disabled

[nctnico]

No. Acquisition can be cancelled/halted/stopped at any point. There is no reason to wait for a full acquisition when a parameter changes.

Of course the acquisition can be stopped and restarted, but it has to complete the subsequent acquisition process before the data can be processed and displayed, no?

No. Acquisition is interrupted and whatever is in the buffer gets displayed. That is how R&S works.

So like Joe said, you put scope to 1s/div, and as soon as you move trace with a knob what happens:

1:  Immediately erases the screen and starts from left side again with changed vertical position.
or
2: Immediately stops the horizontal trace scan  and lets you move what was on the screen up and down. Once you stop, it resets and starts from the left.
or
3: It lets you move trace up and down while simultaneously keep scanning to the right like nothing is happening (except vertical movement, of course)

Thank you.

R&S does option 1. But I've seen all 3 options on scopes I've owned / used. IMHO option 3 is the 'worst' method of all because it allows you to draw fantasy signals.

[bdunham7]

FWIW, Tek Does (3) in the 2.5kS scopes, But trigger is disabled

Yes, but those scan from left to right at slow sweep rates in normal mode with Auto trigger, allowing you to draw like an Etch-a-Sketch with the V-pos knob.  Everything modern I have does the whole acquisition and then displays that, or else it uses 'roll' mode which goes from right to left.  Siglent clears and starts over in roll mode with any vertical adjustment, which actually sems sub-optimal.  Are others different?

[JPortici]

which actually sems sub-optimal.

Actually i don't care, i can work around all of them. I just need to know which way the scope performs.

[Caliaxy]

Of course the acquisition can be stopped and restarted, but it has to complete the subsequent acquisition process before the data can be processed and displayed, no?

No. Acquisition is interrupted and whatever is in the buffer gets displayed. That is how R&S works.

So like Joe said, you put scope to 1s/div, and as soon as you move trace with a knob what happens:

1:  Immediately erases the screen and starts from left side again with changed vertical position.
or
2: Immediately stops the horizontal trace scan  and lets you move what was on the screen up and down. Once you stop, it resets and starts from the left.
or
3: It lets you move trace up and down while simultaneously keep scanning to the right like nothing is happening (except vertical movement, of course)

Thank you.

R&S does option 1. But I've seen all 3 options on scopes I've owned / used. IMHO option 3 is the 'worst' method of all because it allows you to draw fantasy signals.

R&S RTC1002 (ex-Hameg) does #1 too, but keeps trying to restart the acquisition much more frequently than any other scope I've tried. It keeps restarting plotting the trace from the left as you rotate the vertical position encoder slowly but continuously (and it erases it as soon as it figures you are still rotating the knob). At timebases faster than 5ms/div, it *seems*  that it does #3 (or maybe it really does it, hard to tell).

Also, RTC1002 has a vertical "Scrolling" control which lets you move the whole screen content (traces and grid) up and down to explore what's above or below of what's displayed (like a long webpage that doesn't fit on your computer screen). While doing so, it does #3 (at any timebase).

[markone]

I honestly think that the instrument cost factor must be taken in consideration in this kind of debate, otherwise the whole thing becomes pointless.

For instance, i spent the whole day using a customer's Rigol MSO5074, that almost freeze the whole screen update during trace vertical adjustment, but considering the cost paid (around 1000 euros, including PLA2216 digital probes kit) it was expected and tolerated but ... if it had been paid like 4-5K euros, well, there is no way to convince me that this level of "laggyness" could be acceptable.

I worked a lot with power electronics  (brushless motor control and induction heating), the last thing that is accepted in this sector is a DSO that freezes for a bunch of time during trace adjustments and considering that a 12bit DSO like new Rigol HDO series could be aimed to power electronics design lab, statemets like "no problem if DSO stops to update screen for a bunch of time" and / or "i do not give a s*** for analog emulation" make me laugh a lot.

if I bought a 5K euro scope like the HDO4804 to find out later the laggy behaviour shown in Dave's video, I would not be satisfied at all, especially in the belief that the employed HW can do much better.

[bdunham7]

the last thing that is accepted in this sector is a DSO that freezes for a bunch of time during trace adjustments

Could you quantify "a bunch of time"?  I might agree with you if the bunch of time was long enough.

[2N3055]

I honestly think that the instrument cost factor must be taken in consideration in this kind of debate, otherwise the whole thing becomes pointless.

For instance, i spent the whole day using a customer's Rigol MSO5074, that almost freeze the whole screen update during trace vertical adjustment, but considering the cost paid (around 1000 euros, including PLA2216 digital probes kit) it was expected and tolerated but ... if it had been paid like 4-5K euros, well, there is no way to convince me that this level of "laggyness" could be acceptable.

I worked a lot with power electronics  (brushless motor control and induction heating), the last thing that is accepted in this sector is a DSO that freezes for a bunch of time during trace adjustments and considering that a 12bit DSO like new Rigol HDO series could be aimed to power electronics design lab, statemets like "no problem if DSO stops to update screen for a bunch of time" and / or "i do not give a s*** for analog emulation" make me laugh a lot.

if I bought a 5K euro scope like the HDO4804 to find out later the laggy behaviour shown in Dave's video, I would not be satisfied at all, especially in the belief that the employed HW can do much better.

Hardware doesn't exist in isolation. Scope is finely intertwined SW/HW. Maybe it cannot do better, because of architectural choices (in HW and SW) they made. Apparently optimizing this is not important for majority of users. As long as it is not 5-10 seconds, nobody cares..

Delay to restart might be visible but it won't kill anybody.
On Siglents I have here, it is a visible fraction of a second..  On Keysight 3000T it is less than 100ms. In practice either are good.

Would it be nice if every operation on every scope would be super fast and reaction instantaneous? Sure.
Is this a problem? No, it is not. It bothers you for some reason (which is fine by me) but it is no impediment to work.
You have all the right to be very particular with what you like or not, and you might even make (in this case emotional, I think) choices based on some details that are not really relevant to do the job. But you are only punishing yourself, because no scope manufacturer will make scopes that suits you, and you will have very limited and expensive choices.. What do you think, they are going to start crying because you said you don't like something?
Why do you want to buy HDO4000 ? 12 bit resolution? If I were you I wouldn't buy a product that is not finished yet. That would be more of a problem than this irrelevant waveform moving thing.
Do you need 12Bit resolution? If not, get yourself Keysight 3000T/G. That one is fast as you like it. You will get tons of other compromises with that choice though. And those might be important where it matters... Or not. You decide.

But, there is no perfect instrument.

[bdunham7]

On Siglents I have here, it is a visible fraction of a second.. 

I do have to wonder whether that might be done deliberately to give the front end time to settle down after an adjustment...  It does appear to take a bit (a very small bit) longer to get going after a position adjustment than it does from a scale adjustment.

[2N3055]

On Siglents I have here, it is a visible fraction of a second.. 

I do have to wonder whether that might be done deliberately to give the front end time to settle down after an adjustment...  It does appear to take a bit (a very small bit) longer to get going after a position adjustment than it does from a scale adjustment.

I don't have that information. But I know there are things scope has to sort out before continuing. Could it be done faster? I don't know.
It might be that voltage offset circuit needs time to settle to good DC accuracy.
People keep forgetting this is not moving signal plot on screen. Actual analog channel offset function has to offset signal with DC bias. It all has to settle down, otherwise first 10 or 100 triggers (depending on timebase) will have errors until it settles...
What scope does here is mixes in additional DC component, ADC samples that, and then program subtracts DC offset from absolute values and plots waveform in scaled values.

[joeqsmith]

1:  Immediately erases the screen and starts from left side again with changed vertical position.
or
2: Immediately stops the horizontal trace scan  and lets you move what was on the screen up and down. Once you stop, it resets and starts from the left.
or
3: It lets you move trace up and down while simultaneously keep scanning to the right like nothing is happening (except vertical movement, of course)

Thank you.

If you sweep at from 0.5 sec/div and slower my 80's LeCroy 7200 will erase the screen while adjusting, then start to fill the screen from the right to the left (roll mode).   At 0.2 and faster, the screen will display the last data set and return sweeping (left to right) once you stop adjusting.    With the LeCroy 64Xi, no matter if you use the roll mode or not, the screen will show the last data set.   If you display more than one trace, all traces will show the last data collected while adjusting and resume when you stop fiddling. 

I assume my Wavemaster behaves the same as the 64Xi, as they both use the same basic software.   

Of course, as you crank these scopes up, the time that they restart is much quicker.   So fast that you may not think they stopped but they have. 

Has any of this ever been a concern for me, nope.   It's obviously different than the old analog days.   Back then for digital storage, I designed and built a circuit that allowed me to capture the waveforms then play them back to the analog scope.   As shown, channel 1 (yellow) is the waveform and channel 2 is the trigger.  The circuit just keeps dumping the waveform and they trigger keeps it in sync.   You can scroll through the waveform using the delayed trigger output.   Because you may want to capture say a 10 second transient, and the analog scope is not going to have the persistence to show squat,  the box allows you to change the data rate to the scope.  So maybe you capture at 1Hz but you play back at 100kHz.   You can also change the gain and what not.  There was also a printer port but this only supports what ever dot matrix graphic printer I owned at that time.  There was however an RS232 port and I wrote some software for the PC to download and graph the data.  No doubt in assembler back then.      The fun part with it is that it can output a fairly high voltage with a bit of current.  Enough to drive say a small motor or a transformer.   So, you could create some custom transient and dump it like an Arb but with a bit more power behind it.   Funny is the thing still turns on.  Its all wire wrapped. 

... Oh right, there was a point to this.  Because it was driving an analog scope, I always output the waveform  (to keep the display refreshed, again no persistence) no matter what you did with the interface.   I suppose back then, I was thinking things should work like the scopes of the time.

***
tried to clear up some of my mess...

[tooki]

As i wrote in another thread
"like the "zoom out quirk"

it's really incredible what people fixate on. It's just another non issue.

I don't think you fully understand what is going on. What the Rigol seems to be doing is wait until the DSO thinks the user is done adjusting the vertical position for so long that it is perceived as lag. The magic number for humans to experience something without delay is somewhere between 100ms and 200ms. Wait longer, and it is perceived as laggy. So for a fluent user experience (which isn't a non issue!) it is better for a DSO to just try to put traces on the screen while the vertical position is adjusted. This helps both giving visual feedback to the user and prevent perceived lag.

Actually, this makes me wonder whether there is a similar lag / delay on the Rigol when you change the trigger level.

100-200ms are the absolute rock-bottom response times for a UI to not feel sticky like taffy. But if the intent is smooth motion, then sub-10ms response times are desirable. For example, when scrolling on a touch screen. It’s ok if tapping a button then takes 100ms to display the next screen. But if you use a finger to scroll, 100ms is an eternity. A stylus responding in 10ms instead of 100ms is the difference between it feeling like a pen vs feeling artificial. There’s a reason high end mobile touchscreen devices use 120Hz displays (8.3ms). (We can easily see the difference over 60Hz when tracking a fast object around the screen, like during scrolling.) It’s also why mobile OSes don’t rely on re-rendering in real time during pinch-to-zoom: they scale a screenshot (easily done with the scaler in the GPU) and then re-render any time you stop moving. Admittedly with recent models, rendering is so fast that they can keep up in most situations. The transition from GPU-scaled-bitmap to the re-rendered page happens so seamlessly we don’t even notice. (You can provoke this on iOS in Safari by pinch-to-zooming in as close as possible. Then try to zoom in more: it won’t re-render at all beyond the maximum zoom, and you can see some blurriness as it scales the bitmap of the maximum zoom level.) But I remember on the original iPhone (which had less than 1% the raw CPU power of the latest ones), operating on the bitmap “proxies” and other tricks (like tiled rendering) were absolutely critical to UI responsiveness, which is why they wrote an entirely new graphics engine focused on user interface responsiveness.

People “obsess” over it because it matters.

[2N3055]

As i wrote in another thread
"like the "zoom out quirk"

it's really incredible what people fixate on. It's just another non issue.

I don't think you fully understand what is going on. What the Rigol seems to be doing is wait until the DSO thinks the user is done adjusting the vertical position for so long that it is perceived as lag. The magic number for humans to experience something without delay is somewhere between 100ms and 200ms. Wait longer, and it is perceived as laggy. So for a fluent user experience (which isn't a non issue!) it is better for a DSO to just try to put traces on the screen while the vertical position is adjusted. This helps both giving visual feedback to the user and prevent perceived lag.

Actually, this makes me wonder whether there is a similar lag / delay on the Rigol when you change the trigger level.

100-200ms are the absolute rock-bottom response times for a UI to not feel sticky like taffy. But if the intent is smooth motion, then sub-10ms response times are desirable. For example, when scrolling on a touch screen. It’s ok if tapping a button then takes 100ms to display the next screen. But if you use a finger to scroll, 100ms is an eternity. A stylus responding in 10ms instead of 100ms is the difference between it feeling like a pen vs feeling artificial. There’s a reason high end mobile touchscreen devices use 120Hz displays (8.3ms). (We can easily see the difference over 60Hz when tracking a fast object around the screen, like during scrolling.) It’s also why mobile OSes don’t rely on re-rendering in real time during pinch-to-zoom: they scale a screenshot (easily done with the scaler in the GPU) and then re-render any time you stop moving. Admittedly with recent models, rendering is so fast that they can keep up in most situations. The transition from GPU-scaled-bitmap to the re-rendered page happens so seamlessly we don’t even notice. (You can provoke this on iOS in Safari by pinch-to-zooming in as close as possible. Then try to zoom in more: it won’t re-render at all beyond the maximum zoom, and you can see some blurriness as it scales the bitmap of the maximum zoom level.) But I remember on the original iPhone (which had less than 1% the raw CPU power of the latest ones), operating on the bitmap “proxies” and other tricks (like tiled rendering) were absolutely critical to UI responsiveness, which is why they wrote an entirely new graphics engine focused on user interface responsiveness.

People “obsess” over it because it matters.

Yeah but confused what is being talked about here. Screen elements are being refreshed at very fast rate with a frozen capture... Full real time movements. And then you lift finger and then if it restarts capturing new data in 100 ms you won't see the difference. ANd even if there is a fractional perceptive delay, on order of 200-400 ms before it goes on it is not a problem because your attention needs some time to start thinking about what you are doing...
That is the delay we are talking about. At least I am.