Forums

DIY PC Oscilloscope

Started by Unknown March 9, 2013
On Sat, 9 Mar 2013 10:22:38 -0800 (PST), francescopoderico@googlemail.com wrote:

>Hi all, >I've started designing a 200 MSPS Oscilloscope with a 25 MHz analog bandwidth, 3Ksample/channel buffer. >The oscilloscope can be connected to a PC via USB, and eventually via Ethernet and WiFi. >The trigger is ( at moment) rising, falling... auto, normal. > >I would appreciate suggestions and or comment for possible improvement and functionality that could make this oscilloscope interesting. > >Thanks, >Francesco
OK, here's a patentable idea that I donate to humanity: The scope trigger fires a delay and then makes some analog pattern, like a sine burst or chirp or some pseudo-random mess made from delay lines or something. Something with a nice sharp autocorrelation function. Mix that into the scope vertical signal. The PC software looks at that, figures out its timing, and removes the +-1 clock jitter from the displayed data. The burst can be delayed and thereby separated in time from the displayable waveform, or it can be superimposed, no delay, and subtracted out. Of course, the idea works even better if you have another ADC channel to spare. -- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
On Thu, 14 Mar 2013 09:29:48 -0700, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

> > >OK, here's a patentable idea that I donate to humanity: > >The scope trigger fires a delay and then makes some analog pattern, like a sine >burst or chirp or some pseudo-random mess made from delay lines or something. >Something with a nice sharp autocorrelation function. > >Mix that into the scope vertical signal. The PC software looks at that, figures >out its timing, and removes the +-1 clock jitter from the displayed data. > >The burst can be delayed and thereby separated in time from the displayable >waveform, or it can be superimposed, no delay, and subtracted out. > >Of course, the idea works even better if you have another ADC channel to spare.
We're doing something like that to synchronize phase on several free-running ADCs in a distributed data acquisition system on a non-deterministic network. Works, but I'd rather have it done by hardware.
On 3/14/2013 12:03 PM, Nico Coesel wrote:
> rickman<gnuarm@gmail.com> wrote: > >> On 3/12/2013 4:11 PM, Nico Coesel wrote: >>> rickman<gnuarm@gmail.com> wrote: >>>> >>>> I would like to hear from others about why the front end is the hard >>>> part. Exactly how do the attenuators work? Does the amp remain set to >>>> a given gain and the large signals are attenuated down to a fixed low >>>> range? >>> >>> You need to use capacitive dividers which need adjustment. In my >>> design I used one varicap (controlled by a DAC) to do all the >>> necessary adjustments for several ranges. Nowadays you could use a 12 >>> bit ADC so you wouldn't need a variable gain amplifier. Another trick >>> to get a programmable range is to vary the reference voltage of the >>> ADC. I think I re-did the design of the front-end about 3 or 4 times. >> >> I don't get how a 12 bit ADC solves the attenuator problem. That is >> only 2 bits more than what I would like to see in a front end. Once a > > Its a factor 16 attenuation you don't need to do in hardware. So if > the hardware attenuator does 1:1.5, 1:10 and 1:100 (which is doable > with 2 relays) you save quite some circuitry. 8 bits is probably more > then enough. It will be hard to get the response so flat that more > than 8 bits actually adds accuracy of the readout.
I've worked with 8 bit scopes and the vertical clearly shows steps which I find interfere with making reasonable measurements. That's why I said 2 spare bits out of 12. There is also a need for zooming in on a portion of a captured trace. At 8 bits all you see is the steps. With a full 12 bits you have a little bit of extra resolution so you can actually get a bit of detail. -- Rick
rickman <gnuarm@gmail.com> writes:

> On 3/14/2013 12:03 PM, Nico Coesel wrote: >> rickman<gnuarm@gmail.com> wrote: >> >>> On 3/12/2013 4:11 PM, Nico Coesel wrote: >>>> rickman<gnuarm@gmail.com> wrote: >>>>> >>>>> I would like to hear from others about why the front end is the hard >>>>> part. Exactly how do the attenuators work? Does the amp remain set to >>>>> a given gain and the large signals are attenuated down to a fixed low >>>>> range? >>>> >>>> You need to use capacitive dividers which need adjustment. In my >>>> design I used one varicap (controlled by a DAC) to do all the >>>> necessary adjustments for several ranges. Nowadays you could use a 12 >>>> bit ADC so you wouldn't need a variable gain amplifier. Another trick >>>> to get a programmable range is to vary the reference voltage of the >>>> ADC. I think I re-did the design of the front-end about 3 or 4 times. >>> >>> I don't get how a 12 bit ADC solves the attenuator problem. That is >>> only 2 bits more than what I would like to see in a front end. Once a >> >> Its a factor 16 attenuation you don't need to do in hardware. So if >> the hardware attenuator does 1:1.5, 1:10 and 1:100 (which is doable >> with 2 relays) you save quite some circuitry. 8 bits is probably more >> then enough. It will be hard to get the response so flat that more >> than 8 bits actually adds accuracy of the readout. > > I've worked with 8 bit scopes and the vertical clearly shows steps > which I find interfere with making reasonable measurements. That's > why I said 2 spare bits out of 12. There is also a need for zooming > in on a portion of a captured trace. At 8 bits all you see is the > steps. With a full 12 bits you have a little bit of extra resolution > so you can actually get a bit of detail.
I agree a 12 bit (or 16 bit!) scope would be nice. Lecroy make one I think but it is very expensive. The situation with the standard 8 bits is not quite as bad as you portray in a higher end scope. They can sample at the full maximum digitizer rate (5 or 20 GSPS say) then do real-time averaging/DSP on it so that each point plotted at lower sweep rates represents the average of hundreds of samples potentially. The noise at 20GSPS smears out the steps then the averaging smooths out the noise. Or something like that. Anyway the result is much better than you would think from the 8 bit input. -- John Devereux
rickman <gnuarm@gmail.com> wrote:

>On 3/14/2013 12:03 PM, Nico Coesel wrote: >> rickman<gnuarm@gmail.com> wrote: >> >>> On 3/12/2013 4:11 PM, Nico Coesel wrote: >>>> rickman<gnuarm@gmail.com> wrote: >>>>> >>>>> I would like to hear from others about why the front end is the hard >>>>> part. Exactly how do the attenuators work? Does the amp remain set to >>>>> a given gain and the large signals are attenuated down to a fixed low >>>>> range? >>>> >>>> You need to use capacitive dividers which need adjustment. In my >>>> design I used one varicap (controlled by a DAC) to do all the >>>> necessary adjustments for several ranges. Nowadays you could use a 12 >>>> bit ADC so you wouldn't need a variable gain amplifier. Another trick >>>> to get a programmable range is to vary the reference voltage of the >>>> ADC. I think I re-did the design of the front-end about 3 or 4 times. >>> >>> I don't get how a 12 bit ADC solves the attenuator problem. That is >>> only 2 bits more than what I would like to see in a front end. Once a >> >> Its a factor 16 attenuation you don't need to do in hardware. So if >> the hardware attenuator does 1:1.5, 1:10 and 1:100 (which is doable >> with 2 relays) you save quite some circuitry. 8 bits is probably more >> then enough. It will be hard to get the response so flat that more >> than 8 bits actually adds accuracy of the readout. > >I've worked with 8 bit scopes and the vertical clearly shows steps which >I find interfere with making reasonable measurements. That's why I said
That has more to do with how the software shows the signal. Interpolation can solve a lot. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
"John Devereux" <john@devereux.me.uk> wrote in message 
news:87620tvz6t.fsf@devereux.me.uk...
> The situation with the standard 8 bits is not quite as bad as you > portray in a higher end scope. They can sample at the full maximum > digitizer rate (5 or 20 GSPS say) then do real-time averaging/DSP on it > so that each point plotted at lower sweep rates represents the average > of hundreds of samples potentially. The noise at 20GSPS smears out the > steps then the averaging smooths out the noise. Or something like that. > Anyway the result is much better than you would think from the 8 bit > input.
It also reduces aliasing. Mine has a "high res" mode which does this -- only works below a certain range, of course. Tim -- Deep Friar: a very philosophical monk. Website: http://seventransistorlabs.com
On 3/15/2013 4:34 AM, John Devereux wrote:
> rickman<gnuarm@gmail.com> writes: > >> I've worked with 8 bit scopes and the vertical clearly shows steps >> which I find interfere with making reasonable measurements. That's >> why I said 2 spare bits out of 12. There is also a need for zooming >> in on a portion of a captured trace. At 8 bits all you see is the >> steps. With a full 12 bits you have a little bit of extra resolution >> so you can actually get a bit of detail. > > I agree a 12 bit (or 16 bit!) scope would be nice. Lecroy make one I > think but it is very expensive. > > The situation with the standard 8 bits is not quite as bad as you > portray in a higher end scope. They can sample at the full maximum > digitizer rate (5 or 20 GSPS say) then do real-time averaging/DSP on it > so that each point plotted at lower sweep rates represents the average > of hundreds of samples potentially. The noise at 20GSPS smears out the > steps then the averaging smooths out the noise. Or something like that. > Anyway the result is much better than you would think from the 8 bit > input.
You say that the 16 bit converters are expensive, then talk about using a 20 GHz 8 bit ADC. Is that not expensive, not to mention the clocking, the board for the high speed signals and the power supply to make all this happen? I can't imagine this is actually a better approach to designing a scope with a stated goal of 20-25 MHz bandwidth. I would like to see at least 300 MHz, but the OP says 25 is good enough. -- Rick
On 3/15/2013 6:06 AM, Nico Coesel wrote:
> rickman<gnuarm@gmail.com> wrote: > >> On 3/14/2013 12:03 PM, Nico Coesel wrote: >>> >>> Its a factor 16 attenuation you don't need to do in hardware. So if >>> the hardware attenuator does 1:1.5, 1:10 and 1:100 (which is doable >>> with 2 relays) you save quite some circuitry. 8 bits is probably more >>> then enough. It will be hard to get the response so flat that more >>> than 8 bits actually adds accuracy of the readout. >> >> I've worked with 8 bit scopes and the vertical clearly shows steps which >> I find interfere with making reasonable measurements. That's why I said > > That has more to do with how the software shows the signal. > Interpolation can solve a lot.
That may be. The OP was talking about debugging the sinc reconstruction and I've been thinking a little bit about just how useful that is. Is there a downside to sinc reconstruction, other than the work required? I was thinking an aliased signal might interfere with this, but now that I give it some thought, I realize they are two separate issues. If you have an aliased tone, it will just be a tone in the display whether you use sinc reconstruction or not. In fact, the *very* low end scope I was using may have had a limitation in the display itself! 8 bits is 256 steps. That shouldn't be too big a problem. -- Rick
rickman <gnuarm@gmail.com> writes:

> On 3/15/2013 4:34 AM, John Devereux wrote: >> rickman<gnuarm@gmail.com> writes: >> >>> I've worked with 8 bit scopes and the vertical clearly shows steps >>> which I find interfere with making reasonable measurements. That's >>> why I said 2 spare bits out of 12. There is also a need for zooming >>> in on a portion of a captured trace. At 8 bits all you see is the >>> steps. With a full 12 bits you have a little bit of extra resolution >>> so you can actually get a bit of detail. >> >> I agree a 12 bit (or 16 bit!) scope would be nice. Lecroy make one I >> think but it is very expensive. >> >> The situation with the standard 8 bits is not quite as bad as you >> portray in a higher end scope. They can sample at the full maximum >> digitizer rate (5 or 20 GSPS say) then do real-time averaging/DSP on it >> so that each point plotted at lower sweep rates represents the average >> of hundreds of samples potentially. The noise at 20GSPS smears out the >> steps then the averaging smooths out the noise. Or something like that. >> Anyway the result is much better than you would think from the 8 bit >> input. > > You say that the 16 bit converters are expensive, then talk about > using a 20 GHz 8 bit ADC. Is that not expensive, not to mention the > clocking, the board for the high speed signals and the power supply to > make all this happen?
Yes, it is very expensive. I did say "high end scope", by which I mean "really expensive". They usually need to go to GHz anyway, so already have the high speed digitizer. At lower bandwidths they can utilise the excess samples to increase the apparent resolution.
> I can't imagine this is actually a better approach to designing a > scope with a stated goal of 20-25 MHz bandwidth. I would like to see > at least 300 MHz, but the OP says 25 is good enough.
Absolutely, to me the only point of a 25MHz scope would be if it was higher resolution, 16+ bit ideally. Otherwise you may as well just use one of those cheap USB gadgets. A "dynamic signal analyser" that goes above 100kHz seems to be missing from the market AFAIK. So it could do good spectrum analysis, evaluate noise, servo loops, have a tracking generator and plot filter responses, that sort of thing. -- John Devereux
rickman <gnuarm@gmail.com> wrote:

>On 3/15/2013 6:06 AM, Nico Coesel wrote: >> rickman<gnuarm@gmail.com> wrote: >> >>> On 3/14/2013 12:03 PM, Nico Coesel wrote: >>>> >>>> Its a factor 16 attenuation you don't need to do in hardware. So if >>>> the hardware attenuator does 1:1.5, 1:10 and 1:100 (which is doable >>>> with 2 relays) you save quite some circuitry. 8 bits is probably more >>>> then enough. It will be hard to get the response so flat that more >>>> than 8 bits actually adds accuracy of the readout. >>> >>> I've worked with 8 bit scopes and the vertical clearly shows steps which >>> I find interfere with making reasonable measurements. That's why I said >> >> That has more to do with how the software shows the signal. >> Interpolation can solve a lot. > >That may be. The OP was talking about debugging the sinc reconstruction >and I've been thinking a little bit about just how useful that is. Is >there a downside to sinc reconstruction, other than the work required?
It is useable if you have at least 5 samples per period. So that is 0.2fs. The whole problem though is not the number of samples per period. According to sampling theory the signal is there but it just needs to be displayed properly so the operator can see a signal instead of some 'random' dots. With the proper signal reconstruction algorithm you can display signals up the the Nyquist limit (0.5fs).
>I was thinking an aliased signal might interfere with this, but now that >I give it some thought, I realize they are two separate issues. If you >have an aliased tone, it will just be a tone in the display whether you >use sinc reconstruction or not.
In my design I used a fixed samplerate (250MHz) and a standard PC memory module. 1GB already provides for more than 2 seconds of storage for 2 channels. That solves the whole interference issue and it allows to use a proper anti-aliasing filter. With polynomal approximation I could reconstruct a signal even when its close to the Nyquist limit. I tested it and I could get it to work for frequencies up to 0.45fs. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------