Let me say that I regard signature analysis as being a pretty useless diagnostic technique (second only to board-swapping?). Perhaps I should explain a bit... A signature anaylser is basically a shift register with XOR feedback, like a CRC generator/checker. The clock and 'start' / 'stop' signals come calculating the CRC of if it was a CRC generator) comes from the probe, and thus the point you want to know the signature of. The 'signature' is the data in the shfit register at the end. IIRC the HP anaylsers use a 16 bit shift register, the signature is 4 hex characters, but HP didn't use 'A' to 'F' but some odd letters. THey said this was to prevent them being misread on a 7 segment display, I am not convinced... I don;t know the XOR circuit used (==the CRC polynomial), but IIRC the service manual for at least one HP signature analyser is on the web (possibly on one of the video games repair sites). It uses simple TTL chips and a couple of ROMs (one as the control state machine, the other as the display decoder) so you should be able to deduce the polynomial if you want to. Anyway, as you know, the CRC of a stream of data is totally different for small changes in the data (unlike a simple parity check where an odd number of bit errors gives the same partiy bit). Of course with a 16 bit register there are only 65536 possible signature, which is less than the number of possible pulse trains you can analyse, so there's always a chance that an incorrect signal will have the right signature, but it's unlikely (much as it's unlikly a corrupted file or data stream will have the right CRC). THat is not the reason for my dislike of the technique. What I dislike is that while it'll tell you a signal is wrong, it doesn't tell you how it's wrong. Suppose you have a subcircuit with 2 inputs an an output (maybe just a simple gate). If that's part of a complex malfunctioning system, then perhaps all 3 signatures (2 inputs and output) are wrong. But what you don't know (and can't easily work out) is whether the signature you see for the output is the correct one for the 2 input signals (given their signatures). So you don;t know if this cirucit is working correctly (and the fault is elsewhere) or whether it's malfunctioning and the incorrect output of that circuit is causing other parts of the unit to do the wrong things and thus give the wrong input to this little bit. And of course in a microprocessor-controlled device, the signatures of just about all signals round the procesosr/memory are very dependant on what program it's running. Yes, you run a test routine, but I am sure I've seen service manuals where the signatures you should get depend on the ROM version fitted. Great if you don't know the version, or if you have a version later than the ones in the manual. Signature analysis will probably tell you if something is working correctly or not. But I don't think it's much help in finding out _why_ it's not working. My guess is that given the data captured by a logic analyser (taking account of the clock, start and stop signals) and the polynomial used, you could calcuate the signatures. Whether it'll help you get the 3412 working is another matter. BTW, what is the problem with your 3421? I assume you know to do the initial tests using the HPIL interface not hPIB (if you have that option). The point meing that the 3421 is internally an HPIL device, the HPIB interface goes to a circuit somewhat similar to an HP82169 which links to the HPIL port on the mainboard. So if it won't work in HPIL mode, it certianly won't work in HPIB mode (but if it's OK as an HPIL device but not as an HPIB one, the problam is on the HPIB interface PCB). -tony