Re: Logic Analyzer Recommendations

On Wed, 7 Oct 2009 10:26:37 -0700 (PDT), tomcee <tomcees_pc@xxxxxxxxx>


Would anyone care to share their opinions on these logic analyzers?:

They have limited capabilities, but are priced quite attractively.

My application is relatively slow speed and would like to analyze I2C,
RS232 and other parallel communications/buses.

A couple of points about these two gizmos:

1. Input voltage range is -0.5 to 5.25V (Saleae) or ?? to 5.5V (USBee).
The trigger is fixed at <0.8V (low) and >2V (high) (Saleae) or <0.8
(low) and >1.4V (high) (USBee).

The input ranges won't be happy with, for example, the RS-232 side of a
serial line without clamping the, e.g., +/- 10V swing to be within those
limits. Of course, that clamping has to be isolated from other serial
devices that may not be okay with a 0-5V "RS-232'ish" signal. One could
probe the logic-level side of the line driver if it's accessible or else
rig up a MAX232A clone on a breadboard to shift 232 levels back to logic

The fixed trigger voltage simplifies the design and lowers the cost but
may impose limits on flexibility. Some signals (e.g., CAN) may not cross
the trigger thresholds without, again, some external "help."

2. I haven't used either of these but from the blurbs on the referenced
web pages that note that the acquisition speed is limited by the USB bus
speed and bus loading, it looks like the timestamps are applied on the
PC side, not the device side. It communicates over a packetized bus
(USB), therefore the timestamps can be affected by other traffic on the
USB. If there are, say, a USB serial port and USB JTAG or ISP also on
the bus, then accurate time stamping will be ... problematic. Trying to
figure out how much jitter there is with an interrupt service routine?
Good luck.

USB logic analyzers can have a lot of bang for the buck (and I use mine
frequently). They tend to fall into two general classes: deep sample
memory or shallow + compressed sample memory. The deep memory devices
(typically around 1 Mbit per channel) force a tradeoff between precision
and total capture time. Sampling with a 0.1 usec precision can't run for
longer than 0.1 seconds. Is that a problem? Could be in some scenarios.

The compressed sampling devices tend to run a few Kbits per channel.
Compression does allow for long delays between events at quite high
precision. However, they can also be quickly exhausted if one of the
channels has a lot of high speed transitions. Getting long and precise
captures of neighboring signals would probably require dropping the very
active channel, which might not be ideal either. Life sucks ...

So, look at the front end and consider if it is wide enough and flexible
enough for your needs. They're probably great devices where their input
ranges and your problem domains intersect.

On the sample side, I would run away, fast, from any one that added the
timestamps on the PC side of a USB connection. I don't know that these
do, so maybe a current user can jump in here. On the question of deep
versus compressed memory, I personally go with compressed for the

Rich Webb Norfolk, VA