Keithley 705 crickets

[guenthert]

      I just acquired a Keithley 705 scanner with 7164 card in good condition (there's a 30d warranty on it, hence I haven't opened it yet).  It seems to work fine (passes RAM/ROM CRC check, LED and buttons work, relays can be opened/closed -- after I configured the correct "pole-ness" -- even GPIB works) as far as I have tested it.  Only if I set it to display time or date, it does not only do that, but also rapidly exercises the relays, producing a sound not unlike a few crickets.  Is this a firmware bug (version b6 here, iirc)?   

      Any known work-arounds other then "don't do that"?  I mean, I don't really need another clock, but it would be pretty. 

[tymm]

sounds to me like possibly weakened-but-not-dead power supply for the relay coils?  i have seen similar issues with serial controlled power distribution units and other equipment; could be bad caps, overheating regulator or damaged components along the power path - depending on what unit is doing at any point, power draw can change, causing variations in coil magnetic field.

[guenthert]

sounds to me like possibly weakened-but-not-dead power supply for the relay coils?  [..]

     If it would attempt to close all relays (the ones in the 7064 are open when not energized), then a marginal power supply could produce such an effect, I suppose.  But why would it attempt to close them in the first place?

[TurboTom]

My 705 / B6 with two 7056 10-channel cards installed doesn't show anything like this. I can enable time/date display on it without affecting any of the relay stati. I rather don't think it's a PSU problem since if all channels are off, they should simply stay off and there wouldn't be a surge current drawn that might affect stability.

I'ld rather search for the problem in a faulty VIA (U119, 6522), address decoder (U112, 74LS138) or strobe decoder for the output shift registers (U102, 4028). Especially since the clock circuitry and the output shift registers are driven by the same data/clock lines, I would start testing at U102 and work in reverse.

If the strobe of the output shift registers is active all the time, it's pretty obvious that the relays will play some "music" while the instrument accesses the clock circuitry via the same serial bus.

[guenthert]

My 705 / B6 with two 7056 10-channel cards installed doesn't show anything like this. I can enable time/date display on it without affecting any of the relay stati.

     Thanks for confirming this.

I'ld rather search for the problem in a faulty VIA (U119, 6522), address decoder (U112, 74LS138) or strobe decoder for the output shift registers (U102, 4028).

     I was afraid of something like that.  I doubt those chips are in sockets.  Warranty be damned, I'll have a look ...

Especially since the clock circuitry and the output shift registers are driven by the same data/clock lines, I would start testing at U102 and work in reverse.

     Will do.

If the strobe of the output shift registers is active all the time, it's pretty obvious that the relays will play some "music" while the instrument accesses the clock circuitry via the same serial bus.

      I'll need to have a 2nd look at the schematics to find that serial bus.

[guenthert]

     Actually, it turns out most of the VLSI chips are in sockets (does a MC68A50P, which is not, count as VLSI?  today?).

     Visual inspection didn't reveal anything terribly interesting, PCB looks pretty good, well soldered (hard to believe that it is almost 40 years old).  I noticed scratches on the pins of the CPU, then that it's actually a MC6802, while the manual lists it as MC6808 (pin 36 (RAM Enable) is low, so that should be Ok).  Perhaps that has been replaced in the past.

     In an attempt to monitor the issue with the device open (and the relays card and cage removed), I connected an oscilloscope to the serial out BNC connector.  I believe I saw some TTL signal there briefly, but it's now steady high and the front panel display went dark (and the unit doesn't respond to GPIB anymore) 

     Power is still good, chips still get more or less warm, but not unbearably hot, system clock seems to be good too (just looked at Phi2, which is 1MHz square TTL).

     I noticed CB2 on the VIA6522 (serial data) still carries some TTL signal (at *very* low bit rate), but CB1 (clock) is solid high.  I removed that chip, but the data line still carries that signal and clock remains high, so that comes from somewhere else?  That's going to be a longer session ...

[TurboTom]

Bummer - but shit happens...

Anyway, besides the VIA there appear to be only two other circuits that are supposed to drive the synchronous serial data line, these are the real time clock chip and the I/O board. You can disconnect the latter, this shouldn't affect the operation of the main board.

You may want to check if there's activity on the CPU's address lines, and if so, monitor the outputs of the address decoder (U112) if it still enables EPROM, RAM and the peripherials at a certain pace.

The big advantage of circuitry of this age is that things are still quite simple and obvious, and signal speeds don't require special probing techniques or specialized equipment in general. These Keithley "Brownies" are very repairable, though sometimes their analog circuitry is quite intricate - and that's not present in this 705 scanner  .

I'm sure you'll get it fixed.

[guenthert]

Bummer - but shit happens...

Anyway, besides the VIA there appear to be only two other circuits that are supposed to drive the synchronous serial data line, these are the real time clock chip and the I/O board. You can disconnect the latter, this shouldn't affect the operation of the main board.

      I had a closer look at the "*very* low bit rate signal" and it turned out to be a TTL square wave of exactly one Hz ...
      The clock chip (NEC uPD1990) 's output is supposedly open-drain and disabled if OE is low (which it was, or so my oscilloscope indicated).  I was about to cut that pin (do I need the clock I wonder again?) when I had a second (or thirteenth) look at the schematic and noticed that the clock chip's OE is driven by the VIA 6522, which I removed, *cough*.  A 10-times oscilloscope probe was enough to pull that pin down ...
So back in with the 6522 and indeed the mysterious 1Hz signal is gone.   

     There is some activity (~100kbps) on the data line of the system-wide serial bus on boot, but the clock signal looks weird (as if it it tries, but would be pulled up hard elsewhere).  I bent pin 18 of the 6522 (CB1, which drives the clock of the internal serial bus) carefully out and removed the I/O daughter board and then the clock floats.  I need to have a closer look at that I/O daughter board.   
(I wonder now, whether, while originally connecting the oscilloscope to the serial data out BNC, I caused the freely dangling I/O board to make contact with the chassis).

     With CB1 of the 6522 connected to clock again, that's static at high and there doesn't seem to be any activity on the data line either.  I checked the chip select inputs on both ROM chips as well as the 6522 and they are all briefly (~5us) activated after RESET (so at least the CPU and the address decoder seem to work still).  If I had one lying around, I'd swap the 6522 with a known good one now.  Jameco has (plenty of) the CMOS version from WDC -- are those compatible?

      Might be helpful for others (including me, later) attempting to troubleshoot a 705: where R114 and R115 meet, a RESET can be induced safely by pulling that point briefly to GND (the reset button on the front panel won't do any good until the system is mostly functional and can poll buttons).

You may want to check if there's activity on the CPU's address lines, and if so, monitor the outputs of the address decoder (U112) if it still enables EPROM, RAM and the peripherials at a certain pace.

     Thanks for the hint, partly done, see above.

The big advantage of circuitry of this age is that things are still quite simple and obvious, and signal speeds don't require special probing techniques or specialized equipment in general. These Keithley "Brownies" are very repairable, though sometimes their analog circuitry is quite intricate - and that's not present in this 705 scanner  .

      Yeah, the 705 is as easy as one could hope for (earlier devices have so many low density integration chips and discrete parts that they tend to be mechanically challenging and complex to trace, later ones use SMT parts and ASICs/FPGA where repairing generally means replacing unless one has specialized tools and the skill to use those).

I'm sure you'll get it fixed.

       Well, I don't want to give up just yet, but the 705 is odd in that it is (currently) *very* affordable on the secondary market, so it doesn't make much sense to spend too much time on that (it's even questionable whether replacing parts is the most economic solution).

[TurboTom]

...
       Well, I don't want to give up just yet, but the 705 is odd in that it is (currently) *very* affordable on the secondary market, so it doesn't make much sense to spend too much time on that (it's even questionable whether replacing parts is the most economic solution).

That's very true for the US (basically the same for most second hand TM gear), but in other parts of the woods things are quite different. And even though the 705 really is bottom-of-the-barrel price-wise, I usually consider such instruments good training objects for fault finding skills... Take it as a sports of some kind  .

[guenthert]

[..] Take it as a sports of some kind  .

       Understood and I can relate, but I actually meant to use that thing. 


       Answering my own question regarding compatibility of the CMOS (well, there are different versions, I meant W65C22S which has CMOS level in/outputs) version:  strictly speaking they are not compatible, but I was wondering whether there would be a good chance to get away with that anyhow (I thought there might be large enough an overlap).  The W65C22S expects 0.8*Vdd (i.e. 4V in a 5V system) as minimum high input, which TTL very well might not deliver.  Worse I think is the output strength, specified as only 2 TTL loads.  In the 705 quite a few shift register chips hang on the internal synchronous serial bus, so that's probably not going to work.  Further, the W65C22S IRQ output isn't open-drain, but would need an external diode for wire-or connection as used in the 705.

       Might as well also keep a note about the external serial bus: it's asynchronous and driven by the MC68A50P and unrelated to the internal synchronized serial bus (of which the clock is driven by the VIA6522) and hence very likely unrelated to the original problem.

[guenthert]

[..]
      I need to have a closer look at that I/O daughter board.   
[..]

     I meanwhile did and it turned out that both, the 74LS02 NOR as well as the 74LS04 inverter, chips connected to the clock pulled that up hard.  I haven't looked further, but to me it's quite concerning that the damage is on the system facing chips and not only on the ones facing external inputs.  With that it's not too surprising that the VIA6522 (connected directly to those failed chips) acts weird. 

     I haven't yet looked further and probably won't in the near future, as I just got a replacement for a very modest sum.