Documentation and specification not well understood- customer requirem

Hello,
I am looking for a high sensitivity and fast compact scope for a precise application. I have found the cleverscope on the web, and it could meet my requirements. I have read the specifications and the documentation, but I don't understand them completely. Hence my questions:

A) Are the ADCs true 10,12 or 14 bits ADCs? I mean do they really have 10, 12 or 14 hardware output bits ? Or is the 14 bit resolution obtained by oversampling with an ADC with fewer bits ? What does the sentence ""The bit resolution is field upgradeable by changing the sampler circuit board."" mean? Does it mean replacing a 10 bit sampler circuit board by another one with 14 bits for instance?

B) If the ADCs are true 10, 12, and 14 bits ADCs, is the sampling rate really 100MS/s for the three models ? Could you please indicate the measured ENOB of the three models at full (100 MHz), 20 MHz, and 2MHz (moving average) bandwidths? I suggest you include a table with these measured numbers in the documentation.

C) Are the so-called ""anti-alliasing"" filters true analog filters in front of the ADCs or digital filters after the ADC (on the board or in the PC)?

D) What is this 2 MHz moving average filter mentionned in the specifications? It does not seem to be documented in the PDF Cleverscope doc. Isn't the average done numerically on a number of points chosen by the user? So why 2 MHz?

E) What are all the possible combinations of sampling rates and record lengths in a single shot (single trigger event)? The specification indicates 100 MS/s to 1500 S/s and 1300S to 4MS for each channel. Is it possible for instance to sample at 100 kS/s during 4M/100k=40s. The ""captured Sample window duration"" specification indicates ""40 ms - 42.9 secs with 10 ns - 10 µs resolution (Lower sample rates are available for smaller capture buffer sizes)"". Not very precise. Besides, what is the situation with the sequence mode (several trigger events and frames). All These pieces of information should be made very clear for all possible cases.

F) What are the maximum/typical measured transfer rates to a windows PC with USB 2.

Now I come with my requirements so that you can tell me if the cleverscope (or another hardware even in its beta version) meets them.

I have to measure SIMULTANEOUSLY the following signals:
- Two analog channels: +/- 4 V at a sampling rate between 0.1 MS/s and 10MS/s with at least 14 effective bits at 1 MS/s
- A TTL signal at the same sampling rate.

Triggering is provided either by the TTL signal, by one of the analog signals, or by a Logic AND over the three.
Ideally, I need about 1s of data at 10 MS/s, 10s at 1MS/s, and 100s at 0.1 MS/s, whithout any holes (single shot). This represents about 2 x 10 MS (16 bits I suppose) + 10 MS (1 bit) for the digital line. This is more than what is specified for the cleverscope. I could live easily with 8 MS per channel, and 4 is a bit short. Is there a way to reach 8 MS per channel?
Finally, I need to transfer the data to the PC in less than 5-10 s, and then to visualize them. How fast is the cleverscope windows application when it has 8 or 16 MS in memory?

By the way, I have tried to test the cleverscope application, but I get about 50 errors of the "" Missing sub-VI"" type. What did I do wrong?

Thanks for your help and Best regards,

Denis

Hello, I am looking for a high sensitivity and fast compact scope for a precise application. I have found the cleverscope on the web, and it could meet my requirements. I have read the specifications and the documentation, but I don't understand them completely. Hence my questions: A) Are the ADCs true 10,12 or 14 bits ADCs? I mean do they really have 10, 12 or 14 hardware output bits ? Or is the 14 bit resolution obtained by oversampling with an ADC with fewer bits ? What does the sentence ""The bit resolution is field upgradeable by changing the sampler circuit board."" mean? Does it mean replacing a 10 bit sampler circuit board by another one with 14 bits for instance? B) If the ADCs are true 10, 12, and 14 bits ADCs, is the sampling rate really 100MS/s for the three models ? Could you please indicate the measured ENOB of the three models at full (100 MHz), 20 MHz, and 2MHz (moving average) bandwidths? I suggest you include a table with these measured numbers in the documentation. C) Are the so-called ""anti-alliasing"" filters true analog filters in front of the ADCs or digital filters after the ADC (on the board or in the PC)? D) What is this 2 MHz moving average filter mentionned in the specifications? It does not seem to be documented in the PDF Cleverscope doc. Isn't the average done numerically on a number of points chosen by the user? So why 2 MHz? E) What are all the possible combinations of sampling rates and record lengths in a single shot (single trigger event)? The specification indicates 100 MS/s to 1500 S/s and 1300S to 4MS for each channel. Is it possible for instance to sample at 100 kS/s during 4M/100k=40s. The ""captured Sample window duration"" specification indicates ""40 ms - 42.9 secs with 10 ns - 10 µs resolution (Lower sample rates are available for smaller capture buffer sizes)"". Not very precise. Besides, what is the situation with the sequence mode (several trigger events and frames). All These pieces of information should be made very clear for all possible cases. F) What are the maximum/typical measured transfer rates to a windows PC with USB 2. Now I come with my requirements so that you can tell me if the cleverscope (or another hardware even in its beta version) meets them. I have to measure SIMULTANEOUSLY the following signals: - Two analog channels: +/- 4 V at a sampling rate between 0.1 MS/s and 10MS/s with at least 14 effective bits at 1 MS/s - A TTL signal at the same sampling rate. Triggering is provided either by the TTL signal, by one of the analog signals, or by a Logic AND over the three. Ideally, I need about 1s of data at 10 MS/s, 10s at 1MS/s, and 100s at 0.1 MS/s, whithout any holes (single shot). This represents about 2 x 10 MS (16 bits I suppose) + 10 MS (1 bit) for the digital line. This is more than what is specified for the cleverscope. I could live easily with 8 MS per channel, and 4 is a bit short. Is there a way to reach 8 MS per channel? Finally, I need to transfer the data to the PC in less than 5-10 s, and then to visualize them. How fast is the cleverscope windows application when it has 8 or 16 MS in memory? By the way, I have tried to test the cleverscope application, but I get about 50 errors of the "" Missing sub-VI"" type. What did I do wrong? Thanks for your help and Best regards, Denis

Hello Denis,
Thanks for your long and detailed questions.
Ok answers:
A. The ADC's we use are the Linear Technology LTC2280, LTC2282 and LTC2284. These are true 10, 12 and 14 bit dual channel ADC's. We supply three different sampler (digitizer) modules. They are field upgradeable, but we have gone away from that a bit, as the connectors are very small high bandwidth ones, and getting it wrong is expensive.
B. The sampling rate is the same for all three modules - 100 MSPS. Because they are dual channel ADC's both ADC's sample simultaneously at full rate. The ENOB figures are affected by input noise floor and input signal amplitude. We publish a document called 'Digitize performance' in our resources page (you can find it here: http://www.cleverscope.com/resources/Cleverscope%20CS328A%20performance.pdf) that discusses the business of dynamic range and SNR. As you change ranges both the gain and noise floor change meaning that ENOB will also change. Thus there is no one ENOB value. We can say that ENOB will always be worse than the ADC number of bits because of these factors. Such is life! We will do some derivations in the document, and provide indicative ENOBs in an update.
C. The anti-aliasing filter is an analog 20 MHz LT6600-20 filter backed with a noise shaping digital filter.
D. the 2 MHz filter is historical. Using Maths you can design any filter. The filter can be applied across the full sample set (up to 4 M samples) if you get the full frame into PC memory.
E. If you have our 8M sample cleverscope, using 2 frames, one frame will be 4M samples long. For this setup, the system will always try and sample at maximum rate until the scope capture graph window is greater than 40 msecs. At that point the sample interval is stepped down to 20ns, capturing 80msecs. Our maximum capture width is +/-20 secs, at which point the sample interval is 10usec. Though the unit can internally sample slower than this, we never do it. Once the samples are in memory, we use sampled or peak-to-peak decimation to extract the sample set required to be displayed. We only ever transfer the samples you actually need for a display to the PC to maximize frame rate. The exception is if you hit 'Get Frame' in which case the entire frame (or a subset if you choose this) are transferred to the PC, and decimation then takes place from the PC memory instead of the acquisition unit memory. We do not specify specific sample rates - the sampler system is always running at 100 MSPS, and we decimate from those samples. The current longest record we can capture is +/-20 secs (because we use a 10ns timebase with 32 bit resolution timing numbers). We are currently working on a streaming solution that allows storage to hard disk. Our target is 1MSPS sustained.

If you use a larger number of frames, with sequentially triggered frames, then each frame will smaller in size. For example 10 frames yields 800Ksamples/frame for an 8M Cleverscope. This means the sample interval is stepped down earlier - at 8ms per frame we still have 10 ns resolution, but at 16 ms, you will get 20ns resolution. There are many possible cases!

F. The typical transfer rate depends heavily on other USB traffic, and if there is a hub in the way. We measure values between 12 Mbytes/sec to 18 Mbytes/sec sustained throughput. We have 4 bytes per sample (a sample is always the same Chan A + Chan B + Digital In packed into 32 bits), so that means 3 Msamples/sec to 4.5 Msample/sec.

Yes, you can measure two channels simultaneously, +/- 4V is no problem, you can measure/decimate them at any rate upto 100 MSPS. We cannot do 14 bits ENOB with the CS328A. We do have new hardware coming along that will meet the 14 bit ENOB requirements, but it is not yet available, even in beta.

Yes you can measure the TTL signal (actually 8 of them) at the same sampling rate.

Yes you can set up a trigger to capture as you want.

Currently our maximum record size is +/-20 secs (0 being the trigger point). This will be changed in the next month or so.

Yes the data transfers in less than 5-10 secs. We have an example on the website with 4 Msample of data in it (see examples page - http://www.cleverscope.com/examples/data/Filtering%20in%20Cleverscope.zip). You could play with that and see if it seems fast enough. Currently our storage and transfer system does not allow greater than 4 Msamples. We will look at making it so users can do a single shot capture, using the full 8 Msamples.

Is it possible that you have had a previous installation of Labview 7.1.1 on your machine? (ours is done in labview 7.1). Un-installing and re-installing teh applocation seems to help, or you can copy an update from our website to a different directory (eg program filescscope) and run out of teh new directory. This also seems to work. This experiemce is rare. We are about to update the demo app (it is way behind at the moment), so if you could wait until tomorrow for the full app before doing this that would be helpful. Othwerwise you can just copy the update to a new directory.

I hope this is helpful.

Hello Denis, Thanks for your long and detailed questions. Ok answers: A. The ADC's we use are the Linear Technology LTC2280, LTC2282 and LTC2284. These are true 10, 12 and 14 bit dual channel ADC's. We supply three different sampler (digitizer) modules. They are field upgradeable, but we have gone away from that a bit, as the connectors are very small high bandwidth ones, and getting it wrong is expensive. B. The sampling rate is the same for all three modules - 100 MSPS. Because they are dual channel ADC's both ADC's sample simultaneously at full rate. The ENOB figures are affected by input noise floor and input signal amplitude. We publish a document called 'Digitize performance' in our resources page (you can find it here: http://www.cleverscope.com/resources/Cleverscope%20CS328A%20performance.pdf) that discusses the business of dynamic range and SNR. As you change ranges both the gain and noise floor change meaning that ENOB will also change. Thus there is no one ENOB value. We can say that ENOB will always be worse than the ADC number of bits because of these factors. Such is life! We will do some derivations in the document, and provide indicative ENOBs in an update. C. The anti-aliasing filter is an analog 20 MHz LT6600-20 filter backed with a noise shaping digital filter. D. the 2 MHz filter is historical. Using Maths you can design any filter. The filter can be applied across the full sample set (up to 4 M samples) if you get the full frame into PC memory. E. If you have our 8M sample cleverscope, using 2 frames, one frame will be 4M samples long. For this setup, the system will always try and sample at maximum rate until the scope capture graph window is greater than 40 msecs. At that point the sample interval is stepped down to 20ns, capturing 80msecs. Our maximum capture width is +/-20 secs, at which point the sample interval is 10usec. Though the unit can internally sample slower than this, we never do it. Once the samples are in memory, we use sampled or peak-to-peak decimation to extract the sample set required to be displayed. We only ever transfer the samples you actually need for a display to the PC to maximize frame rate. The exception is if you hit 'Get Frame' in which case the entire frame (or a subset if you choose this) are transferred to the PC, and decimation then takes place from the PC memory instead of the acquisition unit memory. We do not specify specific sample rates - the sampler system is always running at 100 MSPS, and we decimate from those samples. The current longest record we can capture is +/-20 secs (because we use a 10ns timebase with 32 bit resolution timing numbers). We are currently working on a streaming solution that allows storage to hard disk. Our target is 1MSPS sustained. If you use a larger number of frames, with sequentially triggered frames, then each frame will smaller in size. For example 10 frames yields 800Ksamples/frame for an 8M Cleverscope. This means the sample interval is stepped down earlier - at 8ms per frame we still have 10 ns resolution, but at 16 ms, you will get 20ns resolution. There are many possible cases! F. The typical transfer rate depends heavily on other USB traffic, and if there is a hub in the way. We measure values between 12 Mbytes/sec to 18 Mbytes/sec sustained throughput. We have 4 bytes per sample (a sample is always the same Chan A + Chan B + Digital In packed into 32 bits), so that means 3 Msamples/sec to 4.5 Msample/sec. Yes, you can measure two channels simultaneously, +/- 4V is no problem, you can measure/decimate them at any rate upto 100 MSPS. We cannot do 14 bits ENOB with the CS328A. We do have new hardware coming along that will meet the 14 bit ENOB requirements, but it is not yet available, even in beta. Yes you can measure the TTL signal (actually 8 of them) at the same sampling rate. Yes you can set up a trigger to capture as you want. Currently our maximum record size is +/-20 secs (0 being the trigger point). This will be changed in the next month or so. Yes the data transfers in less than 5-10 secs. We have an example on the website with 4 Msample of data in it (see examples page - http://www.cleverscope.com/examples/data/Filtering%20in%20Cleverscope.zip). You could play with that and see if it seems fast enough. Currently our storage and transfer system does not allow greater than 4 Msamples. We will look at making it so users can do a single shot capture, using the full 8 Msamples. Is it possible that you have had a previous installation of Labview 7.1.1 on your machine? (ours is done in labview 7.1). Un-installing and re-installing teh applocation seems to help, or you can copy an update from our website to a different directory (eg program filescscope) and run out of teh new directory. This also seems to work. This experiemce is rare. We are about to update the demo app (it is way behind at the moment), so if you could wait until tomorrow for the full app before doing this that would be helpful. Othwerwise you can just copy the update to a new directory. I hope this is helpful.

Thanks for your answers Bart,

I start to understand better but have still a few complementary questions

>> A. The ADC's we use are the Linear Technology LTC2280, LTC2282 and LTC2284. These are true 10, 12 and 14 bit dual channel ADC's. We supply three different sampler (digitizer) modules.

OK

> B. The sampling rate is the same for all three modules - 100 MSPS. Because they are dual channel ADC's both ADC's sample simultaneously at full rate.

OK

>> The ENOB figures are affected by input noise floor and input signal amplitude.

The ENOB indicated by a ADC or scope manufacturer should characterize only the ADC or scope. If you mean ""equivalent input noise floor of the Cleverscope alone"", I agree. The ENOB should not depend on the amplitude of the measured signal but only on the full scale range set on the cleverscope.
This is why indicating the ENOB as a function of the range for 100MHz and 20 MHz bandwidth (with inputs left opened, but shielded to prevent the central pin from capturing external noise) would be very useful to specify the performances of the Cleverscope.

> We publish a document called 'Digitize performance' in our resources page (you can find it here: http://www.cleverscope.com/resources/Cleverscope%20CS328A%20performance.pdf) that discusses the business of dynamic range and SNR.

Thanks a lot ! I have read carefully this document, and was a bit puzzled: You start by measuring the noise with a 8mV full range and find that you should measure at least 192 mV to get an ENOB of 14 (page 4 and 5). Then you try to measure 192 mV on a 800 mV full range and find that you don't get 14 bits (page 17): of course because the full range has changed ! Moreover the measured signal does not occupy the full range which lowers the S/N or ENOB.
Giving simply the couples (Full range - ENOB) or (Full range - S/N) (with the signal being the full range) would be simpler and clearer. From that point of view, your verification of the 14 bits resolution on the range +/- 2.5 V (on page 21) does make sense (I guess a simple attenuator is inserted in front of the ADC for this range).

Then, in all these measurement, the role of the sampling period is not clear. Can the sampling period be interpreted as a bandpass? This would be the case for instance if when the sampling period is 6 µs, 600 samples are taken at 100 MS/s and are averaged to make a single output point, in order to increase the resolution (so-called high resolution mode or oversampling mode in most of the oscilloscopes). Does the Cleverscope does this or something similar to reach the 14 bits on page 21? Note that averaging oversampled samples is more general than all your examples of averaging where you always consider a periodic signal that can be averaged over several frames.
See also the same question in E.

>> As you change ranges both the gain and noise floor change meaning that ENOB will also change.

Of course! Once again, that's the interest of giving a table of the measured ENOB for all available ranges (and filters)!

>> Thus there is no one ENOB value. We can say that ENOB will always be worse than the ADC number of bits because of these factors. Such is life! We will do some derivations in the document, and provide indicative ENOBs in an update.

OK. (Note however that 8 bit scopes can reach easily an ENOB of 10 bits in oversampling mode)

>> C. The anti-aliasing filter is an analog 20 MHz LT6600-20 filter backed with a noise shaping digital filter.

OK.

>> D. the 2 MHz filter is historical. Using Maths you can design any filter. The filter can be applied across the full sample set (up to 4 M samples) if you get the full frame into PC memory.

OK. I understand it is a digital filter in the software, not on the board.

> E. If you have our 8M sample cleverscope, using 2 frames, one frame will be 4M samples long.

Why two frames? What about a single frame? Should I understand that for a single frame (and two channels) I will get two sets of 8MS packed in 8 MWords of 32 bits ?

>> For this setup, the system will always try and sample at maximum rate until the scope capture graph window is greater than 40 msecs. At that point the sample interval is stepped down to 20ns, capturing 80msecs. Our maximum capture width is +/-20 secs, at which point the sample interval is 10usec. Though the unit can internally sample slower than this, we never do it.

OK. So if I understand properly:
All points -> 100 MS/s -> 10ns -> 8MSx 10ns= 80 ms
1 point over 2 -> 50 MS/s -> 20 ns -> 8MSx 20ns= 160 ms
1 point over 3 -> 33 MS/s -> 30 ns -> 8MSx 30ns= 240 ms
1 point over 4 -> 25 MS/s -> 40 ns -> 8MSx 40ns= 320 ms
1 point over 5 -> 20 MS/s -> 50 ns -> 8MSx 50ns= 400ms
...
1 point over 10 -> 10 MS/s -> 100 ns -> 8MSx 100ns= 0.8s
...
1 point over 20 -> 5 MS/s -> 200 ns -> 8MSx 200ns= 1.6s
...
1 point over 50 -> 2 MS/s -> 500 ns -> 8MSx 500ns= 4s
...
1 point over 100 -> 1 MS/s -> 1 µs -> 8MSx 1µs= 8s
...
1 point over 200 -> 0.5 MS/s -> 2 µs -> 8MSx 2µs= 16 s
...
1point over 250 -> 0.4 MS/s -> 2.5 µs -> 8MSx 2.5µs= 20 s
...
1 point over 1000 -> 0.1 MS/s -> 10 µs -> ONLY 2MS x 1µs= 20 s (limitation)

Is it correct?

>> Once the samples are in memory, we use sampled or peak-to-peak decimation to extract the sample set required to be displayed. We only ever transfer the samples you actually need for a display to the PC to maximize frame rate.

Sorry I don't know what is a sampled decimation or peak to peak decimation. I guess it has something to do with the averaging I was mentionning in question B. Do you average or not? And when do you use one mode of decimation or the other?


>> The exception is if you hit 'Get Frame' in which case the entire frame (or a subset if you choose this) are transferred to the PC, and decimation then takes place from the PC memory instead of the acquisition unit memory.

Nice to have this mode!

>> We do not specify specific sample rates - the sampler system is always running at 100 MSPS, and we decimate from those samples. The current longest record we can capture is +/-20 secs (because we use a 10ns timebase with 32 bit resolution timing numbers).

Now I understand this limitation.

>> We are currently working on a streaming solution that allows storage to hard disk. Our target is 1MSPS sustained.

It would be great !


>> If you use a larger number of frames, with sequentially triggered frames, then each frame will smaller in size. For example 10 frames yields 800Ksamples/frame for an 8M Cleverscope. This means the sample interval is stepped down earlier - at 8ms per frame we still have 10 ns resolution, but at 16 ms, you will get 20ns resolution. There are many possible cases!

OK

>> F. The typical transfer rate depends heavily on other USB traffic, and if there is a hub in the way. We measure values between 12 Mbytes/sec to 18 Mbytes/sec sustained throughput. We have 4 bytes per sample (a sample is always the same Chan A + Chan B + Digital In packed into 32 bits), so that means 3 Msamples/sec to 4.5 Msample/sec.

OK

>> Yes, you can measure two channels simultaneously, +/- 4V is no problem, you can measure/decimate them at any rate upto 100 MSPS. We cannot do 14 bits ENOB with the CS328A.

Which ENOB or S/N ratio or can I reach for a 1MS/s apparent sampling time (100MS/s and a clever decimation involving averaging of the oversampled samples) and if I adapt my +/-4V to the best range of the cleverscope (+/-2.5V ?)? This is an important number for me. Note that I can't average frames because my signal is not periodic !

>> We do have new hardware coming along that will meet the 14 bit ENOB requirements, but it is not yet available, even in beta.
Great! Please keep me informed.

>> Yes you can measure the TTL signal (actually 8 of them) at the same sampling rate.
Yes you can set up a trigger to capture as you want.
Currently our maximum record size is +/-20 secs (0 being the trigger point). This will be changed in the next month or so.

OK. Will you increase the maximum length in single shot or only add the streaming mode for times longer than 20s.

>> Yes the data transfers in less than 5-10 secs. We have an example on the website with 4 Msample of data in it (see examples page - http://www.cleverscope.com/examples/data/Filtering%20in%20Cleverscope.zip). You could play with that and see if it seems fast enough. Currently our storage and transfer system does not allow greater than 4 Msamples. We will look at making it so users can do a single shot capture, using the full 8 Msamples.
Great ! When wil it be available?


>> Is it possible that you have had a previous installation of Labview 7.1.1 on your machine? (ours is done in labview 7.1). Un-installing and re-installing teh applocation seems to help, or you can copy an update from our website to a different directory (eg program filescscope) and run out of teh new directory. This also seems to work. This experiemce is rare. We are about to update the demo app (it is way behind at the moment), so if you could wait until tomorrow for the full app before doing this that would be helpful. Othwerwise you can just copy the update to a new directory.

I am stupid: Labview is not installed on my PC! I was thinking that your demo software was made with Labview but was compiled in order to work on any PC without Labview. I will retry on a PC with Labview.

Thanks again.


Denis

Thanks for your answers Bart, I start to understand better but have still a few complementary questions >> A. The ADC's we use are the Linear Technology LTC2280, LTC2282 and LTC2284. These are true 10, 12 and 14 bit dual channel ADC's. We supply three different sampler (digitizer) modules. OK > B. The sampling rate is the same for all three modules - 100 MSPS. Because they are dual channel ADC's both ADC's sample simultaneously at full rate. OK >> The ENOB figures are affected by input noise floor and input signal amplitude. The ENOB indicated by a ADC or scope manufacturer should characterize only the ADC or scope. If you mean ""equivalent input noise floor of the Cleverscope alone"", I agree. The ENOB should not depend on the amplitude of the measured signal but only on the full scale range set on the cleverscope. This is why indicating the ENOB as a function of the range for 100MHz and 20 MHz bandwidth (with inputs left opened, but shielded to prevent the central pin from capturing external noise) would be very useful to specify the performances of the Cleverscope. > We publish a document called 'Digitize performance' in our resources page (you can find it here: http://www.cleverscope.com/resources/Cleverscope%20CS328A%20performance.pdf) that discusses the business of dynamic range and SNR. Thanks a lot ! I have read carefully this document, and was a bit puzzled: You start by measuring the noise with a 8mV full range and find that you should measure at least 192 mV to get an ENOB of 14 (page 4 and 5). Then you try to measure 192 mV on a 800 mV full range and find that you don't get 14 bits (page 17): of course because the full range has changed ! Moreover the measured signal does not occupy the full range which lowers the S/N or ENOB. Giving simply the couples (Full range - ENOB) or (Full range - S/N) (with the signal being the full range) would be simpler and clearer. From that point of view, your verification of the 14 bits resolution on the range +/- 2.5 V (on page 21) does make sense (I guess a simple attenuator is inserted in front of the ADC for this range). Then, in all these measurement, the role of the sampling period is not clear. Can the sampling period be interpreted as a bandpass? This would be the case for instance if when the sampling period is 6 µs, 600 samples are taken at 100 MS/s and are averaged to make a single output point, in order to increase the resolution (so-called high resolution mode or oversampling mode in most of the oscilloscopes). Does the Cleverscope does this or something similar to reach the 14 bits on page 21? Note that averaging oversampled samples is more general than all your examples of averaging where you always consider a periodic signal that can be averaged over several frames. See also the same question in E. >> As you change ranges both the gain and noise floor change meaning that ENOB will also change. Of course! Once again, that's the interest of giving a table of the measured ENOB for all available ranges (and filters)! >> Thus there is no one ENOB value. We can say that ENOB will always be worse than the ADC number of bits because of these factors. Such is life! We will do some derivations in the document, and provide indicative ENOBs in an update. OK. (Note however that 8 bit scopes can reach easily an ENOB of 10 bits in oversampling mode) >> C. The anti-aliasing filter is an analog 20 MHz LT6600-20 filter backed with a noise shaping digital filter. OK. >> D. the 2 MHz filter is historical. Using Maths you can design any filter. The filter can be applied across the full sample set (up to 4 M samples) if you get the full frame into PC memory. OK. I understand it is a digital filter in the software, not on the board. > E. If you have our 8M sample cleverscope, using 2 frames, one frame will be 4M samples long. Why two frames? What about a single frame? Should I understand that for a single frame (and two channels) I will get two sets of 8MS packed in 8 MWords of 32 bits ? >> For this setup, the system will always try and sample at maximum rate until the scope capture graph window is greater than 40 msecs. At that point the sample interval is stepped down to 20ns, capturing 80msecs. Our maximum capture width is +/-20 secs, at which point the sample interval is 10usec. Though the unit can internally sample slower than this, we never do it. OK. So if I understand properly: All points -> 100 MS/s -> 10ns -> 8MSx 10ns= 80 ms 1 point over 2 -> 50 MS/s -> 20 ns -> 8MSx 20ns= 160 ms 1 point over 3 -> 33 MS/s -> 30 ns -> 8MSx 30ns= 240 ms 1 point over 4 -> 25 MS/s -> 40 ns -> 8MSx 40ns= 320 ms 1 point over 5 -> 20 MS/s -> 50 ns -> 8MSx 50ns= 400ms ... 1 point over 10 -> 10 MS/s -> 100 ns -> 8MSx 100ns= 0.8s ... 1 point over 20 -> 5 MS/s -> 200 ns -> 8MSx 200ns= 1.6s ... 1 point over 50 -> 2 MS/s -> 500 ns -> 8MSx 500ns= 4s ... 1 point over 100 -> 1 MS/s -> 1 µs -> 8MSx 1µs= 8s ... 1 point over 200 -> 0.5 MS/s -> 2 µs -> 8MSx 2µs= 16 s ... 1point over 250 -> 0.4 MS/s -> 2.5 µs -> 8MSx 2.5µs= 20 s ... 1 point over 1000 -> 0.1 MS/s -> 10 µs -> ONLY 2MS x 1µs= 20 s (limitation) Is it correct? >> Once the samples are in memory, we use sampled or peak-to-peak decimation to extract the sample set required to be displayed. We only ever transfer the samples you actually need for a display to the PC to maximize frame rate. Sorry I don't know what is a sampled decimation or peak to peak decimation. I guess it has something to do with the averaging I was mentionning in question B. Do you average or not? And when do you use one mode of decimation or the other? >> The exception is if you hit 'Get Frame' in which case the entire frame (or a subset if you choose this) are transferred to the PC, and decimation then takes place from the PC memory instead of the acquisition unit memory. Nice to have this mode! >> We do not specify specific sample rates - the sampler system is always running at 100 MSPS, and we decimate from those samples. The current longest record we can capture is +/-20 secs (because we use a 10ns timebase with 32 bit resolution timing numbers). Now I understand this limitation. >> We are currently working on a streaming solution that allows storage to hard disk. Our target is 1MSPS sustained. It would be great ! >> If you use a larger number of frames, with sequentially triggered frames, then each frame will smaller in size. For example 10 frames yields 800Ksamples/frame for an 8M Cleverscope. This means the sample interval is stepped down earlier - at 8ms per frame we still have 10 ns resolution, but at 16 ms, you will get 20ns resolution. There are many possible cases! OK >> F. The typical transfer rate depends heavily on other USB traffic, and if there is a hub in the way. We measure values between 12 Mbytes/sec to 18 Mbytes/sec sustained throughput. We have 4 bytes per sample (a sample is always the same Chan A + Chan B + Digital In packed into 32 bits), so that means 3 Msamples/sec to 4.5 Msample/sec. OK >> Yes, you can measure two channels simultaneously, +/- 4V is no problem, you can measure/decimate them at any rate upto 100 MSPS. We cannot do 14 bits ENOB with the CS328A. Which ENOB or S/N ratio or can I reach for a 1MS/s apparent sampling time (100MS/s and a clever decimation involving averaging of the oversampled samples) and if I adapt my +/-4V to the best range of the cleverscope (+/-2.5V ?)? This is an important number for me. Note that I can't average frames because my signal is not periodic ! >> We do have new hardware coming along that will meet the 14 bit ENOB requirements, but it is not yet available, even in beta. Great! Please keep me informed. >> Yes you can measure the TTL signal (actually 8 of them) at the same sampling rate. Yes you can set up a trigger to capture as you want. Currently our maximum record size is +/-20 secs (0 being the trigger point). This will be changed in the next month or so. OK. Will you increase the maximum length in single shot or only add the streaming mode for times longer than 20s. >> Yes the data transfers in less than 5-10 secs. We have an example on the website with 4 Msample of data in it (see examples page - http://www.cleverscope.com/examples/data/Filtering%20in%20Cleverscope.zip). You could play with that and see if it seems fast enough. Currently our storage and transfer system does not allow greater than 4 Msamples. We will look at making it so users can do a single shot capture, using the full 8 Msamples. Great ! When wil it be available? >> Is it possible that you have had a previous installation of Labview 7.1.1 on your machine? (ours is done in labview 7.1). Un-installing and re-installing teh applocation seems to help, or you can copy an update from our website to a different directory (eg program filescscope) and run out of teh new directory. This also seems to work. This experiemce is rare. We are about to update the demo app (it is way behind at the moment), so if you could wait until tomorrow for the full app before doing this that would be helpful. Othwerwise you can just copy the update to a new directory. I am stupid: Labview is not installed on my PC! I was thinking that your demo software was made with Labview but was compiled in order to work on any PC without Labview. I will retry on a PC with Labview. Thanks again. Denis

Thanks for your answers Bart,

I start to understand better but have still a few complementary questions

>> A. The ADC's we use are the Linear Technology LTC2280, LTC2282 and LTC2284. These are true 10, 12 and 14 bit dual channel ADC's. We supply three different sampler (digitizer) modules.

OK

> B. The sampling rate is the same for all three modules - 100 MSPS. Because they are dual channel ADC's both ADC's sample simultaneously at full rate.

OK

>> The ENOB figures are affected by input noise floor and input signal amplitude.

The ENOB indicated by a ADC or scope manufacturer should characterize only the ADC or scope. If you mean ""equivalent input noise floor of the Cleverscope alone"", I agree. The ENOB should not depend on the amplitude of the measured signal but only on the full scale range set on the cleverscope.
---- Correct

This is why indicating the ENOB as a function of the range for 100MHz and 20 MHz bandwidth (with inputs left opened, but shielded to prevent the central pin from capturing external noise) would be very useful to specify the performances of the Cleverscope.

> We publish a document called 'Digitize performance' in our resources page (you can find it here: http://www.cleverscope.com/resources/Cl … rmance.pdf) that discusses the business of dynamic range and SNR.

Thanks a lot ! I have read carefully this document, and was a bit puzzled: You start by measuring the noise with a 8mV full range and find that you should measure at least 192 mV to get an ENOB of 14 (page 4 and 5).

----- Our noise floor remains constant. So we start with an 8mV full scale, so we can estimate the noise floor (it is teh best case noise floor, for a variety of reasons). Next we work out what size signal we would need to still have an lsb of headroom. From that we get 192 mv for the 14 bit case. When we set the full range to 192 mV, our noise floor has risen (it is to do with how VGA's work), and we find we cannot get our 14 bits until the full scale is 800 mV.
All our measurements are over the full bandwidth, as we say in the document.

Then you try to measure 192 mV on a 800 mV full range and find that you don't get 14 bits (page 17): of course because the full range has changed ! Moreover the measured signal does not occupy the full range which lowers the S/N or ENOB.
Giving simply the couples (Full range - ENOB) or (Full range - S/N) (with the signal being the full range) would be simpler and clearer. From that point of view, your verification of the 14 bits resolution on the range +/- 2.5 V (on page 21) does make sense (I guess a simple attenuator is inserted in front of the ADC for this range).
---- the 2.5V range has teh greatest dynamic range, because the path is almost direct.

Then, in all these measurement, the role of the sampling period is not clear. Can the sampling period be interpreted as a bandpass?

--- No, the bandwidth is over the full bandwidth. We are just using a sampled signal, and therefore all the noise aliases into the window you are looking at. If as you say, we impose a moving average, or digital filter, we will reduce the noise and increase the dynamic range. But our interest in the document is to look at the native noise of the unit.

This would be the case for instance if when the sampling period is 6 µs, 600 samples are taken at 100 MS/s and are averaged to make a single output point, in order to increase the resolution (so-called high resolution mode or oversampling mode in most of the oscilloscopes). Does the Cleverscope does this or something similar to reach the 14 bits on page 21?

-- No, we have no other processing to improve the resolution here. We are interested in a non-artificially improved raw sample stream. Our philosophy is to capture the stream at full bandwidth, as big as possible, preserve it as the original signal as much as possible, and then manipulate it later. That way it can be re-manipulated again in another way if needed. For example you could apply (using Maths) a digital filter with first one bandwidth, and then another.

Note that averaging oversampled samples is more general than all your examples of averaging where you always consider a periodic signal that can be averaged over several frames.

---- yes, but you can easily do digital filtering in the PC afterwards - remember all the samples are still there.
For the case where our sample rate has been reduced because the scope window is too wide, yes we use a moving average as we go to generate the slower sample rate. But in our document none of the examples used sampling that was that slow.

See also the same question in E.

>> As you change ranges both the gain and noise floor change meaning that ENOB will also change.

Of course! Once again, that's the interest of giving a table of the measured ENOB for all available ranges (and filters)!
Ok, we will look at providing some indicative Enob figures.

>> Thus there is no one ENOB value. We can say that ENOB will always be worse than the ADC number of bits because of these factors. Such is life! We will do some derivations in the document, and provide indicative ENOBs in an update.

OK. (Note however that 8 bit scopes can reach easily an ENOB of 10 bits in oversampling mode).
---- so can we. You can easily achieve 16 bits, if you push the signal through a filter. We have not written a specific white paper on filtering, and this is probably a good thing to do. However, in our resources page we have a document which touches on it - see http://www.cleverscope.com/resources/Cleverscope%20integration%20and%20filtering.pdf


>> C. The anti-aliasing filter is an analog 20 MHz LT6600-20 filter backed with a noise shaping digital filter.

OK.

>> D. the 2 MHz filter is historical. Using Maths you can design any filter. The filter can be applied across the full sample set (up to 4 M samples) if you get the full frame into PC memory.

OK. I understand it is a digital filter in the software, not on the board.

> E. If you have our 8M sample cleverscope, using 2 frames, one frame will be 4M samples long.

Why two frames? What about a single frame? Should I understand that for a single frame (and two channels) I will get two sets of 8MS packed in 8 MWords of 32 bits ?
--- we have two + frames, because that gives us one frame to do sampling in, while the other (s) are used to display the last or previous triggers. This allows you to set the scope to Triggered capture, and examine the previous capture while waiting for the next one. Each sample of 32 bits contains both channels + digitals.

>> For this setup, the system will always try and sample at maximum rate until the scope capture graph window is greater than 40 msecs. At that point the sample interval is stepped down to 20ns, capturing 80msecs. Our maximum capture width is +/-20 secs, at which point the sample interval is 10usec. Though the unit can internally sample slower than this, we never do it.

OK. So if I understand properly:
All points -> 100 MS/s -> 10ns -> 8MSx 10ns= 80 ms
1 point over 2 -> 50 MS/s -> 20 ns -> 8MSx 20ns= 160 ms
1 point over 3 -> 33 MS/s -> 30 ns -> 8MSx 30ns= 240 ms
1 point over 4 -> 25 MS/s -> 40 ns -> 8MSx 40ns= 320 ms
1 point over 5 -> 20 MS/s -> 50 ns -> 8MSx 50ns= 400ms
...
1 point over 10 -> 10 MS/s -> 100 ns -> 8MSx 100ns= 0.8s
...
1 point over 20 -> 5 MS/s -> 200 ns -> 8MSx 200ns= 1.6s
...
1 point over 50 -> 2 MS/s -> 500 ns -> 8MSx 500ns= 4s
...
1 point over 100 -> 1 MS/s -> 1 µs -> 8MSx 1µs= 8s
...
1 point over 200 -> 0.5 MS/s -> 2 µs -> 8MSx 2µs= 16 s
...
1point over 250 -> 0.4 MS/s -> 2.5 µs -> 8MSx 2.5µs= 20 s
...
1 point over 1000 -> 0.1 MS/s -> 10 µs -> ONLY 2MS x 1µs= 20 s (limitation)

Is it correct?
------- Yes


>> Once the samples are in memory, we use sampled or peak-to-peak decimation to extract the sample set required to be displayed. We only ever transfer the samples you actually need for a display to the PC to maximize frame rate.

Sorry I don't know what is a sampled decimation or peak to peak decimation. I guess it has something to do with the averaging I was mentionning in question B. Do you average or not? And when do you use one mode of decimation or the other?
----- sampled means that we just take equally spaced samples from the sample set and transfer those, 8 per display pixel. Peak -to peak decimated means that we find all the samples that one pixel represents, and find both the minimum and maximum values in the interval, and transfer both of them. We over sample 8 points per pixels. For every capture we transfer up to 3 display definitions, which can all be quite different - for the scope graph, the tracker graph, and the spectrum graph. We can also do moving averaged decimation, where the samples are moving averaged and sampled before transfer.

>> The exception is if you hit 'Get Frame' in which case the entire frame (or a subset if you choose this) are transferred to the PC, and decimation then takes place from the PC memory instead of the acquisition unit memory.

Nice to have this mode!

>> We do not specify specific sample rates - the sampler system is always running at 100 MSPS, and we decimate from those samples. The current longest record we can capture is +/-20 secs (because we use a 10ns timebase with 32 bit resolution timing numbers).

Now I understand this limitation.

>> We are currently working on a streaming solution that allows storage to hard disk. Our target is 1MSPS sustained.

It would be great !


>> If you use a larger number of frames, with sequentially triggered frames, then each frame will smaller in size. For example 10 frames yields 800Ksamples/frame for an 8M Cleverscope. This means the sample interval is stepped down earlier - at 8ms per frame we still have 10 ns resolution, but at 16 ms, you will get 20ns resolution. There are many possible cases!

OK

>> F. The typical transfer rate depends heavily on other USB traffic, and if there is a hub in the way. We measure values between 12 Mbytes/sec to 18 Mbytes/sec sustained throughput. We have 4 bytes per sample (a sample is always the same Chan A + Chan B + Digital In packed into 32 bits), so that means 3 Msamples/sec to 4.5 Msample/sec.

OK

>> Yes, you can measure two channels simultaneously, +/- 4V is no problem, you can measure/decimate them at any rate upto 100 MSPS. We cannot do 14 bits ENOB with the CS328A.

Which ENOB or S/N ratio or can I reach for a 1MS/s apparent sampling time (100MS/s and a clever decimation involving averaging of the oversampled samples) and if I adapt my +/-4V to the best range of the cleverscope (+/-2.5V ?)? This is an important number for me. Note that I can't average frames because my signal is not periodic !
-- With a 100:1 reduction in sampling rate, based on what we know about the noise and quantization characteristic of teh ADC you should get around 16 bit equivalent. However, we currently only transfer 14 bits. So lets make it 14.

>> We do have new hardware coming along that will meet the 14 bit ENOB requirements, but it is not yet available, even in beta.
Great! Please keep me informed.

>> Yes you can measure the TTL signal (actually 8 of them) at the same sampling rate.
Yes you can set up a trigger to capture as you want.
Currently our maximum record size is +/-20 secs (0 being the trigger point). This will be changed in the next month or so.

OK. Will you increase the maximum length in single shot or only add the streaming mode for times longer than 20s.
-- we will be adding streaming mode for longer than 20 secs. There has not been much demand for single shot captures longer than +/-20 secs, and it means quite a rejig of the acquisition state systems.

>> Yes the data transfers in less than 5-10 secs. We have an example on the website with 4 Msample of data in it (see examples page - http://www.cleverscope.com/examples/data/Filtering%20in%20Cleverscope.zip). You could play with that and see if it seems fast enough. Currently our storage and transfer system does not allow greater than 4 Msamples. We will look at making it so users can do a single shot capture, using the full 8 Msamples.
Great ! When wil it be available?
---- When we get there.


>> Is it possible that you have had a previous installation of Labview 7.1.1 on your machine? (ours is done in labview 7.1). Un-installing and re-installing teh applocation seems to help, or you can copy an update from our website to a different directory (eg program filescscope) and run out of teh new directory. This also seems to work. This experiemce is rare. We are about to update the demo app (it is way behind at the moment), so if you could wait until tomorrow for the full app before doing this that would be helpful. Othwerwise you can just copy the update to a new directory.

I am stupid: Labview is not installed on my PC! I was thinking that your demo software was made with Labview but was compiled in order to work on any PC without Labview. I will retry on a PC with Labview.
---- No, there is no need for Labview. The application is an executabel, and the installer loads the required run-time libraries. The question was have you had Labview 7.1.1 loaded on your machine at some prior stage. In any case we have just placed a brand new version of the demo program on the website, and if you are willing to download it, it would be a better bet for checking everything out. Please try again to install it. If you have problems, please email us at support.

Thanks again.
--- no probs! - Bart

Denis

Thanks for your answers Bart, I start to understand better but have still a few complementary questions >> A. The ADC's we use are the Linear Technology LTC2280, LTC2282 and LTC2284. These are true 10, 12 and 14 bit dual channel ADC's. We supply three different sampler (digitizer) modules. OK > B. The sampling rate is the same for all three modules - 100 MSPS. Because they are dual channel ADC's both ADC's sample simultaneously at full rate. OK >> The ENOB figures are affected by input noise floor and input signal amplitude. The ENOB indicated by a ADC or scope manufacturer should characterize only the ADC or scope. If you mean ""equivalent input noise floor of the Cleverscope alone"", I agree. The ENOB should not depend on the amplitude of the measured signal but only on the full scale range set on the cleverscope. ---- Correct This is why indicating the ENOB as a function of the range for 100MHz and 20 MHz bandwidth (with inputs left opened, but shielded to prevent the central pin from capturing external noise) would be very useful to specify the performances of the Cleverscope. > We publish a document called 'Digitize performance' in our resources page (you can find it here: http://www.cleverscope.com/resources/Cl … rmance.pdf) that discusses the business of dynamic range and SNR. Thanks a lot ! I have read carefully this document, and was a bit puzzled: You start by measuring the noise with a 8mV full range and find that you should measure at least 192 mV to get an ENOB of 14 (page 4 and 5). ----- Our noise floor remains constant. So we start with an 8mV full scale, so we can estimate the noise floor (it is teh best case noise floor, for a variety of reasons). Next we work out what size signal we would need to still have an lsb of headroom. From that we get 192 mv for the 14 bit case. When we set the full range to 192 mV, our noise floor has risen (it is to do with how VGA's work), and we find we cannot get our 14 bits until the full scale is 800 mV. All our measurements are over the full bandwidth, as we say in the document. Then you try to measure 192 mV on a 800 mV full range and find that you don't get 14 bits (page 17): of course because the full range has changed ! Moreover the measured signal does not occupy the full range which lowers the S/N or ENOB. Giving simply the couples (Full range - ENOB) or (Full range - S/N) (with the signal being the full range) would be simpler and clearer. From that point of view, your verification of the 14 bits resolution on the range +/- 2.5 V (on page 21) does make sense (I guess a simple attenuator is inserted in front of the ADC for this range). ---- the 2.5V range has teh greatest dynamic range, because the path is almost direct. Then, in all these measurement, the role of the sampling period is not clear. Can the sampling period be interpreted as a bandpass? --- No, the bandwidth is over the full bandwidth. We are just using a sampled signal, and therefore all the noise aliases into the window you are looking at. If as you say, we impose a moving average, or digital filter, we will reduce the noise and increase the dynamic range. But our interest in the document is to look at the native noise of the unit. This would be the case for instance if when the sampling period is 6 µs, 600 samples are taken at 100 MS/s and are averaged to make a single output point, in order to increase the resolution (so-called high resolution mode or oversampling mode in most of the oscilloscopes). Does the Cleverscope does this or something similar to reach the 14 bits on page 21? -- No, we have no other processing to improve the resolution here. We are interested in a non-artificially improved raw sample stream. Our philosophy is to capture the stream at full bandwidth, as big as possible, preserve it as the original signal as much as possible, and then manipulate it later. That way it can be re-manipulated again in another way if needed. For example you could apply (using Maths) a digital filter with first one bandwidth, and then another. Note that averaging oversampled samples is more general than all your examples of averaging where you always consider a periodic signal that can be averaged over several frames. ---- yes, but you can easily do digital filtering in the PC afterwards - remember all the samples are still there. For the case where our sample rate has been reduced because the scope window is too wide, yes we use a moving average as we go to generate the slower sample rate. But in our document none of the examples used sampling that was that slow. See also the same question in E. >> As you change ranges both the gain and noise floor change meaning that ENOB will also change. Of course! Once again, that's the interest of giving a table of the measured ENOB for all available ranges (and filters)! Ok, we will look at providing some indicative Enob figures. >> Thus there is no one ENOB value. We can say that ENOB will always be worse than the ADC number of bits because of these factors. Such is life! We will do some derivations in the document, and provide indicative ENOBs in an update. OK. (Note however that 8 bit scopes can reach easily an ENOB of 10 bits in oversampling mode). ---- so can we. You can easily achieve 16 bits, if you push the signal through a filter. We have not written a specific white paper on filtering, and this is probably a good thing to do. However, in our resources page we have a document which touches on it - see http://www.cleverscope.com/resources/Cleverscope%20integration%20and%20filtering.pdf >> C. The anti-aliasing filter is an analog 20 MHz LT6600-20 filter backed with a noise shaping digital filter. OK. >> D. the 2 MHz filter is historical. Using Maths you can design any filter. The filter can be applied across the full sample set (up to 4 M samples) if you get the full frame into PC memory. OK. I understand it is a digital filter in the software, not on the board. > E. If you have our 8M sample cleverscope, using 2 frames, one frame will be 4M samples long. Why two frames? What about a single frame? Should I understand that for a single frame (and two channels) I will get two sets of 8MS packed in 8 MWords of 32 bits ? --- we have two + frames, because that gives us one frame to do sampling in, while the other (s) are used to display the last or previous triggers. This allows you to set the scope to Triggered capture, and examine the previous capture while waiting for the next one. Each sample of 32 bits contains both channels + digitals. >> For this setup, the system will always try and sample at maximum rate until the scope capture graph window is greater than 40 msecs. At that point the sample interval is stepped down to 20ns, capturing 80msecs. Our maximum capture width is +/-20 secs, at which point the sample interval is 10usec. Though the unit can internally sample slower than this, we never do it. OK. So if I understand properly: All points -> 100 MS/s -> 10ns -> 8MSx 10ns= 80 ms 1 point over 2 -> 50 MS/s -> 20 ns -> 8MSx 20ns= 160 ms 1 point over 3 -> 33 MS/s -> 30 ns -> 8MSx 30ns= 240 ms 1 point over 4 -> 25 MS/s -> 40 ns -> 8MSx 40ns= 320 ms 1 point over 5 -> 20 MS/s -> 50 ns -> 8MSx 50ns= 400ms ... 1 point over 10 -> 10 MS/s -> 100 ns -> 8MSx 100ns= 0.8s ... 1 point over 20 -> 5 MS/s -> 200 ns -> 8MSx 200ns= 1.6s ... 1 point over 50 -> 2 MS/s -> 500 ns -> 8MSx 500ns= 4s ... 1 point over 100 -> 1 MS/s -> 1 µs -> 8MSx 1µs= 8s ... 1 point over 200 -> 0.5 MS/s -> 2 µs -> 8MSx 2µs= 16 s ... 1point over 250 -> 0.4 MS/s -> 2.5 µs -> 8MSx 2.5µs= 20 s ... 1 point over 1000 -> 0.1 MS/s -> 10 µs -> ONLY 2MS x 1µs= 20 s (limitation) Is it correct? ------- Yes >> Once the samples are in memory, we use sampled or peak-to-peak decimation to extract the sample set required to be displayed. We only ever transfer the samples you actually need for a display to the PC to maximize frame rate. Sorry I don't know what is a sampled decimation or peak to peak decimation. I guess it has something to do with the averaging I was mentionning in question B. Do you average or not? And when do you use one mode of decimation or the other? ----- sampled means that we just take equally spaced samples from the sample set and transfer those, 8 per display pixel. Peak -to peak decimated means that we find all the samples that one pixel represents, and find both the minimum and maximum values in the interval, and transfer both of them. We over sample 8 points per pixels. For every capture we transfer up to 3 display definitions, which can all be quite different - for the scope graph, the tracker graph, and the spectrum graph. We can also do moving averaged decimation, where the samples are moving averaged and sampled before transfer. >> The exception is if you hit 'Get Frame' in which case the entire frame (or a subset if you choose this) are transferred to the PC, and decimation then takes place from the PC memory instead of the acquisition unit memory. Nice to have this mode! >> We do not specify specific sample rates - the sampler system is always running at 100 MSPS, and we decimate from those samples. The current longest record we can capture is +/-20 secs (because we use a 10ns timebase with 32 bit resolution timing numbers). Now I understand this limitation. >> We are currently working on a streaming solution that allows storage to hard disk. Our target is 1MSPS sustained. It would be great ! >> If you use a larger number of frames, with sequentially triggered frames, then each frame will smaller in size. For example 10 frames yields 800Ksamples/frame for an 8M Cleverscope. This means the sample interval is stepped down earlier - at 8ms per frame we still have 10 ns resolution, but at 16 ms, you will get 20ns resolution. There are many possible cases! OK >> F. The typical transfer rate depends heavily on other USB traffic, and if there is a hub in the way. We measure values between 12 Mbytes/sec to 18 Mbytes/sec sustained throughput. We have 4 bytes per sample (a sample is always the same Chan A + Chan B + Digital In packed into 32 bits), so that means 3 Msamples/sec to 4.5 Msample/sec. OK >> Yes, you can measure two channels simultaneously, +/- 4V is no problem, you can measure/decimate them at any rate upto 100 MSPS. We cannot do 14 bits ENOB with the CS328A. Which ENOB or S/N ratio or can I reach for a 1MS/s apparent sampling time (100MS/s and a clever decimation involving averaging of the oversampled samples) and if I adapt my +/-4V to the best range of the cleverscope (+/-2.5V ?)? This is an important number for me. Note that I can't average frames because my signal is not periodic ! -- With a 100:1 reduction in sampling rate, based on what we know about the noise and quantization characteristic of teh ADC you should get around 16 bit equivalent. However, we currently only transfer 14 bits. So lets make it 14. >> We do have new hardware coming along that will meet the 14 bit ENOB requirements, but it is not yet available, even in beta. Great! Please keep me informed. >> Yes you can measure the TTL signal (actually 8 of them) at the same sampling rate. Yes you can set up a trigger to capture as you want. Currently our maximum record size is +/-20 secs (0 being the trigger point). This will be changed in the next month or so. OK. Will you increase the maximum length in single shot or only add the streaming mode for times longer than 20s. -- we will be adding streaming mode for longer than 20 secs. There has not been much demand for single shot captures longer than +/-20 secs, and it means quite a rejig of the acquisition state systems. >> Yes the data transfers in less than 5-10 secs. We have an example on the website with 4 Msample of data in it (see examples page - http://www.cleverscope.com/examples/data/Filtering%20in%20Cleverscope.zip). You could play with that and see if it seems fast enough. Currently our storage and transfer system does not allow greater than 4 Msamples. We will look at making it so users can do a single shot capture, using the full 8 Msamples. Great ! When wil it be available? ---- When we get there. >> Is it possible that you have had a previous installation of Labview 7.1.1 on your machine? (ours is done in labview 7.1). Un-installing and re-installing teh applocation seems to help, or you can copy an update from our website to a different directory (eg program filescscope) and run out of teh new directory. This also seems to work. This experiemce is rare. We are about to update the demo app (it is way behind at the moment), so if you could wait until tomorrow for the full app before doing this that would be helpful. Othwerwise you can just copy the update to a new directory. I am stupid: Labview is not installed on my PC! I was thinking that your demo software was made with Labview but was compiled in order to work on any PC without Labview. I will retry on a PC with Labview. ---- No, there is no need for Labview. The application is an executabel, and the installer loads the required run-time libraries. The question was have you had Labview 7.1.1 loaded on your machine at some prior stage. In any case we have just placed a brand new version of the demo program on the website, and if you are willing to download it, it would be a better bet for checking everything out. Please try again to install it. If you have problems, please email us at support. Thanks again. --- no probs! - Bart Denis

Dear Bart,

Your last answers make me think that the cleverscope could meet my requirements, although we both thought it was not the case a few days ago. Indeed, you wrote:

""We only ever transfer the samples you actually need for a display to the PC to maximize frame rate.""
""We can also do moving averaged decimation, where the samples are moving averaged and sampled before transfer.""
""With a 100:1 reduction in sampling rate, based on what we know about the noise and quantization characteristic of teh ADC you should get around 16 bit equivalent. However, we currently only transfer 14 bits. So lets make it 14. ""
""Our maximum capture width is +/-20 secs, at which point the sample interval is 10usec.""

1) Thus, I conclude that for voltages in the full range of +/- 2.5 volts, it is possible to record 20 s of points @ 0.1 MS/s and of 4 s @ 1MS/s with a true resolution (ENOB) of 14 bits, with a moving average decimation performed on the board, before transfer. A record of 0.4s @ 10MS/s with a resolution of 14 or 13.5 bits should also be possible.
Do you confirm?

Since my last post, I have installed your new demo software, which now works on my PC (I don't know what happened with the previous version - note that I had not installed any Labview version before).
I have played a bit with the program, using simulated noisy square waves. I have encountered the following problems (probably because I did something wrong):
2) The ""Duration"", ""Resolution"", ""N display"", and ""Fsample"" indicators never change, whatever I do, even with a 0.6 s wide scope window (store 2 frames, 1 frame per capture), and for any ""Display mode"". Is it normal?
3) Selecting ""average"" does not reduce the noise on the plateaus of the square wave, whatever the selected ""acquisition"" and ""averaging settings"" settings are.
4) I did not find how to control this moving averaging decimation before transfer.


Now, I make a few remarks concerning points we have discussed previously:

5) "" We have no other processing to improve the resolution here. We are interested in a non-artificially improved raw sample stream.
Our philosophy is to capture the stream at full bandwidth, as big as possible, preserve it as the original signal as much as possible, and then manipulate it later. That way it can be re-manipulated again in another way if needed. For example you could apply (using Maths) a digital filter with first one bandwidth, and then another. ""

I do understand your point. But lowering the bandwidth by a moving averaging decimation is not an artificial procedure, if you know you measure a signal with no high frequency components. The original signal is the one at the input of the cleverscope, not the set of samples at 100 MS/s with the noise added by the cleverscope. Letting the user choose his effective sampling period and effective bandwidth can also be a good philosophy...


6) "" (Note however that 8 bit scopes can reach easily an ENOB of 10 bits in oversampling mode).
---- so can we. You can easily achieve 16 bits, if you push the signal through a filter. ""
-- With a 100:1 reduction in sampling rate, based on what we know about the noise and quantization characteristic of teh ADC you should get around 16 bit equivalent. However, we currently only transfer 14 bits. So lets make it 14. ""

If you really get a 16 bits ENOB at 1MS/s, you have a very good scope
You may consider giving the possibility to keep this 16 effective bits by throwing away additional digital lines.
Many users would be interested and your competitors (picoscope for instance) communicate a lot on this enhanced resolution mode obtained by oversampling.


7) ""We will look at making it so users can do a single shot capture, using the full 8 Msamples.""
Yes, if you could lower the minimum number of frame down to 1 (at least in the ""single"" trigger mode, but why not also in the ""triggered"" one), it would be very helpfull.

If you confirm my conclusion 1), confirm it is possible to set the cleverscope application parameters to obtain the records described in 1), and extend the record length to 8 MS (7), the Cleverscope is the scope I need !

Best regards,

Denis

Dear Bart, Your last answers make me think that the cleverscope could meet my requirements, although we both thought it was not the case a few days ago. Indeed, you wrote: ""We only ever transfer the samples you actually need for a display to the PC to maximize frame rate."" ""We can also do moving averaged decimation, where the samples are moving averaged and sampled before transfer."" ""With a 100:1 reduction in sampling rate, based on what we know about the noise and quantization characteristic of teh ADC you should get around 16 bit equivalent. However, we currently only transfer 14 bits. So lets make it 14. "" ""Our maximum capture width is +/-20 secs, at which point the sample interval is 10usec."" 1) Thus, I conclude that for voltages in the full range of +/- 2.5 volts, it is possible to record 20 s of points @ 0.1 MS/s and of 4 s @ 1MS/s with a true resolution (ENOB) of 14 bits, with a moving average decimation performed on the board, before transfer. A record of 0.4s @ 10MS/s with a resolution of 14 or 13.5 bits should also be possible. Do you confirm? Since my last post, I have installed your new demo software, which now works on my PC (I don't know what happened with the previous version - note that I had not installed any Labview version before). I have played a bit with the program, using simulated noisy square waves. I have encountered the following problems (probably because I did something wrong): 2) The ""Duration"", ""Resolution"", ""N display"", and ""Fsample"" indicators never change, whatever I do, even with a 0.6 s wide scope window (store 2 frames, 1 frame per capture), and for any ""Display mode"". Is it normal? 3) Selecting ""average"" does not reduce the noise on the plateaus of the square wave, whatever the selected ""acquisition"" and ""averaging settings"" settings are. 4) I did not find how to control this moving averaging decimation before transfer. Now, I make a few remarks concerning points we have discussed previously: 5) "" We have no other processing to improve the resolution here. We are interested in a non-artificially improved raw sample stream. Our philosophy is to capture the stream at full bandwidth, as big as possible, preserve it as the original signal as much as possible, and then manipulate it later. That way it can be re-manipulated again in another way if needed. For example you could apply (using Maths) a digital filter with first one bandwidth, and then another. "" I do understand your point. But lowering the bandwidth by a moving averaging decimation is not an artificial procedure, if you know you measure a signal with no high frequency components. The original signal is the one at the input of the cleverscope, not the set of samples at 100 MS/s with the noise added by the cleverscope. Letting the user choose his effective sampling period and effective bandwidth can also be a good philosophy... 6) "" (Note however that 8 bit scopes can reach easily an ENOB of 10 bits in oversampling mode). ---- so can we. You can easily achieve 16 bits, if you push the signal through a filter. "" -- With a 100:1 reduction in sampling rate, based on what we know about the noise and quantization characteristic of teh ADC you should get around 16 bit equivalent. However, we currently only transfer 14 bits. So lets make it 14. "" If you really get a 16 bits ENOB at 1MS/s, you have a very good scope You may consider giving the possibility to keep this 16 effective bits by throwing away additional digital lines. Many users would be interested and your competitors (picoscope for instance) communicate a lot on this enhanced resolution mode obtained by oversampling. 7) ""We will look at making it so users can do a single shot capture, using the full 8 Msamples."" Yes, if you could lower the minimum number of frame down to 1 (at least in the ""single"" trigger mode, but why not also in the ""triggered"" one), it would be very helpfull. If you confirm my conclusion 1), confirm it is possible to set the cleverscope application parameters to obtain the records described in 1), and extend the record length to 8 MS (7), the Cleverscope is the scope I need ! Best regards, Denis

Hello Denis,
Thanks for your update.
I think you are right! I agree that it is possible for you to transfer then samples at either 10us/sample or 1us/sample, with a moving average decimation.

Our demo software - it uses a real time software simulator to generate sine, triangle and square waves. It has very little of the functionality of the real acquisition unit. It is not (we think) worth our while to spend time improving the simulator, when we could instead spend that time (we are resource constrained) on the real acquisition unit, or the cleverscope application. So the simulator doesn't do those things. We say that on the download page. So 2-4 don't work.

Instead we provide examples of real signals on our examples page, that have been captured with an acquisition unit, so you can play around with them.

The method to select how the waveform is processed before it is transferred is the 'Display Method' on the top centre of the Control Panel. You will see Sampled, Peak Captured, Filtered, Repetitive, Waveform Avg. You want Filtered. (The Waveform Avg takes either 4,16, 64 or 128 consecutive waveforms and averages them time synchronous to the trigger, inside the acquisition unit. It automatically uses the right number of frames, and is much faster than doing it in the PC. Not much use to you I know - but useful for others).

Your point 5) - the idea here is that if you are not reducing the native sampling rate (ie lower than 10ns) it is much better to give the user the ability to reprocess the waveform with whatever process (in Maths) he wants, because information has not been lost. If you do the process in the Cleverscope acquisition unit, information may have been lost (ie he thought there were no high frequencies, but really there were). In any case we will think on what you have said.

6) a good point. But again, the user can already do this now, by using a 1 Mhz filter in Maths, and pushing the entire frame through it. He then gets the real maximum dynamic range (because we use real numbers in the PC). Off course with this method, he can only capture 40 ms, and still maximize the dynamic range.

7). It can only be single shot mode, for one frame. In triggered mode, as soon as there is a trigger, the next frame capture will start, destroying the buffer, and the contents of the last capture.

Ok, we will let you know when we have done the single frame capture change.

regards, Bart

Hello Denis, Thanks for your update. I think you are right! I agree that it is possible for you to transfer then samples at either 10us/sample or 1us/sample, with a moving average decimation. Our demo software - it uses a real time software simulator to generate sine, triangle and square waves. It has very little of the functionality of the real acquisition unit. It is not (we think) worth our while to spend time improving the simulator, when we could instead spend that time (we are resource constrained) on the real acquisition unit, or the cleverscope application. So the simulator doesn't do those things. We say that on the download page. So 2-4 don't work. Instead we provide examples of real signals on our examples page, that have been captured with an acquisition unit, so you can play around with them. The method to select how the waveform is processed before it is transferred is the 'Display Method' on the top centre of the Control Panel. You will see Sampled, Peak Captured, Filtered, Repetitive, Waveform Avg. You want Filtered. (The Waveform Avg takes either 4,16, 64 or 128 consecutive waveforms and averages them time synchronous to the trigger, inside the acquisition unit. It automatically uses the right number of frames, and is much faster than doing it in the PC. Not much use to you I know - but useful for others). Your point 5) - the idea here is that if you are not reducing the native sampling rate (ie lower than 10ns) it is much better to give the user the ability to reprocess the waveform with whatever process (in Maths) he wants, because information has not been lost. If you do the process in the Cleverscope acquisition unit, information may have been lost (ie he thought there were no high frequencies, but really there were). In any case we will think on what you have said. 6) a good point. But again, the user can already do this now, by using a 1 Mhz filter in Maths, and pushing the entire frame through it. He then gets the real maximum dynamic range (because we use real numbers in the PC). Off course with this method, he can only capture 40 ms, and still maximize the dynamic range. 7). It can only be single shot mode, for one frame. In triggered mode, as soon as there is a trigger, the next frame capture will start, destroying the buffer, and the contents of the last capture. Ok, we will let you know when we have done the single frame capture change. regards, Bart

Thanks Bart,

As a conclusion, here is what I am going to do.

1) I 'll play with the examples of signals provided on the website.

2) I'll contact your french representative (my lab is at about 10 km from him) to test the cleversope during an afternoon.

3) If the tests are good, I'd like to order one unit with the 8MS in one shot update, as soon as possible.

4) My lab is specialized in fundamental electronics and I have several colleagues looking for 14 bit and 16 bits scopes (up to now we were all using the old and expensive Nicollet Pro 34 model). I'll let them know about the cleverscope.


Keep me informed for the 8MS/shot update.

Denis

Thanks Bart, As a conclusion, here is what I am going to do. 1) I 'll play with the examples of signals provided on the website. 2) I'll contact your french representative (my lab is at about 10 km from him) to test the cleversope during an afternoon. 3) If the tests are good, I'd like to order one unit with the 8MS in one shot update, as soon as possible. 4) My lab is specialized in fundamental electronics and I have several colleagues looking for 14 bit and 16 bits scopes (up to now we were all using the old and expensive Nicollet Pro 34 model). I'll let them know about the cleverscope. Keep me informed for the 8MS/shot update. Denis

Hello Denis,
Thanks for that. We now have an example of filtering a signal on the website, in the examples folder. You can find the folder here - http://www.cleverscope.com/examples/ . It may be of help!

Hello Denis, Thanks for that. We now have an example of filtering a signal on the website, in the examples folder. You can find the folder here - http://www.cleverscope.com/examples/ . It may be of help!