12 and 16-bit oscilloscopes

Probably - I have not really looked at the numbers too seriously. But desktop CPUs are *very* fast, and edge detection is pretty easy. It would already be doing signal averaging and maybe digital filtering (especially on the slower "timebases"). So simple level detection would not be much extra work.

Of course we could do all this in a bigger FPGA, but then where do you stop...

I regularly take one million or more samples with the Binary Sampler and search the waveforms for different characteristics. Even with smoothing, the response from the keyboard on a 466MHz cpu is almost instantaneous. You should have little trouble finding a desired starting point to display a waveform.

The software is Borland Pascal using inline assembly for the critical sections. I run DOS in Flat Real Mode (FRM) and store the data in Extended Memory. FRM gives instant access to memory above 1 Meg without having to go through Himem, which is painfully slow.

Doing the edge detect in software eliminates the problems with hardware triggering and the extra jitter it adds. I plan to use this technique for an inexpensive 5GHz Binary Sampling scope running on a pc. I was going to use the pc sound card to transfer the waveform, but it needs to have a response to DC. So a simple 16-bit ADC is probably the way to go.

The AD7660 looks quite interesting. The 120dB SNR up to 78KHz is impressive. It might be a good compliment to the inherent noise-rejection capability of the Binary Sampler. This might produce an inexpensive scope with unique capability and wide bandwidth.

Regards,

Mike Monett

Antiviral, Antibacterial Silver Solution:

Mike,

...

I'm impressed with what you're able to do, but you realize you've at least decimated your market by working on a product that requires *DOS*???!!!

---Joel

...

Hi Mike, Joel and all,

OK, the AD7660 is a 16-bit successive approximation ADC that's pretty decent. The AD7760 is the 24-bit delta-sigma part. I'm not quite seeing the 120dB SNR in the data sheet for the AD7760--looks like 112dB to me. At 78kHz bandwidth, that's about -160dBfs/Hz. That's good, certainly, though it's not all that different from a 130Ms/s part that has a 78dB SNR: such a part has a noise level at about -156dBfs/Hz.

If it's really for a scope, my main interest in more bits would be to avoid input ranging, and that's not all that difficult at low frequencies (1MHz these days is "practically DC"...). But if it's for spectral analysis, that's a different story. Then distortion and noise are important (more important than the number of bits, which is largely a red herring).

My personal interest would be in fewer bits and much faster sampling: maybe a Virtex 5 connected to two or four 500Ms/s converters, into a deep buffer memory.

Cheers, Tom

What part number was that?

Hi Win,

It's the E1437A; it's a VXI module, and includes traditional dynamic signal analyzer functions like zoom and decimation.

Cheers, Tom

DOS is still used for critical embedded applications, such as process control, where Windows is simply too unreliable, and Linux may be overkill.

DOS also gives the fastest possible performance, since you own the cpu and don't have to give up cpu cycles for multitasking. That's the reason I mentioned it - the response while sifting through a megabyte of data was practically instantaneous from the keyboard, but it would be a bit slower in Windows.

However, that was on a 450MHz AMD K6 cpu. I would expect higher performance on a more modern 2GHz+ cpu for home lab applications.

Since the code is in Borland Pascal, it would be very straightforward to transfer it to Free Pascal and run it in Windows, or even to Linux running on an X86 machine.

The main point is sifting through a megabyte of data can be very fast if you have taken a bit of care to optimize the code.

Regards,

Mike Monett

Antiviral, Antibacterial Silver Solution:

These are nice A/Ds but a bit hard to use.

I'm not sure how much the zoom/decimation is worth these days as a PC can do it in real time (if you can get the data into it).

To use an E1437A you need the VXI bus cage and slot 0 controller and software. To run at high speed you need to use the E1437A the HP VXI Local bus (100 Mbyte/second ECL) output.

I've got a Pentek Model 4404 HP Local Bus-to-FPDP Adapter and a PC with a FPDP PCI card all cobbled together.

It's not perfect but it can run in 16 bit A/D mode at 20 Msamples/second and the PC can put out the resulting 40 MB/second over Gigabit ethernet (to the cluster).

Sorry for the confusion, I did mean the AD7760 (the 24 bit 2.5MHz delta sigma that my link pointed to).

Interesting; your implication is that one can obtain equivalent performance at lower frequencies by signal averaging, yes? So just pick the device with the highest sampling rate and low dBfs/Hz?

My motivation was based on experience with a TDS3054 scope. I love it, but one thing it does not do is improve resolution at the lower sample rates. For one-shot events, you are stuck with the same ~7 bit resolution at 10kHz that it uses at 500MHz. It would be nice to have something optimized for low frequency use.

Hi Tom,

ADI claims 120 dB dynamic range at 78 kHz, but only 112 dB SNR. From the spec:

FEATURES

So it seems their claims are OK.

Tom, how do you get the -160dBfs/Hz figure for 78kHz? Can you give the calculations?

I can see how the normal SNR calculation gives wideband SNR. For example, 16 bits is

SNR = 20 * log10(2^n) = 20 * log10(2^16) = 96.3295 dB

But how do you include the bandwidth in this calculation?

What's a Virtex 5? It sounds expensive. You are probably the kind who gets ic's with gold-plated pins, where the rest of us have to be content with tin/lead:)

The AD7760 might be good starting point for entry level. At $35.00 it's not too expensive, even for a scope with multiple channels. The 120 dB might give 6 digits at DC, so it could be a combined DVM and scope. The Binary Sampler could give a bandwidth past 5 GHz, so that could give a very inexpensive system with pretty good capability.

Once you have a system running, the wideband sampler could be used for working on a faster digitizing system. Certainly 1 Gs/s is quite feasible.

I believe Maxim had articles on interleaving slow ram to use with their fast digitizers. That could provide a starting point for the pc interface. So it might be possible to bootstrap a system for very reasonable cost.

This is significant from several viewpoints. Sure, you can get cheap systems on ebay. But what do you do when they break? Modern scopes are not repairable, certainly not with the resources available in a home lab or small business. After some point, even Tucker won't quote on repairing them. So they become useless junk. But if you build your own system, you certainly can repair it if it breaks.

Another advantage is you can add more features to the system when it is needed. Say you need more channels. That is simply duplicating what you already have working. The software is open to anything you can imagine. Once you have solved the problem of transferring data quickly to the PC, analysis can be very fast.

You can take also advantage of newer chips with improved performance, so your system can evolve with new technology.

The beauty of this approach is you are not dependent on trying to keep commercial equipment running. Decades ago, I had no problems buying complete labs of new HP and Tektronix equipment.

But over the years, something happened to the reliability. The Tek and HP equipment started breaking down, and repair costs were astronomical. I began to get the impression it would be faster to make my own lab equipment rather than spend the time packing and shipping equipment back for repair.

Now that inexpensive ic's are available with excellent performance, it seems to be very reasonable to build your own equipment.

And with the tremendous resources available in this newsgroup, how can you resist?

Regards,

Mike Monett

Antiviral, Antibacterial Silver Solution:

Au contraire! *Synchronizing* the channels requires a shared timebase distributed to each module or some other solution, and letting *any* module trigger also requires some shared data lines.

Perhaps you didn't mean to imply otherwise, but I've caught myself at times thinking, "Yeah, if I bought a 2 channel USB-based DSO, I could just buy 2 and get 4 channels..." -- which doesn't work with any commercial offering I'm aware of, due to the the need to share timebase/triggering data.

As I mentioned somewhere else, these days I think the bulk of the time is actually in the software, at least for something like a "generic" scope where you just have simple triggering methods and otherwise are just collecting data.

---Joel

...

Yes, with respect to noise anyway. After all, a delta-sigma does it, but in spades, by using feedback (the "modulator") to move the noise from low frequencies to high, and then "averaging" (decimation filtering, actually). ADCs designed for low frequencies are likely going to have better distortion performance than the high speed ones. Of course, the distortion of the high frequency ones is usually worse at high frequencies than at low, but still, even at low, they won't be quite as good. The advantage, of course, is that you can also look at the higher frequencies, which is tough with a delta-sigma narrow-bandwidth converter (except in narrow aliased bands...)

Yes, IF the 7 bits is really linear, then band-limiting filtering will help things out considerably. The ADC in the HP3563 that Fred mentioned is only 13 bits, but is dithered and has very good linearity, so you can accurately measure signals well below one part in 2^13.

I suppose doing decimation on a 130Ms/s data stream with a PC real-time might be possible, but would be pushing things. You have to deal with getting data in, as well as implementing a multiple pole filter that probably is going to take a few dozen instructions per sample. Much nicer to have that with the ADC, along with a big capture buffer.

Cheers, Tom

...

White noise (assumed, but not strictly accurate, especially at frequencies low enough to be in the 1/f noise region) is equal power per unit bandwidth. 78kHz bandwidth is 10*log(78000) decibles more power than a 1Hz bandwidth. Subtract 10*log(78000) from the 112dB SNR.

New (and fast) Xilinx FPGA. You can do a LOT with a much cheaper Xilinx Spartan3E.

An FPGA can accumulate several samples and put them in parallel into a standard (cheap) DDR2 memory module.

There's truth to what you write, though I'd temper it with what the real costs are at various points of use. What's right for you likely isn't for a big company.

There are certainly still a lot of challenges to building your own equipment. How do you deal with big BGA packages? And that's just the tip of the iceburg.

That said, I'll be taking my little $100 L/C meter in to work today because I don't trust the big expensive one there when measuring inductors...

Cheers, Tom

Don't you have gaps where the various interrupts take control away? Perhaps your application doesn't have this problem, but if the gaps occur at "critical times" - say, in the middle of a single-shot acquisition - this would seem to be a problem. Do you turn off interrupts, and if so for how long? Are there any significant penalties for turning them off for an "extended period"?

-f

Tom Bruhns a écrit :

Yes. Thanks for pointing that out. The resolution I get from it, the fact that it has 16b digital data input, the quite strange absence of specifications in the operating manual and my laziness to look any further incorrectly leaded me to the think it was 16b.

I imagine Mike disables interrupts if they'd otherwise interrupt what he's doing.

Windows device drivers can and do disable interrupts and can "hog" the CPU all they want as well... there's just plenty of admonishments not to do so unless you really, truly need to, as of course it does tend to make the entire system sluggish.

For something like a scope, the data would presumably be buffered in a FIFO (or similar) anyway, so as long as you can keep up with the average data coming in, the occasional, brief interrupts shouldn't be a problem.

(That being said... in the server version of Windows OSes on a heavily loaded machine, *user mode* applications can sometimes be pre-empted for *seconds* at a time!)

---Joel

I don't see the problem if you design your own hardware. If you elect to use hardware triggering, you naturally provide a way to share the trigger source and sync with each module.

If you plan do it in software, you can simply distribute the trigger pulse so all modules start at the same point. For fast sweeps, you can trim the time for each channel, much the same as the 7400 series plugins did in hardware.

If you buy the hardware, you need to find modules that do what you want them to, or plan to modify them. That leads to all kinds of problems, so it is probably better to design your own from the start.

Software is a real problem if you can't program. I think most engineers these days have learned how. Certainly if you do any work in embedded systems, you are involved. Fortunately, programming is lots of fun, especailly if you have developed your own software to take care of the drudge.

Regards,

Mike Monett

Antiviral, Antibacterial Silver Solution:

Yes, I'm just saying that I haven't seen anyway do this commercially yet. One thing to keep in mind is that when you start building reasonably fast scopes, you have to ensure that either the delays to all the modules are the same, or at least that you have some means to calibrate out the differences. (As you're probably aware, historically things like network analyzers came with "phase matched" cables that had been trimmed to be very precisely the same length.)

---Joel

The two main interrupts are updating the DOS timer 18 times per second and the keyboard interface.

You can indeed turn interrupts off in critical sections. For example, I usually turn them off when counting the number of cycles a routine takes when optmizing code.

To do this, you read the contents of a 64-bit register in the cpu and take the difference between the starting and ending values. The measurements can be erratic if interrupts are on due to the DOS time routine, so you pretty much have to turn interupts off to get an accurate measurement.

If you turn interrupts off for a very long time, you need to read the CMOS time and update DOS. That is easy to do.

If you turn interrupts off and your software hangs waiting for another signal, you can't use the keyboard and you have to reboot.

So you need some provision to check the keyboard to see if you pressed a key so you can break out of the loop. These things may not be needed or desirable in the actual running code, so you need a language with conditional compiles so you can easily switch to debug mode. Borland Pascal is an excellent language for embedded work in DOS. In fact, TP5.5 is available for free on the Borland Museum.

Regards,

Mike Monett

Antiviral, Antibacterial Silver Solution: