Thanks Poul for the info.
I will be getting the 4501 then.
I would like a copy of NTPns. Is the copy on your web page current?
I may end up using a FEI 5081a and M12+T I already have with the 4501. I
can probably program the frequency of 5081a to what is required.
I'm looking forward to the
In message [EMAIL PROTECTED], Geoff Horner writes:
Thanks Poul for the info.
I will be getting the 4501 then.
I would like a copy of NTPns. Is the copy on your web page current?
No, a lot have happened since and I'm currently actively working on it.
I may end up using a FEI 5081a and M12+T I
SRQ is definitely a pain, but is hard to do without if you're doing
anything with multiple instruments on the bus; my current problem is
trying to read frequency from a 5370A and voltage from the 3456A to plot
VCO performance. Without the SRQ, I'm getting missing voltmeter readings.
Daun
In message [EMAIL PROTECTED], John Ackermann N8UR writes:
SRQ is definitely a pain, but is hard to do without if you're doing
anything with multiple instruments on the bus; my current problem is
trying to read frequency from a 5370A and voltage from the 3456A to plot
VCO performance. Without the
Tom Van Baak wrote:
SRQ is definitely a pain, but is hard to do without if you're doing
anything with multiple instruments on the bus; my current problem is
trying to read frequency from a 5370A and voltage from the 3456A to plot
VCO performance. Without the SRQ, I'm getting missing voltmeter
Does it work, in a loop, to send 3456A commands
to read voltage, get the response, and then 5370A
commands to read frequency, and get a response?
/tvb
Yes, but I've been getting occasional squirrely values from the 3456A in
that mode, possibly because of a timeout and without using
By the way -- your wait_for_SRQ routine is a bit different than mine in
that you're testing for 0x800 while I'm calling the board (not the
device) with the iblines command and looking at 0x2000 to test bit 14,
the busSRQ signal. I'm using the linux-gpib package, which in theory
mimics the NI
Hi John:
The problem is caused by modern computers being much faster than the
ones available in the late 1970s. With the older computers, after
sending a command the instrument had plenty of time to make a
measurement and format the response.
With today's fast computers if you send a
John Miles wrote:
Interesting; I hadn't run across that. The examples in the manuals commonly
show multiple commands in a single string; maybe the old-school BASIC
controllers were smart enough to pause briefly after transmitting semicolons
or string terminators...?
-- john, KE5FX
You can
In message [EMAIL PROTECTED], John Ackermann N8UR writes:
In theory, the bus is supposed
to handshake to avoid that problem, but that's not always reliable on
the older instruments -- they will report that they're ready for another
command when in fact they aren't. In fact, while doing this
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], John Ackermann N8UR writes:
In theory, the bus is supposed
to handshake to avoid that problem, but that's not always reliable on
the older instruments -- they will report that they're ready for another
command when in fact they aren't.
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Magnus Danielson write
s:
I think I have the uPD7210 datasheet lying around here if you still need it,
even for verification.
I would love to. I haven't been able to track one down and ended up
using a summary condensed into a
The unfortunate truth is that GPIB is actually a pretty flaky thing. It
seems there is always a certain amount of swing-a-dead-cat empiricism
involved with getting any complex GPIB hookup to work reliably.
I can't talk to my Tek 492AP SA unless I turn on the 8566B or the 8657A that
shares its
For those who like to keep tabs on WWV and WWVH (note, this is not WWVB!)
reception conditions on the East Coast, I have been maintaining
http://www.trailing-edge.com/~shoppa/wwv/
for the past couple of years. This charts the usability (roughly measured
as the (S+N)/N of the per-minute beep
In message [EMAIL PROTECTED], John Miles writes:
The unfortunate truth is that GPIB is actually a pretty flaky thing. It
seems there is always a certain amount of swing-a-dead-cat empiricism
involved with getting any complex GPIB hookup to work reliably.
I can't talk to my Tek 492AP SA unless I
In message [EMAIL PROTECTED], Takayuki Hosoda writes:
How do you do. I'm new to time-nuts.
How about take a look on National Instruments'
NAT7210 Reference manual which is upward
compatible to NEC uPD7210.
Yes, I have that already, but since I have the orginal uPD7210
chip, that helps me less
In message [EMAIL PROTECTED], Magnus Danielson writes:
Just look in the HP5370B service manual and you see that the GPIB interface is
passive (i.e. TTL chips rather than LSI chip). It may not be the marvel of
modernism.
Some of the smaller devices, like the VHF switches, the entire GPIB
From: Poul-Henning Kamp [EMAIL PROTECTED]
Subject: Re: [time-nuts] Off the wall: anyone with
experienceprogrammingHP3456A?
Date: Sat, 10 Sep 2005 23:16:59 +0200
Message-ID: [EMAIL PROTECTED]
In message [EMAIL PROTECTED], Magnus Danielson writes:
Just look in the HP5370B service manual and
In message [EMAIL PROTECTED], Magnus Danielson writes:
This is less of a problem with modern CMOS based interface chips.
Actually, there you end up in another problem, you power the box through the
protection diodes which you really must have for CMOS. So it is really not so
much better, just
From: Poul-Henning Kamp [EMAIL PROTECTED]
Subject: Re: [time-nuts] Off the wall: anyone with
experienceprogrammingHP3456A?
Date: Sat, 10 Sep 2005 23:26:57 +0200
Message-ID: [EMAIL PROTECTED]
In message [EMAIL PROTECTED], Magnus Danielson writes:
This is less of a problem with modern CMOS
Hi, Poul,
I've the datasheet for the uPD7210 in my 1983/84 Nec Microcomputers
Handbook. If you need it, I can scan it for you.
Regards,
Javier
Poul-Henning Kamp wrote:
Are you 100% sure this is a problem on the 5370B ?
I've spent a lot of time with my logic analyzer while implementing
21 matches
Mail list logo
