Building my own scope

[balnazzar]

Provided the computer can take the samples at a mean rate that is higher than the sampling rate, all is well.

Mh. Not promising.

[jasonRF]

Thanks. If I venture into it, that will be a very-very-long-term learning project, without expecting to get my actual working scope from it.

Yup.  And as others have said, if/when it is finally working, it will almost certainly not compete with a new scope that you could buy with the money you spend on it.

Going back to the beginning of the thread, I think it really is remarkable what $1000 can buy these days.  Exactly what you want might not be available, but that goes along with engineering in general.  Similarly, the exact parts you want for your scope project might not exist, or they may be unavailable (pretty likely these days) or too expensive for your project.  You find creative ways to overcome challenges using the parts and test gear that you have access to. 
 
jason

[gf]

A scope without a FPGA is certainly possible, but would not have a high sampling rate. Take a look at these little scopes made with a STM32103 MCU. Just 1MSa/s

The low-cost Hantek 6022BE uses an EZ-USB microcontroller to stream the ADC samples via USB2 to the PC. No FPGA involved. Sample rate is 48MSa/s, IIRC. Processing (incl. trigger) is done on the PC.

[pcprogrammer]

There is one thing that is overlooked in this talk about a scope without a FPGA, and that is DMA. (direct memory access) It is possible to do sustained capture with it, but to do triggering on the signal will still require the processor to do a lot of work. With microcontrollers it still would not bring the high sample rates. No idea about the speeds that can be obtained with a modern PC.

The cards of the company found by you, balnazzar (https://dev.alazartech.com/en/) also uses a FPGA and has lots of memory on the card to do the data capture.

As a starting point for learning take a look here: https://www.fpga4fun.com/digitalscope.html It starts with the basics.

Since you, balnazzar, did not comment on my last post it might be that you missed it. It provides lots of information you asked for. https://www.eevblog.com/forum/testgear/building-my-own-scope/msg4474414/#msg4474414

[alm]

There's always the possibility to do triggering in the analog domain using a fast comparator and timer. That would remove the need to do any real time calculations on the data.

[pcprogrammer]

True, but this means adding a DAC, and other logic to make it somewhat flexible to mimic like what can be done in software or a FPGA.

[alm]

Yes, absolutely. I'm not saying it's an elegant solution, but it could help towards making a somewhat usable scope while avoiding using an fpga.

[2N3055]

Yes, absolutely. I'm not saying it's an elegant solution, but it could help towards making a somewhat usable scope while avoiding using an fpga.

But you're missing the point.
A home made scope cannot be made to be better and cheaper than many ready made scopes on market.
So only reason why OP would choose to make a scope is a learning experience.

And if so, why he would learn how modern digital scope is NOT made..

A modern digital scope (all of them) have ADC /FPGA combination, minimum. Sometimes special ASICs to accelerate thing or provide some kind of real time capability that is too complicated or too fast for FPGA  They also have digital triggers implemented inside FPGA code as a part of acquisition engine. If they are USB scopes, then they have some sort of solution (also inside of FPGA or a separate CPU) to pump data to PC. Standalone scopes in addition to ADC/FPGA have their own CPU that runs GUI/analysis. Sometimes that CPU is inside FPGA (Zynq for instance). There are few nice scopes on market based on ADC(1 or 2) and Zync.

If he wants to learn sampling theory and DSP math, a sound card built in a PC and Octave (and hundreds of books) will provide lifelong fun and games..

[tggzzz]

Probably, but omit the FPGA and have a FIFO that isn't tied to a communication device

Cats? I know lots of ways to skin them 

and how exactly would you connect it to the computer ?

Sigh. Why do people choose to omit context relevant to their point? Here's what I was replying to...

isn't that exactly what the FPGA + USB fifo + OS device driver combo does ?

Don't use the "USB fifo" as part of the scope's functionality.

[balnazzar]

The low-cost Hantek 6022BE uses an EZ-USB microcontroller to stream the ADC samples via USB2 to the PC. No FPGA involved. Sample rate is 48MSa/s, IIRC. Processing (incl. trigger) is done on the PC.

If 48 MSa/s is the best one can do without FPGA, then FPGA is necessary.

[balnazzar]

There is one thing that is overlooked in this talk about a scope without a FPGA, and that is DMA. (direct memory access) It is possible to do sustained capture with it, but to do triggering on the signal will still require the processor to do a lot of work. With microcontrollers it still would not bring the high sample rates. No idea about the speeds that can be obtained with a modern PC.

The cards of the company found by you, balnazzar (https://dev.alazartech.com/en/) also uses a FPGA and has lots of memory on the card to do the data capture.

As a starting point for learning take a look here: https://www.fpga4fun.com/digitalscope.html It starts with the basics.

Since you, balnazzar, did not comment on my last post it might be that you missed it. It provides lots of information you asked for. https://www.eevblog.com/forum/testgear/building-my-own-scope/msg4474414/#msg4474414

Thanks, quite informative. I indeed missed it, or I owuld have at least thanked you for it! 

Also I didn't catch that alazartech cards had a FPGA.. BAsically then, they are quasi-whole oscilloscopes, except they are directly inserted into the pcie slot rather than using usb or thunderbolt..
I thought they were just analog front end plus ADCs..

Once more, thanks.

[tggzzz]

The low-cost Hantek 6022BE uses an EZ-USB microcontroller to stream the ADC samples via USB2 to the PC. No FPGA involved. Sample rate is 48MSa/s, IIRC. Processing (incl. trigger) is done on the PC.

If 48 MSa/s is the best one can do without FPGA, then FPGA is necessary.

Not if you are only interested in audio signals

(But for audio you might to be very interested in the dynamic range and linearity, for which a decent sound card could be a good "front end + ADC".)

[gf]

The low-cost Hantek 6022BE uses an EZ-USB microcontroller to stream the ADC samples via USB2 to the PC. No FPGA involved. Sample rate is 48MSa/s, IIRC. Processing (incl. trigger) is done on the PC.

If 48 MSa/s is the best one can do without FPGA, then FPGA is necessary.

I think 48 MSa/s was chosen due to USB2 speed limit, and due to the EZ-USB FX2 clock frequency, from which the ADC clock is directly derived as well. In the mean time there also exist EZ-USB FX3 controllers for USB3. I guess they would enable a higher rate. Yet another limit is of course the processing speed of a PC.

[pcprogrammer]

High speed with 8 or more bits per sample results in high bit rates. 1 channel at 1 GSa/s for 8 bits per sample means 8Gbps, which is more then USB3 can handle.

Even for a FPGA it is fast unless paralleling is used. The ADC used in the Hantek DSO2000 series uses a multi phase clock to bring the speed down and spread it over 4 separate bytes into the FPGA. To write it into memory this is also needed. Clocks and data signals at higher rates bring a bucket load of problems that yo need to be aware of.

High speed FPGA design is also tricky. I'm learning about this at the moment and it is not like just slapping some gates together and you got something running. It requires timing constraints and tweaking to get a proper design.

For learning my advice is to stick to sample rates below 100Msa/s.

[Fungus]

There's always the possibility to do triggering in the analog domain using a fast comparator and timer. That would remove the need to do any real time calculations on the data.

A simple rising/falling edge trigger can probably be done on a PC in software.

Modern DSOs can do far more than that though. Take a look at the trigger menu of the average 'scope these days, there's runt pulses, zones, serial data... all stuff that needs an FPGA.

[rob77]

Probably, but omit the FPGA and have a FIFO that isn't tied to a communication device

Cats? I know lots of ways to skin them 

and how exactly would you connect it to the computer ?

Sigh. Why do people choose to omit context relevant to their point? Here's what I was replying to...

isn't that exactly what the FPGA + USB fifo + OS device driver combo does ?

Don't use the "USB fifo" as part of the scope's functionality.

it's pretty relevant i think.. if you propose a solution it must be something that can be implemented in real life..

if your proposed solution mentions  "computer will read the fifo" then please share your idea how... 
probably you didn't noticed that nowadays computers have only PCIe , USB, LPC , SPI, SMBUS I2C.... nothing else , have a look at the datasheets of the CPUs used in computers, for high speed it's PCIe and USB , for generic peripherals it's a superio chip connected through LPC , bios and sensors is SPI, i2c, smbus..... and it's like that for at least a decade...
there is no other way to interface a computer, and only the first 2 in the list are fast enough for data capture at reasonable rates for a scope.

[2N3055]

There's always the possibility to do triggering in the analog domain using a fast comparator and timer. That would remove the need to do any real time calculations on the data.

A simple rising/falling edge trigger can probably be done on a PC in software.

Modern DSOs can do far more than that though. Take a look at the trigger menu of the average 'scope these days, there's runt pulses, zones, serial data... all stuff that needs an FPGA.

At what sample rate you think that can be made? How much data can be synchronously transfered to PC per second without loosing a single bit....?

[tggzzz]

Probably, but omit the FPGA and have a FIFO that isn't tied to a communication device

Cats? I know lots of ways to skin them 

and how exactly would you connect it to the computer ?

Sigh. Why do people choose to omit context relevant to their point? Here's what I was replying to...

isn't that exactly what the FPGA + USB fifo + OS device driver combo does ?

Don't use the "USB fifo" as part of the scope's functionality.

it's pretty relevant i think.. if you propose a solution it must be something that can be implemented in real life..

if your proposed solution mentions  "computer will read the fifo" then please share your idea how... 
probably you didn't noticed that nowadays computers have only PCIe , USB, LPC , SPI, SMBUS I2C.... nothing else , have a look at the datasheets of the CPUs used in computers, for high speed it's PCIe and USB , for generic peripherals it's a superio chip connected through LPC , bios and sensors is SPI, i2c, smbus..... and it's like that for at least a decade...
there is no other way to interface a computer, and only the first 2 in the list are fast enough for data capture at reasonable rates for a scope.

I think there is a language problem here; I'm not sure what you are arguing against and for. I am guessing English isn't your first language.

You wrote "the FPGA + USB fifo + OS device driver combo" which could be parsed as "the (FPGA + USB) (fifo + OS device driver) combo" or  "the FPGA + (USB fifo) + (OS device driver) combo". Only the latter makes some sort of sense, so that is how I interpreted it.

Now a scope (of the type being discussed) will have a signal chain consisting of

• analogue front end
• ADC
• data capture FIFO controlled by an FPGA or by other means
• first level processing and control
• communications mechanism to and from...
• control and display GUI in a computer

The communications mechanism (5) could be over USB, Ethernet, SPI, UART, or even RFC1149 (or revision RFC2549). If you are using USB or Ethernet there will be one or more FIFOs in the comms mechanisms - as you noted.

But, unless you wish to grossly simplify the hardware and limit performance, the FIFO in (5) is separate to the FIFO in (2).

[Fungus]

At what sample rate you think that can be made?

If I'm programming it on a multi-core 3GHz CPU with SSE instructions? Quite high...

[rob77]

Probably, but omit the FPGA and have a FIFO that isn't tied to a communication device

Cats? I know lots of ways to skin them 

and how exactly would you connect it to the computer ?

Sigh. Why do people choose to omit context relevant to their point? Here's what I was replying to...

isn't that exactly what the FPGA + USB fifo + OS device driver combo does ?

Don't use the "USB fifo" as part of the scope's functionality.

it's pretty relevant i think.. if you propose a solution it must be something that can be implemented in real life..

if your proposed solution mentions  "computer will read the fifo" then please share your idea how... 
probably you didn't noticed that nowadays computers have only PCIe , USB, LPC , SPI, SMBUS I2C.... nothing else , have a look at the datasheets of the CPUs used in computers, for high speed it's PCIe and USB , for generic peripherals it's a superio chip connected through LPC , bios and sensors is SPI, i2c, smbus..... and it's like that for at least a decade...
there is no other way to interface a computer, and only the first 2 in the list are fast enough for data capture at reasonable rates for a scope.

I think there is a language problem here; I'm not sure what you are arguing against and for. I am guessing English isn't your first language.

You wrote "the FPGA + USB fifo + OS device driver combo" which could be parsed as "the (FPGA + USB) (fifo + OS device driver) combo" or  "the FPGA + (USB fifo) + (OS device driver) combo". Only the latter makes some sort of sense, so that is how I interpreted it.

Now a scope (of the type being discussed) will have a signal chain consisting of

• analogue front end
• ADC
• data capture FIFO controlled by an FPGA or by other means
• first level processing and control
• communications mechanism to and from...
• control and display GUI in a computer

The communications mechanism (5) could be over USB, Ethernet, SPI, UART, or even RFC1149 (or revision RFC2549). If you are using USB or Ethernet there will be one or more FIFOs in the comms mechanisms - as you noted.

But, unless you wish to grossly simplify the hardware and limit performance, the FIFO in (5) is separate to the FIFO in (2).

the whole point was to grossly simply the hardware and do all processing in software on the computer... i think it was pretty obvious from my posts.... same approach as you do with SDR - "simple" HW sending IQ data to the computer and gnuradio (or whatever else) doing the heavy lifting.

and regarding the interfaces, everything you listed boils down to the very interfaces the CPU has (serial through superio on LPC, MAC controller connected to PCIe for ethernet...etc...) , so to get lowest latency and highest throughput you need to use one of those interfaces the CPU has implemented directly... and that's  PCIe or USB.

[David Hess]

1. If I stick a PCIe frontend/ADC card into a desktop computer, can the computer do what the FPGA does in commercial scopes?

A PC processor has the performance to implement the decimation and triggering which the FPGA handles, but many high speed PCIe and USB digitizers cannot stream continuously at high sample rates.

2. Do USB scopes have a FPGA board inside??

Yes, USB scopes have an FPGA or equivalent for handling decimation and triggering.

Don't forget the analog front-end. You'll want a 1 MOhm in parallel with 10-25 pF or so input impedance to work with standard 10x probes, and some amplification and/or attenuation to extend the range beyond the native range of the ADC. Especially since you value low noise, which presumably means you want to look at low-level signals.

You also may want some input protection so you don't blow up your expensive ADCs.

Do not underestimate the finesse that goes into a high impedance input.  For high impedance attenuators, I would consider picking up a couple of the 4-pin hybrid attenuators Tektronix used in the 1970s.  Add a DPDT telecom relay and you have a switchable high impedance attenuator good to 100 or maybe 200 MHz.

Input noise is dominated by the high impedance buffer, typically an FET being used as a source follower, which is the noisiest part.

Well said. In the end, low noise amounts to a well-thought front end. I don't have the faintest about how to learn concocting good front ends.

The Tektronix Circuit Concepts books "Vertical Amplifier Circuits" and "Oscilloscope Probe Circuits" available here are a good place to start.

"Signal Conditioning in Oscilloscopes and the Spirit of Invention" by Steve Roach included in "The Art and Science of Analog Circuit Design" edited by Jim Williams discusses modern front end designs.

"Good Engineering and Fast Vertical Amplifiers" by John Addis in "Analog Circuit Design - Art, Science, Personalities" edited by Jim Williams would be useful for a discrete amplifier design.

Studying various Tektronix service manuals for their solid state oscilloscopes from the 1970s to 1980s will be helpful.  They include detailed theory sections describing every circuit.  The Tektronix 2230 and 2232 DSOs will be particularly helpful.  The 2230 implemented a sampling rate of 20 MHz with a TTL design.

A scope without a FPGA is certainly possible, but would not have a high sampling rate. Take a look at these little scopes made with a STM32103 MCU. Just 1MSa/s, but good as a basis to learn about how a scope works.

A low sampling rate sampling oscilloscope could be made for bandwidths above 1 GHz but that entails several other design disciplines and is less generally useful.

For higher sample rates without a FPGA you would need a more powerful processor and an external ADC. Don't have examples on this.

Last year I figured there should be standard interface ADCs and processors to allow for a high sample rate design without an FPGA or custom logic, and there are, but they are incredibly expensive.

[balnazzar]

or even RFC1149 (or revision RFC2549)

 

[balnazzar]

The Tektronix Circuit Concepts books "Vertical Amplifier Circuits" and "Oscilloscope Probe Circuits" available here are a good place to start.

"Signal Conditioning in Oscilloscopes and the Spirit of Invention" by Steve Roach included in "The Art and Science of Analog Circuit Design" edited by Jim Williams discusses modern front end designs.

"Good Engineering and Fast Vertical Amplifiers" by John Addis in "Analog Circuit Design - Art, Science, Personalities" edited by Jim Williams would be useful for a discrete amplifier design.

Studying various Tektronix service manuals for their solid state oscilloscopes from the 1970s to 1980s will be helpful.  They include detailed theory sections describing every circuit.  The Tektronix 2230 and 2232 DSOs will be particularly helpful.  The 2230 implemented a sampling rate of 20 MHz with a TTL design.

Thanks. You seem to be remarkably knowledgeable. Do you work in the field of oscilloscope manufacturing?

(P.S. the link to Tek literature contains a typo, but removing the trailing 'url' makes it work)

[py-bb]

It is also the question why. If you need a scope for your hobby it is easier and probably cheaper to just buy one. If it is a hobby to build one then nothing is stopping you to just try. It can be a lot of fun.

I'm motivated by two reasons, essentially:

1. I'm dissatisfied by commercial scopes within my financial reach (say 1 grand).

2. I think I'll learn a lot of things by building my own scope.

That said, I'm having difficulties finding the ADCs, primarily because I don't know exactly where to search, and apart from the main specs (e.g. resolution in bits, etc..), I don't know what to look for... Here is where I need advice.

Analogue ones are much much easier.

With digital ones the problem is that you need to have 1 amplifier (at least for each channel) and one thing sampling it (the ADC). This is because if you had 2 and switched between them (say taking it in turns) they'd be slightly different in gain and sampling. We often don't expect channels to be exactly the same so you can get away with it but still.

Say you want 1ghz bandwidth, you'd need to sample at at least 2ghz, this is where you run into problems, you can't just dump that into DRAM (you can get about ~100m/sec (100mhz) requests from DRAM, they're faster than this at sequential transfers once you've opened the page) - so you'll need to buffer there.

What you need are say ~20 things able to latch the digital reading in a round-robin fashion (this might be doable on the FPGA, but getting it onto it could be tough) - then you can read each at ~100mhz which is bordering on practical.


This is a demultiplexor and something the FPGA can be good at. Then you need to get this to a circular buffer in RAM. I'd also make it so you knew via software if say a "latch" hadn't been read and had to latch a new value (meaning you missed a sample)

That'll be the hard bit, the rest is software or the same as analogue scopes.

[pcprogrammer]

A low sampling rate sampling oscilloscope could be made for bandwidths above 1 GHz but that entails several other design disciplines and is less generally useful.

Correct. Take equivalent time sampling, but for that to work you need a reliable fine scaled delay, or more useful for spectrum analysis a heterodyne mixer to bring your signal down in frequency. But these require a lot of additional electronics to make it work.

https://en.wikipedia.org/wiki/Heterodyne

Last year I figured there should be standard interface ADCs and processors to allow for a high sample rate design without an FPGA or custom logic, and there are, but they are incredibly expensive.

You mean the FMC based systems?