The battle: High waveform update rate versus low screen refresh rate - Page 1
Forum section: electronics / testgear

author: pascal_sweden
author_rank: Super Contributor
timestamp: January 14, 2017, 12:18:48 pm
content: Maybe I miss something here, but isn't it true that a high waveform update rate will not necessarily help to see all glitches on the screen due to the low screen refresh rate?For example: 100.000 waveforms/sec versus a screen refresh rate of 100 HzMy understanding is that you will only see those random infrequent glitches if you have enabled a trigger on them, but that otherwise you might as well miss out on seeing them due to this bottleneck of high waveform update rate versus low screen refresh rate.Without a proper trigger configuration, the software can not be that intelligent that it ensures that a particular glitch waveform out of these 100.000 waveforms should make it in one of the 100 displayed waveforms that are part of the screen refresh rate sequence.The only way to see all those random infrequent glitches, even without a proper trigger configuration, would be to play back the captured waveform in slow-motion mode, just like you would do with a high-speed camera for recording fast-moving objects. But this is impractical, and not in line with the general troubleshooting practices that are done with an oscilloscope on a live signal.

author: Daruosha
author_rank: Regular Contributor
timestamp: January 14, 2017, 01:32:31 pm
content: let's assume you have a glitch happening 1 in a million cycle and your screen refresh rate is 100 Hz, if you are very lucky and scope captures that glitch and displaying in just one frame of 100 frames per second, your eyes cannot capture that particular frame. So:I guess all the DSO's have some sort of display persitancy (in the menus it's "min" not 0). So it all depends on the amount of persistency and manufacture decision to convert waveform capture to screen display timing.That is my guess, could be totally wrong.

author: ebastler
author_rank: Super Contributor
timestamp: January 14, 2017, 01:59:15 pm
content: I'm seconding Daruosha's answer, just trying to paraphrase it:Your DSO will always accumulate multiple waveform scans in its screen buffer and display them together. With graded intensity displays, a pixel shown on the screen will become brighter if it has been scanned multiple times; with the simple non-graded displays, all pixels which have been scanned at least once will light up in the same intensity. In either case, the scope's persistence setting will determine how long the display "remembers" a scanned pixel, before letting it fade away or switching it back to black entirely.Hence, even with a slow screen refresh rate you will see rare event traces light up (dimly in case of a graded intensity display) if the persistence setting is adequate. The screen refresh rate is not relevant for seeing rare events. It has other benefits: A high screen refresh rate will make for a smoother interactive handling of the scope, and will make it more pleasant to visually follow changes of the waveform over time (say on a 1..5 Hz timescale) without getting a "jerky" picture.Of course, when you are looking for really rare events, youshouldset a suitable trigger to freeze the rare waveform when it occurs. That's why you are using a DSO and not an analog scope, right?

author: H.O
author_rank: Frequent Contributor
timestamp: January 14, 2017, 02:04:03 pm
content: (ebastler beat me to it but since I've already written it I'll let it go thru).If the screen updates at 100Hz and the waveform update rate is 100.000 wfrms/s, ie the scope triggers 100.000 per second with the particular signal you happen to have connected at the moment then the scope aquires 1000 waveforms and overlays them on top of each other in the part of the the memory that the screen rendering code reads from.Exactly how this is done probably differs between makes, models etc etc etc.

author: pascal_sweden
author_rank: Super Contributor
timestamp: January 14, 2017, 02:22:42 pm
content: Thanks for all the explanations! Now I finally understand how it works.Essentially the digital implementation with overlaying multiple waveforms on each other, resembles the phosphor persistence on an analog scope.But still there are blind times on a digital oscilloscope, where it can miss out on a trigger.Why don't they use a pipelining mechanism like in a microprocessor architecture to avoid this?This would avoid blind times completely!

author: ebastler
author_rank: Super Contributor
timestamp: January 14, 2017, 02:35:28 pm
content: Quote from: pascal_sweden on January 14, 2017, 02:22:42 pmWell, if the time it takes to process a chunk of data (e.g. check whether there was a trigger event) is longer than the time it takes for that chunk of data to be acquired, then all pipelining does not help you. If your data processing cannot keep up with the incoming data rate, you will need to drop part of the incoming data, resulting in blind times.R&S has an application note which tries to illustrate that, and discusses the effect of blind times. (And, of course, explains the great quality of R&S scopes in this respect.)https://cdn.rohde-schwarz.com/pws/dl_downloads/dl_application/application_notes/1er02/1ER02_1e.pdf

author: nctnico
author_rank: Super Contributor
timestamp: January 14, 2017, 07:16:28 pm
content: Quote from: pascal_sweden on January 14, 2017, 12:18:48 pmOMGThis has been explained a million times already. What you see on the screen is an accumulation of sweeps. The real update rate of the traces could be 5 times per second and it still looks instant.

author: BravoV
author_rank: Super Contributor
timestamp: January 14, 2017, 07:18:46 pm
content: Hey pascal_sweden, what is your current scope ?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 14, 2017, 07:29:20 pm
content: This is what the intensity control is for. At maximum it will show everywhere there had been a 'pixel' in that screen refresh period at full brightness ( maybe plus some persistence). At lower settings, the brightness indicates how often there has been a pixel at a particular location.

author: tautech
author_rank: Super Contributor
timestamp: January 14, 2017, 08:24:21 pm
content: Quote from: pascal_sweden on January 14, 2017, 02:22:42 pmAnd on a CRO.......

author: Someone
author_rank: Super Contributor
timestamp: January 15, 2017, 01:13:16 am
content: Quote from: pascal_sweden on January 14, 2017, 02:22:42 pmYou cant freely add pipeline stages to the computation of a histogram because consecutive points (or many of them) might lie in the same bin. The "fix" for this grows with a power law of at least 2 and would blow out in resources beyond a few clocks of pipeline+latency. Or you can look at just how much data flies around in a modern scope:https://www.eevblog.com/forum/testgear/comparing-agilent-infiniivision-2000-and-3000-x-series-oscilloscopes/msg1010059/#msg1010059

author: nctnico
author_rank: Super Contributor
timestamp: January 15, 2017, 01:21:02 am
content: Pipelining isn't going to help to avoid blind time because there will always be the time between the end of the screen and the next trigger.In theory you could stop writing the trace on a screen when a new trigger occurs and start writing that trace from the trigger point. That leaves an interesting debate on what to do with the rest of the trace. Copy it so the screen is filled until the end or leave the rest of the screen blank. Copying it isn't as bad as it sounds because you have multiple sweeps (aqcuisitions) on the screen anyway but it could be the same anomaly is displayed twice which could confuse the operator.

author: Someone
author_rank: Super Contributor
timestamp: January 15, 2017, 02:14:54 am
content: Quote from: nctnico on January 15, 2017, 01:21:02 amHow about you read the link above, where its discussed how a scope could have zero blind time. But the technology is prohibitively expensive for now. If you put every valid trigger from a signal overlaid you wouldn't see multiple anomalies but several different perspectives of it.

author: nctnico
author_rank: Super Contributor
timestamp: January 15, 2017, 03:27:44 am
content: Your method still doesn't deal with the situation where an anomaly may occur between the edge of the screen and the next trigger. And there is more wrong with the line of reasoning. Creating an intensity graded display shouldn't need that much memory or bandwidth because the display data needs 1000 pixels in the X direction at most. It is easy to run two acquisition systems in parallel. One which does the high speed intensity graded display and the other which does the long acquisition (which is close to the method I used to build an oscilloscope-ish system for one of my customers).

author: Someone
author_rank: Super Contributor
timestamp: January 15, 2017, 04:32:05 am
content: Quote from: nctnico on January 15, 2017, 03:27:44 amSounds like you're falling into the hole everyone else who walks into this does, if the data is arriving at 10GS/s and you can paint each sample to a 1000px display how do you aggregate that down? A video memory the same size as the display with read-modify-write cycles is limited by the available bandwidth, and hiding any latency or pipelining requires more resources again.Circular/paged buffers to capture every single trigger is a nice idea that is possible and could have zero blind time, you'd only miss what was too far away from a trigger to fit on the screen which is a problem no matter how fast the update rate is.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 15, 2017, 04:54:59 am
content: You don't really need to use memory acquisition pipeline to do real-time processing. You can have a separate pipeline which continuously looks for the trigger, and as soon as the trigger is found sends the waveform data centered over the trigger (while all the data points are spread along the pipeline) to the processing. This way you can avoid all gaps and even acquire overlapping screens. And this doesn't require any extensive resources.This process will spew out frames, which can come out really fast. Depending on what you're doing, you may not be able to process all the frames coming out. Although if the process only requires bin counting then you probably can easily do 100MFrames/s with a decent FPGA, and you probably don't need any more than that. Someone just need to sit down and write an optimized code to do so.So, eventually we'll get gap-free and even overlapped acquisitions with unlimited waveforms. I don't see why it cannot be done today, but I would guess there's not enough marketing reasons.

author: Someone
author_rank: Super Contributor
timestamp: January 15, 2017, 05:56:18 am
content: Quote from: NorthGuy on January 15, 2017, 04:54:59 amAgain, if you're so sure its easy then do the "back of the envelope" design for us and share. Getting giga samples per second to a screen is very hard, which is why the easy way out is to just dump triggers to segmented memory and then go through them at a leisurely pace. Doing it sustained is what needs the impossibly large bandwidths.

author: djnz
author_rank: Regular Contributor
timestamp: January 15, 2017, 07:04:38 am
content: Quote from: tautech on January 14, 2017, 08:24:21 pmJust out of curiosity, any idea what the blind time or the wfms/sec spec of old Tektronix analog scopes (like the 2xxx series or the 7000 series) is?

author: ebastler
author_rank: Super Contributor
timestamp: January 15, 2017, 07:38:49 am
content: Quote from: djnz on January 15, 2017, 07:04:38 amFound this measurement right here on the forum:https://www.eevblog.com/forum/testgear/waveform-update-rate-digital-vs-analog-(ds2000-vs-tek-2465)/

author: tautech
author_rank: Super Contributor
timestamp: January 15, 2017, 07:53:17 am
content: Quote from: ebastler on January 15, 2017, 07:38:49 amWhich implies the Tek would have a better chance of displaying some random non-repetitive glitch......not without persistence phosphors it wouldn't.This the tradeoff between CRO's and DSO's, with witch glitches can becaptured.In a DSO you have a few friends to narrow the gap...Trigger suite, GSa/s, Mpts and waveform update rate, all of which when high spec'ed the better.

author: rf-loop
author_rank: Super Contributor
timestamp: January 15, 2017, 09:17:34 am
content: Quote from: tautech on January 15, 2017, 07:53:17 amWith analog scopes it is more complex.This example table (DS2k vs Tek 2465) is calculated, not true. This table forget totally one important thing. Phosphor write speed. In this table phosphor visual writing speed default looks like infinite. This table forget totally one important thing. Phosphor write speed.Tek 2465B Phosphor P31, Visual writing speed>20 divisions/µs. (really slow)With this data, try one single shot 20ns pulse using 5ns/div or 500ps/div and intensity max. Result: visually total blind (but trig led indicate it - of course). This table can not use at all for thinking how it can display random single glitches in practice. If include phosphor writing speed to calculation in table, it looks totally different. Of course example 2467B or 7104 are different due to different tube, MCP and its visual drawing speed is in different class. Around 4 division/ns. Visual blind time is really very bad in analog oscilloscopes fir single random glitches. Nearly hopeless to even try hunt rare fast glitches using analog scope. With MCP tube it is bit better.How about if there is analog memory/variable persistence CRT. Like example in HP 1741A. Yes, there is persistence / memory. Try single shot 10ns 6div height pulse. Result: totallly blind. In normal mode and in memory/persistence mode. (CRT)memory writing speed is also quite slow 200cm/µs.Edit: repaired ALT+230 = µ

author: Fungus
author_rank: Super Contributor
timestamp: January 15, 2017, 10:31:30 am
content: Quote from: pascal_sweden on January 14, 2017, 02:22:42 pmBut nowhere near as many as on a CRO. Whichever way you look at it, a DSO is better in this regard.Quote from: pascal_sweden on January 14, 2017, 02:22:42 pmIt would make the 'scope very expensive and you'd still have to sit for hours staring at the screen trying not to blink in case you miss something.Better idea: They could let you set a pass/fail mask on screen. If any wave goes outside the defined area then it gets flagged/counted. That way you can go away and have a sandwich while the 'scope does all the work.

author: ebastler
author_rank: Super Contributor
timestamp: January 15, 2017, 11:12:03 am
content: Quote from: Fungus on January 15, 2017, 10:31:30 amThat statement does not seem right. As discussed above and in the CRO/DSO comparison I had linked to, the actual duty cycle of CROs is typically better than for a DSO. I.e. the percentage of blind time is shorter on a CRO, and it should miss fewer triggers, right?But, as explained by rf_loop, the fact that the CRO has actually noticed that rare event and scanned it once may not help you much -- since you probably won't be be able to see the resulting, very dim trace.

author: nctnico
author_rank: Super Contributor
timestamp: January 15, 2017, 11:15:43 am
content: Quote from: Someone on January 15, 2017, 04:32:05 amThe only thing which needs to happen in real time is counting which sample value gets hit how many times. If you use the sample value as the address then a 1024*256*Y bit memory is more than enough which is in the realm of fast (FPGA) memory. In an ASIC it is a piece of cake nowadays but there is probably a more clever way of doing this which needs way less memory. Using double buffering techniques you can have this running continuously while the post processing paints a pretty picture on screen. You should not design a system like this in a way it needs to write to something like video memory directly because you'll run into bandwidth problems indeed. There has to be a step in between which deals with the accumulated data.

author: Fungus
author_rank: Super Contributor
timestamp: January 15, 2017, 12:45:43 pm
content: Quote from: ebastler on January 15, 2017, 11:12:03 amOK, I guess you're right there. The overall blind time of a CRO could be less.On balance I'd say the DSO would win in a straight competition to find runt pulses though:a) A DSO can set infinite persistence so the traces don't fade away (no need to worry about blinking).b) Even entry level DSOs have pass/fail testing these days. You can go for lunch and it will count them for you.

author: ebastler
author_rank: Super Contributor
timestamp: January 15, 2017, 01:17:08 pm
content: Quote from: Fungus on January 15, 2017, 12:45:43 pmI fully agree on that one. Pass/fail analysis and advanced triggers, plus the ability to capture and store scans so one can view them comfortably, obviously put DSOs ahead of analog scopes when one is hunting for rare events.[Having written that categoric statement, I am sure someone will now point out the rare situation where that is not the case...]

author: Fungus
author_rank: Super Contributor
timestamp: January 15, 2017, 01:46:13 pm
content: Quote from: ebastler on January 15, 2017, 01:17:08 pmAnd I'll agree that analog scopes are prettier and nicer to use.Seeing the faint rogue trace next to the bright regular traces on a green screen is a joy.(...so long as they happen often enough to see easily. If you have to attach the camera then do a long exposure and develop the film to see them? Not so much)

author: pascal_sweden
author_rank: Super Contributor
timestamp: January 15, 2017, 03:30:56 pm
content: Quote from: nctnico on January 15, 2017, 11:15:43 amLet's build this scope! Shall we use a Zynq-7000 MPSoC?

author: NorthGuy
author_rank: Super Contributor
timestamp: January 15, 2017, 03:51:09 pm
content: Quote from: Someone on January 15, 2017, 05:56:18 amApparently, when a scope stops, you can go through the acquisition memory and do it at a leisurely pace. I'm sure many scopes do that.But, while the scope runs, you need to do your processing at the same speed as new data arrives. At such high speeds, it is better done through a separate path directly to the screen (bypassing memory). Such path would produce surrogate data (such as bin counts) in real time. Then this surrogate data would get converted to pretty pictures at 60 Hz. I don't see anything hard about this.I think most, if not all, current scopes work differently. They acquire data into the memory and at the same time they read memory to compose a picture on the screen. This is not the best for the memory because the memory needs to switch direction all the time. This leads to poor memory performance, inability to acquire all triggers. This produces gaps, limits the number of waveforms than can be processed per second. However, if the memory was used for write-only during the acquisition, most of these problems would be solved.Not to mention, the memory industry made a really good progress. You can buy 32GB of fast DDR3 memory for about $200. Scope makers do not follow the trend. Even 140Mpts which you can find in some scopes sounds really pathetic. With 32GB, you could store full 4 seconds while sampling 4 channels at 2GSa/s.It would be an interesting project to design a better acquisition system, but I don't have neither time nor money to do that

author: pascal_sweden
author_rank: Super Contributor
timestamp: January 15, 2017, 04:15:09 pm
content: What about dual-port memory? Did the industry forget about this concept?

author: ebastler
author_rank: Super Contributor
timestamp: January 15, 2017, 04:23:05 pm
content: Quote from: pascal_sweden on January 15, 2017, 04:15:09 pmYes, I'm sure that's the case. Those engineers in the T&M industry are a bit haphazard and need a reminder from a random hobbyist every now and then.

author: bktemp
author_rank: Super Contributor
timestamp: January 15, 2017, 04:27:46 pm
content: Quote from: pascal_sweden on January 15, 2017, 04:15:09 pmDual port memory is typically SRAM. And SRAM is insanely expensive compared to DRAM.Looking at digikey, the biggest dual port RAMs are 36MBits and you pay about $10 per Mbit compared to about 0.002$ per MBit for DDR3.There may be some niche applications, but it is much cheaper to simply add a second DDR3 memory and fill one while reading the other one.

author: Someone
author_rank: Super Contributor
timestamp: January 15, 2017, 11:53:25 pm
content: Quote from: nctnico on January 15, 2017, 11:15:43 amDo the maths on that histogram module, you're disputing my figures but won't provide your own analysis? For a 256 level grading of 1024*256 you need 2Mb (megabits) of ram, now select your desired bandwidth and divide that out by the 300-400MHz that FPGA ram might run at. Its a lot of ram! This hypothetical case of a zero blind time 10Gpts/s system needs at least 10GT/s so you'd need a parallel array of 25 400MHz rams to absorb that data, bringing us quickly up to 50Mb (megabits) of ram just to draw the display which is the top end of production FPGAs ($3000 and up) and it needs one of those per channel.Quote from: NorthGuy on January 15, 2017, 03:51:09 pmDo the numbers for yourself if you don't believe me, it is very expensive to accumulate histograms at billions of points per second. You need completely random access with no predictable patterns to the data which only low latency ram can provide. DRR has had relatively static latencies going forward:https://en.wikipedia.org/wiki/DDR3_SDRAM#LatenciesSo while they can provide sufficient raw throughput a truly random access pattern could only achieve 100MT/s or so, now you're looking at 100 DDR ram interfaces to stuff the 10Gpts/s into which just isn't feasible (and doesnt even count the overheads yet). There are shortcuts which can produce a nice looking display, but they won't produce intensity graduated images any more and will miss some of the information you can get from a fully graded image. This is why some people prefer to still have a scope with min-max (envelope) capture so they can be sure they didn't miss any outliers.Quote from: bktemp on January 15, 2017, 04:27:46 pmDual port ram is very beneficial to this application, but the latency of the interfaces still complicates it.

author: nctnico
author_rank: Super Contributor
timestamp: January 16, 2017, 12:06:05 am
content: Quote from: Someone on January 15, 2017, 11:53:25 pmI don't work for free but I'm quite certain I can get this to work with one or more high performance FPGAs. You also need to take into account how signficant one sample is for what is displayed. If your screen is 1000pixels wide and you sample continously at 10Gs/s then each vertical line is updated at a rate of 10MHz. To make a nice round number let's assume 10 screen updates per second. This means that each sample counts for only 1 millionth of what ends up on the screen. If you do a min/max average number for 2048 consequetive sweeps (which only needs a couple of bytes of fast memory per vertical line x 1000= -say- 4096 bytes) you can still create an intensity graded display with 256 levels and you'll only need to process these values at a rate of 5kHz. With those rates you can easely use DDR memory. Again: it is all about reducing the datarate to manageble levels.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 16, 2017, 01:33:48 am
content: Quote from: Someone on January 15, 2017, 11:53:25 pmI did the math. First of all, you only need one copy of the "histogram" per channel, which you need to update only when you get a trigger and a frame.By my count, for 2GSa/s sampling rate, a reasonable maximum frequency for triggers to occur is about 100MHz (100 millions waveforms per second). Once this happens, you have a number of points equal to the width of the "histogram" and you just update the histogram with new data. This operation can be done in one clock, so you need FPGA to run at 100 MHz. Even entry level FPGA can do it. And if you want to be able to get more than 100 millions triggers per second, you need to fork over more money for better FPGA, which is not a big stretch of imagination given current prices for 10GSa/s scopes.Quote from: Someone on January 15, 2017, 11:53:25 pmThat's exactly what I'm saying. If you want truly random read-write access to small pieces of data you lose lots of the memory bandwidth. So, you shouldn't do it. Period. While you acquire data you write-and-write-and-write and you can get nearly full bandwidth. Assume 4 channels at 2Gs/s. This is 64Gb/s. You can accept this sort of traffic with one dual rank DDR3-1066 DIMM, and you certainly won't have any problem with DDR3-1333. These are on the bottom of the range in current market and won't require top-of-the-line FPGA to drive.How do you update the screen then? You get a separate pathway for you data to the screen which updates your "histograms" at every trigger and re-draws your data real-time at 60Hz. This pathway doesn't use DDR memory and is done completely by FPGA. I tried to explain this in my previous posts.Once the scope stops, you stop writing to the DDR memory and now you read-and-read-and-read, which also gives you almost 100% of the DDR memory bandwidth, so you can update the screen with more detailed data really quick. Makes sense?

author: Someone
author_rank: Super Contributor
timestamp: January 16, 2017, 01:59:42 am
content: Quote from: nctnico on January 16, 2017, 12:06:05 amAnd then you lose the primary value of the graded display which is catching the singleton events and points, reducing it loses the purpose and becomes something else. You don't want an eye diagram that misses the rare events, or a "graded display" using min/max/average that eliminates the probability distribution of points on the display where you can't tell a sine wave from a square wave from multilevel data. There are good reasons histogramming is used, yes its possible with a lot of brute force:Quote from: Someone on January 15, 2017, 11:53:25 pmBut you felt the need to remove that from your quote.Quote from: NorthGuy on January 16, 2017, 01:33:48 amThere is no way to compute a 2D histogram in a single 100MHz clock cycle, the maths isn't there. Histogramming is an expensive operation and doesn't scale well. If you have such an algorithm we'd love to see it but you're just dreaming at this point.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 16, 2017, 02:11:11 am
content: Quote from: Someone on January 16, 2017, 01:59:42 amYou just increment a selected bin (cell) based on the point value(0 to 255). This certainly can be done in one clock. Why not?Everything else can be done at 60 Hz.

author: David Hess
author_rank: Super Contributor
timestamp: January 16, 2017, 04:25:44 am
content: Quote from: ebastler on January 15, 2017, 01:17:08 pmA MCP (micro channel plate) CRT like that used in the Tektronix 7104 (1 GHz 10cm/ns), 2467, 2467B (400 MHz 4cm/ns), or 11302A (500 MHz 6cm/ns) can visibly write its fastest sweeps. On a 7104, the apparent visible writing rate can be faster than the speed of light. These are great for watching infrequent glitches in real time.Fast storage CRTs used in oscilloscopes like the Tektronix 7834 and 7934 (500 MHz 4.4cm/ns) have a fast storage target which supports much higher writing writes than the direct view phosphor screen. Multiple sweeps can be written and then transferred. These are cumbersome to use but better than nothing..I think some of the Tektronix scan converter CRT based instruments could write multiple fast sweeps to the target and then transfer the accumulation for display. Some of these were much faster than 1 GHz because they could take advantage of a much smaller total deflection than a reasonably sized visible display would require.None of these would be as convenient as a DSO.

author: Someone
author_rank: Super Contributor
timestamp: January 16, 2017, 05:42:15 am
content: Quote from: NorthGuy on January 16, 2017, 02:11:11 amIf the display is 1000 pixels across and you consider only the case where the 10GSa/s signal is neatly sitting with one sample per colum, then yes you can do the histogram in a single cycle if every column of the display is a separate ram, so you've gotjust1000 rams. Its possible for that narrow case but it falls apart when you switch to lower sweep speeds and all of a sudden you need to accumulate x000 points into a single vertical column one after the other, so now you need a 10GT/s fifo in front of each of the 1000 column rams, it spirals out of control.

author: David Hess
author_rank: Super Contributor
timestamp: January 16, 2017, 05:58:24 am
content: Quote from: djnz on January 15, 2017, 07:04:38 amThe worst cast minimum holdoff time for a faster 7000 mainframe depends on the timebase which makes the blind time and sweep rate easy to calculate from the specifications. The 400 MHz and faster timebases have a worst case minimum holdoff time of 2.0us so with a sweep of 200ns/div, the blind time should be about 50% at 250k sweeps/second which is what I measured on my 7904. At 10ns/div, the blind time was about 93% at almost 500k sweeps/second.I measured the holdoff time of my 2445B at about 2.7us so it is a little slower than my 7000 mainframes but not significantly so. My other 22xx oscilloscopes do not have gate outputs so it is not easy to measure them.

author: David Hess
author_rank: Super Contributor
timestamp: January 16, 2017, 07:31:30 am
content: Quote from: Someone on January 16, 2017, 05:42:15 amFIFOs do not solve the discrepancy between input data rate and processing speed. At some point the FIFO fills up and waiting begins.At slow sweeps you might as well produce a 256 word 1D histogram to be merged with the 256 word x display width 2D histogram. Conveniently this problem is easy parallelizable. Demultiplex the incoming data, which is already being done, and write to multiple 1D or 2D arrays which are then merged.That will really hurt getting a 10GS/s stream down to 20 x 500MS/s streams but consider a lower bandwidth and sample rate design where 1 GS/s is demultiplexed down to 4 x 250 MS/s and it almost seems reasonable. Now 256 16-bit words x 1000 horizontal points is 512kbytes per partition and 2Mbytes per ping-pong buffer. Each FPGA is still going to cost more than a low end DSO but at least they exist.What about a useful design? With equivalent time sampling we only care about capturing glitches that fit through the bandwidth and we have lots of acquisitions to create the histogram. That might cut the sample rate again by 4 and if the display is 10 horizontal divisions of 50 points, then each buffer is only 256kbytes. Now the FPGA costs under $200.All of these designs throw away a long record length in DPO mode but so does the Rigol DS1000Z that everybody likes. Marketing is not going to like that though.

author: Someone
author_rank: Super Contributor
timestamp: January 16, 2017, 08:12:51 am
content: Quote from: David Hess on January 16, 2017, 07:31:30 amThe fifos buy time to trickle the data through the histogram process, but they only have finite length and at some point in that design as you reduce the horizontal display you cant store enough data in them. There are many ways to skin the cat but they arent easy, simple, or low cost in implementation if you want to draw sustained GS/s to a screen. Even with only 1GS/s it still requires a lot more than just a chip or two of SDRAM. But you're certainly right that for fast triggered data ETS is still a good option.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 16, 2017, 04:19:38 pm
content: Quote from: Someone on January 16, 2017, 05:42:15 amSince this is all done for the display, you only pick points which would fit into pixels (by simply selecting, averaging, or whatever) relative to the trigger position and work with them. Clearly, the worst case scenario is when the scope is at the highest horizontal resolution. If the user zooms out, the down-sample will decrease the number of points (e.g. if the distance between consecutive pixels is 1us then new frames can only come at 1MHz), so the timing only gets more relaxed.The scope's screen is only 800 pixels (for most of the scopes anyway), less margins which gives you 700 pixels. If you use 256 vertical resolution, it's 179k cells in your "histogram". If you use 8 bits per cell, you need 1.4Mbits per channel, which is not that bad.However, you can use as little as 1 bit per cell. In this case you only know if the pixel has been seen since the last screen update or not (which updates at 60Hz). But this is enough to create very nice phosphorous display. In this case, you only need 179kbits per channel, and this only requires a very modest FPGA.

author: David Hess
author_rank: Super Contributor
timestamp: January 16, 2017, 08:06:44 pm
content: Quote from: NorthGuy on January 16, 2017, 04:19:38 pmI was thinking it would be better to decimate the input throwing samples away to meet the maximum update rate to the 2D histogram. This is easy if external triggering is used (this is how ETS works) but in an all digital design, the undecimated samples could be used to drive the trigger in parallel. Note that the histogram cannot be started until the trigger is recognized so there a short circular buffer before writing the histogram to support a pretrigger record.The problems with what you suggest are that any extra calculation needs to be avoided in this critical path (1) and if you throw away samples based on how well they "fit", it corrupts the statistical properties of the histogram. The R&S paper states that DPO display processing limits measurements but this is incorrect if the statistical distribution is not corrupted. I think their marketing is playing sour grapes like LeCroy did with digital triggering and Rigol does with record length:Additionally, no or limited analysis functions are available with such fast viewingmodes. Processing tasks in combination with the standard mode remain timeconsuming.QuoteAnalog sampling oscilloscopes produce a display like this but to be useful, the number points points needs to be controlled or the display fills in effectively becoming envelope detection. An implementation where the user controls the decimated sample rate to adjust the fill would be interesting but at such low sample rates, 10s to 100s of ksamples/second, you have plenty of time to generate a deep histogram so this operating mode makes no sense.(1) I would like to know how high sample rate high acquisition rate DSOs digitally correct their frequency and phase response and implement sinc interpolation. Can this be done *after* the 2D histogram is generated?

author: Someone
author_rank: Super Contributor
timestamp: January 16, 2017, 09:21:31 pm
content: Quote from: NorthGuy on January 16, 2017, 04:19:38 pmYou're completely missing the point again, the histogramming allows the scope to maintain a higher sample rate and update that to the user with all the points shown even though the screen is only 1,000px across we could be looking at 1,000,000 points of data presented together without any information missing. So far all we've heard is that its easy to show less information by dropping data which is nothing new or interesting, getting sustained data points drawn to a display is hard work and requires substantial resources.

author: nctnico
author_rank: Super Contributor
timestamp: January 16, 2017, 10:12:21 pm
content: If you don't (want to) understand that you don't have to drop or ignore data to get a full picture of the signal then this discussion is futile. Oscilloscope manufacturers are already doing intensity graded displays with >10Gs/s so it seems your assumption it cannot be done with today's technology must be wrong.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 16, 2017, 10:19:53 pm
content: Quote from: David Hess on January 16, 2017, 08:06:44 pmI don't think the way the triggering is done makes much difference. The important thing is that you maintain a pipeline of points, which can easily be few thousands (say pixel size multiplied by 8: 700 x 8 = 5600) and you have means of saying that the trigger has coincided with one of the points by the time the point passes through the "trigger" point of the pipeline. At this moment, you just move from that point in both directions and aggregate points to be used to represent the frame on the screen. At the end of the process, you come up with a 700-point buffer which represents a frame (with known fixed position of the trigger). This buffer is sent down through a histogram building pipeline.If you have too many points you need to aggregate them before the analysis. For example, you have 14M sample points for each frame and you have 700 pixels. That's 20000 sampling points for every vertical line of pixels which need to be represented as a single point. So, you need to down-sample it to some reasonable quantity. Say, you can average points within consecutive blocks of 2500 points each. This way you down-sample to 5600 points per screen and you send these 5600 points down the waiting-for-trigger pipeline. But this makes things slower - if you sample at 2Gs/s, now you get 80Mpts/s, so this is an easy case. Theoretically, you can get a number of triggers within a single pixel if the signal frequency is too high, but there may be no sense in processing them all.If you have less sample points per screen than pixels (e.g. 140 points on 700 pixels), you need to do some interpolation (linear or sinx/x) with your frame before it enters histogram-building pipeline. This is the toughest case because you get the most number of frames.Quote from: David Hess on January 16, 2017, 08:06:44 pmI don't think extra calculations need to be avoided, they can simply be delayed. You can create a pipeline with a number of steps steps. Each step may calculates statistics on every frame. One of the steps will be a histogram. The frame may sit in the pipeline for a while, but it's very fast compare to 60 Hz screen update, so you can do as much as you practically want. Of course, the more you calculate, the more resources you need to use.Quote from: David Hess on January 16, 2017, 08:06:44 pmThis is a question of how many frames you get. If you want 60MFrames/sec and your screen update is 60 Hz, it's a million of frames per screen update. Your 16-bit counters will look not much better than my 1-bit. If you want more frames/more smoothness you have to use more resources. Although you can insert intermediate stages.The idea of continuous sampling is that you look at 100 MHz wave on the screen, you see a single glitch, you have enough time to click the stop button, find the bad waveform and inspect it in details. Keysights which cost more than my car cannot do this, and they going on and on in their datasheets how their sampling has less gaps than the competition.Quote from: David Hess on January 16, 2017, 08:06:44 pmIMHO, if needed it must be done before histogramming.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 16, 2017, 10:43:45 pm
content: Quote from: Someone on January 16, 2017, 09:21:31 pmQuite an opposite. I'm talking about technical means to ensure continuous sampling. This means sampling in such a way that no one single waveform is lost. For example, you had billion sine waves in your signal during past 10 seconds. One of them had a glitch. The purpose of the continuous sampling is to ensure that you see it on the screen. And also that you have enough time to stop the scope and inspect the bad waveform. I'm very sorry if you cannot understand what I'm saying, but I did my best to explain.

author: Someone
author_rank: Super Contributor
timestamp: January 16, 2017, 11:34:53 pm
content: Quote from: nctnico on January 16, 2017, 10:12:21 pmI've said from the start its possible, expensive but possible. The strength of the graded displays is that they don't hide any of the data, its very useful and is being done on high sample rate scopes. Increasing their performance is not easy or cheap to add, the products are making tradeoffs in price/performance. You can't drop/average/envelope samples and compare that to a system which draws all the points to the screen, they're radically different.Quote from: NorthGuy on January 16, 2017, 10:43:45 pmYour solutions have all included dropping points of the waveform, which is fine and a different way of doing it. But its not comparable to getting every single datapoint to the screen, which is currently done, and could feasibly be done at full rate of GSa/s.Quote from: David Hess on January 16, 2017, 08:06:44 pmAs above it has to be done before the histogram.Quote from: NorthGuy on January 16, 2017, 10:19:53 pmWhy do you need to stop and then review that single waveform? The information is on the screen to see what is happening and the general workflow is that you can then determine what sort of trigger you need to capture the problem in more detail. There are Lecroy scopes that show a fast realtime display while in sequence mode as a compromise where you can do both, but it can be hard to stop the acquisitions while the interesting point is within the capture buffer:https://youtu.be/oE_VFYUVwuk?list=PLHb-5d66oKUfYfMTQptmDpZuI2AJVWovtSo that exists in an easy to use package but never really made much traction in the market.

author: nctnico
author_rank: Super Contributor
timestamp: January 16, 2017, 11:55:02 pm
content: Quote from: Someone on January 16, 2017, 11:34:53 pmThis is where your thinking goes wrong. Let's start with the display: a TFT screen. Now manufacturers can boast they offer 256 grades of intensity. The fact is that (the usually 24 bpp) TFT screens can't display 256 shades of any color because the gamma, contrast and intensity are always way off. The next thing is that you will want to see a sample value which occurs in 1 out of a million sweeps (and even less with some persistance). With less than 256 shades that translates to large bins with probabilities of a sample value occuring. This is why you can reduce the amount of data needed quickly WITHOUT throwing anything away and WITHOUT needing to resort to expensive parts to achieve it.

author: Someone
author_rank: Super Contributor
timestamp: January 17, 2017, 02:08:28 am
content: Quote from: nctnico on January 16, 2017, 11:55:02 pmYou can take all sorts of shortcuts, and it ends up with a different result. The intensity graded displays with full histogramming already use an adjustable gamma transform or colour maps (possibly with non linear scalings of the result), these are the easy parts of the system. Sorting the incoming points and accumulating their hits on the histogram is the expensive stage and any compression/reduction/simplification of the data before that step will lose information that is readily visible in the end result.Maxim have a nice example of these concepts in the captures of their application note here:https://www.maximintegrated.com/en/app-notes/index.mvp/id/5053

author: David Hess
author_rank: Super Contributor
timestamp: January 17, 2017, 02:34:12 am
content: Quote from: Someone on January 16, 2017, 11:34:53 pmEvery signal feature needs to be captured but not every sample point. If the sample rate is excessive for the input bandwidth, then samples can be discarded. Most glitches are not bandwidth limited and instead represent an infrequent but continuous event with significant low frequency content.And if there is a compromise which significantly lowers blind time while making the design feasible, that is better than nothing. Decreasing the capture time to find an event in seconds instead of minutes or hours is a big or huge improvement. Decreasing the capture time further is of less use unless like Fedex it absolutely positively must be there at the end of the display cycle.Quote from: nctnico on January 16, 2017, 11:55:02 pmI assume post processing of the 2D histogram would be used to limit contrast or highlight otherwise dim features. I looked into this last year and concluded that highlighting the envelope, standard deviation, and mean over a continuously indexed display would work well.Quote from: NorthGuy on January 16, 2017, 10:19:53 pmWhy bother doing this? The extra computed points do not represent extra information. Sinc interpolation is useful for digital triggering but is not going to add anything useful to a histogram display.QuoteExceeding the depth of the histogram is definitely a problem which would need to be handled.As far as seeing a single glitch at the display rate, I assume that histograms generated by the acquisition system are accumulated in a possibly deeper display histogram. So acquisition histograms are not necessarily transferred at the display update rate; they could be transferred more often allowing them to use a smaller depth compared to the display histogram.

author: Someone
author_rank: Super Contributor
timestamp: January 17, 2017, 03:21:09 am
content: Quote from: David Hess on January 17, 2017, 02:34:12 amI'll disagree with two (albeit synthetic) examples below. But if you can see the problem with less bandwidth then by all means use a lower sample rate, this is the classic tradeoff in update rate that you get with traditional digital scopes. Or with a realtime processing engine you can capture and see the infrequent outliers/glitches quicker and with more detail, such as this 500ps glitch:These are the sorts of features you're hunting for where increasing the throughput (decreasing blind time) becomes advantageous.Quote from: David Hess on January 17, 2017, 02:34:12 amWe already have a range of tools that can test/search at different rates with different levels of complexity but the one thing they have in common is they don't show approximations/simplifications/compromises of the original data. Just sinc interpolation is enough of an estimate/approximation that some people prefer to see traces without it. So we'll disagree on whats acceptable.So far we've not heard any shortcuts for 2D histograms, just approximations which return a different result.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 17, 2017, 03:35:58 am
content: Quote from: David Hess on January 17, 2017, 02:34:12 amIf your triggers have the same resolution as points and you have less points than pixels then some of the pixels will get all the points while there will be black gaps produced by vertical columns of pixels which never get any points. Interpolation will produce smooth lines instead.If your triggers have higher resolution than points, then this may smooth out producing a sort of ETS effect, but it may not necessarily be that way.IMHO, it's easier to interpolate to prevent such effects.

author: David Hess
author_rank: Super Contributor
timestamp: January 17, 2017, 05:41:59 am
content: Quote from: Someone on January 17, 2017, 03:21:09 amSure we have; I suggested one. Decimate the samples before processing the histogram to decrease the blind time for a given investment in hardware. The statistics of the signal remain the same; for instance it has the same peak, mean, and standard deviation values albeit with less confidence.This makes it more likely that a rare short event that falls between samples will be missed (1) but a longer rare event will still be captured and the later are more common.Even if the above is done, there is a simple way to detect some events that occur between decimated samples; since it has low hardware requirements, implement peak detection on a parallel path. Now a full sample rate peak detected envelope is returned with the lower sample rate 2D histogram.I wonder if it would be worthwhile to implement a parallel 1 bit depth histogram as suggested earlier instead of peak detection. I doubt it but it would cover the cases that peak detection would miss like an eye diagram.(1) Tektronix used to give this specification for their DSOs as something like 85% confidence to capture 50% or greater amplitude of a 2ns pulse but it is less relevant today because real time sampling rates have increased enough to capture any bandwidth limited pulse.Quote from: NorthGuy on January 17, 2017, 03:35:58 amThis is why I brought up the digital trigger path running in parallel with the histogram path in an earlier post; interpolation is needed in the trigger path but not the histogram path.

author: Someone
author_rank: Super Contributor
timestamp: January 17, 2017, 07:02:00 am
content: Quote from: David Hess on January 17, 2017, 05:41:59 amWhich is still not a shortcut for the histogram, just presenting it with lower bandwidth information.Quote from: David Hess on January 17, 2017, 05:41:59 amA 2D histogram shows much more than the envelope, mean, and standard deviation. So although those parameters may come through unaffected you've lost other information which can be useful, you don't use a histogram technique on data when the the envelope, mean, and standard deviation are all that you're interested in.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 17, 2017, 02:55:17 pm
content: Quote from: David Hess on January 17, 2017, 05:41:59 amYou need a trigger before you start building the histogram because your points in the frame are relative to the trigger. No triggers - no histograms

author: NorthGuy
author_rank: Super Contributor
timestamp: January 17, 2017, 03:15:49 pm
content: Quote from: Someone on January 17, 2017, 03:21:09 amThe screen can represent 700x256x8 = 1.4Mbits of information. Sampling 4 channels at 2Gsa/s for 10 seconds gathers 640Gbits of information, which is roughly 500,000 more than you can possibly display on the screen. So, you must take as a given that 99.9998% of the information will be removed (and the acquisition memory can then be used to retrieve the information if needed). The important thing is to preserve the information which is needed to the guy starring at the screen at the moment. There are thousands of ways to do it, it doesn't appear to be something difficult, have been done before many times, so there's no point to discuss this unless you're on the verge of actually designing a scope.The important thing is that nothing prevents you from gathering all the waveforms contained in the signal. There doesn't have to be any gaps or omissions. Even overlapped frames do not pose a problem. Thus there's nothing on a technical side of things which prevents scope manufacturers from doing this.

author: nctnico
author_rank: Super Contributor
timestamp: January 17, 2017, 03:35:49 pm
content: Quote from: NorthGuy on January 17, 2017, 03:15:49 pmJust to nitpick: removed is the wrong word here. It should beredundant.