[time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB output?
djl at montana.com
Sun Oct 9 23:30:45 EDT 2016
Hi Bob et al:
I have 4 of these, got some time ago. Here is the data from the ROM's:
s/n Rom no
2510A04059 hp1818-2295A 2335
2136A03167 hp1818-2295A 0844 this one white ceramic with lotsa
gold; the eldest.
2702A04579 $M$hp1818-2295A 2912 this one costcutting. boards
cheaper, no instructions on the bottom cover.
2510A04243 hp1818-2295A 2390
Hope this is of some interest. I also modified a couple of them by
using some spare buffers, U7 on the middle board to TP1, and ran the
output to the extremely convenient BNC for external power; the buffer
chip is right next to it! So I have a very convenient 1 pps. Note you
can choose the external freq standard to be 1, 5, or 10 MHz with an
internal switch by the battery holder. I don't use an internal 9v
battery with these, it does not keep the readouts alive, just keeps the
internal osc and chain going.
I've never played with the GPIB, mainly because AFIRC, it only reads out
to the second.
On 2016-10-09 19:48, Bob wrote:
> Hi Tom & Paul,
> Some progress with the HP 59309A clock debug. Built a ROM reader
> (Teensy++, a 28 pin WW socket, jumpers) and read out the HP 59309A U2
> Compared the user manual to my readings, found three stuck output bits
> out of sixteen, and another few dozen assorted differences out of the
> 4096 ROM bits.
> Also, while moving U2 to the reader socket I noticed that the chip is
> stamped 1818-2295A 2335 vs. the schematic which states U2 is a
> 1818-2193. Perhaps the U2 state machine was updated?
> The O1 (part of Next Address) bit, O9 (LOAD) bit and O11 (Rout) bit
> always read 0. Together those stuck-at-0 bits compose the vast
> majority of the bit differences. LOAD being always zero explains why
> I don't see data written into the RAM when watching with a logic
> I'm 99% sure there is at least some bit rot, in particular there is a
> long unused block at the end of the Talk Enable = 1 table, where all
> addresses should match, and in the middle of that range there are just
> a few wrong bits.
> A small number of differences exist in other Next Address and Next
> Qualifier columns, but there are only a few, not easy to tell if they
> are just changes to the state machine or more bit rot.
> Digging further, the serial number prefix 2510A is much newer than the
> 1632A prefix mentioned in the manual I'm looking at, so there could be
> differences in the schematic. Not clear if HP change pages up to
> 2510A exist, I've not found them so far.
> At this point, I can think of a few paths to take...
> a) Leave it alone, still works fine as a desk clock, but useless for
> reading TOD via HP-IB.
> b) Build a little adapter board and replace U2 with a self-programmed
> 16 bit EPROM or a pair of 8 bit EPROMs. I could use the code in the
> manual, buzz out the circuit to validate the schematic, and (if
> needed) reverse engineer the state machine.
> Tom and/or Paul, would you consider lifting the cover off your clock
> (just 2 screws in the back) and peeking at the part number on your U2
> chips? That's the 28 pin ceramic ROM in the socket on the A5 board
> which is the one at the far left looking from the front. The ROM is
> at the top of the board and should be visible without touching
> If someone happens to have a ROM stamped 1818-2295A 2335, it would of
> course be great to capture the bits, to remove the remaining guesswork
> in creating a replacement image. Naturally, I checked the ROMs on
> Didier's site, but didn't see any for the 59309A.
> In conclusion, reading the U2 ROM shows three stuck bits, including
> LOAD, which explains what I saw on the logic analyzer.
>> On Oct 7, 2016, at 5:15 PM, Tom Van Baak <tvb at LeapSecond.com> wrote:
>> Hi Bob,
>> Yes, the hp 59309A is a wonderful little LED clock. I just re-tested
>> the program I wrote to read/write the time and it still works.
>> For others that are wondering, the code is at
>> http://leapsecond.com/tools/hp59309.c and a Win32 exe is there too.
>> Anyway, one possible suggestion is for you to use ++read 10 instead of
>> just ++read. The 59309A is an early byte-oriented HP-IB device and the
>> Prologix command set is more meant for line oriented communication
>> (using CR or LF or EOI for termination). So when I use ++read10
>> everything is fine, but ++read, or ++read9 or ++read11 or ++read
>> anything else will cause the Prologix to go into an infinite loop.
>> One other idea that may shed light on your problem is to use the /d
>> (debug) option and have a look at the exact communication between the
>> program and the Prologix and the 59309A. Then do the same with your
>> Python code to see if it matches, down to the byte. Again, these
>> vintage HP-IB instruments are wonderfully simple but they don't always
>> take well to things we take for granted these days like extraneous
>> line terminators or spaces or open-ended reads and such. If you really
>> want some fun, use a GPIB bus analyzer.
>> Attached is the debug log from my 59309A.
>> If all else fails I can send you a known working 59309A so you can
>> tell if the problem is with your PC, your Python tool, your Prologix,
>> or your 59309A.
>> ----- Original Message -----
>> From: "Bob" <bob at marinelli.org>
>> To: "TimeNuts" <time-nuts at febo.com>
>> Sent: Thursday, October 06, 2016 12:56 PM
>> Subject: [time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB
>> I'd like to ask the HP 59309A owners on time-nuts if the following
>> symptoms sound familiar, and if so, what would the fix be?
>> o New-to-me HP 59309A clock.
>> o Late build, 1985 date code on many parts.
>> o I replaced the big 1900 uF electrolytic before plugging it in.
>> o Visual inspection very clean, no corrosion, no battery.
>> o 12v reads 13.1v, 5v reads 5.3v, -2v reads -2.9v.
>> o Front panel switches and buttons all work as expected.
>> o Internal and external osc. both work as expected.
>> o Internal "format" switch set to 0000 i.e. comma, cal, no space.
>> o GPIB works to *set* the time, using Prologix Ethernet adapter.
>> o Prologix Ethernet adapter attached directly to the clock, no cables.
>> o Python code to set via GPIB attached below.
>> o Setting time via GPIB always works, tried many times.
>> o Reading time has never worked. All I get is lots of ASCII
>> o Reading with Prologix ++read command
>> o Switches set to 1100010 i.e. Listen, ADDR 2 for normal operation
>> o Tried switches as 0000010 i.e. Talk Only, also resulted in
>> continuous 4444444444444444444...
>> o Tried very long delays between every GPIB command, no change.
>> o Tried removing top cover and running a fan to bring entire clock to
>> 21C, no change.
>> o Tried gently reseating the four boards and three socketed PROMS, no
>> Thanks to TVB for hp59309.c sample Windows Prologix USB code. I based
>> the Python Ethernet code on TVB, to read from the clock he sends
>> command C and then ++read. When I do that all I get are a zillion
>> 0x34 '4' characters.
>> Seems strange that all the GPIB commands work. I tried R reset, P
>> pause T resume D day H hour M minute S second manually and they all
>> work just fine. I have never been able to read anything reasonable
>> As to the Prologix Ethernet adapter, I believe it is working OK
>> electrically as I have been using it for weeks at a time reading PPS
>> time intervals from a trusty HP 5334B counter, the adapter has read
>> hundreds of thousands times from the 5334B.
>> Is there a trick to using the Prologix to read from the 59309A?
>> I did notice that the 59309A has at least one trick - in TVB's code
>> where he reads the Prologix settings and only writes them if they need
>> to be changed, that is actually required(!). Just writing them every
>> time seems to put the adapter into a strange state.
>> Page 4-2 of the 59309A manual seems to imply that the "Output State
>> Machine" generates the GPIB output messages, using input from the
>> "Data Memory". AFAICT, those two functional blocks are the only ones
>> that are not working for me.
>> I think A4U18 ROM is OK as it handles GPIB command decoding and R P T
>> D H M S commands all work.
>> A5U15 appears to do the ASCII encoding for SP, CR, LF, ", : so it may
>> or may not be OK.
>> A5U2 is described as "STATE MACHINE ROM (A5U2). This 4K ROM controls
>> the operation of the circuits that develop the talk output of the
>> 59309A." Has anyone experienced failure of this ROM, and do the
>> symptoms match what I'm seeing?
>> This is a lovely clock, and while I can't actually think of a reason
>> to *need* the GPIB time output, I'd still like to fix it.
>> Bob Marinelli
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> and follow the instructions there.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> and follow the instructions there.
Dr. Don Latham
PO Box 404, Frenchtown, MT, 59834
More information about the time-nuts