GPIB to USB controller/adapter

[asgard]

Dave et al,
I have recently acquired an HP (before it morphed into Agilent) 1631D logic analyzer.  My previously misspent youth was taken up with doing very serious O.S. code using a 1630 as my primary debugging and bench tool, so I have particular fondness for the good old 1630.  What's new with the 1631 as opposed to that is that it includes a 2-chennal, 50MHz DSO as part of the package.  Real cute, albeit primitive by current standards.  Nevertheless I wanted to leverage available equipment as part of my design lab, so I wanted to use the 1631 to prepare documents for standards compliance (I am working on projects that will in all likelyhood require documented compliance with EnergyStar, IEC/EC, and so on).  I want to connect the GPIB (HP-IB) interface on the back of the 1631D to my PC so I can do screen capture and saving/restoring of analyzer setups.

What hacks me off about this is that even in this day and age the typical converter for USB to GPIB/IEEE488 is a little dongle that sells for about 400-500 USD.  That is a serious disconnect between cost of materials and sales price.  Even the One Hung Low stuff is about that price.  There is one notable exception, and that is a little honey from Softmark, in Australia (not Austria).  I don't know if you (or any of the other crazy Aussie blokes down there) have any experience with such gadgets, but I would be interested in knowing why the Softmark converter is so cheap compared with all the others, and whether it is truly usable with LabView or any such stuff on my PC.

Thanks muchly,
J.R. Stoner

[amspire]

The Softmark converter is pretty useless. I would not touch it. It is extremely limited in GPIB capability, and I think it only works via the provided very lame software.  Isn't it run from a parallel printer port? If so, who has a parallel printer port?

The good news is that things are not quite as bad as you think.

If you want something very good, go for the Prologix converters, or about $100, you can probably find Agilent USB/GPIB converter clones that can use the Agilent drivers. These options are fully compatible with most recent IEEE488.2 spec and with Visa drivers.

http://www.ebay.com.au/itm/S82357-GPIB-USB-interface-Agilent-82357-compatible-/171016606020

If that is too much, then there have been a few projects in this forum and elsewhere for DIY converters.

Steve ( scasagrande ) did a great open source board that he was selling, but you could get all the info to make your own.

https://www.eevblog.com/forum/buysellwanted/for-sale-oshw-gpibusb-adapter/

There is also a current thread about a project:

https://www.eevblog.com/forum/testgear/gpib-usb-what-functions-would-you-like-in-one-of-these/

Typically the DIY projects are not VISA compatible which is good and bad.

Bad as you cannot use them with the standard GPIB drivers for compatibility with many high end software tools, but good as you do not have to install 500MBytes of junk to just be able to send a 10 byte request to an instrument, and get a reply back which is maybe 15 bytes.

Richard

[asgard]

I did go and have myself a good hard look at Steve Casagrande's project.  I had a hard time with the schematic, so I wanted to rerender it with my usual tool, which is Eagle.  Here is what my refigure of the schematic looks like.
I have also laid out the pcb to fit one of the Sick Of Beige boxes.  Only thing left is to build the thing and hang it off my scope.

[Wuerstchenhund]

If you want something very good, go for the Prologix converters, or about $100, you can probably find Agilent USB/GPIB converter clones that can use the Agilent drivers. These options are fully compatible with most recent IEEE488.2 spec and with Visa drivers.

http://www.ebay.com.au/itm/S82357-GPIB-USB-interface-Agilent-82357-compatible-/171016606020

I have the faster variant of this adapter (F82357) and can really recommend it, there's probably nothing better for this money available right now than these Beiming adapters. I had a look at the alternatives but none of them supported VISA/IVI which made them pretty useless for me.

I'm using my Beiming adapter in NI.488 mode (National Instruments compatible) as most programs which support GPIB expect NI kit, and so far it works just fine and absolutely stable. Tested under Windowsxp, Vista x64 and Windows 7 (32bit and x64), and also under Windows 8 x64.

[bingo600]

If you want something very good, go for the Prologix converters, or about $100, you can probably find Agilent USB/GPIB converter clones that can use the Agilent drivers. These options are fully compatible with most recent IEEE488.2 spec and with Visa drivers.

http://www.ebay.com.au/itm/S82357-GPIB-USB-interface-Agilent-82357-compatible-/171016606020

I have the faster variant of this adapter (F82357) and can really recommend it, there's probably nothing better for this money available right now than these Beiming adapters. I had a look at the alternatives but none of them supported VISA/IVI which made them pretty useless for me.

I'm using my Beiming adapter in NI.488 mode (National Instruments compatible) as most programs which support GPIB expect NI kit, and so far it works just fine and absolutely stable. Tested under Windowsxp, Vista x64 and Windows 7 (32bit and x64), and also under Windows 8 x64.

I got a Beiming off 'bay
I emailed Beiming twice within the last month to get confirmation that one can use Agilents firmware to update it.
No answer on both accounts 

Beiming claims their adapter is 100% compatible with the Agilent-82357A, and rumours are ... Even firmware compatible.

According to the Linux-Gpib Project : I need to update Agilent-82357A adapter to the included firmware.
http://linux-gpib.sourceforge.net/firmware/gpib_firmware-2008-08-10.tar.gz

Support or any firmwareupdates from Beiming are apparently non-existant
They have releasenotes & upgradeguides , i can't find any firmware files .....
Wonder if it's a Rigol daugthercompany.

To be fair i have heard the adapter does well as an Agilent Clone , but expect no support 

/Bingo

[bingo600]

To be fair , i just got an answer from Beiming today.

I had been "caught in the spam filter" they said.

I was informed that you can not use Agilent firmware , and that they dorsn't support linux-gpib for now.
But they expect that feature to be added soon.

I'll get a new firmware for my adapter this week.

/Bingo

[bingo600]

Good news 

I'm currently in dialog with Beiming , and i am testing linux-gpib support on the S82357.

I have only done some light tests, with the ibtest program.
But it seems to work on my "quirky HP 5384A" that refuses to set EOI , and behaves the same as my Agilent USB adapter

This will be nice , as i paid 2x the Beiming price for an Agilent , to get Linux support.

Beiming offers 2 solutions , 1 where you load the code on usb-insert (fxload) , just as an Agilent.
And (untested by me) , one where you program the new firmware permanently into the iic eeprom , and doesn't need to load firmware on usb insert.

I don't know when they release the frmware(s) for public use , but would not expect a long time.

Nice work Beiming 

/Bingo

Ohh: I get to test the F' firmware also when they're ready.

[manticore00]

Erik,
I bought that one to work with my 34401a and it works great with the Agilent software.

[JoeyP]

I use one of the Prologix adapters. I've found it to be, uh, OK. It does get the job done, but have found it to be susceptible to crashing in a way that requires at least R&R of USB cable, if not reboot of PC. Seems to really not like having devices connected which are not powered up - but that might be the fault of the GPIB device rather than the adapter.

[c4757p]

Seems to really not like having devices connected which are not powered up - but that might be the fault of the GPIB device rather than the adapter.

This is a GPIB connector.



Do you want to have to unplug a bunch of these when devices are shut down? It's the adapter's fault.

[JoeyP]

Do you want to have to unplug a bunch of these when devices are shut down? It's the adapter's fault.

I don't disconnect them. I just make sure the troublesome device is powered up. I realize that this shouldn't be necessary. The GPIB spec says that devices are not supposed to load the bus when power is off. But, I've found that not all devices - particularly older ones, honor that part of the spec. I do suspect the adapter, but it could also be the fault of a non-compliant device in my stack, so don't want to bad-mouth the product without knowing for sure. It only happens with a certain device. Others can be powered off without issue.

[alm]

It might also be weak drivers in the Prologix device. Do they use a real GPIB chip or some random logic gate to drive the cable? GPIB is designed to work with long cable and many devices, so the outputs are supposed to be quite beefy.

[TerraHertz]

Dave et al,
I have recently acquired an HP (before it morphed into Agilent) 1631D logic analyzer.  My previously misspent youth was taken up with doing very serious O.S. code using a 1630 as my primary debugging and bench tool, so I have particular fondness for the good old 1630.  What's new with the 1631 as opposed to that is that it includes a 2-chennal, 50MHz DSO as part of the package.  Real cute, albeit primitive by current standards.  Nevertheless I wanted to leverage available equipment as part of my design lab, so I wanted to use the 1631 to prepare documents for standards compliance (I am working on projects that will in all likelyhood require documented compliance with EnergyStar, IEC/EC, and so on).  I want to connect the GPIB (HP-IB) interface on the back of the 1631D to my PC so I can do screen capture and saving/restoring of analyzer setups.

Hey, I too have a HP 1630G. Used it for many years, though it's currently packed away for lack of workspace.
I'll be interested to hear how you go, getting it to talk with a PC. I'd like to do that too. I have the dual floppy disk unit, but it's a pain since the floppies are non-standard format, and can't be read in PCs. I have several disassemblers for the 1630G on those disks. Would be nice to get them into a more permanently archived form.

It was always tempting to buy the analog scope card, and see if it could be added to my 1630G. The space is there, along with the holes for BNCs. The extra EPROMs are available. But I think when I looked into it there was a problem with number of EPROM sockets free. Can't recall the details.

[bingo600]

Good news 

I'm currently in dialog with Beiming , and i am testing linux-gpib support on the S82357.

I have only done some light tests, with the ibtest program.
But it seems to work on my "quirky HP 5384A" that refuses to set EOI , and behaves the same as my Agilent USB adapter

This will be nice , as i paid 2x the Beiming price for an Agilent , to get Linux support.

Beiming offers 2 solutions , 1 where you load the code on usb-insert (fxload) , just as an Agilent.
And (untested by me) , one where you program the new firmware permanently into the iic eeprom , and doesn't need to load firmware on usb insert.

I don't know when they release the frmware(s) for public use , but would not expect a long time.

Nice work Beiming 

/Bingo

Ohh: I get to test the F' firmware also when they're ready.

Beiming is working on their linux support again 

They apparently upgraded their linux distro , and got some linux-gpib kernel/module troubles , that i helped out with.

I'm currently testing with linux-gpib and gpib-utils , and it looks promising.
So far i have seen no differences to my Agilent adapter.

Thy are now trying to get a "scope" that has support in gpib-utils , in order to test a binary xfer (screendump)

Afaik their windows support is already ok , and it supports all the "VISA's".

I haven't tried any of the adapters on windows , as i am 95% linux based.
And would like to stay that way.

But if they get the linuxsupport error free , i'd say its a nice buy for the price.
I payed 2x the amount for the Agilent adapter on *Bay.

They support loading of firmware via fxload like the Agilent , or you could install the i2c image on the adapter once and skip the loading.

I prefer the fxload way , as i'm used to with the Agilent

/Bingo

[JoeyP]

It might also be weak drivers in the Prologix device. Do they use a real GPIB chip or some random logic gate to drive the cable? GPIB is designed to work with long cable and many devices, so the outputs are supposed to be quite beefy.

They drive the bus directly from their microcontroller, an Atmel ATMEGA644PA which seems like a cheesy way to do it. Didn't look at the output specs for that controller, but did test the adapter with about a dozen devices and much cabling when I first got it. Worked OK in that config, but just doesn't like one particular device when it's powered down. When that device is not powered up, the driver/adapter hangs in the most obnoxious way, and teaches you quickly not to forget to turn it on. If it would at least recover more gracefully from that condition I could overlook/forgive the behaviour.

[MarkL]

Dave et al,
I have recently acquired an HP (before it morphed into Agilent) 1631D logic analyzer.  My previously misspent youth was taken up with doing very serious O.S. code using a 1630 as my primary debugging and bench tool, so I have particular fondness for the good old 1630.  What's new with the 1631 as opposed to that is that it includes a 2-chennal, 50MHz DSO as part of the package.  Real cute, albeit primitive by current standards.  Nevertheless I wanted to leverage available equipment as part of my design lab, so I wanted to use the 1631 to prepare documents for standards compliance (I am working on projects that will in all likelyhood require documented compliance with EnergyStar, IEC/EC, and so on).  I want to connect the GPIB (HP-IB) interface on the back of the 1631D to my PC so I can do screen capture and saving/restoring of analyzer setups.

Hey, I too have a HP 1630G. Used it for many years, though it's currently packed away for lack of workspace.
I'll be interested to hear how you go, getting it to talk with a PC. I'd like to do that too. I have the dual floppy disk unit, but it's a pain since the floppies are non-standard format, and can't be read in PCs. I have several disassemblers for the 1630G on those disks. Would be nice to get them into a more permanently archived form.

It was always tempting to buy the analog scope card, and see if it could be added to my 1630G. The space is there, along with the holes for BNCs. The extra EPROMs are available. But I think when I looked into it there was a problem with number of EPROM sockets free. Can't recall the details.

You likely can't move from a 1630G to a 1631A/D.  Here's the detail on the (obsolete) upgrade kit:

http://www.home.agilent.com/agilent/redirector.jspx?action=ref&cname=PRODUCT&ckey=10330A%3Aepsg%3Apro&lc=eng&cc=US

As far as the GPIB connection via a PC, it does work for storing configs, doing screen captures, and getting data out of the unit.  But you may have some trouble loading the disassembler into a 163x from a PC since, according to the manual, the unit wants to talk to the disk drive directly.

For the OP, screen captures are returned in HPGL format, so you will need to convert them into something more useful for inclusion in a document.

I have a 1631D that hasn't been used in years.  It was great for its time (late 80's), but in today's terms its really quite slow and limited.

[bingo600]

Good news 

I'm currently in dialog with Beiming , and i am testing linux-gpib support on the S82357.

I have only done some light tests, with the ibtest program.
But it seems to work on my "quirky HP 5384A" that refuses to set EOI , and behaves the same as my Agilent USB adapter

This will be nice , as i paid 2x the Beiming price for an Agilent , to get Linux support.

Beiming offers 2 solutions , 1 where you load the code on usb-insert (fxload) , just as an Agilent.
And (untested by me) , one where you program the new firmware permanently into the iic eeprom , and doesn't need to load firmware on usb insert.

I don't know when they release the frmware(s) for public use , but would not expect a long time.

Nice work Beiming 

/Bingo

Ohh: I get to test the F' firmware also when they're ready.

Beiming is working on their linux support again 

They apparently upgraded their linux distro , and got some linux-gpib kernel/module troubles , that i helped out with.

I'm currently testing with linux-gpib and gpib-utils , and it looks promising.
So far i have seen no differences to my Agilent adapter.

Thy are now trying to get a "scope" that has support in gpib-utils , in order to test a binary xfer (screendump)

Afaik their windows support is already ok , and it supports all the "VISA's".

I haven't tried any of the adapters on windows , as i am 95% linux based.
And would like to stay that way.

But if they get the linuxsupport error free , i'd say its a nice buy for the price.
I payed 2x the amount for the Agilent adapter on *Bay.

They support loading of firmware via fxload like the Agilent , or you could install the i2c image on the adapter once and skip the loading.

I prefer the fxload way , as i'm used to with the Agilent

/Bingo

 I just got word from Beiming that they have released the linux (linix-gpib) support firmware for their two USB GPIB adapters - S82357 and F82357 (DMA).

They got the "OK" from the linux-gpib maintainer , where he writes :

I tested your GPIB interface with my Signal Generator and it worked perfectly first time, no problems. For the next release of linux_gpib 3.2.19 I will include your product in the supported devices part of the documentation.

According to Beiming , the firmware should support "Visa" with HP drivers under windows , and now also linux-gpib.

Nice to know there is a $79 / $99 unit with both Win 6 Linux support

/Bingo

[madshaman]

I use this thing: https://www.sparkfun.com/products/549

[RobbieC]

I picked up the Ethernet version of the Prologix to talk to the six or seven GPIB devices I have (including a HP 1650B LA). So far I've only done a few simple comms tests, but I'll be putting some .net programs together that will talk to multiple instruments so that should shake out how well the Prologix works.

Th nice thing about the Ethernet version is the lack of drivers and the ability to access it remotely (say, from upstairs since all of my gear is in the colder basement =).

[samofab]

Anyone tried this one?

 http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=261254570258

I heard that this one has problems with Tek binary transfers.. aparently it works otherwise.

[tinhead]

Anyone tried this one?

 http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=261254570258

I heard that this one has problems with Tek binary transfers.. aparently it works otherwise.

that thing is clone of Beiming GPIB-USB S82357 adapter, it does use one of the early firmwares. I do not recommend to use it, if spend money then at least on a product where one know that the manufacturer is updating firmware/fixing bugs, like the S82357 or F82357 from Beiming.

[mrflibble]

Do you want to have to unplug a bunch of these when devices are shut down? It's the adapter's fault.

I don't disconnect them. I just make sure the troublesome device is powered up. I realize that this shouldn't be necessary. The GPIB spec says that devices are not supposed to load the bus when power is off. But, I've found that not all devices - particularly older ones, honor that part of the spec. I do suspect the adapter, but it could also be the fault of a non-compliant device in my stack, so don't want to bad-mouth the product without knowing for sure. It only happens with a certain device. Others can be powered off without issue.

I noticed mention of this in other threads as well. Is this a particular measurement device? If so, which one? Or is this the GPIB-USB adapter? I noticed in the SN75160/1B datasheets they make a big point that they do not load the bus when VCC = 0, which would be the case when the gpib adapter is powered off. But in your case the adapter is on, but one of the devices is off right? If so, have you even had the chance of testing it with a "proper" gpib adapter that could sink enough current?

[alex.forencich]

I picked up the Ethernet version of the Prologix to talk to the six or seven GPIB devices I have (including a HP 1650B LA). So far I've only done a few simple comms tests, but I'll be putting some .net programs together that will talk to multiple instruments so that should shake out how well the Prologix works.

Th nice thing about the Ethernet version is the lack of drivers and the ability to access it remotely (say, from upstairs since all of my gear is in the colder basement =).

Ethernet is definitely the way to go.  The old HP E2050A units pop up on ebay from time to time for less than $100.  The Ethernet side only supports 10 Mb ethernet, but that's already faster than the GPIB side so it's not really an issue.  They speak VXI-11, so they work with all of the VISA libraries.  I have a pair of them myself, and I wrote a nice cross platform Python library that works perfectly with them. 

The only thing I really don't like about all of the Prologix stuff is that it doesn't support the standard protocols for communicating with the adapter.  If their Ethernet cable spoke VXI-11, it would be decent deal. 

[free_electron]

The Ethernet side only supports 10 Mb ethernet, but that's already faster than the GPIB side so it's not really an issue. 

you need to read up on your standards ...

1)  10 megaBIT ethernet has an effectiveusable rate ( if on a dedicated link ) of about 9megabit ( there is overhead bytes in mac and IP address. The usable payload is smaller)

2) GPIB in its base 488 standard is a 10 megaBYTE transfer rate and can go 25 Megabyte/S in 488.2 (Turbo mode). you need at least a 100base-T link to keep up with a GPIB bus going flat out.

[alex.forencich]

The Ethernet side only supports 10 Mb ethernet, but that's already faster than the GPIB side so it's not really an issue. 

you need to read up on your standards ...

1)  10 megaBIT ethernet has an effectiveusable rate ( if on a dedicated link ) of about 9megabit ( there is overhead bytes in mac and IP address. The usable payload is smaller)

2) GPIB in its base 488 standard is a 10 megaBYTE transfer rate and can go 25 Megabyte/S in 488.2 (Turbo mode). you need at least a 100base-T link to keep up with a GPIB bus going flat out.

I stand corrected.  I was under the impression that GPIB only ran at around 1 MBps or so.  In that case it seems like you would need gigabit ethernet to keep up with turbo mode as 100 Mbit only provides 12.5 MBps. 

[free_electron]

Possibly.
GPIB is very fast synchronous bit parallel, byte serial bus with handshaking and multimaster capability. HP actually had computers where the harddisks , floppy or tape drives were connected on the HPIB bus. The drive unit had its own controller. See it as an early kind of SCSI.

Those controllers used DMA techniques to tranfer large blocks of data very efficiently.

The reason GPIB controllers cost money is due to licencing.
HP's licencing model has always been
-devices do not need to pay licences. Meaning, everyone is free to make a piece of testequipment , or other equipment, that can connect to a GPIB link as a device.
-controllers need to pay a licence. So any computer or instrumnet with those capabilities (instruments that can drive a plotter for example) need to cough up some dough to HP.

That is the reason those boards are so expensive.

Making the device usage free guaranteed a very quick uptake by other manufacturers so they would be compatible. Since you have multiple devices on a bus the cost of the host is shared amongst devices.

National sells their TNT4882 asic in two flavors : one that is host capable , one that is not. They fry an internal fuse. The standard chip is like 4$, the host capable one requires signing of paperwork and costs 54$...

Traditional chips have now all gone the way of the wind. TMS9914, upd7210 , MC68488, hef4788, intel 8291/8292/8293 are all gone.

The intel solution was actually a really nice one. 8293 was their equivalent for the 75160/75161 transceivers. The 8291 was the base GPIB logic. Add on the 8792 to become a master. So only the 8792 requires licencing. It was actually a mask programmed 8048 processor.

National still sells the NAT7210 and NAT9914 as drop in replacements for the NEC and TI , but i think the master capabilites are disabled in those.

Agilent is facing problems in their instruments as well as the original devices are gone. They went so far as to implment the logic either in the ASIC, and for older machines they had a custom chip made by TI called the ML9914. This is again a 9914 that has no master capability.

[mrflibble]

So in summary the  SN75160B + SN75161B are the only "proper" ones left that are actually available and affordable? As for ethernet, I'd say 10 MBit is perfectly fine for just controlling and doing regular readouts. If you need lots of binary transfers then 100 MBit should do the trick in most cases. Gbit is nice but would seem bit overkill to me, especially if you have a nice long GPIB cable dangling on the other end. Parallel port transfers with dma (ECP and all that) pooped out round 35 MByte/s, and that was with a short cable. Don't see GPIB with it's open collector and long cables and multiple devices attached going to reach stellar speeds.

Anyways, that's from a homebrew perspective. 100 mbit is easy enough, gbit not so much. If you are going to professionally manufacture those might as well go for gbit to get that extra bit of transfer speed + lower latency.

[free_electron]

SN75160B + SN75161B are only the bus drivers. they contain no intelligence.

With all those chips i listed ( apart from the intel ones ) you needed the SN75160B + SN75161B as well.

those bus drivers are special. they can drive easily 50 to 100 mA per pin.
GPIB is NOT open collector !
the TALKER is alsways driving the bus hard from a totem-pole output. If a device is on the bus but in off-line state ( not listening , meaning not beeing addressed) then
it is in open-collector mode with pullups off. So it forms no load on the bus. This is why a device that is powered off has no impact on the bus. you can leave it connected . it does not disrupt bus activity

A connected device in listening mode (being addressed ) turns on its pull up resistors.

so essentially the pull up resistors on the network are always where they need to be : at the device that is the current active listener. This guarantees good signal integrity without having to handle the load of 10 pullup resisotr sin parallel if 10 devices are connected.

GPIB is a very cleverly constructed bus.

[MarkL]

The Ethernet side only supports 10 Mb ethernet, but that's already faster than the GPIB side so it's not really an issue. 

you need to read up on your standards ...

1)  10 megaBIT ethernet has an effectiveusable rate ( if on a dedicated link ) of about 9megabit ( there is overhead bytes in mac and IP address. The usable payload is smaller)

2) GPIB in its base 488 standard is a 10 megaBYTE transfer rate and can go 25 Megabyte/S in 488.2 (Turbo mode). you need at least a 100base-T link to keep up with a GPIB bus going flat out.

As per IEEE 488.1, interlocked GPIB transfer rates top out at about 1Mbyte/s.  NI introduced non-interlocked transfers (aka HS488) in IEEE 488.1-2003, which has a maximum rate of about 8Mbytes/s and depends on the total length of the bus.  I've never heard of "Turbo" mode (is that some proprietary implementation?).  488.2 specifies higher layer command structures and doesn't deal with physical layer transmission rates and timing.

GPIB is NOT open collector !
the TALKER is alsways driving the bus hard from a totem-pole output.

Actually, 488.1-2003 (sec 5.3) permits the use of open collector drivers and requires it on certain signal lines.  It also requires it on the data lines if parallel poll operations are to be performed.  However, using open collector drivers during regular data transfers have a detrimental impact on the bus speed due to the slower rise time, and three-state drivers are therefore recommended.

To the original question on interfacing GPIB to Ethernet, most pieces of equipment have slug-like GPIB implementations and wouldn't get close to saturating a 10Mb Ethernet.  You will find HS488 on NI's controllers (no surprise there) and some Tektronix gear, but I don't think it was widely implemented by most equipment manufacturers.  I wouldn't feel that 100Mb Ethernet had to be in the mix for a workable solution, let alone 1G.

[free_electron]

Oops, now i got my revisions confused. 488.1. Is hardware, 488.3 is software.
Turbo mode is a mode implemented by the tnt4882 asic . This can go. Uch faster than standard gpib ,but only for data transfer. Timing of the other signals is the same. It uses a 48MHz master clock and data is pumped at half that speed.
This mode only works between the tnt4882 chips. It is national instruments proprietary.
I had their development kit at one time. We built a machine with that chip in and could use that mode to stream samples very fast.

As for the open colllector/ totempole discussion: of course the drivers switch to open collector during a parallel poll as you do not know how many responders will drive.
The point is you need a chip that can switch between totempole and open collector. Sinply i plementi g a dumb open collector only with pullups is going to give trouble, especially on long lines and with 4 or more instruments attached. I have setups with 20 or more. Machines where i need bus repeaters to improve drive strength. The standard 75160 can handle 15 devices without problems.

[macboy]

SN75160B + SN75161B are only the bus drivers. they contain no intelligence.

With all those chips i listed ( apart from the intel ones ) you needed the SN75160B + SN75161B as well.

those bus drivers are special. they can drive easily 50 to 100 mA per pin.
GPIB is NOT open collector !
the TALKER is alsways driving the bus hard from a totem-pole output. If a device is on the bus but in off-line state ( not listening , meaning not beeing addressed) then
it is in open-collector mode with pullups off. So it forms no load on the bus. This is why a device that is powered off has no impact on the bus. you can leave it connected . it does not disrupt bus activity

A connected device in listening mode (being addressed ) turns on its pull up resistors.

so essentially the pull up resistors on the network are always where they need to be : at the device that is the current active listener. This guarantees good signal integrity without having to handle the load of 10 pullup resisotr sin parallel if 10 devices are connected.

GPIB is a very cleverly constructed bus.

This is not correct, GPIB is definitely driven open-collector. Only with "newer" ( ) high-speed devices is the bus actively driven High. Absolutely all devices must conform to the open-collector mode of operation and optionally can use what HP calls tri-state, where it can drive high or low or go high-impedance for input. The SRQ, NDAV, and NRFD are all open-collector only.  In either case, the receivers need to conform to (inverted) TTL levels: 2.0 V or higher is a 0 and 0.8 V or lower is a 1. This is where a lot of homebrew implementations fail; people use CMOS microcontrollers that need 0.8*Vcc (4+ V) to register a reliable High level (and which at 5 V Vcc will usually register < 2.5 V as low, contrary to the spec).

Every low-level detail of the GPIB can be found in HP's "Tutorial Description of the Hewlett-Packard Interface Bus".

[MarkL]

This is not correct, GPIB is definitely driven open-collector. Only with "newer" ( ) high-speed devices is the bus actively driven High. Absolutely all devices must conform to the open-collector mode of operation and optionally can use what HP calls tri-state, where it can drive high or low or go high-impedance for input. The SRQ, NDAV, and NRFD are all open-collector only.

Well, that's not quite right either.  Here, this is what 488.1-1987 has to say about it (and it's identical in 488.1-2003):

3.3.1 Driver Types

Open collector drivers shall be used to drive the SRQ, NRFD, and NDAC signal lines.

Open collector drivers or three-state drivers may be used to drive DIO 1-8, DAV, IFC, ATN, REN, and EOI signal lines with this exception: DIO1-8 shall use open collector drivers for parallel polling applications (see 2.9.3.3 ).

NOTE — Three-state drivers are useful for systems where higher speed operation is required.

It is recommended that a three-state driver be used within a controller to drive the ATN signal line if the controller is intended to be used in a system in which other devices are implemented with three-state drivers on the DIO, DAV, and EOI signal lines.

Every low-level detail of the GPIB can be found in HP's "Tutorial Description of the Hewlett-Packard Interface Bus".

The actual spec works pretty well too.

[free_electron]

This is not correct, GPIB is definitely driven open-collector. Only with "newer" ( ) high-speed devices is the bus actively driven High. Absolutely all devices must conform to the open-collector mode of operation and optionally can use what HP calls tri-state
[/quote]
All the boards i know of (and there are a lot) use totem pole drivers ( what is called three-state ). When a device is talking the drivers are switched in push-pull and the listener has its pull ups enabled. When a device goes off-bus it disables its pull ups.
The 75160 and 161 has a special io structure to make sure that there is no load when the chip is without power. you can turn off a device ( cut power) while leaving it attached to the bus. This has no impact.

I've done a number of custom instruments that had a GPIb interface using both the uPD7210 and the TNT4882 chip.
I have seen implementations 'el-cheapo' where they hard strap the control pin on the 75160 so it becomes an open collector device but that is NOT the recommended way.

[xzswq21]

I have an old HP spectrum analyzer (HP8560), so I need a GPIB to USB adapter to capture some pictures from the Screen, there are many GPIB to USB adapters in eBay and I'm confused to choose one!

Prologix:
https://www.ebay.com/itm/Prologix-GPIB-USB-Controller-/265103834697?_trksid=p2349624.m46890.l49286

Could you please help me to find a proper Adapter in eBay? Not expensive. I don't have any problem with the used original adapters. Thanks