Re: PCI interface


"Nico Coesel" <nico@xxxxxxxxxxx> wrote in message
news:461e76fb.161803411@xxxxxxxxxxxxxxxxx
"Jon Slaughter" <Jon_Slaughter@xxxxxxxxxxx> wrote:


"Nico Coesel" <nico@xxxxxxxxxxx> wrote in message
news:461d4556.83558040@xxxxxxxxxxxxxxxxx
"Jon Slaughter" <Jon_Slaughter@xxxxxxxxxxx> wrote:


<jrwalliker@xxxxxxxxx> wrote in message
news:1176291190.028355.58260@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Memory is cheap, so why not buffer a capture sweep to some ram which
is local to the adc and then use whatever method is easiest to get the
data into the PC?


Thats was one idea I had but I wonder why most pc scopes do not do this?
Most just have a few KB and at most a few MB. I imagine that it is
probably
more difficult to design a high speed memory controller. I just figure
that
since the pc already has all this stuff one should take advantage of it.

It just seems like its probably much more complicated? (and its
complicated
enough I suppose.)

A PC can't handle the bandwidth for a prolonged period. Besides,
you'll need some processing to display the signal. Processing -say- 1
GB of data takes a while even if you have a fast processor.



I'm not going to display the data in real time. Atleast that doesn't have
to
be an option. In any cause the display of the signal is at a far smaller
resolution than the signal itself so you can ignore a lot of the data. The

If you ignore data, you'll be cutting important information. You'll
need to present the user something which contains all information.
This is the well known peak-detect mode available on every usefull
DSO. Still, you could sample first, show later. Showing data while
sampling will be a lot harder.


your only ignoring information for viewing purposes. The user has control of
how much of the information they want to see.

Showing the data in real time is not harder as you can just show every
1000th sample. If your sampling at 1GS/s then this means you have reduced
the sampling rate to 1M. This is not difficult to display. If it is then
only show ever 10000th sample. Ofcourse now your ignoring a huge amount of
data... but guess what? Its in memory! So if the user wants to go back and
look more closely at a specific part of the signal then they can and you
will pull in more samples... not so much that your wasting processing
displaying two or more samples per pixel. Just can't happen.

The point is, that all the real data is in memory and you display only what
actually can be understood. You cannot display more than about 1000 samples
on a standard monitor at any given time. This is independent of the time
those samples represent. You cannot display more than one sample per pixel
because you only have one pixel. You can but your just wasting time drawing
something that won't be seen. The same idea happens in 3D graphics
optimization. You do not display objects that cannot be seen by the viewport
because its a waste of processing. Without that simple idea you could not
have real time 3D graphics that you have today.


But you kinda have it right. You do sample first and show later(obviously
there is a latency) but you also sample and show simulataneously. But you
do not show anything that is wasteful. You show enough to give the user an
idea of the waveform and not any more.

Actually it would be more effective to do some sort of averaging on all the
samples than just ignoring blocks and this will get a true representative of
the waveform removing the higher frequencies and making it more appropriate
for viewing.

If you need an sample, Take a square wave at 100hz with some sinusoidal
noise of 1mhz

Suppose your sampling this at 1Ghz. Now do you really think you have to
display all the samples on the monitor? Do you even think that you could?
If you did and your viewing this signal in memory and not in real time then
your monitor would have to be 1 billion pixels wide to actually show every
sample. Even if that were the case it would probably need to be several
hundred(a guess) feet wide just so your eyes could differentiate the pixels.
(if you scaled the pixels so the monitor could fit on a desk then they would
be to small to see).


Now take the square wave in the example. Suppose you set the time base so
that you see 3 periods. Do you think you'll be able to detect that noise?
Ofcourse it depends on the amplitude but we'll assume its small. Sure you
might see some of the effects but you'll get a very good idea of the wave
form(double you'll see anything but a perfect square wave though in this
case). Now suppose you want to see if there whats really going on. Just
"zoom in". Zoom in on a corner of the square wave. You'll can now bring in
more samples and you'll be looking at more bandwidth of the waveform.

In any case even if you displayed this in real time and you were sampling at
1GS/s your monitor doesn't have hight enough refersh rate to display
anything above about 10^5hz. (assuming standard monitor and refresh rate of
100hz). Even if it could display at 1Mhz your eyes only work at about 35hz
or so it won't make a difference.


Ofcours say your doing RF and you have a carrier frequency of 100mhz. You
could display the total wave form or just demodulate and then display that.
In this case I suppose you'll want to demodulate before you digitize it but
you could sample first and then demodulate afterwards in software. Ofcourse
it will take time to demodulate in the sofware and your limiting the carrier
frequency by the sampling rate.

In any cause the main use of what I want to do is not a real time display of
a signal but a history of it. Ofcourse one wants real time feed back and
this can easily be accomplished. You don't have to show the full signal in
real time to actually see whats going on.

Jon



.

Relevant Pages

  • Re: PCI interface
    ... In any cause the display of the signal is at a far smaller ... No, thats not real time rendering. ... Ofcourse it depends on the amplitude but we'll assume its small. ... Zoom in on a corner of the square wave. ...
    (sci.electronics.design)
  • Re: PCI interface
    ... I'm not going to display the data in real time. ... No, thats not real time rendering. ... Ofcourse it depends on the amplitude but we'll assume its small. ...
    (sci.electronics.design)
  • Re: 8ms Timer for serial port access
    ... ->-Whether the data is collected in real time, or not, just isn't ... ->update of the display. ... However by not collecting and analyzing data as it comes ... ->data slip as it beats against the 14ms video update. ...
    (comp.os.linux.development.apps)
  • Re: 8ms Timer for serial port access
    ... Unless you put it on a real time scheduling queue. ... update of the display. ... data slip as it beats against the 14ms video update. ... 24 byte packet is ready from the serial port at time X. ...
    (comp.os.linux.development.apps)
  • Problem with X
    ... VendorName "Monitor Vendor" ... SubSection "Display" ... Viewport 0 0 ...
    (Debian-User)