Re: PCI interface

On Apr 12, 2:26 pm, "Jon Slaughter" <Jon_Slaugh...@xxxxxxxxxxx> wrote:
"Nico Coesel" <n...@xxxxxxxxxxx> wrote in message

news:461e8b14.166948359@xxxxxxxxxxxxxxxxx





"Jon Slaughter" <Jon_Slaugh...@xxxxxxxxxxx> wrote:

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

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

<jrwalli...@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.

You'll have to. In one way or another you can't tell which sample is
important and which is not. Some Tek scopes solve this by showing an
arched area in which the signal moved. This involves evaluating all
samples and determine minimum and maximum values.

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.

You've found a very good analogy; like you need to process samples you
can't 'see', you'll need to deal with objects which cast a shadow on
certain areas or emit light even though they may be outside the
viewport or too small to render.

No, thats not real time rendering(well, its becoming that way). That is ray
tracing but games now days use ray casting. You cannot ray trace in real
time yet to any significant degree.





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.

That sounds like a pretty useless oscilloscope to me. Lecroy actually
made DSOs like that -completely useless-.

I want an oscilloscope which shows the imperfections of a signal
(ringing, overshoot, edges). If you don't know an anomaly is there,
you won't zoom into a piece of a signal. In your scenario, the user
would need to go through all the data with a comb looking for the
needle in the haystack.

I'm not going to argue about it any more. You don't have to understand or
believe what I'm saying. Your ringing example is no counter example though
because you still cannot see the higher frequency components. There is
always a band limiting aspect after the conversion and your not taking that
into account. That or you act like I'm going to only display the such a
small portion of the total spectrum of the signal to make it useless. That
is not the case. I will display what is only necessary for real time and
leave the rest for non-real time purposes.

I guess we have two different approaches. My goal is not to see the complete
signal in real time but have a history of the whole signal so I can go look
back at it. For example, I could use a scope like this as a logic analyzer.
A digital signal is simply a signal. I would digitize it, go look at it and
see what happened. With a analog scope this is impossible because you have
no way to see the history. If you try to view it in real time then chances
are you'll not catch anything because it went by too fast. If you have the
whole signal stored in memory then you can easily go back and do processing
on it and view it. You can even view it for ringing and such and get all the
details you need up to the bandwidth/sample rate of the conversion. Ofcourse
even if its not in real time you don't need to display unnecessary
information that the user cannot process.

About the haystack. No, thats not true. You don't understand very well. You
can have triggers, intelligent searches, etc... I'd take that ability to be
able to go back and look at some instant of the signal that was momentary
than loose it for ever. Ofcourse if your dealing with several seconds of a
signal samples at about 1GS/s then it would probably take you several days
to find some random event that happened. Having some intelligent way to go
through the signal would move that down to a few mins. Similary to how a
word processing application works. If your looking for every instance of
some word you do not have to manually search through the whole document.

You could have something like "bookmarks" that set a bookmark when a search
"trigger" occured. This way you can very easily navigate to specific events.

That's the equivalent feature of Wave inspector from Tektronix:
http://www.tek.com/site/ps/0,,3G-20156-INTRO_EN,00.html

.

Relevant Pages

  • 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: PCI interface
    ... I'm not going to display the data in real time. ... on a standard monitor at any given time. ... Now take the square wave in the example. ...
    (sci.electronics.design)
  • 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)
  • Real time phase update of SimulateSignal
    ... synthesis of a square wave using the SimulateSignal VI. ... have a user input for the phase angle, so that the phase of the square ... wave can be changed in real time. ... with a zero degree initial phase angle. ...
    (comp.lang.labview)