Am 02.06.13 23:20, schrieb Tom Van Baak:
Lizeth Norman wrote:
The 59309A can be updated via HPIB.
I did it two ways. The first was to use windows system time and then write
to the instrument. The other was to poll a M12+T and get the proper time.
Sadly, both are in Labview, and as such probably aren't much help.
Hans Holzach wrote:
i use a 59309A as a time and date display in a setup of old HP devices:
10 mhz are taken from a fury gpsdo to keep the clock stable. an HP 71B
reads the time from the gpsdo via an HP-IL/RS-232 interface and delivers
it to the clock via an HP-IL/HPIB interface. setting the clock looks
pretty cool, there is quite some action on the display! the system is so
slow, it takes several seconds until time and date are set. sorry, no
linux/windows involved here...
Norm and Hans,
Were either of you able to sync the 59309A to better than a second? From the
schematic it looks like the P (stoP) and T (starT) commands have 1 second
granularity and the R (Reset) command clears only the last MC14518 decade
counter. This would suggest that one can set to within 100 ms, but no better.
The code that I'm using (http://leapsecond.com/tools/hp59309.c) solves the 1
second problem but I wasn't able to get it to sync better than 0.1 second. If
you have suggestions or solved this without a soldering iron, let me know.
Thanks,
/tvb
tom,
i am an absolute beginner and i am not able to read and understand the
schematic (nor your code...). however, i noticed quickly that most of
the time neither stoP nor starT are executed right after i push the
button and found this to be a bit annoying. in my
spaghetti-basic-program for the HP 71B to set the HP-IB clock i don't
use neither of these two commands, but just R(eset). the next program
line reads the time from the GPSDO. i want to keep these two lines as
close together as possible. the values taken from the GPSDO are then
added to the reset but running clock.
compared to a reference clock the time is off +/- 1 second max.
unfortunately, i have not figured out a better way to get decent results
than running the program several times until the clock ticks more or
less synchronously to the reference clock.
in my setup there may be two reasons more for this behaviour than just
the granularity of the commands or the clearing of the decade counter:
1. the loop consists of an HP 71, a multimeter, a printer, and three
interfaces (HPIB, RS-232, USB) and is very slow. the rs-232 interface
communicates at 19200 baud. you can almost hear the commands creeping
through the cables, one by one...
2. i use the SCPI command ":ptime:time:str?" to read the time from the
gpsdo. if i understand correctly, the resolution of the string is 1
sencond only. this would mean that if i read the time at Z + 0.9 seconds
then i get Z and not Z+0.9s. this does not help much to synchronize the
clock precisely with the GPSDO. or did i misunderstand something here
(which is not very unlikely)?
any ideas how to solve this issue would be very welcome!
best regards,
hans
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
