Favorite Logic Analyzer for Hobby Use

I would favor a used Tek or Hp analyzer over say a new USB or parallel port PC based logic analyzer, its not easy to make a good logic analyzer, Tek and Hp have vast engineering experience behind them, and I wouldn't trust the no name PC based brands, I would always be second guessing myself (was that really what the circuit was doing or an artifact of the cheapo analyzer) and I wouldn't want to lug around a PC to use it.

I would highly recommend that if your familiar with the Tek 1240's and it fills your current needs then that should be your first choice. I have much experience with the HP's and I trust what I am seeing, so that's what I use.

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

Yes, the logic analyzer hater curiously admitted he never used one, like a Doctor never using a MRI, guess you don't miss what you never had

[snip]

Yep, that works, too... awwwwh shit ;-)

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC\'s and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
I love to cook with wine.      Sometimes I even put it in the food.

Sure, but complex problems, even with careful design tend to produce complex errors.

Same deal with logic analyzers. The parallel is obvious. ;-)

UNless the error only happens once a day. ...or maybe not.

I don't think that follows, any more than emulators do the same for software. Sloppy is just sloppy.

My day job happens to be processor verification. These things are designed fairly carefully, but simulation is still needed. Simulation tools are quite analogous to a logic analyzer.

The application was the hardware for entry, storage, and physical security of crypto keys. The CPU powered up driving noise (oscillating, actually) over the interface. Once in a great while the 8051 detected an illegal command sequence on the interface and ate the keys, as it was designed to do (detected tamper). The problem would have been easy to track down by stopping a logic analyzer on a detected error (easy to pick that branch point on the 8051) and look back at what caused the failure. Without the analyzer I had to track back through the executed code and infer what happened. Since it took roughly an hour to cycle the CPU[*] and the fault on the worst system happened perhaps one out of every

20 power cycles, it took time. Every step backtracking took another failing power cycle. [*] After we determined that the fault had nothing to do with the 8051 function, the OS, or any programs running on the CPU we found that we could shorten the time to just a reset, maybe five-ten minutes per cycle. It was still a lot of waiting around for something to happen.

--
  Keith

Sure. Same project a year or so earlier; I couldn't wake up the 8051 for beans. Nothing I did for weeks (other than a reset) worked. I was re-running my power calculations to see if I could get away without putting it to sleep at all. I was missing about 50% of the needed power. :-( Anyway, my manager asked if he could help. I said sure, gave him an hour dissertation on the problem, gave him a copy of the 8051 databook, and sent him on his way. The next morning he came in and the conversation went sorta:

Manager: "did you try...?".

Me: "Huh?" "What?" "Why?"

Manager: "It says here on page..."

Me: "Let me see that!" Aw, $#|+! "Wait, that's not what my databook says."

Yep, different versions of the databook with only one paragraph changed. Mine was the previous year's, with all my notes and dog-ears. Evidently, Intel had an oops in the interrupt logic, fixed in documentation.

--
  Keith

The LogicPort is probably the best home/hobby deal today. It's small enough to carry in a laptop bag, has 32 channels + 2 clock, and reasonable depth as it uses event stamping and not free-running recording. Connects to a PC via USB without needing an additional power supply. The software runs in demo mode if it doesn't detect an instrument so you can take it for something like a test drive.

Best price I've seen is here (where I bought mine)

They'll also throw in a cheap but serviceable DMM as a free promo (see the info at I've gotten a couple of them and while they're not Flukes, they're OK meters.

LogicPort homepage at

--
Rich Webb   Norfolk, VA

Really silly sport. You sit around under a tree most of the day drinking beer and telling lies, and if you're lucky (and rich) get two

15-minute rides up in a crowded plane and two 1-minute jumps down. Oh yeah, you get to repack your chute for comic relief.

I made two jumps. Second one, I rolled wrong and twisted both my ankles. Crappy 22-foot military canopies let you down hard! I had to crawl to the bathroom for two weeks. So now I ski, in nice hard shin-high plastic boots.

John

Wow.

You can diagnose hardware failures by sipping coffee and thinking?

You _are_ good.

--
Grant Edwards                   grante             Yow!  Yow! I threw up on
                                  at               my window!
                               visi.com

I'm thinking more of things that don't meet their timing specs or are just plain buggy and don't work the way the data sheet says.

I agree that looking that the code and thinking about it is often the best way to find software design problems. but I've dealt with enough buggy and broken hardware that I wouldn't want to entirely do without a good 4-channel DSO or a logic analyzer.

Not to mention trying to reverse engineer something...

--
Grant Edwards                   grante             Yow!  Yow!! "Janitor
                                  at               trapped in sewer uses ESP
                               visi.com            to find decayed burger"!!

It's not uncommon for hobbyists to be dealing with 'black boxes' at some points in the design - sensor modules, rf modules, salvaged controller boards and the like. Often datasheets aren't available or don't provide enough information. You can't analyse the logic on paper if you don't know exactly what it is. For that you need to characterise your 'black box'. A logic analyser can make this much easier.

Tim

--
Shares are your votes in a pigologocracy.

I read in sci.electronics.design that Grant Edwards wrote (in ) about 'Favorite Logic Analyzer for Hobby Use', on Mon, 10 Oct 2005:

You just think about where the smoke came from. Even if it IS rocket science.

--
Regards, John Woodgate, OOO - Own Opinions Only.
If everything has been designed, a god designed evolution by natural selection.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk

I am with John larkin on this one. Careful design, with plenty of fore-thought, and a decent highly modular structure will tend to lessen the need for use of a logic analyser. This applies to hardware logic as well as to microprocessor based logic. Once I am satisfied that my power rails behave themselves I rarely need even a scope. A simple logic probe coupled with the ability to have close control over the hardware during the problematic code segment suffices.

[%X]

Emulators, yes. Debuggers (as in a peice of extra equipment) no. That, though, is just a measure of how closely I can control the hardware with my Forth based set-up. However, rigorous review of the design should eliminate the majority of silly mistakes.

They should try switching those proportions around a bit. >70% design, 20% test and

stuff

is

a

is

are

I

end.

not

I hear you and agree with you. Have you tried explaining the code to someone else, in detail of course? When I was stuck on something like this in my past life as a programmer, I would often find the problem by painfully explaining the workings of the code to a coworker. They didn't really have to contribute anything useful to the one-sided conversation, just pretending to listen was often enough. During the course of explaining it all, the lights would often go on mid sentence.

I think John's point is that if the RTOS was designed properly in the first place you wouldn't have had that problem. Which is true. Unfortunately most of us live in the real world; with imperfect documentation, imperfect devices, imperfect software and imperfect selves. Eliminating those imperfections is the ideal, but while we're still trying to get there I think there will still be a healthy market for logic analysers and software debuggers. Even if the people who buy them use them only to find the other guy's mistake.

Tim

--
Shares are your votes in a pigologocracy.

If you're using somebody else's IP, and especially if you don't have the (fully commented) source code, then you are indeed in the analysis business. I understand that some of Microsoft's TCP/IP socket stuff is

*only* documented by the code itself.

That's why I like to program in assembly, bare metal, no RTOS, and do FPGAs as schematics. It's all there, in plain sight.

What do you do there? Seems like you'd need a multiport comm protocol analyzer.

But why are you doing this, and not designing optics? Computer systems stuff is an infinite source (frustration) / sink (time.)

John

John,

I agree that more effort should be put into the up-front design.

But if a processor / fpga has built-in debug facilities, you're effectively already using a logic analyzer (and a more powerful one at that, often with the ability to halt on instructions and register values, manipulate registers, etc.)

On low-end processors, these facilities don't exist. They often have the option of running in a sterile emulator (good for debugging logic problems), or running at full-speed on the real hardware with no debug port. That's where the external LA is a very handy tool - especially when that external controller chip isn't behaving quite as documented.

Richard

Then you have obviously never worked on a design where a particular chip had an undocumented 'feature'.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org

I tend to find 4 channel digital scope (TDS3014 or TDS2000 series) very good for checking logic timing such as SPI bus, CAN bus. It also very good for analogue signal of all sort.

Careful design and implementation is a key of successful design, otherwise we end up more time to diagnose circuit failure than designing it. We limited by resource and failure do tend to occurs.

HP1630 logic analyser is good model.

ant8

Not to quibble too much, but a debug monitor, BDM, or other means to single-step code isn't the same as a logic analyzer. A logic analyzer samples a running system broadside and stores history in a buffer for analysis; stopping a program and examining its state is a simpler process, and doesn't require another box and 80 connections to the target.

Most simple CPUs can run a debug monitor (well, maybe not train wrecks like the 8051) which is all you need to test and debug code. I wrote my own monitors for several CPUs, including the 6800, 6802, and 6803. Newer embedded CPUs have background debug ports, where you just connect a simple, cheap BDM pod to a small, few-pin header on the target board. Again, this isn't a logic analyzer.

My point was that most people, especially hobbyists, don't need a LA if they do careful design, which they should do anyhow. I've done hundreds of embedded systems, including designing one CPU with TTL, and never had to use a logic analyzer. When one of my guys has a nasty logic problem, we analyze it on a whiteboard, and ususlly find the problem in a half hour, often less.

True electrical problems can be found with a good oscilloscope.

Later today, I have to persuade a 24-bit serial ADC and a lot of mux stuff, and a lot of math code, to all play nice together, using a BDM pod and a dual-channel scope.

John