[time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB output?

[Bob]

[combined replies to Paul, Tom, Mark and Pete below]

Hi Paul,

Thanks for the helpful suggestions.  Yes, I spent a pleasant afternoon with the little 59309A, sides and bottom removed, 0.025 pins soldered on to the RAM, other interesting signals, and U2 the ROM.  That makes it easy to pick any 16 for the Salea logic analyzer, which BTW is super easy to use and perfect for this.

The good news is that the HP-IB bus looks fine (when sending commands to the clock) and the inputs and outputs for U14 the SN7489N 4x16 RAM look reasonable. The RAM ME pin toggles, but the RAM WE pin stays high (never asserted), following that back though U10 shows the clock AKA TB2 looks good, but the other LOAD input to U10 is never set.  Following LOAD which is AKA TP1 back, we get to U4A which is a D-FF, input is pin 2 which has a 10k pullup and is sourced from our friendly ROM U2, pin 10.  I have hooked up a dozen of the ROM output pins and they all are busy toggling, but pin 10, LOAD never changes.  So, maybe we are stuck in some strange state due to my not understanding the Prologix ++read, or perhaps U2 LOAD bit is not working.

Carefully moved the ROM U2 into anti-static foam, then checked the socket, pin 10 reads 9.98kOhm to the +5 line, so the socket and pullup per schematic are both good.

While reverse engineering this clock, I realized that the entire clock including HP-IB remote setting commands will all work perfectly without the U2 ROM (!).

Tomorrow I will try reading U2, it has eight address lines, sixteen output lines, power +12 +5 -2 with a Teensy++ uC to step through the addresses while reading the outputs.

Reading U2 seems the most straightforward way to test it.   If the LOAD bit has failed, that should be obvious from reading it  Or maybe U2 is good, and I just don't understand how LOAD works with RAM while talking.

That's the status so far.  This is a nice device to debug.  Very much the opposite of 25 Gbps SerDes debug.

Hi Tom,

Thanks, yes there was a URL link to hp59309.c as the 3rd line in the hp59309.py source, so folks could easily find your original code.

After connecting a Salea logic analyzer to the GPIB bus, the traffic looks ok right up until I do a ++read 10 which is the first time we put the 59209A into TALK mode.  Per your suggestion, I have changed the code to always do ++read 10.

I would have tried hp59309.c with debug flag if I had a Prologix USB adapter.

Hi Tom and Mark,

Thank you both for your very generous offers to test using your known-good 59309A clocks.

Hi Mark,

If you have the time, it would be informative to try the attached hp59309.py with your clock and Prologix Ethernet adapter.  Change line 9 to your adapter IP address, and line 12 to your clock HP-IB address.  This version uses Tom's suggestion of ++read 10.  It will set the clock, and then try to read the clock.  It should finish in a second or two.

Hi Pete,

Yes the -2v reading -2.9v seemed suspicious.  I forced it to -2v and saw no change in symptoms.  Also Paul measured the -2v line in his clock and it read -3v so while suspicious, not likely the root cause.

Cheers,

Bob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hp59309.py
Type: text/x-python-script
Size: 2747 bytes
Desc: not available
URL: <http://www.febo.com/pipermail/time-nuts/attachments/20161008/242fa750/attachment.bin>
-------------- next part --------------