12 and 16-bit oscilloscopes

Thanks Tom. That helps a lot. I was trying to divide and that didn't work at all.

That's the point of the Maxim approach also. Use cheap pc memory.

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:)

How do you handle them in regular designs? Same way.

See, small companies can often give better solutions:)

Regards,

Mike Monett

Antiviral, Antibacterial Silver Solution:

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

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: