Building an oscilloscope

[colejohnson66]

I know this will be a project I'll probably never finish, but I've been wanting to build/design my own oscilloscope. I'll start off by saying that my experience with electronics is very limited; I've only used Arduinos and similar boards (Metro from Adafruit, ESP8266, etc.).

I have no designs yet because I want to get the hardware selection down first. I was thinking of using an FPGA that would handle the intake from the ADC(s) and save the bits into memory. Then the main processor (essentially a BeagleBone Black) would read data off the RAM and perform the bulk of the processing. I was initially thinking of using the PRUs in the BBB, but I'm not sure that would be a good idea because I'd like to avoid doing everything on the BBB.

I was thinking of using the BeagleBone Black (or possible a Raspberry Pi) because it would give me a full OS to build off. Then I could use something like Qt for the GUI instead of writing my own software stack. It seems other scopes use full operating systems as well, but I could be wrong.

As for the FPGA, I've never worked with them before, so I don't know how portable the code would be, but I was thinking of designing using a DE0-Nano which uses a Cyclone IV. I could also use the DE10-Nano (Cyclone V) if needed.

I'm not going for a budget design here; I'm wanting to do this for the learning experience: working with SBC besides the Arduino, programming an FPGA, learning circuit layout, etc.

Anyways, my question is this: Is my choice of hardware good enough for a, say, 10 to (maybe) 100 MS/s scope? (I'm still looking at what ADC to use)

[MosherIV]

Hi

Then the main processor (essentially a BeagleBone Black) would read data off the RAM and perform the bulk of the processing

Most processor do not have the processing power to handle the data in real time. Have the FPGA do the real time data processing. Only use the processor to handle gui.

I have worked on system where real time data is overlaid into video memory and the main processor handles user interactions, draw the gui around the video overlay and configure the FPGA for data aquisition and display.

Personally I would avoid Linux for this kind of thing. There is a reason why commercial scopes use Windows for their GUI ! It is partly to do with licensing, a lot more to do with development tools. Commercially, there is better support for Windows based tools for FPGAs and embedded software development. Many on this forum will dissagree, but that is because they are thinking about hobby use.
I do this kind of thing for a living, I would not waste my/company time on freeware tools (it wastes a lot of time !) However, commercial tools may be out of reach for most hobbiests.

You have already realised that the FPGA needs to grab real time ADC readings and route that into memory. It also needs to handle timing, how often to grab data and put it into video overlay RAM. Do this at the right rate and you have sort of got your time base working. It therefore must generate the right RAM addressing.
The FPGA will also have to do the trigger.

I am not sure what platform will work best for you. I do not think bbb or rasberry pi will work. You need something which will give the FPGA shared access to large amount of RAM, the video RAM so that you can overlay the captured data. I do not know of any off the shelf dev board that allows this.

The other part is the analogue front end. You need analogue circuit with bandwith of 100MHz if I understand your requirement. This front end  needs to amplifiy and attenuate the input signal. It also needs to interface to osilloscope probes.

[james_s]

What are you talking about? The big FPGA dev environments are native Linux software that has been ported to Windows, it works fine in either.

What on earth does that have to do with the OS running on the scope itself? Why anyone would want an oscilloscope to run Windows is beyond me. I've seen scopes that ran WinXP embedded but I'm pretty sure most of them now are on embedded Linux or some sort of realtime OS. Windows embedded is pretty much dead.

[tggzzz]

Work out what you might be able to achieve, and equally importantly not achieve.

Implement it.

Work out what you would do better/differently next time.
Work out the next steps for an improved device.

You will make many mistakes - but that really doesn't matter!

It will look good on your CV.

[rstofer]

Start by reading all the design info on the Digilent Analog Discovery 2.  It uses a combination of an FPGA and USB to the PC for graphics.  Now try to download and install the Waveforms software on a Raspberry Pi.  The Pi 4.0 supports USB 3.0 so it should work out pretty well.

Or, look at the sound card oscilloscope software.  No real electronics required but very limited bandwidth and voltages.

[NiHaoMike]

Personally I would avoid Linux for this kind of thing. There is a reason why commercial scopes use Windows for their GUI ! It is partly to do with licensing, a lot more to do with development tools. Commercially, there is better support for Windows based tools for FPGAs and embedded software development. Many on this forum will dissagree, but that is because they are thinking about hobby use.

The only scopes I have seen running Windows are the really high end ones with a bandwidth of many GHz. The lower end ones commonly used by hobbyists are more likely to run Linux or some sort of RTOS.

[TomS_]

What are you talking about? The big FPGA dev environments are native Linux software that has been ported to Windows, it works fine in either.

What on earth does that have to do with the OS running on the scope itself? Why anyone would want an oscilloscope to run Windows is beyond me. I've seen scopes that ran WinXP embedded but I'm pretty sure most of them now are on embedded Linux or some sort of realtime OS. Windows embedded is pretty much dead.

Ahem. Pretty much any Keysight oscilloscope, even their bench multimeters run Windows embedded.

[Someone]

What are you talking about? The big FPGA dev environments are native Linux software that has been ported to Windows, it works fine in either.

What on earth does that have to do with the OS running on the scope itself? Why anyone would want an oscilloscope to run Windows is beyond me. I've seen scopes that ran WinXP embedded but I'm pretty sure most of them now are on embedded Linux or some sort of realtime OS. Windows embedded is pretty much dead.

Ahem. Pretty much any Keysight oscilloscope, even their bench multimeters run Windows embedded.

Yes, an example of an embedded RTOS:
https://en.wikipedia.org/wiki/Windows_Embedded_Compact

[thinkfat]

Guys, what does the choice of operating system to run on the scope have to do with anything? If you start from scratch, you start with what you're most familiar with, because it'll get you to being productive much faster. It's plain nonsense to limit yourself with arguments like "I've seen vendor X use that OS, so it must be a superior choice".

[maginnovision]

What are you talking about? The big FPGA dev environments are native Linux software that has been ported to Windows, it works fine in either.

What on earth does that have to do with the OS running on the scope itself? Why anyone would want an oscilloscope to run Windows is beyond me. I've seen scopes that ran WinXP embedded but I'm pretty sure most of them now are on embedded Linux or some sort of realtime OS. Windows embedded is pretty much dead.

Ahem. Pretty much any Keysight oscilloscope, even their bench multimeters run Windows embedded.

The UXR run windows 10.

[thinkfat]

I was thinking of using the BeagleBone Black (or possible a Raspberry Pi) because it would give me a full OS to build off. Then I could use something like Qt for the GUI instead of writing my own software stack. It seems other scopes use full operating systems as well, but I could be wrong.

I suggest you start from a Xilinx Zynq-7000 platform. It's way more powerful than the BeagleBone Black and it brings an FPGA with it. Siglent have been using it as a platform for their entry-level oscilloscopes. You could still run a full OS on it, e.g. there's Xilinx own PetaLinux that should work nicely. You won't have the sizable BeagleBone or Raspberry community to jump in for help, but trust me, its mostly an IoT crowd nowadays and there's few EEs there who could help you with your project.

[ledtester]

Doesn't use an FPGA, but you still may want to look at this design for some ideas:

https://hackaday.com/2017/11/18/ds212-oscilloscope-review-open-source-and-great-for-hacking/

Firmware with English comments:

https://github.com/kortschak/ds212/

[colejohnson66]

I considered the DS212 as a starting point, but it’s too “slow” compared to what I want. 1 MS/s is two orders of magnitude slower than what I want. Even with a 1 GHz processor, to do it all through the CPU, I’d only have 10 (20 for some RISCs?) cycles to read in 8 bits of data and save it to RAM. I’d then have no processor time to draw the GUI unless I use a dual core processor. But a dual core has downsides with shared RAM (delays when accessing RAM “owned” by the other core, etc.).

As for an update: I think I’m settled on the AD9288-100 for the ADC. It’s ~$23 for dual inputs with 8-bit 100 MS/s output.

Re: the BeagleBone, it seems people have mixed opinions, but for its price and its features, I can’t find anything with as big a community that presents a compelling reason to switch. While yes, the community is more IOT focused now, there’s thousands (or more) of articles about how to take advantage of, or “hack,” it. I’m still open to ideas though.

I’m still unsure of what FPGA I should use. I’m also confused on how I would implement external RAM used by the FPGA and accessible by the CPU. Should I make the BeagleBone access RAM through the FPGA using an “interrupt” like feature? Or should I do something else? I wasn’t around decades ago when 80s computers had to share RAM between the CPU and the “GPU”, so I don’t know how that was implemented. Any tips on that would be appreciated. I did find this SO question on external SRAM DMA, but there’s no answers.

For the software stack, I’m a C# guy, so I’d love to use that for the GUI (but I’m fine using C for the PRUs if need be). I saw a blog post of someone getting Windows Embedded/IOT running on the BeagleBone, but from what I’ve read, the BeagleBone uses a nonstandard ARM core that’s not compatible with Windows IOT. I know this isn’t really the place, but any suggestions on a cross platform GUI would be nice. I’m currently looking at Mono plus Eto.Forms (which uses Gtk# under the hood) running on some tiny Linux distro (maybe Arch?), but I’m open to ideas.

[thinkfat]

Well, I think you need to be clear about the system design first and then you can see if your preferred platform matches with what you want to achieve.

Also, I think your choice of GUI toolkit and highlevel programming language is of secondary importance. You want to create a serious test instrument, that means you need to solve the aspect of data acquisition first. This is your primary problem. If you end up coding the GUI in C# or Python is not an important design question. It's as arbitrary as can be.You need to get the hardware done right, this is an aspect that cannot easily be changed later on.

A possible system design could be to have an FPGA handling the data acquisition autonomously. You would connect some memory to it and the ADC and then provide some control interface for the application processor to read the data for display. You don't want to share memory cycles between CPU and FPGA, seriously, no. The interface to the application processor would only need to fast enough for your projected waveform display rate. Gut feeling, 60 waveform updates per second will be a stretch goal with the BeagleBone already. Also, the acquisition memory doesn't need to be random accessible. You can implement a FIFO-style interface. You'll just need a pointer to the location of the trigger event.

You m ight want to think about selectable memory depth, too.

You see, there's such a lot of thought to be put into the system design that the question of which GUI toolkit to use will be almost an afterthought, and you haven't even started thinking about the analog frontend!

[MosherIV]

Good reply Thinkfat.

Does the bbb have a video output? I saw one diagram with something about HDMI.

What are all the connectors pins for?
Does it have direct access to the RAM on the bbb?

As I said before, what you want to aim for to grab data straight into the display buffer.
Alternatively, grab data into another block of RAM, then dma the data you want to display into the RAM area being used for display.

Does the bbb have dma into memory or have control signals on RAM and micro for the FPGA to take control of the RAM and do the dma?

If not, the bbb may not be the best platform to use.

I worked on a project where the FPGA managed the video RAM. The fpga did the data capture and scaled the data directly into the display RAM. The fpga read the ADC and clocked the data into the RAM, generating the correct RAM addresses.
The fpga gave access to the micro to draw the grid, control buttons etc in the display RAM.
The FPGA would manage the timing to give access to the RAM for the micro.
The FPGA also generated the video out. This way the micro did not have to be very fast, the bulk of the work was done in the FPGA.

[jhpadjustable]

Just so we aren't underestimating what we're working with, the TI AM3358's product page.

The AM3358, like many popular Android-adjacent SoCs, has got some pretty strong display hardware for its age, and unlike Android SoCs, it has two real-time coprocessors similar to a Propeller COG. For example, imagine the plot area as an OpenGL textured polygon or as a video overlay, the external DMA ports or a PRU accepting data from the FPGA/FIFO, and the PRUs and/or shaders drawing the plot to some own block of display memory, to be composited/rendered with the UI layer by hardware, or maybe just drawn into the framebuffer.

It's worth looking at FOSS prior art as long as you don't look at the code.

[ADLab]

hi all,

There is a web-based oscilloscope built on beaglebone black and Spartan 6 FPGA.
It can be accessed via LAN or Wi-Fi. The DSO part has 8 bits, 250 MS/s, 100 MHz bandwidth, dual channels.
here is the link:

[David Hess]

What you suggest is certainly feasible.  I suggest studying the last generation of DSOs which were fully documented like the Tektronix 2232.  This will provide information on both the analog and digital side of what is required.

[tggzzz]

The OP might want to look at the Red Pitaya, a sort-of-open oscilloscope based around a Zynq FPGA/ARM SoC.

Googling for Zynq oscilloscope might also prove fruitful.

Do not underestimate the challenges of putting a Zynq on a PCB (i.e.use a premade module), nor the complexity of the toolset.

[Fishayyy]

hi all,

There is a web-based oscilloscope built on beaglebone black and Spartan 6 FPGA.
It can be accessed via LAN or Wi-Fi. The DSO part has 8 bits, 250 MS/s, 100 MHz bandwidth, dual channels.
here is the link:

Were you ever able to make any considerable progress on this project? I'm looking into something similar for my company, but it seems like a lot of engineers that answered on this post advise against using the BBB and Linux whereas this Hackaday project seems to have done a lot with just the BBB and an FPGA.

Here's a link to the full project write-up: [Web-based oscilloscope DIY using beaglebone black][ https://hackaday.io/project/171379-web-based-oscilloscope-diy-using-beaglebone-black]

[rstofer]

Read everything you can find about the Digilent Analog Discovery 2 - it isn't especially fast (30 MHz) but it works real well.

https://digilent.com/reference/test-and-measurement/analog-discovery-2/start?redirect=1

There's an Open Oscillocope project

https://www.eevblog.com/forum/testgear/a-high-performance-open-source-oscilloscope-development-log-future-ideas/

Considering the price of a 'real' scope, I wouldn't even consider such a project.  Just looking at that PCB makes my head spin.  My time is worth $<pick a number> and there's no way I could have it working in $349 worth.

[rstofer]

I wonder how far you could get with a 600 MHz Teensy 4.1.  No, it won't sample a single ADC at 1 GHz but it's still pretty quick and suitable for bare hardware programming.

https://www.pjrc.com/store/teensy41.html

[nigelwright7557]

I have designed a few low cost USB PC scopes.
From systems with A2D inside  PIC microcontroller to a PIC microcontroller with external 20MHZ A2D.
The beauty of the PIC is reading A2D and performing trigger modes before taking in data.

For the speed your looking at the FPGA is the only way to go I can think of.
Its not only just acquiring data but doing the trigger modes too, no trigger, positive going trigger and negative going trigger.
Your micro will look after USB interface.

The PC side is a project on its own having to deal with data acquisition via USB.
Resizing plots to fit the users screen. X shift. X + Y channel adding mode. Plot up and down shifting.
Coping with different voltage range inputs.

I also added a spectrum analyser screen. I had a struggle finding a FFT routine that worked well.
I think I tried 5 before I got one that gave acceptable results.