From: Mike Monett on
"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

"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
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
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
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