Prev: Are low/lower cost USB Oscilloscope's any good?
Next: datasheets for Semefab 051-8728 and KSP 10-124
From: Mike Monett on 19 Dec 2006 18:00 "Joel Kolstad" <JKolstad71HatesSpam(a)yahoo.com> wrote: > "Mike Monett" <No(a)email.adr> wrote. >> 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 ISTR my network analyzers had a small knob on the front panel to set zero phase. Nowadays you can do it in software. In fact, there is an excellent VNA design on the web that uses a very innovative method to get amplitude and phase. He uses shorts, opens, 50 ohm terminations, and a calibrated cable to calibrate the system. You can see more here: http://n2pk.com/VNA/VNAarch.html Even more reasons to build your own equipment:) 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: Mike Monett on 19 Dec 2006 18:35 "Tom Bruhns" <k7itm(a)msn.com> wrote: > Mike Monett wrote: [...] >> But how do you include the bandwidth in this calculation? > 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. Thanks Tom. That helps a lot. I was trying to divide and that didn't work at all. [...] >> 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:) > 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. That's the point of the Maxim approach also. Use cheap pc memory. [...] >> And with the tremendous resources available in this newsgroup, >> how can you resist? > 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. The whole discussion is towards a home lab or small business. A big company has completely different requirements and probably can't afford the time it takes to build their own equipment. Also, they probably have NIST traceability requirements, which adds a whole dimension to the design. So you start a small business to solve these problems for them:) > 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. How do you handle them in regular designs? Same way. > 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. See, small companies can often give better solutions:) > Cheers, > Tom 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: Frank Miles on 20 Dec 2006 13:28 In article <Xns989EB56EB8FAFNoemailadr(a)208.49.80.251>, Mike Monett <No(a)email.adr> wrote: > 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. [snip] Well, then, it would seem to be a problem getting to the "all PC" 'scope (including using main CPU as trigger detector) if there are going to be times when you have to "look away" from the input in order to do housekeeping. You either have to give up the idea of super-simple hardware OR being sure you won't miss important events. -f --
From: John Devereux on 20 Dec 2006 14:23 fpm(a)u.washington.edu (Frank Miles) writes: > In article <Xns989EB56EB8FAFNoemailadr(a)208.49.80.251>, > Mike Monett <No(a)email.adr> wrote: >> 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. > > [snip] > > Well, then, it would seem to be a problem getting to the "all PC" 'scope > (including using main CPU as trigger detector) if there are going to > be times when you have to "look away" from the input in order to do > housekeeping. > > You either have to give up the idea of super-simple hardware OR being > sure you won't miss important events. I think there has to be local buffering on the "scope", but not much more hardware than that. In particular I don't think you need triggering. I was thinking - ADC - CPU with "hi-speed" USB - SDRAM - USB powered - input signal conditioning - "sync" input to sync multiple "channels" The CPU would DMA ADC samples into a circular buffer in SDRAM. A 64MB chip could hold at least 16M samples, i.e. several seconds worth. The timestamp for each sample can be derived from its location in the buffer and a known start point relative to the sync input. The host PC would continously read the data into RAM (another circular buffer) or stream onto disc. Software can then process the data, look for trigger edges, do signal averaging, FFTs, correlate multiple channels. -- John Devereux
From: Mike Monett on 20 Dec 2006 14:31
fpm(a)u.washington.edu (Frank Miles) wrote: >> 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. > [snip] > Well, then, it would seem to be a problem getting to the "all PC" > 'scope (including using main CPU as trigger detector) if there are > going to be times when you have to "look away" from the input in > order to do housekeeping. > You either have to give up the idea of super-simple hardware OR > being sure you won't miss important events. > -f I'm not sure I follow. I was talking about the software development process, where you may need to disable interrupts to measure how many cpu cycles a routine takes. Because the cpu has two simultaneous execution paths, you try to ensure they don't conflict. This would stall the pipeline and waste cpu cycles while waiting for one path to complete. Rearranging the sequence of instructions can help solve this problem, but each cpu is different so it takes skill and knowledge to arrive at an optimum solution. Terje is one of the best on the planet for this kind of work, and he would probably laugh himself silly reading my simplified explanation of how the process works. But the end result is to try to minimize the time required for a routine. And you can spend an exorbitant amount of time trying to shave a couple of cpu cycles in a critical spot in the code. Once this is done to your satisfaction, you can change the compile options to generate the working code that is shipped to your customer. This can be completely different from the development code, so you really don't have to give up anything in either process. So, yes, you can have your cake and eat it too. Does this make any sense, or was I just swishing around muddying the waters? 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 |