Logic Analyzer Shootout
This is a smackdown cage match between my three logic analyzers, a vintage HP 1650A, cheap Open Workbench Logic Sniffer and tiny Saleae Logic. Who will win? Read on...
I've used each logic analyzer on a few projects. Without one, writing my Game Boy Camera driver software on three different MCUs would've taken way longer and most of my of I2C projects would've stalled out while troubleshooting. Writing my Propeller I2Cmaster object would've been orders of magnitude more difficult.
So, which Logic Analyzer is best? What are the strengths and weaknesses of each? Here's the summary first, followed by the full-on cage match comparison.
free to $200Where to Get:
huge, heavy case with CRTConstruction:
professional grade test equipmentTriggering:
2-stage, multi-edges + stateProtocol Decoding:
scroll wheel, keypad, buttonsOperating Systems:
built-in, no external computer
Mine was free, given to me at a robot club meeting. It's main advantage over modern logic analyzers below is the ridiculous number of ports. The machine is really noisy, cumbersome to use due to lack of a keyboard, and it's huge. I have to really clear off the workbench. Nevertheless, it is still cool and it works flawlessly because even a quarter-century after it was built, industrial grade test gear is typically quite solid and usable. It has complex 2-stage triggering with high, low, edge, rising-edge, and falling-edge.
It cannot do protocol analysis which is normally a big time saver. To get one of these running you may have to find and write your own 3.5" boot floppy with a proprietary filesystem, but that is a path well-trodden by other DIYers. You may also need to get "pod" cables and test clips which aren't cheap.
Despite the fact that I now two more modern logic analyzers I am still somehow unable to part with this dinosaur.
$150Where to Get: Adafruit
tiny machined aluminum caseConstruction:
high quality intended for professional useTriggering:
2-stage, 1 edge + stateProtocol Decoding:
all the regular stuffUser Interface:
computer clientOperating Systems:
Windows, Mac OS X, Linux
Saleae gave me one of these to review but I bought it from them. I will give you the straight story good and bad alike. The cost is high. The triggering is a bit limited. But this is one of those rare tools that just works, always, no matter what I do with it. When I'm frustrated with a problem the last thing I need is to also fight my tools, fight some weird serial driver problem on Linux, or who knows what else. The Logic just works.
I hadn't planned to get one but after using it to solve real problems, its value was apparent. Seeing how easily and quickly I could get at the problem--how transparent the tool was, never getting in my way, I decided to buy the demo I was given. I would have given it back, otherwise.
The client software is fully cross-platform. This tool has operated flawlessly on Linux for me for several weeks and a handful of projects. I've played with it on Windows and Mac, no problem. The software is intuitive, minimalist, but powerful.
Triggering is 2-stage assuming a single edge combined with high/low states on the other pins. It has been sufficient for what I've been doing, so far. There's only 8 inputs which is probably enough but I may run up against that limit and the Logic 16 is even more expensive.
Open Workbench Logic Sniffer
|Picture from Sparkfun.com
$50-62Where to Get: Seeed StudioPorts:
32, 16 normal useForm Factor:
moderate sized bare circuit boardConstruction:
hacker style, not productizedTriggering:
4-stage, no edgesProtocol Decoding:
all the regular stuffUser Interface:
computer clientOperating Systems:
Windows, Mac OS X, Linux
Having 16 ports is nice just in case, for complex projects like cameras. The board is just bare which saves money I guess, or you can buy a case. There are two clients, the SUMP client
and an alternative OLS client
. I've been using the latter. The 4-stage triggering sounds like a lot but edge detection takes up two states. Still, it's powerful. The OLS alternate client is fully cross-platform. I find the software somewhat frustrating to use.
Ready to Rumble
Here's the blow-by-blow of the death-match between the three. Here's what I looked at.Usability:
If you've spent any time being frustrated at a bug while troubleshooting, you already know that efficiency and intuitiveness are gold because wasting time on the interface or fighting your tool adds to your frustration and takes time away from your troubleshooting. You need a zero-hassle tool you can trust, that you can just pick up and use to find the problem, like, now.Capture:
How many transitions can be captured and the rate of capture are both important to troubleshooting particularly if your circuit infrequently bursts fasts protocols, such as reading 8 bytes of 400kHz I2C data every second. Ideally, being able to capture a long period of time with lots of samples means you can find the problem quickly, without creating intricate triggers or rewriting your code for testing.Protocol Decode:
Working with I2C, etc., and manually decoding it, you know that easy, fluid protocol analysis is a huge time saver.Triggering:
Triggering is critical to finding the specific error state you're trying to fix.Portability:
if you do any troubleshooting in the field (like at the Sparkfun AVC
) having a giant device to lug along sucks. Having a bare PCB that is easily damaged isn't such a great thing, either.Value:
if it costs a lot it damn well better be worth that in spades. Even then maybe a cheaper option is good enough.
The HP, after it takes a couple minutes to boot, requires you to use the scroll wheel and keypad to tediously configure which POD you're using, configure the sample rate and time, traversing a few 'screens'. Eventually you get it configured, you enjoy single-button capture and easy scroll. Lack of a keyboard sucks and slows down most operations. It's not bad, but it's not great. From a hardware side of things, the two types of probe clips I got are both genuine HP and industrial grade, high quality stuff. You can interchange them on the POD cable which itself is also genuine HP, costs quite a lot, and is of excellent quality.OWLS:
Start the GUI, plug in the board, click capture, configure the serial port on the first tab, then configure the acquisition settings. You're limited to 24kB of memory which isn't much so you must play around with the acquisition sampling rate to get a capture. Instead of troubleshooting.
When you're trying to fix a problem niggling UI details get really annoying and over many fix-capture-diagnose cycles can slow you down. You can re-run the capture if the settings are ok with no extraneous dialog. Good. If not, you click start capture, a dialog opens which doesn't remember what tab you left off on, so when tuning the sample rate or triggering, it is yet another annoying step to find the right tab, change the options, and try again.
If you forget to configure the port, it breaks. (So configure the port, you say... well, I don't have to on the HP or the Saleae).
|I am pretty good at breaking things
Another example of a niggling issue is that the tool generates error dialogs if the protocol decode doesn't work right. Instead of simply showing me what it knows and letting me use the tool and my brain to do the diagnosis. As mentioned, protocol decode must be run after every Start Capture, which really, really sucks.
|Error boxes are like user punishment. Why are we punishing the user?|
It's a small point, but the probes bought from Seeed for the OWLS are low grade, rather thick, permanently attached, operate rather roughly, and have wire exits right where you thumb is supposed to go. They're usable but ultimately they suck compared to the Saleae and HP probes. It's one more straw to put on the camel's back.
With the Saleae you fire up the GUI, plug in the device--it automatically detects it--and connect the probes, click Start, and get useful data back. Your friends with HP and OWLS are still dinking around trying to get something working.
My first thought after actually trying to debug an I2C problem the first time using this tool: Wow. That was ridiculously easy. I expected to have to mess around with some things, figure out why I broke something. Instead I was immediately solving my problem.
Oh sure, maybe you have to click on the trigger buttons or select different sample memory or rate, but all that's on the main window a click away. No extraneous dialog boxes appear. You might see the capture dialog the first time only.
Analysis is a matter of intuitive mouse movements. Protocol decode is configured once and stays enabled for every subsequent capture so you can focus on finding and fixing the problem, rapidly iterating through many fix-capture-diagnose cycles.
In short, the UI is fast, fluid, streamlined, easy, transparent. I hardly think about using the tool, it's second nature to just use it to find the problem and move on. That's precisely how diagnostic tools should be.
My superpower is breaking software without trying but this time it took many, many hours and numerous projects without a single failure or issue, until I finally
was able to generate error dialogs. That is very unusual for me. And the error dialogs weren't even the Saleae s fault. The cause? I was running a backup to a USB NTFS drive from Linux, hammering the USB bandwidth. I could get away with much faster capture and far more samples once the backup finished.
The probes clips are nearly identical to the HP clips. They are high quality, industrial grade stuff but without an HP logo. They are not permanently affixed, either. The probe wires are thick, very flexible, high quality, tending to stay where you put them. They plug into the probe clips on the side so they don't get in the way of your thumb. Another high quality detail that adds to the value.
The device has a selection to capture at up to 200MHz. Unfortunately, the amount of capture memory, mentioned above, is limited to only 24kB, about 1.2 ms at 20MHz rate. This sucks compared to the other logic analyzers and it gets in the way of using the device. You can increase the sample time by lowering the rate, but to accurately capture timing, you can't go too low. In addition to having a hard time capturing all the samples you need, spending time tuning settings instead of troubleshooting is a downside. It's another example of how the software gets in the way instead of helping you.
Another annoyance: using my superpower, I found that checking the noise filter causes the capture to fail with a device not found error on Linux.
I never worried if the tool could take enough samples. One simply sets the time/div to between 10ns and 1000s and the sample period is set automatically.
|At Time/Div=20us, sample period is 800ns|
|At Time/Div=1ms, sample period is 40us|
Saleae Logic: I rarely have to think about memory limits or how much to capture. I was capturing a few million samples at 24MHz but there is a tradeoff between samples and rate. The UI permits you to select 10 billion samples at 24MHz but in practice it's unlikely the device can actually do this. Lower sample rates are required. At 24MHz it can capture 50M samples (2 seconds) no problem. Also worth noting is that rates below 2MHz generate an error dialog indicating proper analysis may not be possible.
|Sampling below 2MHz gives you this every time.|
|Too many samples, too fast a rate, or USB is overloaded|
HP 1650A: there is no protocol decode. Huge time-waster and big fail.
OWLS: You must open another dialog out of another menu to decode protocols for every single capture. It's usable, but not fluid. It gets in the way, in my experience with it. The actual decode isn't bad. It shows just enough. It's a bit hard to tell what is a start and what is a stop. That matters when you are writing an I2C driver for an ATtiny and for a Propeller like I was. When the starts and stops get mixed up can you tell instantly? No, you cannot.
|A bit hard to tell an I2C stop from a start.|
You set protocol decode once, then every subsequent capture decodes your protocol, saving you time and letting you focus on debugging rather than configuring the debugging tool. Also I find the I2C protocol decode easier to quickly decipher. You can quickly see that the green circles are starts and red squares, stops. Serial decode features an autobaud analysis that tells you what the real baud rate is. This feature was immensely helpful to me in troubleshooting a communication error I ran across. It's clever little details like these that make this tool so valuable to me.
Triggering is based on detecting any one rising or falling edge plus the state of any other pins. Multi-stage complex triggering isn't presently available. I've been happy with it so far and haven't needed anything more powerful, yet. Even decoding the somewhat complicated 7-signal Game Boy protocol is entirely doable because the signal sequence starts with an edge. To detect I2C Start, you click the SCL high button, and the SDA falling edge button. Just two mouse clicks. SPI would require detecting a falling edge on the SS line. A TTL serial start is a falling edge on TX.OWLS:
Triggering is relatively powerful, with 4 stages of triggering. But because it cannot trigger on edges, doing so requires two stages to detect pin transitions on any of the pins. That's still more powerful than Saleae Setting it up takes a bit of playing with but once you get it figured out using it isn't all that hard and it's worth it if you require it. I haven't, yet. For each stage you identify the bits of interest via the Mask, then you indicate the desired states via the Value. You can choose SIMPLE or COMPLEX for the Type. Complex is multi-stage and you can then select an action to either start the capture, or to pass on to the next Stage. To reliably detect I2C Start, use a complex trigger, select two channels in the mask, both high value, leave Start capture unchecked, go to the next trigger Stage tab, select the two channels in Mask and select SDA low and SCL high and check Start capture. That's considerably more cumbersome than the two mouse clicks required by Saleae.
HP brings two stage, multi-edge detection to the table. It can detect three possibilities: rising edge, falling edge, or any transition. It can do this for any one of its 80 pins, while also being able to detect static high/low states on any other pins. Full on smackdown.
I never verified but it may only be possible to trigger on a single POD at a time. In the picture below I'm triggering on POD1 with only 8 pins activated, but normally you'd see all 16.
|Note only have 8 of the 16 POD1 pins are enabled|
It's portable. Like a bag of bricks is portable. I don't need to drag a computer along with me, just a giant heavy box. Oh. Wait. Nevermind. Yeah, that's a fail.OWLS:
I can easily stick the raw, bare, uncovered board with its delicate, easily bent pin headers into my bag-o-tools along with sharp, heavy, and/or metallic things like pliers and DMMs. Because that's a great idea. Here's a nice case from Built-to-Spec costing just over $10.
I may have to get one of these.Saleae Logic:
It's tiny at about 1.75" (4.5 cm) square and 0.25" (1.0 cm) high, it's light. Having a machined aluminum case with protected, shrouded pin headers means I don't have to worry about hurting it if I threw the bare thing into a random tool bag. But I don't have to do that because it comes with a really nice Case Logic zipper case to store analyzer, probes, and USB cable is one more detail they've taken care of. I will be bringing this to the next AVC and other robotics competitions.
Mine was free, the cables and clips cost something like $50 for one pod and two sets of clips. I've seen asking prices on ebay range up to $400. Given other logic analyzers available, unless you need 80 channels, to me it doesn't seem worth it to spend more than, say $50-100, the cost of a similarly old analog oscilloscope. I just don't think the value is there compared to OWLS or Saleae.OWLS:
Cost is $50 at Seeed
plus $6 for each 8-pin probe/cable set up to $24 for 32 channels bringing the total to $74. You end up with a usable, but somewhat frustrating UI that gets in the way a lot. You could have a better life than this. On the other hand, I understand bare bones hobby budgets personally which is why I bought an OWLS originally.Saleae Logic:
Costs $150 from various sources, comes in a nice equipment-quality enclosure with a sturdy Case Logic case ($15 at Micro Center), high end USB cable, and industrial quality cables and probes. The software is truly outstanding, a study in high quality and streamlined design that balances power and minimalism very well. I don't have to configure serial ports; it just detects the device when plugged in and connects. I've spent $100 on a good, but old, analog Oscilloscope and $50 on a DMM. This tool is every bit as useful and transparent and in that context, $150 isn't that much to ask. Buying a Saleae Logic means you have a high quality diagnostic tool that will help you fix problems very rapidly. You trade money for saving time and reducing frustration over the device's lifetime.
Everyone has their own priorities. I get frustrated easily so I value streamlined software that works flawlessly with robust hardware. I don't have a lot of hobby time so I don't want to waste it on the tools. Doing so makes me really angry. I like quality tools and feel the job is easier and faster that way whether it's hand tools, power tools, or electronics diagnostic tools. But my hobby budget is also tight so I have to spend my money where it really matters.
The OWLS price is great. And it is certainly a usable tool even if it takes some getting used to. And the software and hardware are open source and I value that. And you could conceivably improve the UI yourself. The OWLS will no doubt get better over time.
All that said, I personally wished I'd spent my money on the Saleae first and saved $50 on the OWLS. I went ahead and bought the Saleae once I realized how good it was and how much it helped me in my many projects. I would've sent it back if it wasn't worth $150 to me. But that's me.
Hopefully reviewing some of the main points about all of these logic analyzers gives you a better idea of what you get and what you're getting into with each.
Syndicated 2013-09-24 16:00:00 (Updated 2013-09-24 17:09:50) from Michael Shimniok