B
Bob
Thu, Oct 6, 2016 7:56 PM
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 44444444444444444444444...
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 change.
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 though.
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.
Cheers,
Bob Marinelli
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 44444444444444444444444...
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 change.
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 though.
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.
Cheers,
Bob Marinelli
PB
Paul Berger
Fri, Oct 7, 2016 2:08 AM
On 2016-10-06 4:56 PM, Bob wrote:
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 44444444444444444444444...
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 change.
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 though.
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.
Cheers,
Bob Marinelli
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
I have two of these clock both working, however I have never tried to
read one with anything like a Prologix adapter I have only used mine
with HP computer of a similar vintage, however as long as the adapter
adheres to the handshake timing it should be ok. I was going to say
that the -2 seemed excessively high, but I just checked one of mine and
it is -3V and works fine. Since it display fine my guess would be that
the problem area would be at the right end of sheet 2 of the A5 board.
Yes it is possible for ROMs to go bad, but I have not experienced it
personally. Since your adapter is reading something that would suggest
it is handshaking on the GPIB bus, but the fact that it seems to run
away might suggest that the send sequence does not terminate correctly,
in the mode you say you have it set for it should send a string of 18
characters including the terminating CR LF and then stop, however in
talk only mode there will likely not be a big break between strings.
If you set it to talk always you should see the RAM addresses cycling
and on the input side it should alternate between addresses coming from
the A4 side and addresses coming from the state machine ROM. If you had
a logic analyzer you could monitor the inputs and outputs of the RAM as
well as the addresses as it cycles through loading and reading out the
addresses. On page 5-9 there is a table of the state machine ROM
contents note addresses are in octal, you could remove U1 and U3 and
then supply your own TTL level addresses to the ROM to see if you get
the correct bits out or it A7 is controlled by the rear panel talk
always switch. You could also remove the ROM and read it out
externally, but be very careful handling it, they are not kidding when
they say they are very static sensitive, I would recommend a properly
grounded static mat and wrist strap. Out of circuit you will need to
create your own rig to read it since it requires multiple voltages.
If it was me I would dive in with a logic analyzer, there are flow
charts to tell you how the sequence of events should go and the analyzer
will quickly tell you if that is what is happening.
Paul.
On 2016-10-06 4:56 PM, Bob wrote:
> 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 44444444444444444444444...
> 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 change.
>
> 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 though.
>
> 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.
>
> Cheers,
>
> Bob Marinelli
>
>
>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
I have two of these clock both working, however I have never tried to
read one with anything like a Prologix adapter I have only used mine
with HP computer of a similar vintage, however as long as the adapter
adheres to the handshake timing it should be ok. I was going to say
that the -2 seemed excessively high, but I just checked one of mine and
it is -3V and works fine. Since it display fine my guess would be that
the problem area would be at the right end of sheet 2 of the A5 board.
Yes it is possible for ROMs to go bad, but I have not experienced it
personally. Since your adapter is reading something that would suggest
it is handshaking on the GPIB bus, but the fact that it seems to run
away might suggest that the send sequence does not terminate correctly,
in the mode you say you have it set for it should send a string of 18
characters including the terminating CR LF and then stop, however in
talk only mode there will likely not be a big break between strings.
If you set it to talk always you should see the RAM addresses cycling
and on the input side it should alternate between addresses coming from
the A4 side and addresses coming from the state machine ROM. If you had
a logic analyzer you could monitor the inputs and outputs of the RAM as
well as the addresses as it cycles through loading and reading out the
addresses. On page 5-9 there is a table of the state machine ROM
contents note addresses are in octal, you could remove U1 and U3 and
then supply your own TTL level addresses to the ROM to see if you get
the correct bits out or it A7 is controlled by the rear panel talk
always switch. You could also remove the ROM and read it out
externally, but be very careful handling it, they are not kidding when
they say they are very static sensitive, I would recommend a properly
grounded static mat and wrist strap. Out of circuit you will need to
create your own rig to read it since it requires multiple voltages.
If it was me I would dive in with a logic analyzer, there are flow
charts to tell you how the sequence of events should go and the analyzer
will quickly tell you if that is what is happening.
Paul.
TV
Tom Van Baak
Sat, Oct 8, 2016 12:15 AM
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.
/tvb
----- Original Message -----
From: "Bob" bob@marinelli.org
To: "TimeNuts" time-nuts@febo.com
Sent: Thursday, October 06, 2016 12:56 PM
Subject: [time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB output?
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 44444444444444444444444...
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 change.
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 though.
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.
Cheers,
Bob Marinelli
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.
/tvb
----- Original Message -----
From: "Bob" <bob@marinelli.org>
To: "TimeNuts" <time-nuts@febo.com>
Sent: Thursday, October 06, 2016 12:56 PM
Subject: [time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB output?
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 44444444444444444444444...
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 change.
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 though.
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.
Cheers,
Bob Marinelli
MS
Mark Spencer
Sat, Oct 8, 2016 12:26 AM
Hi in the (probably unlikely) event another tester would help I have a 59309a and a spare prologix gpib / Ethernet adaptor.
I may try this code out at some point in any event.
Best regards
Mark S
Sent from my iPhone
On Oct 7, 2016, at 5:15 PM, Tom Van Baak tvb@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.
/tvb
----- Original Message -----
From: "Bob" bob@marinelli.org
To: "TimeNuts" time-nuts@febo.com
Sent: Thursday, October 06, 2016 12:56 PM
Subject: [time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB output?
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 44444444444444444444444...
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 change.
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 though.
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.
Cheers,
Bob Marinelli
<59309-log.txt>
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi in the (probably unlikely) event another tester would help I have a 59309a and a spare prologix gpib / Ethernet adaptor.
I may try this code out at some point in any event.
Best regards
Mark S
Sent from my iPhone
> On Oct 7, 2016, at 5:15 PM, Tom Van Baak <tvb@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.
>
> /tvb
>
> ----- Original Message -----
> From: "Bob" <bob@marinelli.org>
> To: "TimeNuts" <time-nuts@febo.com>
> Sent: Thursday, October 06, 2016 12:56 PM
> Subject: [time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB output?
>
>
> 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 44444444444444444444444...
> 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 change.
>
> 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 though.
>
> 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.
>
> Cheers,
>
> Bob Marinelli
>
>
>
> <59309-log.txt>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
PL
Pete Lancashire
Sat, Oct 8, 2016 2:32 AM
Those voltages look a bit too high. Shoot for setting them to their values
or even a couple percent low.
On Oct 7, 2016 5:27 PM, "Mark Spencer" mark@alignedsolutions.com wrote:
Hi in the (probably unlikely) event another tester would help I have a
59309a and a spare prologix gpib / Ethernet adaptor.
I may try this code out at some point in any event.
Best regards
Mark S
Sent from my iPhone
On Oct 7, 2016, at 5:15 PM, Tom Van Baak tvb@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
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.
/tvb
----- Original Message -----
From: "Bob" bob@marinelli.org
To: "TimeNuts" time-nuts@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
44444444444444444444444...
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
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
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 though.
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
A5U15 appears to do the ASCII encoding for SP, CR, LF, ", : so it may or
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.
mailman/listinfo/time-nuts
and follow the instructions there.
Those voltages look a bit too high. Shoot for setting them to their values
or even a couple percent low.
On Oct 7, 2016 5:27 PM, "Mark Spencer" <mark@alignedsolutions.com> wrote:
> Hi in the (probably unlikely) event another tester would help I have a
> 59309a and a spare prologix gpib / Ethernet adaptor.
>
> I may try this code out at some point in any event.
>
> Best regards
> Mark S
>
>
> Sent from my iPhone
>
> > On Oct 7, 2016, at 5:15 PM, Tom Van Baak <tvb@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.
> >
> > /tvb
> >
> > ----- Original Message -----
> > From: "Bob" <bob@marinelli.org>
> > To: "TimeNuts" <time-nuts@febo.com>
> > Sent: Thursday, October 06, 2016 12:56 PM
> > Subject: [time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB
> output?
> >
> >
> > 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
> 44444444444444444444444...
> > 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
> change.
> >
> > 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 though.
> >
> > 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.
> >
> > Cheers,
> >
> > Bob Marinelli
> >
> >
> >
> > <59309-log.txt>
> > _______________________________________________
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> > and follow the instructions there.
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
B
Bob
Sat, Oct 8, 2016 7:16 AM
[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
[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
B
Bob
Mon, Oct 10, 2016 1:48 AM
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 ROM.
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 analyzer.
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 anything.
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.
Cheers,
Bob
On Oct 7, 2016, at 5:15 PM, Tom Van Baak tvb@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.
/tvb
----- Original Message -----
From: "Bob" bob@marinelli.org
To: "TimeNuts" time-nuts@febo.com
Sent: Thursday, October 06, 2016 12:56 PM
Subject: [time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB output?
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 44444444444444444444444...
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 change.
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 though.
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.
Cheers,
Bob Marinelli
<59309-log.txt>_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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 ROM.
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 analyzer.
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 anything.
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.
Cheers,
Bob
> On Oct 7, 2016, at 5:15 PM, Tom Van Baak <tvb@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.
>
> /tvb
>
> ----- Original Message -----
> From: "Bob" <bob@marinelli.org>
> To: "TimeNuts" <time-nuts@febo.com>
> Sent: Thursday, October 06, 2016 12:56 PM
> Subject: [time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB output?
>
>
> 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 44444444444444444444444...
> 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 change.
>
> 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 though.
>
> 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.
>
> Cheers,
>
> Bob Marinelli
>
>
>
> <59309-log.txt>_______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
D
djl
Mon, Oct 10, 2016 3:30 AM
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.
Don
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
ROM.
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
analyzer.
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
anything.
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.
Cheers,
Bob
On Oct 7, 2016, at 5:15 PM, Tom Van Baak tvb@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.
/tvb
----- Original Message -----
From: "Bob" bob@marinelli.org
To: "TimeNuts" time-nuts@febo.com
Sent: Thursday, October 06, 2016 12:56 PM
Subject: [time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB
output?
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
44444444444444444444444...
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
change.
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
though.
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.
Cheers,
Bob Marinelli
<59309-log.txt>_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Dr. Don Latham
PO Box 404, Frenchtown, MT, 59834
VOX: 406-626-4304
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.
Don
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
> ROM.
>
> 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
> analyzer.
>
> 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
> anything.
>
> 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.
>
> Cheers,
>
> Bob
>
>> On Oct 7, 2016, at 5:15 PM, Tom Van Baak <tvb@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.
>>
>> /tvb
>>
>> ----- Original Message -----
>> From: "Bob" <bob@marinelli.org>
>> To: "TimeNuts" <time-nuts@febo.com>
>> Sent: Thursday, October 06, 2016 12:56 PM
>> Subject: [time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB
>> output?
>>
>>
>> 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
>> 44444444444444444444444...
>> 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
>> change.
>>
>> 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
>> though.
>>
>> 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.
>>
>> Cheers,
>>
>> Bob Marinelli
>>
>>
>>
>> <59309-log.txt>_______________________________________________
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
--
Dr. Don Latham
PO Box 404, Frenchtown, MT, 59834
VOX: 406-626-4304
PB
Paul Berger
Mon, Oct 10, 2016 3:34 AM
Bob,
I just looked at the clock I am not using and it is 1818-2295A, it is
not convenient for me to check the other one as it is running and in a
place where I would have to disconnect it to get it out. I could dump
this ROM for you but it may take me a few days as I have other things on
the go right now.
Paul.
On 2016-10-09 10:48 PM, 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 ROM.
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 analyzer.
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 anything.
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.
Cheers,
Bob
Bob,
I just looked at the clock I am not using and it is 1818-2295A, it is
not convenient for me to check the other one as it is running and in a
place where I would have to disconnect it to get it out. I could dump
this ROM for you but it may take me a few days as I have other things on
the go right now.
Paul.
On 2016-10-09 10:48 PM, 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 ROM.
>
> 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 analyzer.
>
> 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 anything.
>
> 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.
>
> Cheers,
>
> Bob
>
>
FM
Francesco Messineo
Mon, Oct 10, 2016 7:20 AM
I have a dump of the 1818-2295A somewhere, it should be archived in
one of my backups. I also made a replacement with a board having 2 x
28C64 SO-28 eeproms and it worked in my 59309A as far as I could test
it. However these eeproms present many glitches on the outputs during
address toggling, so it's way better to use a suitable CPLD after
recovering the equations (I'm a bit stuck on this project due to lack
of time...).
If someone needs the dump, just let me know and I'll dig it out.
HTH
Frank IZ8DWF
On Mon, Oct 10, 2016 at 5:34 AM, Paul Berger phb.hfx@gmail.com wrote:
Bob,
I just looked at the clock I am not using and it is 1818-2295A, it is not
convenient for me to check the other one as it is running and in a place
where I would have to disconnect it to get it out. I could dump this ROM
for you but it may take me a few days as I have other things on the go right
now.
Paul.
On 2016-10-09 10:48 PM, 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 ROM.
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 analyzer.
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 anything.
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.
Cheers,
Bob
I have a dump of the 1818-2295A somewhere, it should be archived in
one of my backups. I also made a replacement with a board having 2 x
28C64 SO-28 eeproms and it worked in my 59309A as far as I could test
it. However these eeproms present many glitches on the outputs during
address toggling, so it's way better to use a suitable CPLD after
recovering the equations (I'm a bit stuck on this project due to lack
of time...).
If someone needs the dump, just let me know and I'll dig it out.
HTH
Frank IZ8DWF
On Mon, Oct 10, 2016 at 5:34 AM, Paul Berger <phb.hfx@gmail.com> wrote:
> Bob,
>
> I just looked at the clock I am not using and it is 1818-2295A, it is not
> convenient for me to check the other one as it is running and in a place
> where I would have to disconnect it to get it out. I could dump this ROM
> for you but it may take me a few days as I have other things on the go right
> now.
>
> Paul.
>
> On 2016-10-09 10:48 PM, 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 ROM.
>>
>> 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 analyzer.
>>
>> 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 anything.
>>
>> 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.
>>
>> Cheers,
>>
>> Bob
>>
>>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
