Oscilloscope blind time and waveforms per second - Page 1
Forum section: electronics / projects

author: Nolly
author_rank: Newbie
timestamp: April 26, 2025, 05:21:11 pm
content: Dear colleagues, helloFor training purpose I’m designing a homemade oscilloscope based on an STM32, SDRAM and a 7" screen and now that it’s running pretty OK some questions came up concerning sampling and triggering, and mainly aboutblind timeof scopes andwaveframes per second.For my questions to be clear I made nice schemes, simplified assumptions and will use simple numbers. It’s a mix of questions and what I understood so far.At the moment, and because at first I didn’t want to loose any sample, when in RUN mode, my scope is continuously sampling in circular buffer. Let’s say it does the following (without trigger for now):- it continuously samples at 1MHz,- every VSYNC (say 20ms, 50Hz) it reads the sampled data and plots them.So if I’m at 2ms/div with 10 divisions (green), I read 20 K samples and I can show all samples in real time, given my bionic eyes and brain can interpret information at 50Hz.If I switch to 1ms/div (blue), I read 10 K samples and thus I miss samples, the scope is already half blind.Note: say screen width is 500 pixels, it’s 20 samples per pixel. For every pixel I read 20 samples and keep only the min/max values to be displayed, for each pixel.This is where I am at the moment :-).Now let’s say I switch to 500µs/div, which is 5 K samples, but I’m stubborn and don’t want to miss any sample. It means since the last VSYNC (or whatever processing period) I must read all 20 Ksamples, and somewhatsuperimposeall them together.Does this makes sense? Do the scopes actually do this?Is this the so called ‘persistance’ mode that can be activated? Superimpose all green, all blue, all orange together at each VSYNC.Is thoses 5 K samples window what is called awaveform? in this case, I would have here 4 waveforms every 20ms, which makes 200 waveforms per second. Is that correct? But what the point of having a waveforms/second rate higher than VSYNC, if they can’te be showed up or eye can’t see it (unless using persistence mode)?Shouln’t we show only the last samples?Anyway, here the issues start.First issue, the number of waveforms may be irregular if there is no synchronisation between process period (VSYNC) and div/s. But I guess it’s not so important and noticeable only for slow periods.Second issue, let’s set up a trigger. Trigger somewhat means that events with two different periods must appear synchronised together, that one should has a exact multiple period of the other. As it’s almost never the case, it means that some samples are automatically ditched out.Using a trigger already means it’s not possible to see all the samples. My dreams are in trouble, I stopped sleeping at night. But OK I can coope with this and still want to continuously sample. I will very soon have a memory bandwith issue: how can I continuously write to memory at a decent pace, and periodically in parallel read a fat quantity of samples? Double port memory is too expensive, so yes, double buffering.Looking at my spams email it appears I just won the lotteryso I can now afford a big FPGA with 2 different DDR controllers and 2 separated memory chips.MCU and FPGA could be inside the same chip (SoC). Let’s say since now I have a FPGA I can sample at 100MHz (10ns period) because lower frequency doesn’t really make any sense nowadays. So in 20ms I now have 2M samples. Scope has 4 channels of 8 bits (32bits). I have 16bits DDR3 at 533MHz. It’s 1066MT/s, I need 2 access for my 32 bits data, so it’s like having 533MT/s. Having 100MHz sampling rate there is some room left for memory protocol overhead (precharge, refresh, no idea I’m not so familiar with DDR).Now let’s say I need to read all this back in 5ms maximum to have 15ms free in processing time by the MCU and the screen stuff. It’s 400M transfers per second, I’m already very close to the DDR3 capabilities. And if I want to go faster that the modest 100MHz sampling that exists since the last millenium, the DDR3 can’t follow, and DDR4 will allow to go only 2 times faster. Anything faster (DDR5 on FPGA, ASIC) is out of budget, competencies, manpower since that lottery ticket appeared to be fake. So I think this is the main reason why scopes don’t continuously sample. Am I right here?And as I understand, the higher the sample frequency, the worse (in terms of ratio blind/not blind) it is. But I have a last question here. What if I press pause and want to see older samples that don’t exists, because they were not sampled? I guess this is not possible, and we should use only single trigger mode?What if I want to zoom in a glitch I discovered in ‘persistent’ mode? I guess the data on screen is only a scaled-down data (inside a screen frame buffer), and all raw samples are long gone already.The vendors focus on waveforms per second. Is’t it better to have a high-performance trigger? But if we don’t know on what issue trigger to?Actually I never thought that in ‘run’ mode the scope is actually in repeated ‘run/stop’ mode!Thanks for your patience, I went trough some extended reading before to post this.

author: 2N3055
author_rank: Super Contributor
timestamp: April 26, 2025, 07:06:09 pm
content: This would be a 50 pages white paper if we would go into details.Short summary:- Because scope needs some time to be ready to get new trigger after it captured previous one, there is "blind time"- waveforms per seconds is actually name for how many trigger/capture pairs can scope do in a second.- What is not captured is gone.- Some scopes support segmented mode that deliberately forgoes any processing apart from capture/save to memory to minimize blind time.- Some scopes support history mode, that saves previous triggers. So, in your case, you could go back to a screen where you had the glitch- Segmented and history mode will be limited by memory. Depending on settings it can be 2 captures deep or 10000 captures deep.- Your comment on how blind time is "larger" as you go up the sample rate is partially correct. Generally processing time will tend to have minimum time it has to work, and as you go up the timebase, a ratio of "useful" and "blind" time will change. It is actually a complex table that has to be measured.

author: Someone
author_rank: Super Contributor
timestamp: April 26, 2025, 11:43:25 pm
content: Quote from: 2N3055 on April 26, 2025, 07:06:09 pmThat got confused as some manufacturers used waveforms for things going to the screen, as distinct from segmented (or other non-displayed) modes that you go on to mention. Still no consensus on the terminology.Quote from: Nolly on April 26, 2025, 05:21:11 pmYes, and this will consume as much or more resources as any of the other part of the processing.

author: pcprogrammer
author_rank: Super Contributor
timestamp: April 27, 2025, 06:28:52 am
content: I'm no expert, but have done some coding in this field.With a basic digital scope there will be loss of data, simply because one can't check it fast enough in real time, nor can the hardware itself capture and keep it for very long periods of time. The display has a refresh rate that limits the updating of the waveform on the screen, so why would you capture more data. The additional data would only be useful if it could be examined later in time, and this would require a lot of sample memory.Like 2N3055 wrote the number of waveforms per second is mostly determined by the number of trigger/captures cycles can be done in a second. But this also includes the time needed to get the data into the display frame buffer, otherwise the capturing is useless. There are multiple aspects to what determines this rate, and one can ask itself if it is important.The sampling rate and the length of the buffer used for a capture are the main factors in this. The longer the buffer, the more time it takes to make a full capture. The higher the sample rate, the less time it takes to make a full capture. So the number a manufacturer specifies only makes sense when given in respect to these conditions.Way more important is the trigger setup, and the options given to control it. Simple scopes basically only have the level and edge settings to play with. Depending on the hardware implementation it can be crap too. Take for instance the FNIRSI 1013D, where it is done in the digital domain on the actual sampled data it is kind of useless. Fast glitches are impossible to catch with this when a low sample rate is selected.On the matter of blind time, think back to analog scopes where the beam is swept from left to right and than needs time to go back to the left. This is the blanking time during which the signal is not monitored. When does it matter that parts of the signal goes lost? Mainly when there is actual important information in the signal, like with serial communication. In these cases a logic analyzer is a better tool to be used.And 2N3055 is certainly right that explaining everything on this would take a long white paper.

author: gf
author_rank: Super Contributor
timestamp: April 27, 2025, 10:52:00 am
content: Quote from: pcprogrammer on April 27, 2025, 06:28:52 amMost modern scopes have a digital trigger. As long as the sampling theorem is respected (by ensuring that the signal arriving at the ADC is sufficiently bandwidth limited), a digital trigger is fine, and even at the highest sample rate it is possible to determine fractional-sample trigger point positions by interpolation. At lower acquisition sample rates, the key is to run the ADC and the trigger logic in the FPGA still at the fastest possible sample rate and to downsample to the selected acquisition sample rate before storing the data in the acquisition memory.

author: pcprogrammer
author_rank: Super Contributor
timestamp: April 27, 2025, 03:44:14 pm
content: Quote from: gf on April 27, 2025, 10:52:00 amYes, and that is what is wrong in the FNIRSI 1013D and 1014D, and most likely the follow up models. They process the trigger on the selected sample rate, not the highest possible. So fast glitches can easily be lost.There is nothing wrong with triggering in the digital domain, as long as it is properly implemented.

author: Nolly
author_rank: Newbie
timestamp: April 27, 2025, 07:27:14 pm
content: Quote from: 2N3055 on April 26, 2025, 07:06:09 pmSo blind time is a direct consequence of the combinaison of processing power / sample rate / screen refresh rate. It's not "mathematically" intrinsic. I think it's totally doable to make a no blind time scope for not to high frequencies (until tenth of MHz) and using persistence. The questions is more, do we need it?Same for this, a number waveforms per seconds above screen refrehing rate makes sens only if there is this persistence mode. Actually, we could se the waveforms per seconds of a scope as the smallest time base the scope can process and display without any blind time.I would say that the processing time get smaller in smallest timebases, only if you show the last waveforme, because you capture less samples. But in case of using persistence, the smallest the timebase, the most waveforms are to be captured (and processed), until the scope can't follow anymore.I do not get what is the 'segmented' mode though?Quote from: Someone on April 26, 2025, 11:43:25 pmYes you are correct. You need to read the same number of points, but the highest the number of waveforms, the most loops you must compute (read every waveforme and compare/add to the previous one). Actually in my scope, this is what takes the most processing power, and I spent hours optimizing.Quote from: pcprogrammer on April 27, 2025, 06:28:52 amI came to this conclusion too. It makes sens to capture more waveforms/second only if you use the persistence mode. I would add that we can capture for infinite period of time. We just are limited in number of points "how far in the past can we read". It can actually be usefull also in the case, when you suddently press pause and wants to go back in the past watch your signal without interruption.Quote from: pcprogrammer on April 27, 2025, 06:28:52 amHere I totally agree. A powerfull trigger seems way more interesting than the wavefroms per seconds, butonly if onlyyou know exactly what to look for. Before that, you would need to "see" with your eyes the glitch appearing, to get an idea what to look for. So here the no blind time mode (which is equivalent to a super high waveforms/second + persistence mode) makes sens.Quote from: pcprogrammer on April 27, 2025, 03:44:14 pmI haven't look on this in details already but I think advanted triggered options can only be done in the digital domain (like "window" trigger, for example). You need to compare very preciselly in vertical, horizontal domain, eventually count some events.. I don't see how it can be be easily done in analog with a good amount of precision and be programmable.So in this case, the scope MUST continuously sample. I did not say continuously put into memory, although if we also want the pre-trigger data, so until a trigger cames, literally, the scopes must continuously samples and put into memory until a trigger happens. I also guess the trigger jitter is somehow equals to the sampling period.Anyway I'm not trying to reinvent the wheelThanks for the hints.I just want to take some good direction before continuing my developpement without wasting time on making stuff that doesn't make any sense. I'm also not here to compete with scope manufacturers. I just want to implement basics functions which makes sense, even if not fast, and be able to say with confidence "my demo scope is capable of this, this and this, and theses are the limitations".So I guess, that I can continue somewhat this way:In RUN mode:-Continuously samples and put in memory until I get a trigger, then stop sampling after the requested number of samples to fill the screen has been reached, process, draw-If no trigger happened, show the last new samples anyways when screen asks for a refresh,-Put the "persistence" mode as an option, otherwise always show the last samplesIn SINGLE mode:it's just the RUN mode ran once without persistence mode, and with maximum record length available (since user pressed the button).I may open another thread for FPGA selection because I have zero idea what to do next

author: David Hess
author_rank: Super Contributor
timestamp: April 27, 2025, 09:43:28 pm
content: Quote from: Nolly on April 26, 2025, 05:21:11 pmDPO (Digital Phosphor Oscilloscope) style DSOs work like that, which is effectively what analog oscilloscopes do. Modern non-DPO oscilloscopes from the past 30 years by default do not do this, often because the processing record is too long to process in a reasonable amount of time. It requires high performance hardware to generate a histogram in real time so this is not a budget feature.QuoteThe point is to display as much of the waveform as possible with a minimum of blind time. Fast events which would be lost from being dim could be accented.Note that the original sequential waveform record is not required for most measurements, because most measurements are made on a histogram anyway, so nothing is lost.QuoteWhen I did paper DSO designs a couple years ago, I decided that the best solution is to process the input in real time for the display histogram, updated at the display rate, while simultaneously capturing it into a long acquisition record as budget DSOs do. There is no reason both cannot be done. Now everything which produced the histogram, including the missing parts, are available if the acquisition is stopped.Hardware performance limitations could be accommodated by generating several histograms in various resolutions. If this is done on CPU hardware, then the histogram sizes and display record will be limited by cache size. No discrete memory made is fast enough. FPGAs and ASICs would be limited to their integrated memory and still require parallelization to get the needed performance.

author: gf
author_rank: Super Contributor
timestamp: April 28, 2025, 06:19:52 am
content: Quote from: Nolly on April 27, 2025, 07:27:14 pmThe trigger level comparator in conjunction with the slew rate dV/dt of the signal at the trigger point inevitably turns amplitude noise into trigger jitter. So it depends on the signal. If the signal has fast edges, the trigger jitter can be as low as just a fraction of one sample period (of the highest sample rate), provided that you interpolate and determine the trigger point with fractional sample interval resolution, and honor the fractional offset when drawing the traces. The prerequisite for proper sin(x)/x interpolation is, however, a bandwidth-limited signal, where all frequency components >= sample_rate/2 are sufficiently attenuated. If this is not granted, the interpolation introduces artifacts not present in the original signal.

author: David Hess
author_rank: Super Contributor
timestamp: April 28, 2025, 12:28:26 pm
content: Quote from: gf on April 28, 2025, 06:19:52 amAnother way to think about the aliasing trigger problem is that if aliasing is present, then the sin(x)/x interpolation returns multiple solutions.

author: pdenisowski
author_rank: Super Contributor
timestamp: April 28, 2025, 12:32:02 pm
content: Quote from: 2N3055 on April 26, 2025, 07:06:09 pmOr it could be a 12:29 YouTube videoWe also have a whitepaper (by one of my colleagues) on this topic - only 20 pageshttps://scdn.rohde-schwarz.com/ur/pws/dl_downloads/pdm/cl_brochures_and_datasheets/white_paper/3609_0543_52/Selecting--Why-fast-update-rate-matters_wp_en_3609-0543-52_v0100.pdf