I use a national instruments PCI-GPIB card in a Windows 10 PC, works just
fine.  Usually can find them <$100 on eBay.

I've also used a HP/Agilent 82357A (or B) which does USB-GPIB for those
cases when you need it for a laptop or something else without a pci or pcie
slot.

I understand the USB ones in particular are prone to being counterfeited,
but evidently most of the counterfeit ones work even though they're not
original HP/Agilent.

There are various other options out there, for instance prologix (and
possibly others) make a GPIB-ETHERNET converter which will convert GPIB
instruments to network instruments.

On Fri, Nov 2, 2018 at 2:05 AM Rex rexa@sonic.net wrote:

--
Forrest Christian CEO*, PacketFlux Technologies, Inc.*
Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602
forrestc@imach.com | http://www.packetflux.com
http://www.linkedin.com/in/fwchristian  http://facebook.com/packetflux
http://twitter.com/@packetflux

Hi!

On Fri, Nov 02, 2018 at 01:04:02AM -0700, Rex wrote:

There are quite a number of reasonably-priced Agilent 82357B on eBay,
see [1]. They work reasonably well. Since they are interfaced via USB,
talked to them from recent laptops is not an issue.
There are also several open-hardware projects that implement GPIB, e.g.
[2,3].
All these solutions have the drawback that they cannot react quickly
enough to ATN messages on the bus, implying that they can only function
as controller on the bus, not as instrument. Whether that is an issue
for you or not is something you'll have to assess yourself. The details
around the ATN issue are outlined in [2]. German article though that
might need translation.
I believe it should be feasible to implement a GPIB<-->USB interface
with instrument impersonation capability with reasonably effort in at
least those two ways:

• By using a CPLD/FPGA instead of a microcontroller. The Lattice devices
  with the open source yosys/icestorm/arachne toolchain come to mind.
• By using a microcontroller + additional, discrete logic to take care
  of ATN handling.

I am not going to implement either due to lack of time and extrinsic
motivation, but would much appreciate if somebody picks up one of the
ideas.

-Alex OE2AHL

[1] https://www.ebay.com/itm/183267275589
[2] https://www.mikrocontroller.net/articles/GPIB-RS232-Schnittstelle
[3] http://scasagrande.blogspot.com/2012/04/gpibusb-for-sale.html

How important is ATN in a typical time-nuts usage ?

I can see it being important in a complex ATE setup where some instruments
are automatically providing data to a schedule and need to be serviced, but
in my understanding the time-nuts case is often capturing a stream of data
from a single TIC. Are there other common configurations that need ATN
handling ?

Although GPIB is (obviously) a bus, it seems to me that modern usage could
be handled more easily using multiple USB interfaces, each connected to
only one instrument. This means the interface can be much cheaper than an
82357a or similar, because it doesn't need bus buffers capable of driving a
full load, and you can use lightweight USB cabling instead of the heavy
GPIB cable.

Getting further off-topic (so please followup off-list if this is of
interest), I'm surprised that the 82357a appears to contain both an FPGA
and a cypress FX2 USB device. The cypress device has a crude (8051)
processor but also a programmable DMA engine that ought to be capable of
doing the source-acceptor handshake on its own. Why does the HP interface
need the FPGA too ?

You can buy FX2 dev boards (sold to be used as clones of Salae and other
USB logic analysers) for a few pounds each. Of course, this doesn't allow
instrument-to-instrument transfers but this is probably mitigated by having
a fast PC and multiple busses - a star rather than a bus topology.

On Fri, Nov 2, 2018 at 9:43 AM Forrest Christian (List Account) <
lists@packetflux.com> wrote:

I use NI USB interfaces,  They are reliable process ATN messages and of course have the vast programming library associated with NI interfaces.

Used ones can be found on the well known auction site for 250-400 bucks.    Make sure you get the BLUE ONES the Brown ones are USB 1.0 and are obsolete.

As to your older Prologix interfaces they SHOULD still work just fine,  i dont think much has changed with them over the years other than packaging.  Get the driver  and give them a shot.

On Nov 2, 2018, at 7:39 AM, Adrian Godwin artgodwin@gmail.com wrote:

How important is ATN in a typical time-nuts usage ?

I can see it being important in a complex ATE setup where some instruments
are automatically providing data to a schedule and need to be serviced, but
in my understanding the time-nuts case is often capturing a stream of data
from a single TIC. Are there other common configurations that need ATN
handling ?

Although GPIB is (obviously) a bus, it seems to me that modern usage could
be handled more easily using multiple USB interfaces, each connected to
only one instrument. This means the interface can be much cheaper than an
82357a or similar, because it doesn't need bus buffers capable of driving a
full load, and you can use lightweight USB cabling instead of the heavy
GPIB cable.

Getting further off-topic (so please followup off-list if this is of
interest), I'm surprised that the 82357a appears to contain both an FPGA
and a cypress FX2 USB device. The cypress device has a crude (8051)
processor but also a programmable DMA engine that ought to be capable of
doing the source-acceptor handshake on its own. Why does the HP interface
need the FPGA too ?

You can buy FX2 dev boards (sold to be used as clones of Salae and other
USB logic analysers) for a few pounds each. Of course, this doesn't allow
instrument-to-instrument transfers but this is probably mitigated by having
a fast PC and multiple busses - a star rather than a bus topology.

On Fri, Nov 2, 2018 at 9:43 AM Forrest Christian (List Account) <
lists@packetflux.com> wrote:

time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.