The price leader is probably This is a 16- or 32-channel bare board sampling at up to 200MHz. Some very flexible triggering is built in and supported by the software clients, both the standard one and my work-in-progress at .
Check out the Intronix Logicport. I have used it and it works well. I don't own one however. The $390 price is a bit higher than I would like to pay. If it had one or two oscope channel inputs that would be the ticket! I'd also like to see it with a Linux driver, but they only support Windows.
The software supports a variety of serial protocols and includes the input "probe" meaning the ribbon cable. The grabbers are extra.
I've owned a Logicport for years and use it pretty much daily for commercial stuff at work as well as my own fiddle-farting around for hobby projects.
Must-haves, for me, include
- A wide input range (+/- 40 V) and adjustable trigger (+/- 6 V). That's needed to look at RS-232 "on the wire" and not after it has passed through the line receiver. I need it specifically to probe NTDS "A" traffic that runs strictly below the equipment ground reference (0 to -15V) with a -6 V threshold (conveniently), which is a fairly rare protocol but I'd stay far away from anything that could only handle, say, a 0-5V input range or that had a fixed trigger.
- Data compression, being able to run a fast sample clock to look at bursty data over long periods. With direct sampling, even a relatively slow 10 MHz sample rate fills a 1 MB buffer in only 0.1 seconds. Not very useful if one is simultaneously watching, say, 4800 baud serial traffic and high speed digital I/O. That said, having only 2K transitions per channel can occasionally be annoying. I'm astounded that they haven't yet come out with V2 hardware with deeper memory.
- The serial protocols are a nice-to-have until you're trying to decode a new manufacturer's data sheet and it's "Am I not sending the right stuff or is the other chip not happy for some reason?"
As with USB scopes, it is essential that all high speed processing is done on the device (such as triggering), since there is a severe bottleneck (the USB bus). Thus, only relatively short captured frames can be transferred later on to the host for post processing and display.
Fancy protocol decoding can well be done in the host, but first you must capture (in the device) a part of the data stream containing at least the high level frame (and some extra data) and transfer over USB to the host, where it can be decoded and displayed.
Works great. Back in the days before GA's were FP, we used to put a GAL20v8 on a proto board and program it as a complex trigger/qualification state machine. Easily created trigger sequences far beyond the capabilities of the logic analyzers of the day. But it was a bitch to reprogram with the tools of the day.