Standardised Way To Test Oscilloscope Screen Update Rate

[EEVblog]

Maybe Dave can (and should) tell us, what he wants to measure. Anyway, thank you Dave! While I'm not happy as an engineer (I was told that measuring is not guessing) I think you created a really interesting topic that I hope will keep our minds busy.

Basically I want to measure how fast the screen is updated with new waveform information.
Assuming the actual (capture) waveform update rate is way faster that human perception (let's say a standard 60wfs or faster), then how quickly is that information relayed to the screen.
Of course this is the #1 thing that the gamer kiddies care about, why should we care about thsi on a scope also.

If two scopes are equal in everything else and one updates the screen waveform at 60wfs and one updates at 5wfs I guarantee you are going to think the 5wfs scope seems "slow"

I like pdenisowski's "pixels changing" definition, so any test source need to have "pixels changing" at a fast enough rate to make the measurement possible.

[David Hess]

I think the old DPO style instruments updated at the display's frame rate, so 30 or 60 Hz.

For measuring the update rate, I would use the same method as used for mechanical camera shutters.  Create a fast series of pulses with a variable but increasing delay, and then measure the width of the captured set of pulses, which will reveal how much time is displayed on each screen refresh, like a streak camera.  This relies on external triggering.

[joeqsmith]

I placed a stopwatch in front of my scope's display.  Connected to a RF generator set to sweep from 5M - 100M.  Very small data set.  Norm trigger.  All processing turned off.  Camera set to 1000fps.   Recorded for 1sec.  Manually counted each screen update.  I measured a pathetic 30fps.  It's an 18 year old PC and based on how poorly it handles the X-Y music, not surprised. 

[tautech]

I placed a stopwatch in front of my scope's display.  Connected to a RF generator set to sweep from 5M - 100M.  Very small data set.  Norm trigger.  All processing turned off.  Camera set to 1000fps.   Recorded for 1sec.  Manually counted each screen update.  I measured a pathetic 30fps.  It's an 18 year old PC and based on how poorly it handles the X-Y music, not surprised.

You may also been able to extract that info from the OS display refresh rate settings if you can stop the boot before the scope app loads.

[joeqsmith]

I placed a stopwatch in front of my scope's display.  Connected to a RF generator set to sweep from 5M - 100M.  Very small data set.  Norm trigger.  All processing turned off.  Camera set to 1000fps.   Recorded for 1sec.  Manually counted each screen update.  I measured a pathetic 30fps.  It's an 18 year old PC and based on how poorly it handles the X-Y music, not surprised.

You may also been able to extract that info from the OS display refresh rate settings if you can stop the boot before the scope app loads.

Windows reports 60Hz refresh but they appear to refresh at half that. 

***
Just to add more detail, I can zoom in to say show only 25 data point on the screen, show dots rather than lines, it seems to top out at 30.   Member Wuerstchenhund had log ago suggest I swap out the CPU stating some significant performance gains.  I don't believe they ever provided me with any data and I have never tried to swap it out.  Maybe it would improve the refresh. 

[bdunham7]

I like pdenisowski's "pixels changing" definition, so any test source need to have "pixels changing" at a fast enough rate to make the measurement possible.

You'd just have to ensure that the waveform rate was higher than the screen rate so that you'd expect new information to be available at every screen refresh.

What is bit  confusing about the video I posted is that the waveform update is set at 60/s (using line trigger) and the 60fps video shows a display update (pixel change) on each and every frame yet there are multiple traces showing.  This is why I was saying that 'screen rate' or 'screen update' may not be simple, clear-cut concepts.

[joeqsmith]

You'd just have to ensure that the waveform rate was higher than the screen rate so that you'd expect new information to be available at every screen refresh.

What is bit  confusing about the video I posted is that the waveform update is set at 60/s (using line trigger) and the 60fps video shows a display update (pixel change) on each and every frame yet there are multiple traces showing.  ...

Your video requires some codec I don't have. 

The nice thing when using the camera, you may be able to see more detail into how they are updating the screen.  At 1000fps capture and only a 30fps screen refresh, it's plenty of data.  I purposely used >MHz signals, normal trigger, and very small data sets in an attempt to make sure they were updating the screen as fast as possible.  With the camera, it appears that the scope is not periodically refreshing.  It seems to stutter or stall at times and then plays catch up.  I had turned off all the readouts and such and set the scope software to the highest screen priority but with Windows not being a RTOS, I am not too surprised. 

[Kosmic]

I placed a stopwatch in front of my scope's display.  Connected to a RF generator set to sweep from 5M - 100M.  Very small data set.  Norm trigger.  All processing turned off.  Camera set to 1000fps.   Recorded for 1sec.  Manually counted each screen update. I measured a pathetic 30fps.  It's an 18 year old PC and based on how poorly it handles the X-Y music, not surprised.

Not long ago (10 years?), 30fps was pretty standard for most application on a PC. Now these days it has increased to 60 - 120 fps for dynamic and responsive application. Nevertheless, 30fps is still present. For example you still find a lot of video games running at 30fps.

[radiolistener]

I think it will be hard to determine refresh rate from high speed video camera capture of the display pixels change, because display has some limited pixel change speed. If there is a way to attach external display it will be better to analyze video signal.

[bdunham7]

Your video requires some codec I don't have.

That's Windows pissing in your ear and telling you that it is raining.  HEVC (h265) has been around for quite a while now, but MS still wants a fee to let you use it.  Download VideoLan if you want a decent video viewer.

https://www.videolan.org/vlc/download-windows.html

It seems to stutter or stall at times and then plays catch up.  I had turned off all the readouts and such and set the scope software to the highest screen priority but with Windows not being a RTOS, I am not too surprised.

Those stutters and stalls are the main thing that makes a display annoying and not 'live'.  I think a consistent 30fps might be marginally sufficient for most people in most cases just like video, but throw in 5 consecutive missing frames every two seconds and everyone will hate it.

[m k]

Is strobo light mentioned.
It can at least artificially freeze something.

[joeqsmith]

I think it will be hard to determine refresh rate from high speed video camera capture of the display pixels change, because display has some limited pixel change speed. If there is a way to attach external display it will be better to analyze video signal.

Odd, seemed easy enough to detect.  Only problem was manually going through the data.   

Your video requires some codec I don't have.

That's Windows pissing in your ear and telling you that it is raining.  HEVC (h265) has been around for quite a while now, but MS still wants a fee to let you use it.  Download VideoLan if you want a decent video viewer.

https://www.videolan.org/vlc/download-windows.html

Installed and running. I remember that icon (assume same software) from 20 years ago.  Not a fan of the MS media viewer anyway.   

It seems to stutter or stall at times and then plays catch up.  I had turned off all the readouts and such and set the scope software to the highest screen priority but with Windows not being a RTOS, I am not too surprised.

Those stutters and stalls are the main thing that makes a display annoying and not 'live'.  I think a consistent 30fps might be marginally sufficient for most people in most cases just like video, but throw in 5 consecutive missing frames every two seconds and everyone will hate it.

To record for longer times, I need to reduce the sample rate  (camera).   

I placed a stopwatch in front of my scope's display.  Connected to a RF generator set to sweep from 5M - 100M.  Very small data set.  Norm trigger.  All processing turned off.  Camera set to 1000fps.   Recorded for 1sec.  Manually counted each screen update. I measured a pathetic 30fps.  It's an 18 year old PC and based on how poorly it handles the X-Y music, not surprised.

Not long ago (10 years?), 30fps was pretty standard for most application on a PC. Now these days it has increased to 60 - 120 fps for dynamic and responsive application. Nevertheless, 30fps is still present. For example you still find a lot of video games running at 30fps.

I wouldn't be surprised if some of the scopes shown in the music thread are running 120Hz.  They are very impressive compared with my scope  running Windows XP.   It's why I had brought up the refresh rate when I asked about buying a new DSO. 

[joeqsmith]

I see between 2 and 4 lines on the screen, indicating a 15 to 30Hz screen refresh rate. 

Now that I can view the file, it appears some are even a single line.   

What is bit  confusing about the video I posted is that the waveform update is set at 60/s (using line trigger) and the 60fps video shows a display update (pixel change) on each and every frame yet there are multiple traces showing.  This is why I was saying that 'screen rate' or 'screen update' may not be simple, clear-cut concepts.

Agree.  It seems that turning off persistence never really turns it off.  I'll try it with mine.

[bdunham7]

I wouldn't be surprised if some of the scopes shown in the music thread are running 120Hz.  They are very impressive compared with my scope  running Windows XP.   It's why I had brought up the refresh rate when I asked about buying a new DSO.

I discovered my phone has a super-slo-mo feature that takes fairly bad video at 960fps.  I don't have time to edit or analyze them right now, but I took two recordings of an 8-level staircase at 10kHz and 1kHz, triggered at 301Hz.  The slo-mo feature apparently produces a video at 30fps with the beginning and end at normal speed and the middle of the video slowed down by 32X (I think).  You can judge the timing yourself by the flashing of the frame of the scope as this is being illuminated by a cheap LED filament bulb that is blinking at 120Hz.

This reminds me of writing video games on very old Z80 and 6502 based computers where the TV adapter would read dual-ported memory at 60 field or 30 frames per second but you couldn't write to the memory nearly that fast unless you had a very simple program.  It looks like that here--you see changes quite often (didn't try to guess the rate yet) but it takes longer to complete them.  The second video, with the staircase at 1kHz, has a nice analog flicker to it in real life and looks quite "live"--no stuttering or stalling at all.

Again, sorry about the .zip format, but YouTube will butcher the video and videos can't be uploaded here.

Edit:  I had a look and it appears that it more or less updates the screen about every two blinks of the lighting, so ~60Hz. 

[radiolistener]

Odd, seemed easy enough to detect.  Only problem was manually going through the data.   

it will be easy if lcd/led matrix is rated for much higher refresh rate than actually used (very much higher). But usually it is close to actual refresh rate or even worse. In such case you cannot see pixel on/off event immediately, it will be very smooth and it will be hard to determine exact frame when pixel appears or disappears.

If video camera uses lossy compression format, it will be even more hard because compression will remove very small change of pixel brightness between frames.

[thm_w]

it will be easy if lcd/led matrix is rated for much higher refresh rate than actually used (very much higher). But usually it is close to actual refresh rate or even worse. In such case you cannot see pixel on/off event immediately, it will be very smooth and it will be hard to determine exact frame when pixel appears or disappears.

If video camera uses lossy compression format, it will be even more hard because compression will remove very small change of pixel brightness between frames.

If on screen trace refresh is keeping up with the LCD refresh, which on any modern scope should be 60-75Hz, then that would be great, perfect A rating, whatever you want to call it. What we are looking at with the siglent was probably sub 20 or 15 fps.
Could have two categories then to make it harder:
1) Single channel, no measurements on, no processing on.
2) All four channels on, 10 measurements on, something like that.

Though I would expect any good modern scope to not slow down noticeable with measurements or multiple traces?

[David Hess]

Your video requires some codec I don't have.

That's Windows pissing in your ear and telling you that it is raining.  HEVC (h265) has been around for quite a while now, but MS still wants a fee to let you use it.  Download VideoLan if you want a decent video viewer.

https://www.videolan.org/vlc/download-windows.html

When I first ran into that problem, I stupidly followed Microsoft's advice and bought the codec though the Microsoft store, which of course never worked.  My prefered solution now is the K-Lite Codec Pack:

https://www.codecguide.com/about_kl.htm

[joeqsmith]

I'll try it with mine.

On my scope, using your setup, they appear to display the latest data with the previous data (two lines).  Next it erases the previous, left with current (one line).  Then turn on the latest data (two lines) and continues to cycle.   So the screen updates at 60Hz but they only update the latest data at 30Hz.   The LCD appears to require a long time to clear so you get a very gradual fade out.   

So with persistence turned off, my scope will also not fully disable it.   

One thing I did try was increasing the trigger to 120Hz to see if they would stack more traces on.  There was no difference.   

No thanks to LeCroy (still not privileged enough to have an account with them), I am running the latest firmware available for this this scope. 

[joeqsmith]

8-level staircase, 10Gsps, dot mode, 1000fps capture.  Showing 1 second of data.

[EEVblog]

What is bit  confusing about the video I posted is that the waveform update is set at 60/s (using line trigger) and the 60fps video shows a display update (pixel change) on each and every frame yet there are multiple traces showing.  This is why I was saying that 'screen rate' or 'screen update' may not be simple, clear-cut concepts.

They are not. I'm sure there are scopes that manipulate the data to provide a more "analog like" display.

[bdunham7]

They are not. I'm sure there are scopes that manipulate the data to provide a more "analog like" display.

That gave me the obvious idea to compare an analog scope with a DSO.  Here's a slo-mo 960fps of a Tek 2221A (in the .zip file) with the readouts turned off, the same 1kHz 8-step signal with a 301Hz trigger and the brightness cranked up.  And then a 60fps video of both side by side.  If you just look at them and then go frame-by-frame, the Siglent DSO is actually remarkably comparable with the behavior of the CRO as far as persistence, fadeout and even the random appearance of the vertical transitions, although those are very faint in real life on the CRO.  So yeah, I assume they went to considerable trouble to mimic CRT appearance.  The photo is a snapshot from the 60fps video, you can see 4-5 lines appearing on each one.