12 and 16-bit oscilloscopes
in [Design]
|
Prev: Are low/lower cost USB Oscilloscope's any good?
Next: datasheets for Semefab 051-8728 and KSP 10-124
From: Fred Bartoli on 19 Dec 2006 13:15 Tom Bruhns a �crit : <...> >> 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. > > 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. > 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. -- Thanks, Fred.
From: Joel Kolstad on 19 Dec 2006 13:53 "Frank Miles" <fpm(a)u.washington.edu> wrote in message news:em98kr$l6b$1(a)gnus01.u.washington.edu... > Don't you have gaps where the various interrupts take control away? 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. > 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. 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
From: Mike Monett on 19 Dec 2006 17:32 "Joel Kolstad" <JKolstad71HatesSpam(a)yahoo.com> wrote: > "Mike Monett" <No(a)email.adr> wrote: >> 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. > 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. 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. >> Now that inexpensive ic's are available with excellent >> performance, it seems to be very reasonable to build your own >> equipment. > 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. 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. > Joel Regards, Mike Monett Antiviral, Antibacterial Silver Solution: http://silversol.freewebpage.org/index.htm SPICE Analysis of Crystal Oscillators: http://silversol.freewebpage.org/spice/xtal/clapp.htm Noise-Rejecting Wideband Sampler: http://www3.sympatico.ca/add.automation/sampler/intro.htm
From: Joel Kolstad on 19 Dec 2006 17:46 "Mike Monett" <No(a)email.adr> wrote in message news:Xns989EB234FCE9Noemailadr(a)208.49.80.251... > 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. 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
From: Mike Monett on 19 Dec 2006 17:51
fpm(a)u.washington.edu (Frank Miles) wrote: > 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"? 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: http://silversol.freewebpage.org/index.htm SPICE Analysis of Crystal Oscillators: http://silversol.freewebpage.org/spice/xtal/clapp.htm Noise-Rejecting Wideband Sampler: http://www3.sympatico.ca/add.automation/sampler/intro.htm |