Standardised Way To Test Oscilloscope Screen Update Rate - Page 1
Forum section: electronics / testgear

author: EEVblog
author_rank: Unknown
timestamp: April 29, 2024, 06:07:03 am
content: As per this video at around 4:00I'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.

author: boggis the cat
author_rank: Regular Contributor
timestamp: April 29, 2024, 06:20:02 am
content: 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?

author: EEVblog
author_rank: Unknown
timestamp: April 29, 2024, 06:26:10 am
content: Quote from: boggis the cat on April 29, 2024, 06:20:02 amYes, 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.

author: nctnico
author_rank: Super Contributor
timestamp: April 29, 2024, 07:33:21 am
content: Quote from: EEVblog on April 29, 2024, 06:26:10 amThis 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.

author: tautech
author_rank: Super Contributor
timestamp: April 29, 2024, 07:36:43 am
content: 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.

author: EEVblog
author_rank: Unknown
timestamp: April 29, 2024, 07:56:08 am
content: Quote from: nctnico on April 29, 2024, 07:33:21 amSure, 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

author: EEVblog
author_rank: Unknown
timestamp: April 29, 2024, 07:57:55 am
content: Quote from: tautech on April 29, 2024, 07:36:43 amThat's interesting, must not have implemented that in the web interface

author: tautech
author_rank: Super Contributor
timestamp: April 29, 2024, 08:15:45 am
content: Quote from: EEVblog on April 29, 2024, 07:57:55 amCan we ask the FW version in your unit ?

author: m k
author_rank: Super Contributor
timestamp: April 29, 2024, 10:13:24 am
content: Analog optical sensor?Bright part of the screen has a brightness dent.Lightpistolgun used to be a thing.E,the other way then.

author: nctnico
author_rank: Super Contributor
timestamp: April 29, 2024, 10:18:13 am
content: Quote from: EEVblog on April 29, 2024, 07:56:08 amOfcourse 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.

author: tautech
author_rank: Super Contributor
timestamp: April 29, 2024, 10:54:12 am
content: Quote from: EEVblog on April 29, 2024, 07:57:55 amYep.Now requested to be supported in all models.

author: pdenisowski
author_rank: Super Contributor
timestamp: April 29, 2024, 10:59:34 am
content: Quote from: EEVblog on April 29, 2024, 06:07:03 amIf "screen update" means "pixels changed" (assuming a continuously changing input), then I think that's the only wayWe (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.htmlhttps://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/AdVISE_bro_en_3607-3168-12_v0500.pdfI 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"

author: RoGeorge
author_rank: Super Contributor
timestamp: April 29, 2024, 11:21:35 am
content: Quote from: EEVblog on April 29, 2024, 07:57:55 amAn 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).

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 29, 2024, 11:35:12 am
content: Quote from: pdenisowski on April 29, 2024, 10:59:34 amNo 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.

author: nctnico
author_rank: Super Contributor
timestamp: April 29, 2024, 11:58:48 am
content: Quote from: mikeselectricstuff on April 29, 2024, 11:35:12 amThe 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 29, 2024, 12:35:25 pm
content: Quote from: EEVblog on April 29, 2024, 06:07:03 amThis is why I had asked to see those musical X-Y graphing tracks.QuoteSome 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/#msg5446370https://www.eevblog.com/forum/testgear/oscilloscope-music-on-dsos-post-your-results/msg5446613/#msg5446613

author: moerm
author_rank: Regular Contributor
timestamp: April 29, 2024, 01:19:54 pm
content: 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 alreadyhavea 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 gettwopieces 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.

author: XiMMiX
author_rank: Newbie
timestamp: April 29, 2024, 02:32:43 pm
content: 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.

author: m k
author_rank: Super Contributor
timestamp: April 29, 2024, 02:54:57 pm
content: 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?

author: joeqsmith
author_rank: Super Contributor
timestamp: April 29, 2024, 07:40:48 pm
content: 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 ArticlesTest Equipment PrinciplesMorgan Jones, in Building Valve Amplifiers (Second Edition), 2014Refresh rateThe 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.

author: bdunham7
author_rank: Super Contributor
timestamp: April 29, 2024, 09:21:50 pm
content: Quote from: EEVblog on April 29, 2024, 06:07:03 amPerhaps 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.

author: moerm
author_rank: Regular Contributor
timestamp: April 29, 2024, 10:42:44 pm
content: 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 meansonly, 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,whathe 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

author: EEVblog
author_rank: Unknown
timestamp: April 29, 2024, 10:47:04 pm
content: Quote from: nctnico on April 29, 2024, 10:18:13 amAs mentioned in the video, both were at the same waveform brightness setting.

author: EEVblog
author_rank: Unknown
timestamp: April 29, 2024, 10:50:34 pm
content: Quote from: pdenisowski on April 29, 2024, 10:59:34 amYes, "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.

author: EEVblog
author_rank: Unknown
timestamp: April 29, 2024, 10:53:31 pm
content: Quote from: joeqsmith on April 29, 2024, 07:40:48 pmHaving 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.

author: EEVblog
author_rank: Unknown
timestamp: April 29, 2024, 11:01:46 pm
content: Quote from: moerm on April 29, 2024, 10:42:44 pmBasically 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.

author: David Hess
author_rank: Super Contributor
timestamp: April 29, 2024, 11:35:34 pm
content: 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 30, 2024, 01:05:10 am
content: 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.

author: tautech
author_rank: Super Contributor
timestamp: April 30, 2024, 01:10:44 am
content: Quote from: joeqsmith on April 30, 2024, 01:05:10 amYou 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 30, 2024, 01:27:38 am
content: Quote from: tautech on April 30, 2024, 01:10:44 amWindows 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.

author: bdunham7
author_rank: Super Contributor
timestamp: April 30, 2024, 02:21:46 am
content: Quote from: EEVblog on April 29, 2024, 11:01:46 pmYou'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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 30, 2024, 12:47:43 pm
content: Quote from: bdunham7 on April 30, 2024, 02:21:46 amYour 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.

author: Kosmic
author_rank: Super Contributor
timestamp: April 30, 2024, 01:17:52 pm
content: Quote from: joeqsmith on April 30, 2024, 01:05:10 amNot 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.

author: radiolistener
author_rank: Super Contributor
timestamp: April 30, 2024, 01:23:51 pm
content: 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.

author: bdunham7
author_rank: Super Contributor
timestamp: April 30, 2024, 01:42:45 pm
content: Quote from: joeqsmith on April 30, 2024, 12:47:43 pmThat'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.htmlQuoteThose 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.

author: m k
author_rank: Super Contributor
timestamp: April 30, 2024, 02:50:26 pm
content: Is strobo light mentioned.It can at least artificially freeze something.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 30, 2024, 04:38:00 pm
content: Quote from: radiolistener on April 30, 2024, 01:23:51 pmOdd, seemed easy enough to detect. Only problem was manually going through the data.Quote from: bdunham7 on April 30, 2024, 01:42:45 pmInstalled and running. I remember that icon (assume same software) from 20 years ago. Not a fan of the MS media viewer anyway.Quote from: bdunham7 on April 30, 2024, 01:42:45 pmTo record for longer times, I need to reduce the sample rate (camera).Quote from: Kosmic on April 30, 2024, 01:17:52 pmI 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 30, 2024, 04:59:50 pm
content: Quote from: bdunham7 on April 29, 2024, 09:21:50 pmNow that I can view the file, it appears some are even a single line.QuoteAgree. It seems that turning off persistence never really turns it off. I'll try it with mine.

author: bdunham7
author_rank: Super Contributor
timestamp: April 30, 2024, 05:33:07 pm
content: Quote from: joeqsmith on April 30, 2024, 04:38:00 pmI 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.

author: radiolistener
author_rank: Super Contributor
timestamp: April 30, 2024, 07:57:26 pm
content: Quote from: joeqsmith on April 30, 2024, 04:38:00 pmit 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.

author: thm_w
author_rank: Super Contributor
timestamp: April 30, 2024, 09:08:11 pm
content: Quote from: radiolistener on April 30, 2024, 07:57:26 pmIf 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?

author: David Hess
author_rank: Super Contributor
timestamp: April 30, 2024, 10:34:03 pm
content: Quote from: bdunham7 on April 30, 2024, 01:42:45 pmWhen 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

author: joeqsmith
author_rank: Super Contributor
timestamp: May 01, 2024, 12:14:05 am
content: Quote from: joeqsmith on April 30, 2024, 04:59:50 pmOn 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: May 01, 2024, 01:00:06 am
content: 8-level staircase, 10Gsps, dot mode, 1000fps capture. Showing 1 second of data.

author: EEVblog
author_rank: Unknown
timestamp: May 01, 2024, 02:28:29 am
content: Quote from: bdunham7 on April 30, 2024, 02:21:46 amThey are not. I'm sure there are scopes that manipulate the data to provide a more "analog like" display.

author: bdunham7
author_rank: Super Contributor
timestamp: May 01, 2024, 04:02:57 am
content: Quote from: EEVblog on May 01, 2024, 02:28:29 amThat 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.

author: teddychn
author_rank: Regular Contributor
timestamp: July 14, 2024, 02:38:27 am
content: Below are some of my guesses and assumptions:When sending a 1MHz signal into the SDS2000X HD, it looks like each trigger cluster has a period of about 16.28ms, suggesting that the screen update rate could be around 61FPS.Trig_Out-1: 1 cluster = 31 - 14.72 = 16.28 (mS)1 / 16.28ms = 61.43 FPSI know most of us usually think in terms of 60 FPS, but these numbers are just derived from my observations.In another test, 1MHz bursts were sent to see if the trigger signal keeps its tempo. It seems to do so, as the timing is likely to be an integer multiple of 16.28ms. This suggests that the screen might be updating its screen at 61Hz, independent of the signal timing. There's another story for slow signals or processing bottlenecks.Of course, to accurately observe the real delay between the signal and the screen display, a high-speed camera would be needed.Trig_Out-2: (112.6 - 14.72) / 16.28 = 6.01 ≈ 6Trig_Out-3: (373.8 - 14.72) / 16.28 = 22.06 ≈ 22Trig_Out-4: (863.5 - 14.72) / 16.28 = 52.14 ≈ 52In a previous rough test, the SDS2000X Plus was estimated to have a screen update rate of about 30 FPS.