My goal is to make Pi based instruments, starting with an oscilloscope. So I read answers to

It seems possible to read analog inputs at very low sampling rates, but I wonder if I could reach mega samples-per-second rates. Continuous data acquisition would probably be hard, if it is possible at all, so I can do without it. Would Pi be under equipped for that? I want to observe waveforms on displays connected to Pi at first, and later on my mobile devices (while Pi transmits wireless data to them).

My experience with system-on-chips tells me that these systems may easily saturate on continuous I/O. Is this the case for Pi as well?

8 Answers 8


Let's have a high-level overview of what an oscilloscope has:

First we have the analog front-end. Here we have impedance-matching network for the probes (but the probes will have to have a capacitance matching part too), attenuation section (very important, so we don't overload the ADC or let high voltages in), triggering and connection to analog to digital converter. I won't talk too much about this, since I'm not too good with analog stuff, but the bottom line is: There's nothing we can do with Pi in this section.

Next we have the analog to digital converter part. You'll need at least one ADC for each channel. More can be used for higher sample rate. In traditional scope, the ADC is connected to an ASIC or a FPGA device. They are used because traditional computers aren't real-time enough (and don't confuse real-time with fast!) to process the data provided by the ADC. That data is then stored into RAM of some sort. Some devices will use static RAM, wile some other will use dynamic RAM. In general the SRAM approach is more traditional and seen in big-name manufacturers, while DRAM use seems to be the newer approach seen in the cheaper Chinese-designed units.

The amount of RAM and its speed will determine how many samples can be stored. Almost always the ADC will be 8-bit ADC, so for say one megasample we'll need 8 b times 100000 = 8 Mb or 1 MB of RAM. For one MSa/s, we'll need RAM which can work at that speeds. Today, that should be relatively easy to obtain. The FPGA usually drives the RAM directly and is responsible for storing data in it. It works by filling the sample memory while there's still empty room and then overwriting it when it's full. When there are multiple ADCs per channel, the FPGA will set them so that first starts sampling, then on the next clock second and so on. When they finish sampling, sample of the first ADC will be written into memory first, then second ADC's sample. This will make it look like the ADCs are sampling faster then they really are.

Next point in this section is that the samples should be equidistant in time. This is the main problem with use of PCs in oscilloscopes and the reason why FPGAs and ASICs are predominant. If some samples are late or early, then the image represented on screen will be incorrect.

In this part we see the first possible use of the Pi. If the sample rate is low enough, we might be able to drive the ADCs directly from the Pi and store their results in Pi's RAM. How fast we can go depends on the way the ADC is connected to the Pi and how Pi does its I/O. From what I've read, the highest speed of Pi's I^2C ports is 150 MHz (how easy that would be to achieve in GNU/Linux is another question) while the highest standardized speed is 5 MHz and for SPI the highest speed in Pi is 250 MHz. I'm not sure what is the highest standard speed of SPI, but I expect it to be somewhere in the 100 MHz range at the maximum.

So in theory we have more than enough speed on Pi to run an ADC in low MSa/s range. I have a feeling that the RAM speed won't be a problem here, but I don't have any data to back that up. If that is the case, then we'd have a major benefit over usual scopes: There would be very large amount of capture memory available. For example if we dedicate 32 MiB of RAM to the program for sample memory and we have two channels, that would leave us with 16 MiB for each channel or a bit more than 134 Mb or 134 megasamples per channel. That's something that even today many oscilloscopes don't have.

The downside is that we'd need heavy modifications to the operating system in order to be able to get accurate sampling here. I don't have any experience with real-time Linux, so I don' know how easy this would be.

Anyway, let's get to the next step. So we have a sampling system that's filling up the RAM. Next part is the trigger. Trigger is closely related to the screen refresh rate. What it basically does is finding an interesting sample and holding it in memory. When the scope triggers, it continues sampling after trigger until it has filled up the memory and then it sends it to be processed and displayed on screen. While the data is being processed, sampling system if often frozen and waiting for the data to be displayed. That is why low-end scopes have lower refresh rates while high-end scopes will have special high refresh rate displays and spend much less time waiting for the data to be displayed.

In this section there will often be another ASIC or FPGA that will do signal processing on the samples, any protocol decoding if the scope supports it and actually driving the display itself.

This is the part where from what I can see the Pi can really shine. It can drive a nice 1920x1080 display (while scopes are often in the sub 800x600 land) and can do protocol decoding very nicely. The only problem I can see would be speed and how processing would affect the hold-off time. If we go for a low refresh rate, then we can get a really good logic analyzer with it.

Finally a word about USB oscilloscopes and why USB is bad in general for this type of project: Traditional USB oscilloscope does input and sampling and sends the sampling data over to the PC for processing for which a host application exists. Basically something very similar would be done with Pi too. Usually the PC applications are badly designed and full of bugs. Next bad part is USB itself. It's advertized as fast bus which can do 480 Mb/s in "Hi-Speed" mode. The truth is that it's extremely rare to find a USB controller that can support such high speeds (the average seems to be around 250 Mb/s from what I've seen) and that it as a protocol isn't very suited for any real-time application. First it's shared among all devices on a hub (and Pi only has one USB port to which Ethernet+USB Hub is connected), has relatively high overhead (when compared to say SPI) and has high latency (remember that at 1 MSa/s each sample lasts for just 1 µs, so we must have memory on our board since we can't send samples in real-time over USB). Finally using USB would make the data acquisition part o the scope to be just another USB oscilloscope and that's where we loose any benefit of using Pi: Traditional desktop computers are much more common, faster, more easily obtained and have much better USB capabilities.

EDIT I've read a relatively recent post by Gert van Loo and according to him, realistic rates for Pi's I^2C are 400 kHz and for SPI are 20 MHz.

  • So what is the pinnacle of your answer? This is more like a wiki.
    – Piotr Kula
    Commented Jan 29, 2013 at 12:56
  • @ppumkin Yes, a question like this requires such answer.. Well there is no pinnacle. We haven't been provided enough information about the expected performance of the device we need so assuming that Pi will do acquisition, the bottom line would be yes, for low enough frequencies. If Pi won't do acquisition, then it's pointless to use Pi due to its bad USB performance.
    – AndrejaKo
    Commented Jan 29, 2013 at 16:00

We have found the Raspberry Pi to be an excellent platform for running the software you'd need for a project like this. The problem is getting the signals into the RPi in the first place and performing high speed jitter free real-time signal capture on the same CPU that's running the O/S and application software. Our solution is the BitScope Raspberry Pi Oscilloscope which pairs a BitScope (for high speed mixed signal waveform capture) with the Raspberry Pi which runs all the necessary software.

enter image description here

  • shameless plug =)
    – lenik
    Commented Sep 23, 2013 at 23:37
  • 2
    Thats awesome. But it has nothing to do with the answer! Or maybe it proves that the Pi is to weak to be an oscilloscope?
    – Piotr Kula
    Commented Sep 25, 2013 at 8:56
  • The Pi is not "too weak" but it does not have the I/O capability needed for (high speed) waveform acquisition. In the words of the original question, it's "under equipped for that" :-)
    – BitScope
    Commented Sep 25, 2013 at 12:57

N.B: This is more a 'thinking out loud' piece of text then a real Answer

The idea also crossed my mind some time ago, and I still like the general idea!

As far as I know, the high-end scopes are since 15 years (or even more) just computers (PC) with a bunch of specialized high speed I/O. I think that when similar I/O is designed/connected to the RPi, the result might be surprising good.

IMHO a good way to do this is to let the RPi just store and display the gathered data (received for example over the USB port) and let some specialized hardware do the high speed measuring. This high speed measuring unit can then also be controlled by the RPi based on user input or something similar.

In the first version on the RPi there were/are some problems with the USB ports, I have not searched lately if those are solved at the moment. I heard also a rumor that the new 2.0 version of the RPi should not have these problems, but I also have not checked this rumor.

I think the results without any external (specialized) hardware are limited because of the number of I/O ports and the fact that a whole OS is running on it (which limits the realtime options). Unless you're planning to write your own OS?

Also using for example I2C chips for this purpose will not have sufficient speed to do something really nice. SPI gives already a lot more bandwidth (upto 100Mhz from the top of my head), but I would go for USB and if needed compress, or use some good encoding scheme before sending the data, to gain more bandwidth.

So I guess it is possible, but the hardware that needs to be added to the RPi will be much more expensive then the RPi itself.

Last but not least (before I stop daydreaming about this subject) I would not be surprised if a search on internet would result in some group already busy doing this.


The answer is Yes.

It is powerful enough! But only for certain frequencies- As pointed out already because of the limitations.

SO! -> You have to ask your self what you want to measure?

  • Because you are not asking specifically what you want to measure the answers are open to speculation.
  • So let me introduce you to alternatives and suggestions. Maybe you can ask a new question that is more specific to the Raspberry and not general Oscillator topic!

Oscillators can range from simple low frequencies that cost 5USD, and then others can handle to 50Ghz+- that cost as much as a small house! 75,000USD-100,000USD!

I think the Raspberry will be good enough to measure sub Giga frequencies, like 433mhz wireless signals, low speed CPU bus communications, TTS/UART, I2C debugging- not much more really. And the higher frequencies will not be really accurate, as by design the Raspberry does not run realtime OS. So you will need to start with the OS (or as mentioned external realtime devices- But what is the point then? )

But if you really wanted to measure signals, then you can buy a really good and fairly priced device that is on par with the Raspberry specifications. But is already designed well, full of features, really mature in design and proved it self to be handy in a hobbyist environment.

There No need to re invent the wheel here. For example a DSO Nano for under 100USD single channel.

enter image description here

A DSO Nano Quad Channel for under 200USD

enter image description here

And then, what a Raspberry or similar device CANNOT DO!

And cost a small fortune ...

enter image description here

  • Upto 110Ghz, with hard drive to store data, extremely precise, simulations and triggers.
  • Measures Buuetooth, WCDMA/EDGE/3G/4G, Wireless A/B/G/N 2.4Ghz/5Ghz, SATA, AGP/PCI/PCI-Express, Raw Satellite signals, Hard drive head channels, Ethernet, etc, etc ...
  • 2
    I could make my RPi LOOK like the Rohde&Schwarz, would be a nifty, maybe somewhat over the hill, case mod :-)
    – ikku
    Commented Jan 29, 2013 at 12:56
  • LOL! That will be a sight for sore eyes :)
    – Piotr Kula
    Commented Jan 29, 2013 at 12:58

You could connect one of our TiePie engineering Handyscope HS5 oscilloscopes/arbitrary waveform generators to the USB port. A library compiled for the Raspberry Pi to use one or multiple oscilloscopes simultaneously is available for download. The instrument uses its own timing and memory, so there is no performance loss. So yes, the Pi is powerful enough for an oscilloscope project.

Handyscope HS5

Key specifications of the oscilloscope: 2 channels, 14 bit, 500 MS/s, 250 MHz bandwidth, 20 MS/s 14 bit continuous gap free streaming, 32 MS memory per channel, 1 ppm time base accuracy.

Key specifications of the Arbitrary Waveform Generator: 1 µHz to 30 MHz waveforms, 240 MS/s, 14 bit, 64 MS memory, -12 to 12 V output (24 Vpp), 1 ppm time base accuracy.

  • Hello. In the future please disclose your affiliation with the product you are advertising. Thank you.
    – user46
    Commented Jan 29, 2013 at 12:16
  • Bly me! Look at the prices! Looks like nice products though. Not in my budget range.
    – Piotr Kula
    Commented Jan 29, 2013 at 13:59
  • Was not aware of affiliation disclosure necessity. Changed text to indicate I am affiliated with TiePie engineering.
    – Marthein
    Commented Jan 30, 2013 at 10:12

Your best chance is to try if sigrok and it's frontend libsigrok can be compiled on Pi, and then buy some compatible oscilloscope hardware. That way you can grab signals up to 24 mega samples per second. With enough knowledge you can customize the software any way you want, including wireless transmittion to mobile devices.


Some one talking about Sigrok. I think the nearest way is using well documented CY7C68013A with driver EZ-USB FX2LP. On desktop PC it was not work with Weezy, but on Jessy it is work good. Here is the known limitation about 24 Msps. I thinking about another way, using camera interface. This interface could manage 2.1 mega pixel and 30 frame per sec, what mean it could transfer data to GPU with speed over 60 mega "samples" per second. Soounds more usefull then 20MHz SPI or USB.

  • These are digital interfaces, so this would not produce an oscilloscope unless you drive them with a high speed ADC's output. Most practical solutions sample orders of magnitude more quickly, but do not do so continuously - which is a better fit for usual problems. Commented Jan 27, 2015 at 17:44

If you don't mind being limited to audio frequencies, I use an inexpensive MCP3202 12-bit dual channel A/D converter to acquire on the pi with spidev, and pydatascope to display data passed over Ethernet via TCP socket. Pydatascope also acts as a spectrum analyzer!

I made relatively trivial changes to the pydatascope open source code to have dual channels, mostly because it was easy and not that I really needed it.

Post follow-ups or mail me directly if you have any questions, I'll be glad to help out.

  • You are using my copyrighted image without permission. Please remove the copyrighted image from your web site. Commented Jan 16, 2014 at 0:44
  • Thank you for your answer @James Philips. I removed the image from your answer. It is waiting to be reviewed. Note that I am not the one who added it. Can you provide your site's address which contains the image for those who are interested to see?
    – niw3
    Commented Jan 21, 2014 at 10:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.