Standardised Way To Test Oscilloscope Screen Update Rate

[EEVblog]

As per this video at around 4:00




I'm thinking about a way to come up with the best and/or most easily test screen update rate (NOT waveform update rate).
High speed camera and frame anlaysis is one way obviously.
Comments invited.

[boggis the cat]

I am thinking about the purpose of the refresh rate.

Perhaps the screen refresh rate is less important than the ability to display the waveform appropriately – so a waveform with a 'glitch' repeated at different rates could be used to test for this.

Would setting an AWG to generate a glitch at different rates be a way to verify that the 'scope is functional?

[EEVblog]

I am thinking about the purpose of the refresh rate.
Perhaps the screen refresh rate is less important than the ability to display the waveform appropriately – so a waveform with a 'glitch' repeated at different rates could be used to test for this.

Yes, in theory the display refresh/update rate shouldn't matter if the scope is designed to or set up to capture the thing you are interested in. Persistance is one obvious way to do that for example.
But often you are just causally using you Mk1 eyeball probing around, in whcih case you don't want your fast waveform capture rate hindered by a slow display update rate.

[nctnico]

I am thinking about the purpose of the refresh rate.
Perhaps the screen refresh rate is less important than the ability to display the waveform appropriately – so a waveform with a 'glitch' repeated at different rates could be used to test for this.

Yes, in theory the display refresh/update rate shouldn't matter if the scope is designed to or set up to capture the thing you are interested in. Persistance is one obvious way to do that for example.
But often you are just causally using you Mk1 eyeball probing around, in whcih case you don't want your fast waveform capture rate hindered by a slow display update rate.

This really is a non-issue which has been discussed before. Any form of high-waveform update rate will have a certain amount of persistence time to make sure the signal stays on the screen long enough to be noticed. Think in order of magnitude of 200ms. Anything below is likely to be missed. If you think about it and think back about the relative long fade times of phosphorus used in CROs, you'll come to the conclusion that the display update period can't be a parameter in the process which shows the signal.

[tautech]

As you know display HW is different so some HW analysis should reveal the reason for apparently faster display rates in SDS2000X HD.

File convertor in the webserver virtual button is a little app to convert BIN files to CSV.
It can also be downloaded to USB from the Save/Recall menu to be then transferred and installed on PC.

Setting the LAN address requires clicking OK and reopening the LAN menu to see the IP DHCP has assigned.

With mouse plugged into the scrope the scroll wheel is available for making numeric field adjustments.

[EEVblog]

This really is a non-issue which has been discussed before. Any form of high-waveform update rate will have a certain amount of persistence time to make sure the signal stays on the screen long enough to be noticed. Think in order of magnitude of 200ms. Anything below is likely to be missed. If you think about it and think back about the relative long fade times of phosphorus used in CROs, you'll come to the conclusion that the display update period can't be a parameter in the process which shows the signal.

Sure, but why does any scope update the display faster than 200ms then?
I for one prefer the apparent faster updating of the 2000 vs the 1000

[EEVblog]

With mouse plugged into the scrope the scroll wheel is available for making numeric field adjustments.

That's interesting, must not have implemented that in the web interface

[tautech]

With mouse plugged into the scope the scroll wheel is available for making numeric field adjustments.

That's interesting, must not have implemented that in the web interface

Can we ask the FW version in your unit ?

[m k]

Analog optical sensor?

Bright part of the screen has a brightness dent.
Light pistol gun used to be a thing.

E,
the other way then.

[nctnico]

This really is a non-issue which has been discussed before. Any form of high-waveform update rate will have a certain amount of persistence time to make sure the signal stays on the screen long enough to be noticed. Think in order of magnitude of 200ms. Anything below is likely to be missed. If you think about it and think back about the relative long fade times of phosphorus used in CROs, you'll come to the conclusion that the display update period can't be a parameter in the process which shows the signal.

Sure, but why does any scope update the display faster than 200ms then?
I for one prefer the apparent faster updating of the 2000 vs the 1000

Ofcourse a 'smoother' fading may look nicer but you are not getting more or less visual information (assuming the visualisation of the signals isn't broken). It is also possible (likely) the persistence setting and/or brightness setting influence the rendering of the signal.

[tautech]

With mouse plugged into the scrope the scroll wheel is available for making numeric field adjustments.

That's interesting, must not have implemented that in the web interface

Yep.
Now requested to be supported in all models.

[pdenisowski]

High speed camera and frame anlaysis is one way obviously.

If "screen update" means "pixels changed" (assuming a continuously changing input), then I think that's the only way

We (R&S) actually make a visual monitoring system, mostly for EMS testing, that detects display changes (max speed is 30 frames / second).  One metric that it reports is how long something stops moving ("motion freeze")

https://www.rohde-schwarz.com/us/products/test-and-measurement/emc-test-software/rs-advise-visual-inspection-software_63493-149761.html
https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/AdVISE_bro_en_3607-3168-12_v0500.pdf

I assume a similar approach could be homebrewed by simply grabbing frames at a very high speed, doing a "diff" on them, and then measuring the time difference between "diffs"

[RoGeorge]

With mouse plugged into the scrope the scroll wheel is available for making numeric field adjustments.

That's interesting, must not have implemented that in the web interface

An USB mouse only sends the displacement+buttons when polled, and the standard HID poll rate is something about 100Hz (don't recall the exact rate, it's in the HID specs).  That is low enough to affect pro gamers, so there are non compliant USB ports, and non compliant USB drivers that can poll a mouse at 200Hz or more.

Another thing, LCD panels are very hard to drive at fast refresh rates, and they are usually working at less than the CRT used to.  Most LCD and/or IPS panels are at 50/60Hz refresh rate, yet they do not flicker to the eye (like a 50/60Hz CRT would), because of the remanence.  Flat panels are very hard to drive at more than 200Hz, and gaming monitors at >150Hz are very expensive.

My guess is the refresh rate in an oscilloscope panel would be a casual 30 or 60Hz, I don't see why I would need more than that, but I didn't measure.

The "slower" update might look so because the memory depth is higher.  A waveform is redrawn on the screen at each trigger, but only after the memory is full (or at least that is how it seems to be for my Rigol DS1054Z).  Because of this, at the same sampling rate, same oscilloscope will appear "slower" when the memory depth is set to higher values.

For slower ADC sampling rates, it might even take seconds to fill something like the 14 mil samples (the max memory in a DS1054Z).

[mikeselectricstuff]

High speed camera and frame anlaysis is one way obviously.

If "screen update" means "pixels changed" (assuming a continuously changing input), then I think that's the only way

No need for a high speed camera though - you have full control of the source signal, so you can create test signals and use a simple single-point optical sensor on a specific area of the screen. 

[nctnico]

High speed camera and frame anlaysis is one way obviously.

If "screen update" means "pixels changed" (assuming a continuously changing input), then I think that's the only way

No need for a high speed camera though - you have full control of the source signal, so you can create test signals and use a simple single-point optical sensor on a specific area of the screen.

The more I think of it, the less I'm convinced this is actually easy to measure. In the end the rendering engine of an oscilloscope needs to pack multiple acquisitions into a rendered image which is not necessarily equal, but likely synchronised to the screen refresh rate to avoid tearing effects. If you look at the trigger output signal from an oscilloscope, you often see a whole bunch of triggers, dead time and another burst of triggers. The dead time is likely the time needed to create the rendering from (pre-processed) acquired data.

Still, sending a single pulse into an oscilloscope and measuring the time until it is rendered onto the screen (using a simple optical sensor) could lead to some interesting data on what the latency (min / max) is between signal input and display rendering.

[joeqsmith]

I'm thinking about a way to come up with the best and/or most easily test screen update rate (NOT waveform update rate).
High speed camera and frame anlaysis is one way obviously.
Comments invited.

This is why I had asked to see those musical X-Y graphing tracks.   

I guess it wasn't clear but my goal wasn't to evaluate the X-Y mode of a DSO.  Rather I am trying to get a feel for how they update their screen.  Granted, its about as revealing as using an AM broadcast band radio to determine how much noise is on your supply rail.   Still, I suspect it would tell me something...  Maybe not..

Some of the new DSO's a very impressive.  My old scopes are worse than the worse ones shown in those threads.   Hard to say if it is a useful metric.


https://www.eevblog.com/forum/testgear/magnova-oscilloscope/msg5446370/#msg5446370

https://www.eevblog.com/forum/testgear/oscilloscope-music-on-dsos-post-your-results/msg5446613/#msg5446613

[moerm]

Possibly an approach that turns out to be not smart, but here's how I'd approach it.

Analysis:
- any optical approach (sensors, cameras, ...) Nope, because that just shifts the problem into a different area instead of solving it sufficiently well (the sensors info must be processed and displayed, etc).
- we already have a display available. Let's use it.
- if there's one factor even a cheap scope can measure sufficiently well it's time/frequency, so let's make use of that. After all the order of what we're (mainly) looking for is ridiculously low (< 1kHz).
- we also have or can get very cheaply another strong (in terms of time) player, namely a (dirt cheap) mcu board thingy.
- It seems we actually want to get two pieces of information, a) the effective screen (aka TFT or similar) update rate, 'effective' as in "no matter who's slow, processing, the display itself, or whatever, we just want to see what we effectively get out of it". And b) the time delta between 'signal in' and 'signal shown'.

Implementation:

I'd express the results on the DUT display in the form of what  a scope can measure and show quite well, frequency.
How? Have a cheap MCU generate pulses that a) provide timing information ("what's the current test frequency?") as well as b) pulse trains which "contain" the currently tried frequency information with a sufficiently long pause in between "shots" (> scope's blind time). So if my current "shot" is at say, 42 HZ the pulse train would contain '42' in binary. Assuming an increasing frequency the last one I see well (clearly) is the upper display update boundary. As for (a) a sufficiently precise "ping" of some frequency, but integer fractions or multiples of 10 MHz may come in handy, should do the trick. And again I'd express some info in a pulse train, e.g. a "marker" every so often. Note however that generating pulse trains of hundreds of MHz will require a fast (~ more expensive) MCU or a FPGA, so probably my first approach at a solution of (a) isn't the smartest.

Please note that those two measurements are made separately as is the kind of information we're looking to gather.

[XiMMiX]

That sounds like using the screen's refresh rate which may not be the actual update rate of the information on the screen.
As a comparison, the screen I'm using on my computer runs at 120HZ but if I'm watching a fullscreen jpg the actual screen update rate is 0.

[m k]

How very slow time is updated, like a heart monitor?

I guess I'm wondering how partial pixel is appearing and can it be manipulated by a test signal.
At least badly scaled screen resolution is clearly visible.
Something like a triangle wave where a vertical step is either bigger or smaller depending how frame start correlates the wave amplitude.

One other, a Moire pattern.
Can the angle of extra raster tell something?

[joeqsmith]

Using a camera to compare them:


Based on the X-Y music plotting, I wouldn't be surprised if my DSO was not slower than the Rigol shown in this video.

***
I have no idea how he has these two scopes configured.   Maybe it's not a good comparison.   Searching EEVBLOG, seems the topic has come up before:

https://www.eevblog.com/forum/testgear/dso-waveform-update-rate-importance-in-practice/

***
Google search:


Chapters and Articles
Test Equipment Principles

Morgan Jones, in Building Valve Amplifiers (Second Edition), 2014
Refresh rate

The screen’s refresh rate has to be fast enough (>80 Hz) for flicker not to be visible, but if the oscilloscope’s memory was only refreshed at this rate we might miss momentary glitches. Ideally, we would like every waveform capture to be followed by another at the first occurrence of the user’s trigger conditions being satisfied, and for all of this data to be written to display memory. In practice, some triggers and subsequent acquisitions may be missed because the oscilloscope’s memory system is not ready to accept data. Although refresh rate can be measured easily enough in terms of waveforms per second, it is hard to specify on a data sheet because it depends on time base setting, record length, triggering, and waveform shape, so vague descriptions like “up to” and “typical” are used. It is rare for an oscilloscope to reveal its refresh rate in use, which is a shame because indication allows the user to iteratively adjust settings to maximise it if necessary. Be assured that a cheaper oscilloscope is likely to save cost by having slower memory and busses that degrade its refresh rate.

Although difficult to specify, a good subjective assessment of a basic oscilloscope’s refresh rate may be quickly made using orchestral music recorded in stereo without data compression. Using analogue audio, connect L to Ch1 and R to Ch2 (or vice versa), select XY mode, select AC auto-triggering, and observe the resulting Lissajous figure. A perfect display would be identical to that produced by an analogue oscilloscope, resembling a continuous ball of wool smoothly pulsing in size and intensity without any jumps, glitches, or discontinuities. Unlike an analogue oscilloscope, a digital oscilloscope is forced to trigger and capture input waveforms before displaying them sequentially as discrete Lissajous figures, and because music is essentially random to an oscilloscope, really basic oscilloscopes fare very badly on this test due to their poor refresh rate.

[bdunham7]

I'm thinking about a way to come up with the best and/or most easily test screen update rate (NOT waveform update rate).
High speed camera and frame anlaysis is one way obviously.
Comments invited.

Perhaps the concept of screen refresh isn't as well determined as we might think--what is and isn't refreshed?  I made a video where I set up a 1MHz sine wave displayed at 1ns/div (so that it would appear as successive horizontal lines) and then set it for a 60Hz line trigger.  This gives me a random horizontal line every 16ms.  With persistence turned off I thought I could determine the screen rate by how many lines appear on the screen, assuming that the scope would write all the events that were triggered during the refresh time.  I see between 2 and 4 lines on the screen, indicating a 15 to 30Hz screen refresh rate.  However, the 60fps video actuallly shows me that the screen changes with each and every frame but the events are not cleared after each--IOW there is still a tiny bit of deliberate persistence even with persistence set to OFF.  So what is the screen refresh rate?

The video is in a .zip file because I can't upload an .mp4 and I didn't want to send it to YouTube because their processing might affect what you see.

[moerm]

Yep, Dave's question is indeed tricky. Quite a few factors at work, panel response time being an important one. But also the human eye; after all Dave seems to relate to what one sees, and it's well known that the resolution rate of that (human) visual perception mechanism is a complex one and not exactly a fast one (a couple of dozen images per second typically) and btw also a complicated one. For instance, what is 'seeing'? Is it the physical perception of optical stimuli -or- is it the "internal image" created by the brain, based, by no means only, on what the "sensor", the eye perceives.

Not too dissimilar the scope situation. Are we talking about how fast a panel can show data input? Or are we talking about e.g. the total time delta between "processor sends (image) data and we see those data on the screen ("wiggly lines")? Or something in between or maybe about something else entirely?

Re. @bdunhams7's "lines": A good thought IMO, and in fact my approach is based on something similar: let the scope itself tell us ...
And also one reason why I don't like the camera or sensor approach. I don't really want (don't think it's the smartest aproach) to count (and correlate!) sensor output or, even worse, camera frames (or lines). Imagine counting say LED flashes instead of using a frequency counter.

And, with all due (and sincere) respect, @joeqsmith, I don't think that "interpreting" something "resembling a continuous ball of wool smoothly pulsing in size and intensity" meets what I'd call measuring (although it might serve well as a crude indicator).

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.

Friendly regards a good week to everyone

[EEVblog]

Ofcourse a 'smoother' fading may look nicer but you are not getting more or less visual information (assuming the visualisation of the signals isn't broken). It is also possible (likely) the persistence setting and/or brightness setting influence the rendering of the signal.

As mentioned in the video, both were at the same waveform brightness setting.

[EEVblog]

High speed camera and frame anlaysis is one way obviously.

If "screen update" means "pixels changed" (assuming a continuously changing input), then I think that's the only way

Yes, "pixels changed".
Hence why random noise at the lowest vertical setting is a good way because it's always changing.
I suspect camera/capture might be the only way.

[EEVblog]

Using a camera to compare them:


Based on the X-Y music plotting, I wouldn't be surprised if my DSO was not slower than the Rigol shown in this video.

I have no idea how he has these two scopes configured.   Maybe it's not a good comparison.   Searching EEVBLOG, seems the topic has come up before:

Having a sine sweep like that at a known sweep rate seems like a good way to get "pixels moving" as pdenisowski put it.
In this case though the Rigol display is not doing this because of slow updating, it's doing it because of a deliberate display processing choice, which is a different thing to memory->screen update rate.
I could indeed technically have a very fast memory->screen update rate but still look horrible like that because they are diddling with the data.