Forums

DIY PC Oscilloscope

Started by Unknown March 9, 2013
On Sat, 09 Mar 2013 18:38:51 GMT, Jan Panteltje
<pNaonStpealmtje@yahoo.com> wrote:

>On a sunny day (Sat, 9 Mar 2013 10:22:38 -0800 (PST)) it happened >francescopoderico@googlemail.com wrote in ><c1ad2481-696a-4257-8242-a8c92169124b@googlegroups.com>: > >>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. > >Add TV: > http://panteltje.com/panteltje/scope_tv/index.html > > >>Thanks, >>Francesco
Kind of interesting. Just the same an FFT module for translation to spectrums might be a great add on. Or perhaps a DVB-T tuner us module = add on to get really serious. Then you could add on all sorts of = demodulation systems. ?-)
On 3/11/2013 3:49 AM, Francesco Poderico wrote:
> On Monday, 11 March 2013 00:48:33 UTC, Tim Williams wrote: >> "Nico Coesel"<nico@puntnl.niks> wrote in message >> >> news:513d21d9.4118857421@news.kpn.nl... >> >>> If you distribute the trigger and use a global reference clock to >> >>> which all the ADCs are synchronised it will work. At least that is how >> >>> I planned it for my own USB scope design about 9 years ago. But then >> >>> Rigol emerged so I stopped the project. >> >> >> >> You still have the propagation delay of the clock (and trigger if shared) >> >> cascading between modules. You could characterize each unit's delay and >> >> adjust in the DLL, perhaps, or perform a round-trip self-calibration, or >> >> ask the user to run a BNC cable from the "probe test" connector on the >> >> master unit down to each successive input; assuming the cable remains >> >> constant during the test, this would allow the inputs to be adjusted for >> >> zero time difference. >> >> >> >> Tim >> >> >> >> -- >> >> Deep Friar: a very philosophical monk. >> >> Website: http://seventransistorlabs.com > > Thanks to everybody for the suggestions, > I will think about... as it could be a good selling point... > I'm a bit concerned regarding the clock syncronization between different FPGA, at 200 MHz it's not easy and you can have easily have 1 or 2 clock skews between modules... > I need to think about
There are a lot of things to consider when designing a scope like this. I wouldn't bother too much up front with trying to include all the fancy features. If you want a four or eight channel scope, it can be done as a separate design using modules from the original better than trying to make the entire design into a cascading unit of some sort. Although connecting modules as cascaded units wouldn't really be all that hard. If the modules are made to snap together with a mating connector, like the TI-99 computer used to do, then the paths would be short and you could actually distribute the clock so that all delays were equal. I think the cascading is practical, but I just don't think it adds a lot to the value of the device. If you design a good, two channel low cost scope, I am sure it will do well. But I don't think 25 MHz is good enough to set yourself apart. As others have said, there are a number of 20/25 MHz units available in the low $100's. If it isn't 300 MHz or so analog bandwidth, why bother? Those units tend to be rather pricey like >$1000. That gives you some room to really beat their price. I was looking at doing a low end scope on what would be close to a single chip. There is a multiprocessor chip that should be able to do everything but talk over USB for a 10 MHz scope. It even includes ADCs which have a variable resolution so that they could be used for faster low res signals as high as 50 MSPS or slower high res, down to 15/16 bits at CD rates. So there can be better ways to do a low end scope than the traditional scope design. A major feature I would like to see is a 16 channel logic input along with the two analog channels. Also keep in mind that it needs to run off the USB power which is limited to 2.5 Watts. If the scope requires a separate wire for power, it becomes much less attractive. Someone mentioned that they didn't think 3K was deep enough channel memory and I'll second that. One SDRAM chip can provide MBs of memory at very high speeds and not use a lot of power. If you are really serious about this, I might be interested in helping with the digital design and the FPGA code. That's my focus area. My last comment on this is about the software. Others have mentioned that the software is where all the features are added. That is true, so don't short change the difficultly of getting the software done and done right. I could see this being integrated with one of the many single board computers for a portable device as an option in place of being tethered to a PC. I read that there is a new BeagleBone coming out which includes video, although I suppose there is nothing much wrong with the raspPi really. 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? -- Rick
On Tuesday, 12 March 2013 00:11:14 UTC, Tim Williams  wrote:
> "JW" <none@dev.null> wrote in message > > news:jhirj8h7ach6hj7nlc2fllel66n94ptf2t@4ax.com... > > > One thing positive I will say about them, I've never seen a 93XX or LC > > > series scope alias, where as Tek and Agilent scopes of similar vintage > > > are > > > very easy to get to alias. > > > > Not necessarily an advantage -- in the old days, of course, the analog > > trace simply looked fuzzy due to any modulation that was too fast to > > resolve, or not harmonically related to the trigger source. On digital > > scopes, it's best to have the option. Many times I've looked at a signal > > and thought, "where did it go?" Zooming in, it shows up. Tek's "high > > res" mode, I think, does a crude oversampling IIR effect, which looks very > > nice around traces with much noise or ripple (clearing away noise I would > > have trouble cutting through otherwise), but also misses that information. > > > > Speaking of noise, it aliases too, correct? As long as the bands are > > uncorrelated (to each other; correlation to the sample rate I don't think > > matters, as long as it's still "noisy"), it should go as V = Vo*sqrt(B / > > (2*Fs)), given a noise source of full-bandwidth amplitude Vo, bandwidth B, > > and sample rate Fs. But then, random sampling has to have the same > > statistics as the source signal. I seem to be forgetting something. > > > > Tim > > > > -- > > Deep Friar: a very philosophical monk. > > Website: http://seventransistorlabs.com
Hi all, thanks a lot for all the suggestions... I have a problem... I believe some of you guys may have some idea of what is going on here... I'm using the sin(x)/x interpolation algorithm... which works OK, but I do have a problem... if you go to my blog : http://thefpproject01.blogspot.co.uk/ you can see that the interpolation algorithm I'm using gives a waveform wobbly... but... by using a linear interpolation algorithmic then it's OK! what is going on her? what I'm doing wrong?
rickman <gnuarm@gmail.com> wrote:

>On 3/11/2013 3:49 AM, Francesco Poderico wrote: >> On Monday, 11 March 2013 00:48:33 UTC, Tim Williams wrote: >>> "Nico Coesel"<nico@puntnl.niks> wrote in message >>> >>> news:513d21d9.4118857421@news.kpn.nl... >>> >>>> If you distribute the trigger and use a global reference clock to >>> >>>> which all the ADCs are synchronised it will work. At least that is how >>> >>>> I planned it for my own USB scope design about 9 years ago. But then >>> >>>> Rigol emerged so I stopped the project. >>> >>> >>> >>> You still have the propagation delay of the clock (and trigger if shared) >>> >>> cascading between modules. You could characterize each unit's delay and >>> >>> adjust in the DLL, perhaps, or perform a round-trip self-calibration, or >>> >>> ask the user to run a BNC cable from the "probe test" connector on the >>> >>> master unit down to each successive input; assuming the cable remains >>> >>> constant during the test, this would allow the inputs to be adjusted for >>> >>> zero time difference. >>> >>> >>> >>> Tim >>> >>> >>> >>> -- >>> >>> Deep Friar: a very philosophical monk. >>> >>> Website: http://seventransistorlabs.com >> >> Thanks to everybody for the suggestions, >> I will think about... as it could be a good selling point... >> I'm a bit concerned regarding the clock syncronization between different FPGA, at 200 MHz it's not easy and you can have easily have 1 or 2 clock skews between modules... >> I need to think about > >There are a lot of things to consider when designing a scope like this. > I wouldn't bother too much up front with trying to include all the >fancy features. If you want a four or eight channel scope, it can be >done as a separate design using modules from the original better than >trying to make the entire design into a cascading unit of some sort. >Although connecting modules as cascaded units wouldn't really be all >that hard. If the modules are made to snap together with a mating >connector, like the TI-99 computer used to do, then the paths would be >short and you could actually distribute the clock so that all delays >were equal. > >I think the cascading is practical, but I just don't think it adds a lot >to the value of the device. > >If you design a good, two channel low cost scope, I am sure it will do >well. But I don't think 25 MHz is good enough to set yourself apart. >As others have said, there are a number of 20/25 MHz units available in >the low $100's. If it isn't 300 MHz or so analog bandwidth, why bother? > Those units tend to be rather pricey like >$1000. That gives you some >room to really beat their price. > > >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. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
"Francesco Poderico" <francescopoderico@googlemail.com> wrote in message 
news:1be3122c-aa57-481c-a95e-34792d03adf5@googlegroups.com...
> Hi all, thanks a lot for all the suggestions... > I have a problem... I believe some of you guys may have some idea of > what is going on here... > I'm using the sin(x)/x interpolation algorithm... which works OK, but I > do have a problem... > if you go to my blog : http://thefpproject01.blogspot.co.uk/ > you can see that the interpolation algorithm I'm using gives a waveform > wobbly... but... by using a linear interpolation algorithmic then it's > OK! > what is going on her? what I'm doing wrong?
Without looking at your code, or playing with it, I'd have to guess you got the T or Fs incorrect. The formula posted is just a convolution, of course (as well it should be, since it's filtering a time-domain signal, and sinc(t) is the complement of a rect(f) "brick wall" filter). Which is tedious for math (doing it literally consumes lots of sines and divides), but not intractible (the samples are windowed by the buffer length, so the infinite sum over n reduces to buffer length only). A better way of writing the argument is, sinc(t/T - n) since this showcases the dimensionless ratio, which ultimately is all we really care about, since digital up-sampling just uses different ratios in T. This is actually: sinc(x*(Ts / Td) - n) for screen coordinate x, sample n, and sample rate Ts and displayed sample rate Td, which is actually Td = (selected time/div) / (graphical pixels/div). A more practical implementation might also window the sinc function, with a rect function for starters, but perhaps using another function as well, like a good old Hamming window, to keep it smooth. The actual number of samples convolved need not be too much; a few times the Told/Tnew ratio should be sufficient. Then you might as well precalculate it and shove it in a table, since it doesn't need to change. (Okay, it might change if you want to make the graphical display resizable.) Tim -- Deep Friar: a very philosophical monk. Website: http://seventransistorlabs.com
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 waveform is captured, I would like to be able to zoom in a bit to view detail, I think that requires 10 bits. This only leaves 2 bits of flexible range which is just a factor of 4x. Even if you are happy with a vertical range using 8 bits, that only leaves a factor of 16x. Most scope front ends I have seen work over a range of multiple decades, 16 mV to 80 V FS on my scope. That would require over 12 bits just to match that range, not counting the bits you want for the display. I suppose a 16 bit converter could be used leaving less than 4 bits on the most sensitive ranges. I know they are faster now days, any idea how fast a 16 bit converter is? The reason adjusting the reference voltage on the ADC is a bad idea is that the noise floor goes up as your reference voltage goes down. That just reduces the ENOB. -- Rick
On Sun, 10 Mar 2013 14:43:39 -0700 (PDT), Francesco Poderico
<francescopoderico@googlemail.com> wrote:

>On Sunday, 10 March 2013 21:25:43 UTC, Roberto Waltman wrote: >> Jeff Liebermann wrote: >> >6. Presumably, it's dual channel. If so, make it stackable via a >> >common bus or preferably via ethernet, so that multiple units can be >> >conglomerated into a 4,6,8, etc channel scope.
>> From my (rather narrow) point of view, where the main use of an >> oscilloscope is in debugging embedded software, this would make it >> stand out above the competition. >> Roberto Waltman
>Thanks Roberto, >I'm not sure what do you mean with a stackable oscilloscope, >do you mean... e.g. 4 oscilloscopes... 2 channel each that >makes a 8 channel oscilloscope? >The only problem I see with that is that between each scope >you can have 20 ns max. of time offset.
I think your question was addressed to me, not Roberto. My idea was to make the device modular. Thinking about it some more, I believe that the world does not need yet another USB scope. Surveying the available instruments, I find complete units, with integrated LCD display, and USB scopes, with very little in between. In order to supply the necessary product differentiation necessary for you to compete on something other than price and support, you need to do something different. What I suggest is a modular scope, where the display is NOT built in, and is externally driven via a common VGA or HDMI output. For example, if I wanted to use it for a classroom demonstration, technical lecture, and product demonstration, I could easily connect the scope to anything from a simple VGA monitor, to a projection display. Personally, I would just love to have a projection oscilloscope. Extra credit for installing a camera and making the on screen controls adjust following a red or green laser pointer. Instead of relying on a user supplied SBC (single board computah) to do the processing, you supply a mini-ITX or stackable industrial PC running your favorite OS and your software. The customer supplies the display device. If you use stackable SBC, such as PC/104, EPIC, or something more modern, you have the advantage of direct access to the various PCB busses, which do NOT need to go through the USB bottleneck. To add features, you just add an additional PCB to the stack. There are PC/104 boards that can act as an oscilloscope, but they tend to be rather pricey. For example: <http://www.acquitek.com/ad2100-12/digitizer-pc104-module.html> To the best of my limited knowledge based on Google searches, I can't find anyone that makes a similar instrument (which doesn't mean that it doesn't exist, just that I can't find one). My suggestion of adding additional input channels, allowing this device to act as both a multi-channel analog and a digital logic analyzer fits in nicely with the modular concept. Need more inputs? Just add more boards to the sandwich. How the all the parts are glued together is beyond my level of expertise. Offhand, I would guess(tm) that the 20nsec latency can be drastically reduced by polling each FPGA for data in sequence. This will slow down the response time, but will better keep the various boards in sync. There are probably better ways to do it. Of course, supplying an SBC with the device raises the selling price. That may not be such a bad thing, as it brings your device out of the low priced hobby market, and into the higher price ranges of those that buy instruments, not kits or toys. You may sell 1/10th as many devices, but your profit per sale will easily be 10 times higher. Good luck. -- Jeff Liebermann jeffl@cruzio.com 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 http://802.11junk.com Skype: JeffLiebermann AE6KS 831-336-2558
"rickman" <gnuarm@gmail.com> wrote in message 
news:khqr7p$q4k$1@dont-email.me...
> I know they are faster now days, any idea how fast a 16 bit converter > is?
How fast can you afford? ;-) IIRC, 14 or 16 bit goes for ca. $1/MSPS. Beware the INL usually stops at 12 bits, typical of pipelined types (which the fast high-bit ones all are). DNL is all that matters for SDR, so they aren't useless; INL could be calibrated, as long as you can generate a 16 bit-linear ramp (now Larkin will chime in..). Tim -- Deep Friar: a very philosophical monk. Website: http://seventransistorlabs.com
On Mar 14, 12:07=A0am, "Tim Williams" <tmoran...@charter.net> wrote:
> "rickman" <gnu...@gmail.com> wrote in message > > news:khqr7p$q4k$1@dont-email.me... > > > I know they are faster now days, any idea how fast a 16 bit converter > > is? > > How fast can you afford? =A0;-) > > IIRC, 14 or 16 bit goes for ca. $1/MSPS. =A0Beware the INL usually stops =
at
> 12 bits, typical of pipelined types (which the fast high-bit ones all > are). =A0DNL is all that matters for SDR, so they aren't useless; INL cou=
ld
> be calibrated, as long as you can generate a 16 bit-linear ramp (now > Larkin will chime in..). > > Tim >
analog has a 16bit 250Ms, it is "only" ~150$ -Lasse
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. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------