I was reading USB scope probe - request for comments and ideas, and it got me thinking. What I'd really like is a very high performance oscilloscope, one which would cost $10000 or so. Surely many other people would like one too. And surely, with the expertise available on this site, it should be possible to design and open-source one.

Here's my idea:

  • It would be a hand-held 'scope probe with a USB lead coming out.
  • Battery operated to isolate it from USB power.
  • Input stage is a high speed op-amp, like THS3201DBVT?
  • ADC is something like ASD5010, which is 1 Gs/s and 650 MHz input bandwidth.
  • FPGA to handle the 32-bit data coming out, do the triggering, and package it into the USB.
  • Open-source software to run on the PC.

Is this a fool's errand? What am I missing?

Added, more details in response to the answers:

  • This 'scope would not be able to compete with the fancy expensive scopes out there. The main aim is to have something which would make it possible to examine high speed signals, while costing less than $200 for someone to make themselves.
  • USB bandwidth: This is not an analog scope, nor is it a fancy LeCroy. However, USB is quite capable of transfering 2k samples at 60 Hz. This still makes it extremely useful, even though it might not be capable of capturing transient events in between those frames.
  • A clear responsive display. Well, a PC's monitor is certainly clear. Better than almost all scopes on the market. So clarity and size are no problems. Responsive? As long as the screen can be updated at 60 Hz, I think that's pretty responsive.
  • Triggering: I was imagining simple level triggering happening on the device. Again, it would not be able to compete with fancy scopes, but remember: this is supposed to be a $200 device.
  • It's not supposed to have 1 GHz bandwidth. Where did I say that? But surely it could have more than 100 MHz bandwidth?

Take home points:

  • It's a $200 device.
  • The main aim of the device is to make it possible to see high speed signals without spending $10000.
  • There would be many things that it would be unable to do.
  • Surely something like this would be fairly useful to people here.
  • Surely, with the expertise available on this site, we could make it happen?
  • 1
    \$\begingroup\$ * A clear, responsive display * A trigger circuit capable of all the fancy trigger modes available in newer 'scopes * Memory \$\endgroup\$
    – The Photon
    Apr 4, 2012 at 23:27
  • 4
    \$\begingroup\$ The problem is that with an instrument you need to TRUST as much as possible what you read on the screen; otherwise, it generates only confusion \$\endgroup\$
    – clabacchio
    Apr 5, 2012 at 9:04
  • 3
    \$\begingroup\$ I have to agree with clabacchio, My Conar model 255 (solid State) analog scope, I don't trust the readings for voltage or time/cm, and has only led to more confusion and percussive debugging with a large heavy object. But I Like the Idea of building your own. \$\endgroup\$
    – jsolarski
    Apr 5, 2012 at 14:22
  • \$\begingroup\$ http://www.osciprime.com/ Ehh 8 Mhz theoretically? Fun has been had by some one else. I do love to read the "thinking", particularly by AngryEE. Though osciprime has some good ideas, mainly the network beta phase of their/his software "over the network data" I might make one for fun. Thanks, -Danny K \$\endgroup\$
    – user17819
    Jan 12, 2013 at 4:30
  • 1
    \$\begingroup\$ It's easy to say It won't work, and it's easy to find 100 ways it won't work. What's hard is finding a way it will work, even if that means changing the scope (of the proj, no pun intended) and or features, but I see what Rocketmagnet is getting at. as far as USB goes, AngryEE (whose name fits btw) has a point. However, eSATA gives you 6GBps theoretical, and USB 3.0 is 5.0Gbps theoretical. That's the best we have right now with going with a PCIx connection which will certainly give us the bandwidth we require (if it's good enough for a video card, I think it will do lol). \$\endgroup\$
    – MDMoore313
    Mar 14, 2013 at 15:27

5 Answers 5


This comes down to a question of bandwidth and latency. For a simple system let's assume one probe with 100 MHz bandwidth with 1GS/s sampling rate and an 10-bit A/D converter (I've had bad experiences with 8-bit scopes).

I want a real-time display on the PC with a minimum sampling window of let's say 10ns - 1 cycle of a 100MHz sine wave and a maximum window of (I'll be generous to you in this) half a second. In other words, the lowest time setting will be something like 1ns/div and the highest is .05s/div. I also want several voltage modes - 100mV range up to 20V let's say.

What kind of data rates does this involve?

1Gs/s * 10 bits/sample = 10Gbits/s

Those aren't USB speeds. Far from it. And I didn't even take overhead into account. First off, you just don't have the bandwidth. And it's not just bandwidth either. For your real-time display you need to be consistent. You need to transfer 100 bits to your application layer every 10 nano seconds. That kind of consistency can't be had from USB. It's not designed to cater to one device with extravagant demands - it's designed as a bus. And you can't control when you own the bus - the devices are just slaves. If the host lets another device talk when you need to send data, your data is lost.

You may be crying foul - why transfer real-time data to the computer when 'real-time' for a person is 60Hz? If all you need to do is update the display you certainly don't need that much data. Except you do - your display is some linear combination of all of the samples you've collected. Averaged, least-mean-square approximated, cubic spline interpolation - it doesn't matter. To make a nice pretty display that isn't just a bunch of dots, you need most to all of that data and you need to post process it. Any triggering? The calculations have to be done on the host - at the application layer. No matter what way you slice it, for real-time displays at 1GS/s rates for any accuracy worth a damn, you have to transfer orders of magnitude more data than USB can handle and you have to do it more reliably than you're guaranteed by USB.

What are the ways around this? Don't do a real-time display. Some USB scopes only offer triggered modes. The triggering is handled on the device and when a trigger is found, data is collected in a buffer. When the buffer fills, the USB scope slowly transfers it to the application and then the application displays it. That suffices for lot of scope use, but it's not real-time. And the transfer - that takes a while too. It's inconvenient. And usually the drivers suck. You can tell I've had bad experiences.

I've always wondered why Firewire wasn't used for scopes. It avoids some of the headaches of USB. It's peer-to-peer, offers isochronous (consistent timing) modes and is relatively high bandwidth. You might be able to make a 10MHz real-time scope or so with that.

To address your points after the edit:

  • The usability of a scope goes up tremendously with price. When you make the jump from a $200 USB scope to even a $500 standalone you get tremendous increases in features and basic functionality. Why spend just $200 when for a little bit more you can get a real scope? Now that China has opened up the floodgates of cheap, effective scopes, there's little reason to want to save $300 that will just frustrate you later. The 'fancy' scopes that have these features are cheap nowadays.

  • Yes, limiting your data transfer to only provide something around 60Hz-worth of consistent data will be easier with USB, but that's still not something you want to do. Don't forget about your DSP classes - only grabbing certain data from the stream amounts to decimation. When you decimate, you have to add antialiasing filters. When you do that, you lose bandwidth. This makes your scope less useful - it will limit your bandwidth on the real-time display (and only for real-time - triggered modes would be okay) to much less than the bandwidth of your analog front-end. Managing the signal processing aspects of an oscilloscope are tricky business.

  • Clear responsive display? The PC? Not consistently. Regardless of how you do this, you need to buffer data. As I said before, USB doesn't guarantee when your data gets through. I'll say it differently: USB is not designed to accommodate hard real-time data transfer. Sure, for sufficiently small amounts of data at large intervals you may get some good performance, but not consistent performance. You WILL use buffering and once in a while you WILL miss transferring your buffer in a timely manner. Then your display skips, data is stale, etc. etc. Clear and responsive real-time displays require hard real-time data links, period.

  • Simple triggering - again, we get back to cost vs. complexity vs. responsive. To do triggering on the device to detect transients your device can't just be a dumb data pipe that transfers samples irresponsibly over USB. You have to buffer, buffer, buffer samples on the device until you see your trigger condition. That means you need memory and intelligence on your device - either a large FPGA or a large microcontroller. That adds to size and space. If you use an FPGA you have to balance the amount of triggering logic with your need for lots of RAM for buffer space. So your buffer is smaller than you'd like it to be already. That means that you get a miniscule amount of data around your trigger point. Unless you add external memory - then you can do more. That increases the size and cost of your device though - this certainly won't be just a probe with a USB cable attached to it.

  • You'd be lucky to get 100MHz bandwidth - usually 10x the sampling rate is considered the minimum cutoff for bandwidth. So if you have 1GS/s sampling rate that barely gets you 100MHz bandwidth. You can't get more - a 200MHz square wave is going to look like a 200MHz sine wave. That sucks. That's dumb - it's nowhere near professional level.

Your other set of points:

  • $200? How do you figure? What's the parts list?
  • Good scopes to read high-speed signals do not cost thousands of dollars. They cost maybe A thousand dollars. 100MHz is child's play in the scope department and your idea won't even meet that benchmark as well as a $1000 scope
  • Yes, from the way you describe it it would be very limited indeed. The technical aspects of even the few requirements you have mean a very limited device.
  • It wouldn't be nearly as useful as the $1100 scope I bought with a logic analyzer and 60MHz analog bandwidth. I'd rather pay for my test equipment that dick around with intentionally-limited child's toys.

You live and die by your test equipment as an engineer. If you're not certain you can trust it you're wasting your time. Given the lack of expertise you've shown about high-speed communication, signal processing and the power of embedded processing (in FPGAs or microcontrollers) I wouldn't wager you're up to designing it yourself and no one else who's answered is anything other than ambivalent.

If there were a better-targeted set of requirements that hit upon a real need in the community that wasn't being served, that I could see being technically feasible I'd be on board. But your vague requirements don't seem researched. You need to do a survey of the available options out there for hobbyists - what USB scopes and standalones are people using, what are their strengths and weaknesses, and determine if any niches aren't being filled. Otherwise this is just fantasizing.

  • \$\begingroup\$ USB has isochronous transfers too. But yeah, you'd be limited to about 400MB/sec at best on USB 3.0 superspeed connection, which amounts to about 320M samples/sec at 10 bits/sample, assuming no compression, no triggering, and one channel. USB 3.1 doubles that limit. \$\endgroup\$
    – doug65536
    Apr 20, 2018 at 13:21
  • 1
    \$\begingroup\$ Sorry but I don't buy your argument. Even USB 2.0 offers plenty of bandwidth and low enough latency for a fluent display (check out USB webcams), and buffering a long enough signal inside the scope deals with with decimation. I know it's an answer from 2012 and USB scopes sucked back then, but the reason they sucked was not USB. The main reason was that they were not considered professional, so they had to be cheap, and were not build professionally as a result. \$\endgroup\$ Jan 28, 2019 at 8:00
  • 1
    \$\begingroup\$ Parts of this answer are outdated (USB 3.1 pushes 10Gbit/s, although of course that's not accounting for overhead) and parts of it were never valid. You absolutely can downsample and trigger on the peripheral in ways that don't reduce usefulness, if you're willing to put enough processing power there. It's not easy, and it's probably beyond one random person's ability, but there's no law of physics against it. \$\endgroup\$
    – hobbs
    Aug 4, 2019 at 5:28
  • 1
    \$\begingroup\$ What about just focusing on Thunderbolt 3 (Up to 40Gbps)? Even Thunderbolt 2 can support up to 20Gbps. Most older macs (2012 and later?) have Thunderbolt 2 ports. A lot of newer PCs have a Thunderbolt 3 port. Thought maybe it's more difficult to code/support drivers via Thunderbolt, I don't know. \$\endgroup\$
    – Ryan Weiss
    Oct 17, 2019 at 14:08
  • \$\begingroup\$ I don't get this answer. To have a real-time display you only need to be able to send enough pixels. The bandwidth for a 1920x1080p HDTV at 120Hz and 10bit data is about 2.5Gbps. Easily doable for USB3.0. All processing you do on the scope itself. Triggers you communicate back to the scope. \$\endgroup\$ Jul 2, 2021 at 11:01

You would not want it to be in a hand-held probe format, as a single channel scope is not very useful. The additional cost of 2 channels (even if you mux the ADC) is a small percentage additional cost, but a huge increase in usefulness.

Unless you are wanting to pull more than 500mA, no reason to use a battery as you could have an isolated DC-DC converter. However getting high bandwidth across an isolation barrier is nontrivial.


Well there are a couple of problems here. If we take as our reference standard a 1GHz analog scope (like a good Tektronix) then this proposed scope will suffer in the following ways:

1) the ASD5010 is an 8 bit converter. 8 bits is not nearly enough to be able to compete with a good analog scope.

2) Don't confuse sampling rate with analog bandwidth. For the chip you selected the equivalent analog bandwidth would probably be much closer to 100 MHz than 1 GHz.

This is not to say that it isn't possible to construct such a scope, one can clearly buy one meeting these specs commercially. It is just non trivial to achieve 1 GHz bandwidth, and special engineering and better parts would be required.

  • 8
    \$\begingroup\$ 8 bits is actually pretty typical for a digital oscilloscope, and it doesn't seem to limit Agilent, Tektronix, etc's ability to compete with any putative analog 'scopes that someone might have thought to put out on the market. \$\endgroup\$
    – The Photon
    Apr 4, 2012 at 23:30
  • 1
    \$\begingroup\$ Also, I'm not familiar with any 1 GHz analog scope. I wouldn't be surprised if they were built, maybe for very special applications (nuclear scientists or something), but I'd expect it to be a very rare beast to find in the wild. Prior to 1990 or so, 1 GHz was very rare in digital electronics (maybe in Cray supercomputers and things); after 1990 or so just about every new scope design from a top-tier vendor was digital. \$\endgroup\$
    – The Photon
    Apr 5, 2012 at 20:34
  • \$\begingroup\$ One commercially available 1 GHz analog scope is the Iwatsu TS_81000: testequipmentconnection.com/tecspecs/Iwatsu_TS-81000.PDF \$\endgroup\$
    – JonnyBoats
    Apr 5, 2012 at 22:04
  • 2
    \$\begingroup\$ Nice, your link led me to find the Tek 7104, a 1 GHz analog scope. Also good to know I'm not the only one who thought 1 GHz analog is pretty impressive. One website has "The Tektronix 7104 is the fastest analog oscilloscope ever produced. Originally designed in the 1970s for the US Atomic Energy Commission, it has a 1-GHz bandwidth ..." (readingjimwilliams.blogspot.com/2011/08/scope-sunday-4.html) So at least I wasn't too far off to say a 1 GHz analog scope would be a rare beast. \$\endgroup\$
    – The Photon
    Apr 5, 2012 at 23:11
  • 1
    \$\begingroup\$ Also the datasheet for the 7104 at testequipmentconnection.com shows a list price over $30k, probably in the mid-80s. \$\endgroup\$
    – The Photon
    Apr 5, 2012 at 23:13

8bit ADCs are pretty common in oscilloscopes, however the technique of using ADCs is a bit different. As I've seen some scopes internals, the common case is to use 4 ADC chips, each of them clocked with 90deg phase increment, so You get 4x samples per one clock cycle and that's why the clk freq is pretty low, but data bandwidth is high. Anyway, such project will end up in more money wasting than buying a brand new scope :-) However, it could be a good practice for self-learning. OTOH, think about analog side of the scope. That part is damn hard and very tricky to do.

  • 1
    \$\begingroup\$ That's exactly what the ASD5010 is. It's 4 ADCs in a single package. Each samples at 250MHz with a 90 degree phase difference. \$\endgroup\$ Apr 5, 2012 at 9:22
  • 1
    \$\begingroup\$ The question is not so much how hard it is, but whether such a scope would be useful, and if there are people here willing and able to solve those problems. \$\endgroup\$ Apr 5, 2012 at 9:23
  • 1
    \$\begingroup\$ Think about what has been achieved in the software domain by those communities. It's very hard to make an operating system, but look what they have achieved! \$\endgroup\$ Apr 5, 2012 at 9:25
  • \$\begingroup\$ It's NOT very hard to make an operating system - people do it all the time. \$\endgroup\$
    – AngryEE
    Apr 5, 2012 at 12:24
  • 1
    \$\begingroup\$ I may be mistaken, but I think that rather than using four ADCs, it's more common for scopes to use pipelined converters which have a number of stages, each with a sample-and-hold circuit. The first stage samples the input, the next stage identifies it as one of 32 levels, the next one subtracts out the previously identified and scales up the signal, and the next one identifies that as one of 32 levels. The two five-bit values obtained for a sample can then be put through a lookup table to yield an 8-bit reading (the 5-bit ADCs may be a little crummy, but the lookup table corrects for that). \$\endgroup\$
    – supercat
    Apr 5, 2012 at 16:09

Other issues:

  • protection: for sure you don't want it to break the fist time you erroneously put 20-30 V to the input;

  • calibration: even at 8-bit accuracy, you still have to control the error within 1/256 = 0.4% overall; not trivial with standard components;

  • noise filtering: it has to be shielded and filtered, and it's not enough because also the FPGA will likely generate noise, so you have to separate the analog and digital domain.

Anyway, about the USB connection, I think it's more functional to process internally the data, and connect it directly to the display.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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