Digital Sampling Oscilloscope attachment (DSO wing)

[Entropy]

Lets try for a more precise requirements list.

 100 MSPS A/D converter  ( I am not sure that sample rate is achievable without problems )
  20MHz Analog frontend  ( This is to high for the sample rate above, but you can at least check if the usual microcontroller oscillators swing).
  1 to 20V input stage         ( in 5 or more steps )

As Luke mentioned the buffer depth is not great but I can remember fancy Tektronix scopes with less buffer memory. I also think in Luke's
calculation is off. I get 120us at 50MSPS until the buffer is full.
 
Klaus Leiss

The general rule of thumb for scopes is samplerate = 10x analog bandwidth, but people have gotten by with 5x.  You just have to be more careful about filtering and interpolation.

IF it is possible to drive the buffered inputs of the new LA design with an AD9288 it's possible to achieve 200 MSPS (100 per DAC in the 9288 with clocks 180 degrees out of phase, two 8-bit parallel outputs) - some of the remaining 16 GPIOs would have to be used for control and clock.

Problem is that from what I see, to maintain the standard Gadget Factory "wing" form factor, you are limited to a 16-bit wing - The 32 bits of I/O (actually 16 of I and 16 of I/O) are broken out to two separate wing headers, somewhat different from the original gadgetfactory design that permitted a single 32-bit wing.

In addition to the 16 bits for the data, you'd need more lines for control of the analog frontend and ADC clocks, so at least something along the line of 20-24 signal lines would be needed.  (Two ADC clocks, and you might be able to control the frontend using I2C, allowing you to work with 20 signal lines.  However once you go past 16, the next logical steps are 24 or 32.)

It appears that most of the faster ADCs (some can do 250 in a single ADC) need more I/O per single ADC - One of the 250 MSPS units from ADI interleaves data between two 8-bit outputs, and the other has 8-bit LVDS (16 lines).

A Spartan-3E in a QFP144 or QFP208 would have provided more flexibility for a DSO - either would have allowed for at least four interleaved AD9288s, coming up to 800 MSPS.

[alm]

Disclaimer: I've done a fair bit research in digital oscilloscopes, and my conclusion was that all PC-based oscilloscopes are basically crap compared to entry level stand-alone oscilloscopes (like the Rigol DS1000D/E and Tektronix TDS1xxx series), unless you pay more than the price of an entry level DSO. If I wanted a cheap scope, I'd look for a used 50-100MHz analog scope. Still, I try to offer some ideas to make this as useful as possible. Your advantage over a $50-$100 used analog scope would be price(?), digital storage and size. I'm going to offer some ideas, and you're going to tell me that that's completely unrealistic for a hobby project, but it might help you along.

Something about bandwidth (most of this is in the already posted Agilent appnote). The rule-of-thumb for analog signals is that the analog bandwidth of the scope should be about five times larger than your signal frequency to get a reasonable representation (even more for accurate measurements). Note that the analog bandwidth is the -3dB point of the front-end amplifier. At the specified bandwidth, your signal amplitude will be 40% lower than the input signal.

For digital signals, you should be looking at rise times, not clock frequencies. An 8MHz digital signal (period = 125ns) might have a rise time of about 10ns. To display a 25ns rise time, you need 0.35/10ns = 35MHz of analog bandwidth. This will only let you see the rising edge with a 40% uncertainty, to get an accurate view of the rising edge, you need even more bandwidth. If you observe a 20MHz clock signal with a 20MHz scope, you will only see an attenuated sine wave, and none of the overshoot, ringing or glitches that may be present. You use the scope to see actual details like rise times, glitches or overshoot. If you only wanted to see the bits, you'd use a logic analyzer. See also this link about bandwidth and rise times.

The bottom line is that you never have enough bandwidth, and 20MHz is barely enough for even 8-bit micro work, not to mention FPGA's. Commercial scopes start at about 60-100MHz. I'm not saying this is a realistic target for this project, but 20MHz is definitely not overkill. You should think of bandwidth in the frequency domain, i.e. the highest component in the Fourier analysis, not just the period.

Sample rate is independent of analog bandwidth, the are scopes with a 20GHz bandwidth but a 100kS/s sample rate, and there are scopes with a 60MHz bandwidth and a 1GS/s sample rate. The basic rule-of-thumb is sample rate should be ten times larger than the bandwidth. The reason that you can't just apply the Nyquist-Shannon theory is that the Nyquist frequency is two times the highest frequency component. A 20MHz amplifier will also let through signals above 20MHz, just attenuated (about 6dB/decade if I remember correctly for Gaussian roll-off). This means that there will be some 40MHz and 60MHz components, which would screw up your interpolation if you were sampling at just twice the bandwidth. On the higher end, scope manufacturers sometimes cheat with just five times the analog bandwidth as sample rate, but these usually have a sharper roll-off (as on page 2 of the Agilent appnote). I'd go for ten times the analog bandwidth to keep the filter and interpolation simple.

There's a trick called equivalent time sampling to compensate for slow ADC's. It was used in the first DSO's when no fast ADC's were available, and it's used in the really fast scopes (above 20GHz or so). What you do is sample a periodic waveform at a random time, so you get a different part each time. You combine all these samples to get one waveform. You still need a good timing resolution to do this, and it only works for repetitive signals. I wouldn't attempt this, but it is a workaround for slow ADC's. Here is an example of that.

To look at the 8MHz signal, you needed 35MHz bandwidth, so you want to sample at 350MS/s. This why even (good) entry-level scopes sample at 1GS/s. So a 100MS/s scope would probably be usable for max. 2MHz signals if you want a reasonable level of detail.

Memory is the third important parameter, with a low sample rate, memory is cheap. The entry level Tektronix stuff is 2.5kpoints/channel, more is better.

It would be very useful if logic analyzer channels and the scope channel could be used at the same time, synchronized on the same timebase. This is what the current mixed-signal oscilloscopes do. Not sure if the FPGA has enough resources for this.

I haven't heard anyone about triggering. You want at least level triggering good to the analog bandwidth (20MHz?). Other types like pulse triggering would be cool if they didn't cost much hardware, but not mandatory in this class in my opinion. Letting the logic channels trigger the scope (so you can trigger on certain serial data) would be useful. You obviously also want pre-trigger information (so you can see the signal just before the problem area).

For the input impedances, you have basically two options: 1Mohm, 10-35pF or 50ohm. Designing a good wide-band 1Mohm front-end with good transient behavior, good overload recovery and reasonable linearity is really hard. It might be easier for just 20MHz, but there are few PC-based oscilloscopes that get this right. Something like 'I haven't tested it, but I expect the frequency response to be flat to 100MHz' doesn't really convince me. You're not in a transmission line environment, so you have to deal with reflections and parasitic inductance/capacitance. There are not a lot of off-the-shelf parts for this. I'd go for 50ohm. The disadvantage is that you can't use regular passive probes. There are some DIY FET probes floating around: Bob Pease published one in 'Troubleshooting Analog Circuits', Elektor has a design (and a PCB, there's a PDF of that article somewhere on the net last time I checked), and I think Jim Williams published one in an appendix of LT AN47. A resistive 50ohm probe works great for high-speed circuits over 100MHz, but the 50/500/2000ohm input resistance would probably be too low for many slow digital circuits.

I'd probably mostly use the scope for signals below 5V, but this highly depends on the user. Probes do slip, however, so it would be nice if accidental contact with mains wouldn't kill my computer (put opto-couplers or RF isolator chips in the serial connection?). I think the way for this project to succeed is to really limit the scope (as in range, not oscilloscope). For example, only signals of 0-5V, fixed gain, absolute max -15V to +40V, DC-coupled, and I'd stick an isolation device in the UART port (I like the Silabs isopro/AD iCoupler devices, but opto-couplers might work too). In case of an overload, only the SUMP PUMP and wing would be killed, and not the computer.

Alson

[ian]

@alm - thanks! That's a great writeup and a lot to chew on.

@everyone - The Bitscope is the design that first interested me in building a LA/DSO. The design was first published in Circuit Cellar, and now the author has a business around it. The original kit is no longer available, and it's many years out dated, but my vision had always been something similar in specs to this design with modern parts (FPGA instead of CPLD, etc):

http://www.bitscope.com/design/hardware/
http://www.circuitcellar.com/library/print/0898/Jackson97/index.htm
http://www.circuitcellar.com/library/print/0898/Jackson97/Jackson97.pdf

[jack.gassett]

@alm - That writeup is very helpful, thank you. So maybe we should target a 50 ohm impedance for the first revision? This website has a very nice comparison of probe types, maybe we could come up with a Resistive Input style probe pretty easily?
http://www.signalintegrity.com/Pubs/straight/probes.htm

I think our first action is to really decide on which ADC to go with, then we can start making the EAGLE footprint.

Jack.

[alm]

A resistive probe for 20MHz would be trivial, just a piece of 50ohm coax with a resistor on the end and some tip/ground connection would probably be good to a few hundred MHz. The hard part would probably be the mechanical part, you want it reasonably sturdy, a soft resistor lead will break soon.

If you're going the DIY probe route, I'd also consider how to attach to modern devices. I find the old retractable hook and minigator fairly useless for modern fine-pitch SMD devices, I'd make 0.025" sockets and use E-Z-hook-style clips (like the Saleae Logic uses). You want to minimize inductance, so keep the leads as short as possible (no 30cm leads), and put a pin (maybe a pin from a gold-plated 100mil SIP connector?) in the socket for hand-held use. Like the Tektronix P6561 or P6243.

You can also connect any source with a 50ohm output directly to the input.

The disadvantage of resistive probes is the low impedance at DC and low frequencies. At higher frequencies, the input capacitance dominates: a 10Mohm passive 10x probe with 10pF capacitance, which is quite good, has an impendace of 160ohm at 100MHz, and 800ohm at 20MHz. This makes the parallel 10Mohm resistance completely irrelevant. A 1x 1Mohm probe usually has an order of magnitude more capacitance, which explains why they're useless for anything remotely high-frequency. A resistive probe might be 500-5000ohm // 1pF. The low resistance means high loading at DC (500ohm vs. 10Mohm), but lower at higher frequencies (still 325ohm at 100MHz).

A 10x resistive probe would be about 500ohm, a 100x probe would be 5000ohm, and you can obviously use any value in between. Nice round values are easy to work with, although this can be compensated in software. A 100x probe requires a very sensitive amplifier, a 1.8V signal will become only 18mV, so you would probably need to stick to a 10x or 20x probe. I have no idea how slow digital digital circuits react to a 500ohm load, it would draw 10mA from a 5V signal, which is often about the max for many chips. Resistive probes work great for fast digital circuits, which need a low output impedance to get the slew rate necessary for that 3GHz bus, so they don't mind a few mA extra. Some smart people like Howard Johnson (you already linked to his website) and Doug Smith (has instructions for a restive probe to 1GHz) really like resistive probes, but I'm not sure if they're the right choice for your average 8-bit micro and 74HC logic.

It's basically the law of conservation of misery: you either make it 50ohm, simplify the front-end, but make the probes more difficult (either low DC resistance or FET probe, which are more complex and expensive), or you use off-the-shelf probes but have a more complex front-end.

[jack.gassett]

@alm - Ok, so it sounds like for our low frequency application the current draw of a resistive probe could be problematic.

I would prefer to put the work into the front end and make it compatible with off the shelf probes. But at this point I'm still trying to get a handle on what exactly that entails and what is the best approach. So any recommendations are greatly appreciated.

With the information I have now what I think needs to be done to use off the shelf 1Mohm probes is this:

-Bandpass filtering to limit the signal to the range we are targeting. 0-20Mhz or 0-50Mhz.
-Set the impedance to 1Mohm using one of the following options:
   -Try to find an op amp that has 1Mohm impedance.
   -Use a transformer like is done with telephones.
   -Use a resistor for resistive impedance matching.

Am I way off here? It's been a long time since I've thought about analog design, (not since school) so I'm having to re-educate myself.

Jack.

[alm]

I don't claim to be an expert on oscilloscope design, I've never designed one and I wouldn't have the knowledge to do so, but I do know some of the pitfalls, and I'll try help out as much as I can.

A 1Mohm input would indeed be the most versatile for low-frequency work, although harder to design.

For the bandpass filter, I think 20MHz is already pushing it for 100MS/s. Imagine a 100MHz, 5V plus a 10MHz, 1V sine. The 5V sine will be down about -15dB with a 6dB/octave roll-off (the bandwidth is specified as the -3dB point). The 100MHz sine will have an amplitude of about 0.9V, so the 10MHz sine will appear to have an offset of -0.45V to +0.45V, depending on the phase. A 100.1MHz sine wave would introduce some ugly interference patterns. This effect gets worse with more analog bandwidth and/or a more gradual roll-off (that's why DSO's that oversample less than 10x often have a steeper roll-off, see the Agilent appnote). The -3dB point and roll-off should be for the whole system, if you have a bandpass filter with a 20MHz -3dB point and an amplifier with a 20MHz -3dB point, 20MHz will end up at -6dB. A larger analog bandwidth will only be useful if you do equivalent time sampling, which IMO is not worth the effort at this speed (just spend the extra bucks on a faster ADC/FPGA if you want more speed).

The filter should have a (fairly) linear phase response. Attached is a spice simulation of a 10MHz pulse with a 1ns rise time, through a simple 1-pole RC filter (R=10k, C=1p) (transient.png). This is a filter with a 16MHz corner frequency and 6dB/octave roll-off, so the rise time of 22ns is as expected (0.35/16MHz = 0.022us), but the phase shift causes an ugly asymmetrical waveform. An ideal response would show a symmetrical shape with a rise and fall time of 22ns. The second attachment (tds220.png) is a screenshot from a real 100MHz scope with a 60MHz square wave, and a rise time of <1ns (should have been 0.15ns, but my pulse generator won't do that). This should be equivalent to the simulation, except that everything is 6.2 times faster. The 'square' wave is pretty symmetrical, the ringing is probably caused by the setup (a high-impedance scope probe parallel to a back-terminated 50-ohm source).

You usually want DC coupling for a scope, so a transformer is out unless you do some modulation (probably not worth the effort unless you really want isolated channels). AC coupling is usually handled by putting a capacitor in the signal path, with a corner frequency of 10Hz or so. You either need a switchable attenuator or a variable gain amplifier, sensitivities usually range from 40mV full-scale to 40V full scale (400mV to 400V with a 10X probe). The bandwidth of a voltage feedback amplifier depends on the gain, which could make for some interesting interactions. A current feedback amplifier doesn't have this problem, I think. The usual commercial solution is attenuators and a fixed-gain amplifier, although they do change the gain for the lowest vertical ranges.

Re impedance matching, you're not in a transmission line environment with 1Mohm input impedances. There's no such thing as a 1Mohm cable or PCB trace (a 1Mohm coax cable with PTFE insulation would have a 1nm conductor and a 1e10239m shield!), and the source doesn't have a 1Mohm output impedance. You will have reflections and standing waves, so you try to minimize these (or hope that your frequency is low enough that you can ignore these effects).

The reason that you want the constant input impedance is because a 10x probe forms a voltage divider (9Mohm/4pF in series with 1Mohm/20pF or so, plus some stray capacitance/inductance), so it should be constant over the frequency and voltage range. The capacitance should be between 10pF and 45pF or so (preferable around 20pF), so the probes will compensate properly.

The input resistance and capacitance of some (most?) op-amps is in the same order of magnitude as the input impedance (3Mohm // 1.8pF for the first fast op-amp I looked at, LMH6657), so they will influence the input capacitance, as will any parasitics. An input attenuator (if any) will also be part of this network. The op-amp input impedance might also change depending on the input voltage, I'm not sure if it's stable enough for a voltage divider. I think there's a schematic of a setup to measure op-amp input resistance in Bob Pease's Troubleshooting Analog Circuits.

Another important spec is the overload recovery. The LMH6657 doesn't seem too bad (18ns, or two samples), but others (LMH6642) are a lot worse (<100ns). These are just the first two I found using the parametric search. You need good overload recovery so you can have large peaks beyond your vertical range without screwing up the rest of the measurement.

I'm not aware of any good commercial oscilloscopes that use op-amps as vertical amplifiers, but this may just be because their bandwidth requirements are usually higher than contemporary op-amps.

This service manual could be useful: Tektronix 453A Manual (warning, 30MB PDF). Mainly p. 3-4 to 3-6 (channel 1 vertical preamp circuit description) and Diagrams-6 to Diagrams-8 (channel 1 vertical preamp schematics). You wouldn't need the trigger pick-off (this is probably handled in the FPGA?). This is a 50MHz scope that's 40 years old or so, but it's mostly standard components and fully documented. I'm not suggesting to copy this design, it probably requires special construction for the attenuators and some things will be easier with modern components, but it might be a helpful reference.

Alson

[jack.gassett]

Well, this is a lot of great information to mull over. It's a lot to take in but we'll just have to take one step at a time and start figuring it out.

Jack.

[Scorpia]

I just had a website pop up on anther list thayt im subscribed to.

Thought some of the info there might be usefull here

http://www.pdamusician.com/dpscope/index.html

I hope some of the information is at least a little usefull

[alm]

Thanks for the link, at least the design is well documented. My $0.02:

Low bandwidth (1.3MHz, 1MSPS), useful for RS232, I2C, SPI? Really? Even low-speed I2C is 100kHz, 1MSPS is going to be iffy to accurately measure that. Equivalent time sampling is almost useless for digital signals without advanced (serial pattern) triggering. Low bandwidth does make design easier, obviously. 200 points is pathetic, especially since it's shown on a 20" wide-screen monitor instead of a dinky 320x240 QVGA screen in a stand-alone scope. Probably to get the 45 waveforms per sec over the async serial connection.

The offset is a useful feature (mainly used to observe small AC signals on a larger DC offset), but I find it strange that it can't measure any negative signals without using the offset function. AC coupling is going to be hard this way. Some cheap probes might not compensate all the way to 15pF (most cheap scopes are higher).

The 1x/10x amplification and programmable gain amplifier is a smart trick, but won't work very well at higher frequencies. The fastest Microchip part that I could find (MCP6S9x) is specified as 18MHz, but according to figure 2-25 of the datasheet, the -3dB bandwidth is about 10MHz at unity gain, and less than 10MHz at higher gain values. I couldn't find any affordable, fast ones in my quick search. The LMH6502 is pretty fast fast, but $7 for one at Digikey, and programmed by analog voltage. The variable bandwidth with gain shouldn't be too much of an issue as long as the bandwidth is much higher than the input signal bandwidth (>>20MHz). You'd also need a fairly fast op-amp for 10x gain at 20MHz.

It seems to me that there's much less than $130 in parts in there, although he can of course charge whatever he wants for it.

Alson

[alm]

You guys are probably busy finishing the basic logic analyzer to before designing add-ons, but I just came across this post on the TekScopes yahoo group. Kuba talks about a special zero-holdoff DSO (that will re-arm the trigger immediately after it stops sampling), but it also contains general information, mainly about the analog part.

I've rambled about it for a while, but I'll repeat it in a more concise
fashion.

First, some acronyms of my own making:
DO - digital oscilloscope, everything falls under this umbrella,
DD - signal digitizer, that's what your sound card is, for example,
DSO - digital storage scope, anything with a framebuffer functionality falls
under it, the DDs are excluded,
BDSO - bistable digital storage, that's what Tek TDS1k/2k, and LeCroy
93xx/94xx are, some of those have "variable persistence" but are still
bistable,
BDSO0 - "cheap" bistable where for each column only min/max values are stored,
BDSO1 - real bistable where each pixel is a bit or two wide; say 00 -
extinguished, 01 - lit up, 11 - lit up in the most recent refresh (has to be
reset to 01 on next refresh)
DPO - digital phosphor scope, where the framebuffer accumulates "hits" from a
simulated "beam"

In the DSOs, the biggest factor in overall design is the refresh rate (holdoff
time). This is like the hip point in the automotive industry: it defines the
whole thing.

Slow refresh rates (up to say 100Hz) in a DSO are doable with a PC and a
digitizer card. You implement the framebuffer in software. No big deal.

The technology is right now at a point where it's not only feasible, but not
necessarily a big deal to have zero holdoff DSO. I.e. a scope where after the
last sample of the current trace is acquired, the next sample goes to the
beginning of the next trace. This is essentially a double-beam functionality:
one beam finishes the current trace, while the second beam has already
triggered and paints the next trace.

Making a zero-holdoff DSO is a worthy goal, and with some forethought it'snot
that hard.

For one-shot acquisition, almost any PC memory will do without much hassle --
you can interface to it in discrete low voltage logic and keep the 8-bit
acqusition rate at 200Ms/s easy (that's 50Mhz single data rate clock).

And, for almost any nontrivial scope, you will want only to use stock, off the
shelf PC memory (DDR). It's cheap and has mucho bandwidth. Some short-term
buffering will need to happen in the FPGA, but for everything else go with
regular DIMMs or else it'll end up another piece of overpiced, unmaintainable
*deleted*.

In the mixed signal chain, several things are worth mentioning:

1. You need a "very stable" clock source. Phase noise will degrade your
signals, especially at fast sampling (Gs/s) or higher resolutions (say 16 bit
100Ms/s). Everything in the clock chain has to have "low" jitter. Unless test
results tell you otherwise, trust nothing. Even gates with specified low
jitter can behave wildly due to noise in the power supplies etc. You have to
first spec it out, then test it out, then put in a factor of safety of two at
least (more if you only test at room temp!). I gave words in quotes meaning
that what's "low" for one application may he "high" for another ;)

2. Your analog antialiasing filters can only go so far -- you should expect to
oversample to compensate for that. A good rule of thumb would be to sample at
10-15 times the antialiasing f-3dB.

3. You will need a FIR to compensate for the response of your analog signal
chain, and to optimize the phase response. It's simpler than endlessly
tweaking the analog signal path. [Your analog signal path should not really
use feedback in a way which would produce slew rate limit, as this is a
nonlinear effect and much harder to compensate for]. So, we're talking of at
least 64 tap filters, running at 100Ms/s+ (I assume 100Ms/s is the least you
want to do). This takes big FPGAs, but is doable. Note that those FIRs will
need fairly large accumulators, and if done in fixed point, the coefficients
may easily end up being 2-3x as wide as the signals.

4. PC memories are very fast at block access. They are slow when it comes to
addressing the next block. This places very real constraints on any sort of
storage functionality other than a DD. Let's assume a 512-pixel high
framebuffer (length doesn't matter for bandwidth), 16 bit vertical dynamic
range, and 32 bit intensity dynamic range in DPO applications.

a) In a DD, your access is sequential, even if you do averaging: you read a
block, add your signal to it, then write it back. Your bandwidth is at most 4
bytes per sample, all sequential and blockable.

b) In a BDSO0, you're storing min-max values, so that's 4 bytes per column,
and 8 bytes per sample, also nicely sequential and blockable .

c) In a BDSO1, it's 2 bits per pixel, so 128 bytes per column. The bandwidth
is 256 bytes per sample, also sequential and blockable. You process each
column at a time in order to introduce cheap variable persistence: you
extinguish lit pixels with a certain probability. You also want to clear
the "last refresh" bit.

d) In a DPO, you will want to think about bandwidths and how to split column
processing. You can probably do a persistence sweep of the memory only when
the framebuffer is displayed (say at 100Hz). But still, the data points
(pixels) to be written to are far away from one another, so that whether you
need the whole column or not, you will either access it all, or have to wait
longer to readress the next pixel. The specs need to be worked out depending
on what memory standard you're setting for (PC-xxxx). If things were pink and
pretty (asynchronous RAM), you'd only need 8 bytes per sample (a pixel is 4
bytes). Per column, that's 4096 bytes, so 4Gbyte/s at 100Ms/s. Two PC-3200
sticks would handle that. Assuming the readressability overhead is such that
you'll get by effectively accessing half a column each time (bandwidth to
time equivlency!), a single PC-3200 stick should handle that, including 100Hz
framebuffer-to-screen transfer. I'd have to work the actual numbers out -
haven't got that far just yet for PC-3200.

In DPO calculations, if you're doing a full column-per-sample access, the
number of channels doesn't matter much. What you do is read the column in,
increment the pixels for each channel that you sample, and write it back out.
If you want to have different colors for different traces, you can scavenge a
bit per channel from each intensity accumulator. Multiple channels call for
full-column access, or for a separate phosphor for each channel. Which way
you do it depends on the bandwidths involved.

Also, you may end up storing several columns on the FPGA: read them in
advance, then update and write them out when you're done. The PC RAM performs
best in terms of bandwidth with unidirectional, block-access. Everything here
depends on column size and page size of the RAM.

5. Zero holdoff implies doubling your memory bandwidth requirements.
A "multi-beam" (multi-trigger) functionality additionally multiplies the
bandwidth needed by number of "beams", as you will be accessing several
columns at once. For such functionality, it's simpler to design
single-channel digitizer, filter and framebuffer as a unit, with room for one
or two sticks of DDR.

6. For more realistic CRT-like DPO, you can easily approximate rate of change
of the signal and vary the "writing brightness" with it. This of course would
need to be user-controllable.

7. In spite of having a potentially long framebuffer, you may still want to
have a separate memory to keep a given number of previous acquisitions in
isolation, so that signal history can be easily reviewed.

I'd say that a good starting point for homebrew work is 10MHz analog bandwidth
and 100-150MHz sampling rate, with at least 12 bit A/Ds. I'd also initially
just use a premade preamp plugin, such as a 7A15N -- they have differential
outputs and are easy to use. Then you do a differential antialiasing lowpass,
and feed the signal to the A/D.

Given a FIR, it's very easy to have split signal path if that makes feeding
your fast A/D easier. You'd acquire low frequency part of the signal with a
good DC spec amps, and a slower, DC-accurate A/D. Then you feed the fast A/D
with AC, high-freq optimized circuit. Then you add them together and the FIR
makes the response well behaved, although for proper low-frequency response
you'll need long FIRs running at high sampling rate speeds. You may end up
being able to partition them into slow and fast FIRs, if the coefficients
agree with you on that.

[rct]

For what it's worth, this Oscilloscope page at OpenCircuits has links to a number of previous oscilloscope design projects.   Not sure how much value they offer but thought it would be worth mentioning
*http://www.opencircuits.com/Oscilloscope

[ian]

Some additional links from Uwe:

Today I saw this on the elektor site:

http://www.elektor.de/elektronik-news/open-source-usb-oszilloskop-mit-propeller.1299421.lynkx

and this is the link to the ProScope on the Parallax site:

http://www.parallax.com/Store/Microcontrollers/PropellerTools/tabid/143/ProductID/586/List/0/Default.aspx?SortField=ProductName,ProductName

Maybe it gives some more inspiration for the DSO project.

[metRo_]

Sorry for not add any important information to this topic but can you tell us about the state of that project? :)

PS: I can't open the attachements

Good luck with this :)

[jack.gassett]

@metR0_

It is still in the works but is on the backburner while we get the OLS into peoples hands.

Jack.