Products > Test Equipment

Standardised Way To Test Oscilloscope Screen Update Rate

<< < (5/10) > >>

bdunham7:

--- Quote from: EEVblog on April 29, 2024, 06:07:03 am ---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.

--- End quote ---

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:

--- Quote from: nctnico on April 29, 2024, 10:18:13 am ---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.

--- End quote ---

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

EEVblog:

--- Quote from: pdenisowski on April 29, 2024, 10:59:34 am ---
--- Quote from: EEVblog on April 29, 2024, 06:07:03 am ---High speed camera and frame anlaysis is one way obviously.

--- End quote ---

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

--- End quote ---

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:

--- Quote from: joeqsmith on April 29, 2024, 07:40:48 pm ---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:

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod