Favorite Logic Analyzer for Hobby Use

I am looking for a good basic logic analyzer for hobby use.

I am currently considering the Tektronix 1240/1241 series.

What is the opinion of the group?

Any suggestions or advice would be appreciated.

TMT

Reply to
Too_Many_Tools
Loading thread data ...

HP 1630G is a nice unit if you don't need to go over ~25MHz IIRC. Make sure you get the pods and all the leads (and clips, if you can). A set of new clips alone will cost more than the used unit.

Richard

Reply to
Richard H.

The logic analyzer you need for your hobby depends on what your hobby is. Back in the old days, you could hook up a logic analyzer to your TTL and see what was going on. Today, there's way more going on inside that chip than is visible on the outside. You can spend a lot on a logic analyzer and still not be able to learn much about what's going on.

So, disclosing more about your hobby would help. mike

--
Wanted, Serial cable for Dell Axim X5 PDA.
Return address is VALID but some sites block emails
 Click to see the full signature
Reply to
mike

The 1630G is a fine logic analyzer but finding the fly leads for the pods has become quite a challenge.

For the HP line you really should go for a 1650 or later model.

There seems to be a lot of 16500(A/B/C) mainframes available on ebay.

If you are going to buy from an auction make sure that a working analyzer is shown in the pictures with all the cables and fly leads.

All of the HP 165xxx and later analyzer pods require the fly leads or other input terminator networks.

Reply to
Keyser Soze

The 1630D/G the others mention is good. I have and use a Tek1241. I think you can get one on Ebay for about $150. The cables and clips seem to be readily available.

I paid $400 6 for mine 6 years ago. It came with a memory upgrade,

1 9-channel 100MHz card and 1 18-channel 50MHz card.

If you're looking at something smaller and/or mixed-signal, you should check out the BitScope

formatting link
There is also one tuned for BASIC Stamps from Parallax
formatting link
The Saelig company imports several small, logic analyzers and scopes
formatting link

HTH, Noel

Reply to
Noel Henson

HP 1630 series (A/D/G) or 1631 (with built is scope) are workhorses, they power up quickly (without any floppy boot disk needed) easy to use and reliable, like others said, make sure they have the test clips, like this one

formatting link

Reply to
joep

I've never used a logic analyzer. Seems to me that in a fraction of the time it takes to learn how to use one, and set up all the connections, and acquire and analyze all the data, you could have solved the problem in the comfort of your office, sipping coffee, thinking over the logic design like you should have in the first place.

Logic analysis, like software debugging, usually just points out stuff that should have been obvious from the beginning. Both contribute to the hack-and-fiddle style of design.

John

Reply to
John Larkin
[snip]

"hack-and-fiddle"? Isn't that the subtitle of this group ?:-)

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
 Click to see the full signature
Reply to
Jim Thompson

For actual logic errors, I tend to agree with you. But timing and assembly errors can be very difficult to debug without a logic analyzer. A good analogy would be a doctor and a patient. The cause of many symptoms cannot be diagnosed without tests. I find a logic analyzer to be an indespensable tool during prototyping.

Noel

Reply to
Noel Henson

The more complex it it, the more it deserves careful design.

I use a background debug pod to test uP code. It plugs into the bdm header and lets you load/step/modify code. What it usually does is concentrate your attention on a section of code where you (I) made a dumb mistake. I always read over my code several times before I run it, so I find most of the bugs before it's ever run.

Most logic problems, including electrical glitches/crosstalk and such less-predictable stuff, can be found with an oscilloscope.

A lot of engineers and programmers spend 20% of their time designing and 80% debugging. That's clearly inefficient and sloppy design, and they usually declare victory when *most* of the bugs are eliminated. Fancy analysis tools may be fun to play with, but they encourage design-by-test instead of design-by-design.

The harder it is to debug, the more careful people are in the initial design. VLSI chips and moon rockets are examples.

So, what did the 8051 problem turn out to be?

John

Reply to
John Larkin

Hardware failures, as in fried chips, are usually obvious from simple electrical behavior; a DVM and a scope are usually all you need here, or just have manufacturing replace the chip if it's in doubt. Why should I spend days of my time with a logic analyzer testing a suspect standard chip when I can have it replaced in a half hour?

Beside, admit it: 95% of the time the problem is a dumb design error, right in front of your face, not a bad part. I *can* find dumb design errors sipping coffee and thinking.

John

Reply to
John Larkin

If you want new look at DigiView from Tech-tools.

formatting link

$500 with 18 channels, software runs on a PC via USB. We use it all the time and it works very well.

--
Scott
Validated Software Corp.
Reply to
Not Really Me

You can make your own by grinding off the locking ridge from Molex .156" shrouds.

If you have the bench space, a 16500 with scope cards and a fast analyzer card is a great and cheap tool.

Reply to
Jim Stewart

You're a better engineer than me.

I don't believe in the hack-and-fiddle style of design either. On the other hand, about twice a year the logic analyzer saves my ass and shows me why I've been banging my head against the wall for a couple of days.

Reply to
Jim Stewart

[snip]

I always find it helpful to have a "disinterested" person take a look. For some reason designers always overlook their own mistakes ;-)

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
 Click to see the full signature
Reply to
Jim Thompson

Thanks for the suggestions so far....

In your opinion, is it better to buy an older logic analyzer or to get a new one?

I mentioned the Tektronix 1240/1241 series because I had used one many years ago and was impressed.

As for using or not using a logic analyzer, more than once I have found designs to not behave as they should because of race conditions that were caused by out of spec vendor parts.

Logic analyzers are as important as an oscilloscope in my opinion.

TMT

Reply to
Too_Many_Tools

I tend to agree in general, but once in a multitasking application, events were lost very seldom and nothing was wrong in our code. The bug was in the RTOS we had bought and we were able to pinpoint the problem only with the help of an emulator. It happened that the kernel lost events in rare occasions and this was due to the fact that interrupts were not disabled at a critical time. Without an emulator it would have been impossible to find it. The problem was solved by patching the hexadecimal code.

Reply to
Lanarcam

I would agree BUT when did you last work for a manager who was happy when you weren't out in the lab testing and debugging?

The ugly little truth is that rarely are hardware design engineers given sufficient time to do 70-80% design up front so the later test and debug is minimized.

The uglier truth is that all schedules slip to the right and the software guys are even more squeezed when the hardware doesn't work.

I have worked both sides of the fence and the tools that software developers have still pale compared to the hardware design and testing suite. More than once as I have integrated hardware and software, I have used a hardware logic analyzer to discover a hardware design problem that should never have occurred and should have been caught early on. In my experience, most hardware designers expect to use the application software to "test" their hardware. In reality, utility software should have been developed independent of the application software to test the initial hardware platform but never is.

Meanwhile, the project misses deadlines and goes over budget...

TMT

Reply to
Too_Many_Tools

For simple problems, maybe. I take it that you don't approve of emulators or debuggers either?

I once had a problem that took *weeks* (at >80hrs per) to find. I pretty much knew what the problem was but couldn't prove it. Management wouldn't get me a logic analyzer so I had to "hack-and-fiddle" in on the problem with an 8051 emulator, while cycling power on a rather expensive mainframe (a customer's machine, no less). We ended up putting so many cycles on the system that the processor had to be replaced ($everal hundred thou$and). A logic analyzer would have cost maybe $10K, or maybe $1K to rent. Hey, that's what management wanted.

--
  Keith
Reply to
Keith Williams

This is true in principle, but only if everyone working on a project is infinitely smart, and all the APIs, tools, and libraries are bug-free and are described exactly correctly in the docs. For example, I have a massively multithreaded, clusterized electromagnetic simulator. It works great on a single machine (including SMP) but the clusterized version currently has some race condition in the TCP/IP sockets communication--it causes data corruption about 1 time in 5000. This is clearly pilot error, since it does similar but not identical things on Linux, Windows, and OS/2, with 3 different compilers. Just localizing where the problem occurs is hard even *with* a debugger.

My communications code is all logic-table driven, with clearly defined pre- and post-conditions, all resources shared by different threads are serialized, and so forth. It's nicely modular and object-oriented, so I can rip the TCP/IP comms code out and cram in local communications without recompiling most of it. I know roughly where the problem is occurring. I've gone over the logic N times in the way you suggest.

And I'm still probably going to have to re-code the whole receiver end.

Bugs are like sins--it's possible to avoid each individual one, but not possible to avoid all of them, every time.

Cheers,

Phil Hobbs

Reply to
Phil Hobbs

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.