DIY PC Oscilloscope

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=.)
--------------------------------------------------------------