hi echen1024.. nice videos!
At that moment, the Rigol is sampling at 500MSa/s - so 2ns per sample. In order to fill 12M of memory, it takes 24 milliseconds. What is the maximum number of times in a second any sampling device in the world could capture 24ms of time?
1 / .024 = 41.666.
So in fact, it's not terrible at all - it's almost perfect given the memory size.
I've always thought there needs to be a change in the way they do this. The problem is that they sample at the chosen rate, filling the memory buffer (takes 24ms) then when they are finished they update the screen (can be done approx. 40 per second) ... but the screen is often zoomed in to a small portion of the entire capture buffer, and this zoomed in area could be updated much, much faster and at the same time.
They just need to sample continuously into the 24M sample buffer; 'trigger' should be a display control, sliding the view window over the samples, forward in time, and stopping when a trigger matches, and displaying the really small portion of the sample memory that fits into the graticule at that trigger point. Triggering should not necessarily be something that controls when a sample is taken (although this is useful too). In my view, sampling should be continuous, not-triggered, and the 24Meg sample buffer is circular, and the display is merely a triggered viewport into the sample memory. It is sliding across the samples in real-time and checking the samples for a trigger match... the trigger level is used to center the viewport on a matching point in the sample memory, then the (very small) display window is updated, and moved on to the next sample, looking for another trigger match..
5 (standard), or 6 (widescreen) horizontal divisions on either side of the center line (10 or 12 total divisions) at 5ns/div means only 50ns or 60ns of time sampled data needs to be taken from the sample buffer and displayed; you could theoretically update that much data 20 million times per second (not realistic, I know, because you can't draw it that fast)... but you could guarantee at least 100,000 waveform updates per second this way. You would be able to stop sampling anytime and scroll around in the buffer. Sampling data and displaying that data should be two separate functions of the scope.. most scopes are full or DSP's and FPGAs, yet still put those two functions in a sequential lockstep.
Maybe that's how the big guys get the huge waveform updates per second. it just seems like it should be the only way it is done (or least, the
default way)