Why do I only get 20msec of capture before the sample rate reduces?

Why do I only get 20msec of capture before the sample rate reduces?, a forum discussion on Cleverscope. Join us for more discussions on Why do I only get 20msec of capture before the sample rate reduces? on our Questions forum.

Back to Forum Index : Back to Questions   RSS

10 Apr 2006
Posts: 395

Cleverscope has 4M samples of memory, and so you might think that 40 msecs of capture should be achieved before reducing the sample rate. However that would mean that you could not capture a signal and then look at it while waiting for the next trigger - which is a very common way of using an oscilloscope. To allow this to happen Cleverscope uses 'frames' to hold the captured signal. You can have beetween 2 and 3000 frames. The 4M memory is divided amongst the frames. So if you have 2 frames, each will contain 2M samples, giving you 20 msecs of capture at the full 100 Msamples/sec rate. With 16 frames you will only have 250K samples per frame, and you will only be able to capture 0.25 msecs before the sample rate is reduced. However while sampling into the current frame, you can look at any of the other 15 frames. This is useful for history, and averaging in the acquisition unit.

So to recap, with 2 frames, you can explore the signal in one frame, while sampling into the other (as a circular buffer). Once you have the next trigger, the newly captured frame will be displayed, and Cleverscope will use the old frame as the new capture buffer. In this way you can capture 20msec of information before the sample rate is automatically reduced.

20 May 2006

So you're saying that the longest continuous acquisition possible is actually 2M even though there is 4M of memory?

22 May 2006


Just checking back to see if you had released the USB2.0 version of the scope yet when I spotted this post. Is this a limitation for the driver as well as the oscilloscope software. IE if I buy the scope and use it with the drivers can I use the full memory or only half the memory?


PS Just thought I had better check - does the scope have all the required CE / LVD / ROHS certificates. Our lab is getting pretty hot on all this now.

26 May 2006
Posts: 395

First, for the driver it is possible to get an acquisition of 4M, and resturn it. It is not possible for it to be waiting for a trigger while you interrogate the buffer at the same time.

For the application we could do this also, but we found people found it confusing that they could not zoom in on the buffer (which returns samples from the acquisition unit) while waiting for the next trigger. You will find the Agilent Megazoom works in the same way.

When the USB 2.0 system is done, we will look at returning all samples (it could be 4 x 4 = 16 Mbytes, which will takes some time at 40 Mbyte/sec) following a single trigger.

The scope is CE and LVD compliant. We will be ROHS compliant by the next production run (which includes the USB 2.0 version). At presen one connector is not Rohs compliant, and the current boards have been soldered in a non-ROHS way.

We are still about 6 weeks away from the USB 2 version sorry - there have been some holdups in teh production process.

21 Sep 2006

You mentioned 4 months ago in May that you'd have the USB2.0 version available in about 6 weeks. OK, it's a little late, but so are most of my projects.

I have been waiting for the 328A before I buy. In the meantime I've found someone with a used 328 for sale. Will I be sacraficing other features if I buy his USB 1.1 328, or will the 328A simply be identical except for adding USB2.0?

If there will be other new hardware features, I may be willing to wait (and pay more) for a new 328A unit. Otherwise I'll buy the used 328 unit.

27 Sep 2006
Posts: 395

Hello JMB,
There will be differences, in the longer term, between the CS328 and the CS328A. Our difficulty is that we have been silly in saying that the CS328A will be available - it has raised expectations, and reduced sales, and increased dissatisfaction. We will not make this mistake again! So just to confirm the silliness, the CS328A will initially do exactly what the CS328 does, except it will use USB 2. However, we have made a couple of future proofing changes and these will enable us to greatly increase the capability of the CS328A in the future by software download (I won't say what these capabilities are right now for the above reasons). The CS328A also exhibits less noise in the front end, which will be used to advantage in the future as well. We expect the CS328A to be available in November. (We took time away from the development to attend to software... sorry about that). You should know that the CS328A and CS328 are code combatible, and you can link them together to make a 4 channel/16 digital scope, or run them as completely seperate scopes (perhaps with a common trigger) on one desktop. So if you bought the second hand CS328, you might even find it useful to expand later on.

28 Sep 2006

Thanks for the update. I know you probably don't want to hear this, but I've decided that it's definitely worth waiting for the newer version. Aside from the faster data transfer, I'm glad to hear that there will be a quieter front-end. I actually had some concerns about the noise level. It seemed to me that the waveforms in your documentation were surprisingly noisy. I can understand this for small signals, but it seems to be present even on fairly large signals.

I didn't see a noise spec in your documentation. I've noticed that you like to compare your product to the agilent megazoom (54622D). They specify a maximum peak-peak noise level of ""1mv or 2%, whichever is greater"". Can you provide a spec for your product?

3 Oct 2006
Posts: 395

Hello JMB,
The Agilent noise is 2% of FSD, or 1 mV p-p, whichever is greater. Thus with a 10V FSd, they indicate 200 mV p-p noise. Our noise, using a 10us wide capture window, 100 MHz bandwidth, peak captured, 10 vertical divisions, measured with a randomly selected scope is as follows:
10mV FSD - 1.5 mV
20 mV FSD - 1.5 mV
50 mVFSD - 1.5 mV
100 mV FSD - 1.6 mV (1.6%)
200 mV FSD - 5.5 mV (2.8%)
500 mV FSD - 10 mV (2.0%)
1 V FSD - 16 mV (1.6%)
2V FSD - 30 mV (1.5%)
5V FSD - 41 mV (0.8%)
10V FSD - 180 mV (1.8%)
20V FSD - 310 mV (1.6%)

So you can see we are slightly worse at the very sensitive ranges, but similar or better at higher ranges. There are a couple of reasons why our graphs can look noisy. These are:
1. Visually we often show more divisions than a normal scope. A normal scope usually shows 8 vertical divisions, while we might show 20. Say our FSD is 2V, and so is the other scopes. However our divisions will be 100 mV, while the other scopes divisions will be 250 mV. A noise of 20mV p-p will look 2.5x larger on our display than on the other display, assuming the same number of pixels per vertical division (which is how it is). (So a small display looks better!).
2. The interval over which you capture is also important. As noise is unbounded, the longer the interval, with the same bandwidth, the higher the peak captured noise. The 54622D spec does not say over what interval the noise is captured, and if indeed it is peak captured (which means the bandwidth stays the same). For example with the 100 mV FSD range, we get 1.6 mV of p-p noise over 10 us, but 2.6 mV p-p over 20 msecs (and 1.8mV over 20 msecs with sampled display). For many of the graphs we show, we are trying to show how you can get both a zoomed out and a zoomed in view at the same time, and so the interval is long, leading to higher displayed noise.

If the interval is long (eg 20 msecs), you are probably not interested in the full bandwidth. In this case, you can turn on the 25 MHz filter to reduce noise. The 2.6 mV p-p over 20 msecs, changes to 1.6mV p-p.

In addition, we should point out that this is p-p noise, which we take to be 3 standard deviations either side of the mean encompassing 99.7% of all the possible values (assuming a normally distributed, random noise). A more realistic estimate of the actual sample value might be 1 standard deviation either side of the mean, which is 1/6 of the p-p, encompassing 68% of the total signal values. This is what you would usually see on an analog scope (the peak values being so faint they don't show up).

Finally you can do a lot about the noise by using the tools provided. You can use averaging to drastically reduce the noise, and you can also make a filter using the Maths module to reduce the noise to just the bandwidth of interest to you. Cleverscope offers averaging in the acquisition unit to give very fast averaged updates.

5 Oct 2006

It seems that you're comparing one example of your ""typical"" numbers with Agilent's guaranteed worst-case specs. That's not really ""apples to apples"" is it?

The company I work for happens to own an Agilent 54622D. I did some measurements using your parameters (100MHz bandwidth, peak-detected, no averaging, 10us window). Here's what I got:

8mV FSD - 0.63 mV
16mV FSD - 0.63mV
40mV FSD - 0.60mV
80mV FSD - 0.90mV (1.16%)
160mV FSD - 1.2mV (0.75%)
400mV FSD - 3mV (0.75%)
800mV FSD - 6mV (0.75%)
1.6V FSD - 19mV (1.19%)
4V FSD - 30mV (0.75%)
8V FSD - 60mV (0.75%)
16V FSD - 130mV (0.81%)

As you can see, their spec is appropriately conservative.

I also measured the noise level at 80mV FSD with the bandwidth limited to 20MHz. This is the closest possible setting to your test at 100mV FSD and 25MHz bandwidth. The 54622D measured 0.60mV vs your 1.6mV.

I am hoping that the tests you made were on a current production unit, rather than the new quieter version in the works.

Still, considering that you are limited to using off the shelf components vs Agilent's mega-team designing mega-ASICs, I think that your higher noise levels will be tolerable for the price.

5 Oct 2006
Posts: 395

Hello JMB,
Thanks very much for doing those measurements. The measurements I gave were based on a standard CS328. Another way of expressing the noise is as Electrical noise/rt Hz.Lets assume that one standard deviation is 1/6 of the p-p noise.

For the CS328, 1V range, we measured 16 mV p-p -> 2.7 mV rms -> 270 nV/rtHz
For the 54622D, 800 mV range, you measured 6 mV p-p -> 1 mV rms -> 100 nV/rtHz.
The new CS328A, our calculations show that at 1V range, the noise is 68 nV/rtHz. So we should compare with the 54622D quite well.

6 Oct 2006

Peak-peak noise levels are more meaningful since that's what I'll actually see, but 4mVpp (68nV/rtHz) sounds like a nice theoretical noise level for the 1v FS range.

What do you predict for the 10mV FS range?

A 4x reduction in noise must have required some significant design changes. Did any other specs (such as offset range) change/improve?

I look forward to owning/testing the real-life result when this new version becomes available.


6 Oct 2006
Posts: 395

Yes we have changed the programmable gain amplifier system quite significantly. The scale/offset and front end remain the same.
With 10mV, we predict 22 lsb p-p noise, or 0.22 mV p-p on the 10 mV range (its a 5.8nV/rtHz front end, amplified to match the ADC input voltage range).

7 Oct 2006

So your prediction is that the 1V FS range will have a 4x improvement (16mV/4mV), and the 10mV FS range will have a 7x improvement (1.5mV/0.22mV).

I will be very impressed if the real-world result matches these figures.

I look forward to buying one when they become available.

12 Oct 2006
Posts: 395

We will let you know when it's done!

25 Apr 2007

BartSchroder said...
Yes we have changed the programmable gain amplifier system quite significantly. The scale/offset and front end remain the same.
With 10mV, we predict 22 lsb p-p noise, or 0.22 mV p-p on the 10 mV range (its a 5.8nV/rtHz front end, amplified to match the ADC input voltage range).

So I see that the 328A is now available (presumably with the improved front end). I think I'm ready to buy one, but first I would like to know how the noise levels turned out. Did you hit that 0.22mv p-p you were predicting? I hope so. I'd like to own one if the noise level is now reduced to a reasonable level.

26 Apr 2007
Posts: 395

Hello JMB,
Thanks for staying on top of this.
Sometimes what you hope for is not what you get! We have done a fair bit of improving, but there is still some more to come. More on that below.

Here is a table using your values for the Agilent 54622D, our recent measurements for the CS328, and the CS328A, all in mV p-p, over a 10 us period, peak captured. The CS328 and CS328A were randomly selected, measuring the same common ranges:

FSD mV/div 54622D CS328 CS328A
8mV FSD (1 mV/div) - 0.63 1.3 0.96
16 mV FSD (2 mV/div) - 0.63 1.3 0.96
40 mV FSD (5 mV/div) - 0.63 1.5 1.7
80 mV FSD (10mV/div) - 0.9 1.5 1.7
160 mV FSD (20 mV/div) - 1.2 3.5 1.7
400 mV FSD (50 mV/div) - 3 6.0 1.7
800 mV FSD (100 mV/div) - 6 9.6 1.7
1.6V FSD (200 mV/div) - 19 17 4.0
4V FSD (500 mV/div) - 30 28 8.2
8V FSD (1V/div) - 60 99 36
16V FSD (2V/div) - 130 180 70

What this shows you is that at, and below 160 mV FSD (20 mV/div) the 54622 is better, and above 160 mV FSD, the CS328A is better. We think we have identified where the low level noise is coming from, and so the next build (production has started for this) incorporates some improvements to the filtering between the digital and analog sections. We hope (and there are no guarantees) that this will improve the low level noise position.

Note that averaging can be used to significantly improve the position when looking at stationary signals. For example on the 8 mV FSD range, with 16x averaging, the CS328A noise is 190 uV p-p. This is equivalent to a -95dBV noise floor with 1024 point FFT (~100 kHz frequency bin), and -105 dBV noise floor with 16384 point FFT (~6 kHz frequency bin). Without averaging the noise floor is -85 dBV and -95 dBV respectively. So we get about 10 dB improvement with a small average.

We have also made big improvements in other areas - for example, the noise is now uniform over the common mode range (top of the graph to the bottom of the graph), whereas noise became significantly worse when at the common mode extremes in the CS328. As well as that, by making a modular ADC unit, we now have much more flexibility about bit resolutions, external clocks, and sample rates.

I hopes this helps in your deliberations.

27 Apr 2007

Well, that's a little better, but I was really looking forward to 0.22mv p-p. It would have been very useful to us. Averaging is not an option for our application. Like most people seeking deep memory, we need the deep buffer to capture a lot of data which is not repetitive. If we were looking at a simple repetitive waveform then we could average multiple captures to ""clean-up"" the noise, but we wouldn't really have a use for the deep memory in that case.

The problem with noise is that it obliterates the low order bits of the digitized signal. For example, at 20mv p-p full scale your noise level of 0.96 mv p-p is 1024 x 0.96/20 = 49 counts of noise. 32 counts would be 5 bits, so 49 counts means more than 5 of the least significant bits are just random numbers. This reduces the effective resolution of the 10 bit converter to less than 5 useful bits.

I am still interested though. You said that further improvements are in the works. If you get that noise level down I will buy one - and the company I work for may buy several ;)
Back to Forum Index : Back to Questions   RSS
You must be logged in to post a reply

You need to Register or Log In before posting on these forums.


Your shopping cart is empty.