Anyone else noticed that with a 20ms or so timebase that the display isn’t updating very frequently?
There’s 10 horz. divs, so that’s 200ms total. I would expect the display to update about 5 times a second. FPS says 40/Sec., but it sure doesn’t look like it. Perhaps the screen is refreshing that fast, but the information that’s on it isn’t.
Display update rate is based upon the acquisition of data and then prep for next acquisition update. In this case the acquisition of data takes long enough to fill 4K samples which is much more time than the approximately 300 samples that fill the screen display buffer. So in round numbers, each update will probably take approximately 10 times as long as you have calculated.
With the current Quad info available, you can not determine the maximum update rate because it is affected mostly by the acquisition samples/sec and that info is not readily available for this T/Div setting.
BenF addresses this problem when using slow time bases on the DSO Nano, by incorporating a “Fast” mode of acquisition. It is explained in his User Guide V3.62 for the Nano if you are interested. BenF also has a table that shows the samples/sec for various T/Div settings. This concept would also be relative to the Quad, just different numbers but similar ratios. Basically, in “Fast” mode, the samples/sec is at a much higher rate for that same T/Div setting at the cost of reduced sample depth (smaller acquisition buffer is used). This makes the update rate about 10 times faster.
This is a prime example of why I believe that Bure should incorporate all the DSO Nano BenF improvement features into the Quad as soon as possible. In this example, you would get updates about ten times faster while in the “Fast” mode.
Hello Folks,
At the risk of repeating this post from elsewhere I think it is also relevant here.
[i]I am just starting to use my Quad for the first time as a tool to measure some I2C signals from sonar device. I am seeing a lot of flicker on the screen at 20usec/Div and the system only triggers about 1 time in 5 at 10usec/Div. I am using channels C/D for inputs. Channels A/B just gave me a badly slewed wave that was all but useless to read.
I was also wondering why there is a threshold on the trigger for C/D since they only show as logic 0/1 with a single Div difference. The only sensible trigger for these inputs it leading/falling edge. It gets confusing when you switch between trigger sources C/D only to find that the trigger level is set outside the signal level that you have no control over.
Since the inputs C/D have no signal processing like A/B I can only assume that the firmware is missing trigger events on these channels. I would be expecting to be able to see a 10 meg bandwidth at the very least on these inputs. Perhaps someone can look at the trigger logic for the digital inputs[/i]
Cheers Pete.
I just finished reading all 3 of your posts.
1. this topic
2. DSO Quad suggestion and bugs
3. DSOQuadV2.6 RESOURCE
I read all the new posts. I would have seen it anywhere you posted it.
However, I’m going to do a little experiment and wait a little while before I reply to your actual question. I need the time to cool off.
Who made you the posting police 
, you don’t have to read my posts 
. Get a few miles (and posts) under your belt before coming onto the forum and raising your temprature 
.
Cheers Pete.
So are you saying on a larger timebase the samples are taken less frequently, and there’s more time between them? It seems like really poor design in that case to wait for all 4k of the samples to be filled when we only need 300 (considering they’re an order of magnitude apart). I don’t see why if the display is working around 40fps why it can’t just draw the information as it becomes available (like a heart monitor, or a normal digital scope on a large timebase)
BenF can correct me if I am wrong, but here is the answer to your “why”. A software trigger acquisition requires that the trigger be found and then, for the Quad, 50% more of the circular capture buffer must be filled to complete that data capture portion of the acquisition. Then the capture buffer must be processed before the selected windowed portion of the capture buffer can be used to update the display. The Quad XPOS is how you select which windowed portion of the capture buffer gets displayed (relative to the detected trigger) on the Quad. Then user parameters for the next acquisition are established and then the next acquisition capture takes place.
What you want is what BenF calls “fast mode”, and the current form of the Quad does not support “fast mode”.