Microcontroller oscilloscope project

[yalect]

Hi,
Can I build or simulate an oscilloscope of high range response 100Mhz or more with microcontroller like Atmega or other?
Regards

[FrankBuss]

What do you mean by "response"? The analog bandwidth? Then you would need a multiple of it as the sample frequency. Forget Atmel, it can do maybe 1 MHz, because the internal ADC is not that fast and the CPU itself is not fast. You could do it with a Parallella board, as I did for my logic analyzer:

http://www.frank-buss.de/parallella/sampler/

or a Beagle Bone, which also achieves 100 MSps:

https://github.com/abhishek-kakkar/BeagleLogic/wiki

and then using a fast external ADC chip.

[yalect]

I mean by response the range of frequency that the oscilloscope can work on maybe there is some fast simple usb oscilloscope

[FrankBuss]

Yes, there are USB microscopes with 100 MHz bandwidth. But if you want something decent, I would recommend a real oscilloscope. Entry level Siglent scopes are not that expensive, e.g. you can get a Siglent SDS1102CML for EUR 333, which has 100 MHz analog bandwidth, and 1 Gsps samplerate.

[David Chamberlain]

Yes, there are USB microscopes with 100 MHz bandwidth.

Last one i brought had a bandwidth of 700THz, not too shabby

[ebastler]

Hi,
Can I build or simulate an oscilloscope of high range response 100Mhz or more with microcontroller like Atmega or other?
Regards

What do you mean by "simulating" an oscilloscope?

[FrankBuss]

Last one i brought had a bandwidth of 700THz, not too shabby

Do you have alien technology? 700 THz is the wavelength of purple light

[ebastler]

Last one i brought had a bandwidth of 700THz, not too shabby

Do you have alien technology? 700 THz is the wavelength of purple light

Which seems entirely plausible for "USB microscopes", which you started talking about. 

[FrankBuss]

Oops 

[Ian.M]

Last one i brought had a bandwidth of 700THz, not too shabby

Do you have alien technology? 700 THz is the wavelength of purple light

Which seems entirely plausible for "USB microscopes", which you started talking about. 

Actually, the visible spectrum bandwidth is only about 340 THz, (due to its lower limit of deep red at about 430 THz)  but what's a factor of two between friends?    

(see https://en.wikipedia.org/wiki/Visible_spectrum )

[ebastler]

Actually, the visible spectrum bandwidth is only about 340 THz, (due to its lower limit of deep red at about 430 THz)  but what's a factor of two between friends?    

(see https://en.wikipedia.org/wiki/Visible_spectrum )

Maybe you could switch your microscope input to DC Coupling? 

[David Chamberlain]

Actually, the visible spectrum bandwidth is only about 340 THz, (due to its lower limit of deep red at about 430 THz)  but what's a factor of two between friends?    

(see https://en.wikipedia.org/wiki/Visible_spectrum )

Hey I'm not just going to take an eyeball measurement of the electromagnetic spectrum, anyway I'm well overdue for glasses. Were talking about man made instrumentation here

[Ian.M]

Well we are both making the assumption that the camera in a USB microscope will be a colour one  optimised for visible light, so its bandwidth limits will be set by the RGB filters used on the sensor. 

However this isn't any help to the O.P.

A 100MHz bandwidth implies a 200MHz minimum sample rate, and that's difficult and expensive to do, even if you have fast parallel ADCs sampling direct to fast RAM and a FPGA to provide the sampling clock and manage the RAM's address and control busses.   Forget about doing it in a MCU unless it can do I/O port to RAM DMA at better than 200MHz.  Also a MCU's limited on-chip RAM is likely to limit the maximum  sample memory depth.

Its highly probable that you could put 100 times the price of an entry level 100MHz bandwidth DSO with save to USB storage, and several man years of work into developing your own USB scope platform and *STILL* have inferior performance and capabilities compared to that DSO.

[David Chamberlain]

Yes back on topic.

I would recommend OP have a look at the scopefun design as a basic reference, will at least give an idea of whats involved. It's a pretty minimal design.
http://www.scopefun.com/hardware

Or for video pleasure, daves teardown of a Uni-T


Or a low end (from The Signal Path perspective)

[FrankBuss]

Last one i brought had a bandwidth of 700THz, not too shabby

Do you have alien technology? 700 THz is the wavelength of purple light

Which seems entirely plausible for "USB microscopes", which you started talking about. 

Actually, the visible spectrum bandwidth is only about 340 THz, (due to its lower limit of deep red at about 430 THz)  but what's a factor of two between friends?    

(see https://en.wikipedia.org/wiki/Visible_spectrum )

The Wikipedia article you quoted says violet: 668-789 THz.

[Ian.M]

The Wikipedia article you quoted says violet: 668-789 THz.

I just took the approximate limits from the first paragraph of the article:

A typical human eye will respond to wavelengths from about 390 to 700 nanometers.^[1] In terms of frequency, this corresponds to a band in the vicinity of 430–770 THz.

Oscilloscope bandwidth is DC to max frequency.  Microscope 'bandwidth' is difference between upper and lower frequency limits of the spectrum its image sensor is sensitive to, which, in the absence of a sensor datasheet and the interest of avoiding extreme pedantry and dead horse flogging, I *HOPE* we can agree to take as near enough to the visible spectrum limits:  770 THz - 430 THz = 340 THz.   Taking far visible violet as 789 THz only adds 5%.

[David Hess]

With equivalent time sampling, a 100 MHz bandwidth or even higher is feasible with some inexpensive ADCs at sample rates that an Atmega or similar can handle but this would require implementing an analog trigger and time to digital converter.  And do not underestimate the difficulty of 100 MHz signal conditioning; 20 MHz would be difficult enough.

[b_force]

With equivalent time sampling, a 100 MHz bandwidth or even higher is feasible with some inexpensive ADCs at sample rates that an Atmega or similar can handle but this would require implementing an analog trigger and time to digital converter.  And do not underestimate the difficulty of 100 MHz signal conditioning; 20 MHz would be difficult enough.

I agree, PCB and layout is very important at these speeds

[NorthGuy]

With equivalent time sampling, a 100 MHz bandwidth or even higher is feasible with some inexpensive ADCs at sample rates that an Atmega or similar can handle but this would require implementing an analog trigger and time to digital converter.  And do not underestimate the difficulty of 100 MHz signal conditioning; 20 MHz would be difficult enough.

The ADCs in small MCUs use sampling capacitors. Also, the ADC will usually have some series resistance. This effectively forms a low pass filter effectively limiting the bandwidth (I guess well below 100MHz). Though you can get any sort of sample rates with ETS, it still won't have enough bandwidth.

[David Hess]

With equivalent time sampling, a 100 MHz bandwidth or even higher is feasible with some inexpensive ADCs at sample rates that an Atmega or similar can handle but this would require implementing an analog trigger and time to digital converter.  And do not underestimate the difficulty of 100 MHz signal conditioning; 20 MHz would be difficult enough.

The ADCs in small MCUs use sampling capacitors. Also, the ADC will usually have some series resistance. This effectively forms a low pass filter effectively limiting the bandwidth (I guess well below 100MHz). Though you can get any sort of sample rates with ETS, it still won't have enough bandwidth.

The sampling time constant for typical microcontroller ADCs limits them to somewhere between 10s of kHz and a couple MHz.  They can actually be driven faster with a low impedance source but they are not suitable for the reason you identify and more (1) unless an external track-and-hold is used which is feasible (2) but there are easier ways now.

Something like an $3 AD9283 can operate down to 1 MHz while providing a 475MHz input bandwidth.  If that sample rate is still too fast, then the parallel output can be decimated.  In the worst case, a fast 8-bit external latch (3) and some clocking logic are necessary to capture the output from the fast ADC for the slow microcontroller to digest but these are just a minor addition to the external logic for the time to digital converter necessary for ETS operation.

(1) Microcontroller ADCs would also have too much sampling jitter limiting equivalent time performance.  An external track-and-hold solves this problem as well.

(2) A track-and-hold made from a diode sampling bridge can easily get into the 100 to 400 MHz range without being exotic and could feed a microcontroller ADC but it involves a lot more design work than the alternative discussed above.  This level of performance is not difficult once you consider a 25 ohm or lower source impedance driving just a couple picofarads through a diode bridge into a JFET or MOSFET gate.  Check out the Tektronix 2230 design for a 100 MHz example.

(3) Fast is relative and what is needed is well within the capability of modern easy to use logic families.  In the past this was only slightly difficult.

[daybyter]

http://www.stm32duino.com/viewtopic.php?t=107

Read this thread. Lots of info in it.

[FrankBuss]

http://www.stm32duino.com/viewtopic.php?t=107

Read this thread. Lots of info in it.

Not even 2 MHz. And I wouldn't like the solutions with the external sample and hold ICs, because this would make sense for repeating signals, only. You couldn't sample e.g. a one-shot high speed digital signal.

[daybyter]

You can get higher sampling rates by overclocking the stm32, it seems...