Great work making this available for sale. NI and Keysight are the only two traditional vendors of this kind of thing and they’re priced close to $1k these days. There are tons of knock-offs on Ebay that won’t last more than a few months if they ever work.
You are correct. UsbTmc exposes no multi device capability. Also when I made first versions many years ago I had no "garden hose" GPIB cables and saw they were more expensive as the whole adapter.
V3 which will come early next year supports GPIB daisy chaining/multi device support via Ethernet VXI11 & HiSlip.
The V2 adapter shown here supports trigger, SRQ, serial poll, trigger, clear, local lockout, goto lockal, pulse indicator, all features though.
If you absolutely need common synchronous trigger to a chain of GPIB instruments which is quite seldomly absolutely required, you'll have it in next version V3.
Interesting. I built an AR488 a while back (https://github.com/Twilight-Logic/AR488) and it worked alright for my needs. I'd be interested to see a comparison of the two projects.
Ooh! The faster speeds would be very welcome, I was bothered by the slowness of the AR488 but I assumed that was just how GPIB was (I had no baseline to compare to). I'll switch over when I get a chance.
That user's project also looks very interesting - My TDS684A's CRT seems to have died, and rather than fix it I could switch to using a software scope.
The upcoming V3 adapter reaches even more than 1 MByte/s with my fastest instruments. Unless you connect long GPIB cables to it, because capacitive load slows down GPIB as it self regulates speed down in the way GPIB is designed.
Am I wrong in understanding that each physical device supports only a single GPIB device at a time? The enumeration and discovery scheme is certainly novel, but one device per hardware would seem to prevent using some of GPIB’s advanced features like parallel polling and low latency triggers.
There’s a fairly large second-hand market for old electronics test equipment. A lot of that stuff only had GPIB ports, even well into the 90s. Cheap Chinese entrants (Rigol, Siglent, etc.) only within the last decade started making an impact
Maybe someonw can explain me, but I never understood the appeal of GPIB for modern instruments (legacy instruments are of course "excused"). Electrically is a terrible interface that introduces ground loops with the control computer. Speed are laughable and it requires exensive and exotic adapters with complex sw stack (I wish this projects good success, it's needed!). Ethernet in comparison tick all my boxes. It's electrically decoupled by default (just use UTP cables), crazy cheap, very fast and with sane sw stack thanks to vxi-11. You can even bypass visa if you wish and open a plain TCP socket, no need for any library. What am I missing?
Not much, but consider latency: You can use the Group Execute Trigger (GET) to simultaneously trigger multiple instruments with both very low latency and very low latency dispersion. Think, easy-to-use sub-microsecond synchronization.
Ethernet and USB 4 may have orders of magnitude more bandwidth, but can’t achieve the same multi-device synchronization capability without side channel signals.
Now, sure, you can add the same capability with a programmable pulse generator connected via coax to the trigger input of all your instruments, but GBIP lets you do that with just the data connection (and you don’t always have a spare trigger channel). The only other protocols I know of with similar capabilities are PXI and PXIe, which are “PCI(express) in an incompatible form-factor, plus some extra signals for real time synchronization”.
If you buy used equipment which doesn't have Ethernet or your company wants you to ise the stuff that is in the Lab since 10+ years there's simply no other choice. Or companies that see Ethernet as a potential security attack vector.
It's indeed not that GPIB is better than Ethernet. In tiny aspects that's argueable, but as general statement true.
I strongly suspect that this does not meet the strict timing requirements that GPIB has. Putting this on your bus is likely to violate both the T1 hard timing requirements and the impedance requirements.
Use of the "standard" set of 74-series buffers that everybody uses would meet impedance requirements and would also allow the usage of a much faster MCU which likely could be made to adhere to the strict T1 timing requirements (with the caveat that most microcontroller USB stacks are piles of garbage that demand that they get interrupt priority even when you tell them otherwise).
For a situation where the instrument is directly connected to the adapter like here there is no difficulty in fast T1 timing on a MCU.
V3 will have btw. fully compliant GPIB electrical specs without 74 series buffers.
48mA drivers are not required for a direct connection scenario as V2 supports. VIH is a bit violated, though not practically meaningful. So far I heard of no device not working after over 6 years and those who did not in early stages I managed to get running with sw updates.
This is not a one shot plain textbook GPIB simple thing implementation, it's years of iterations, debug, improvement.
Great work making this available for sale. NI and Keysight are the only two traditional vendors of this kind of thing and they’re priced close to $1k these days. There are tons of knock-offs on Ebay that won’t last more than a few months if they ever work.
I wish AVR DU series had any sort of open source support, we could finally move on from 32U4.
https://www.microchip.com/en-us/products/microcontrollers/8-...
You are correct. UsbTmc exposes no multi device capability. Also when I made first versions many years ago I had no "garden hose" GPIB cables and saw they were more expensive as the whole adapter. V3 which will come early next year supports GPIB daisy chaining/multi device support via Ethernet VXI11 & HiSlip. The V2 adapter shown here supports trigger, SRQ, serial poll, trigger, clear, local lockout, goto lockal, pulse indicator, all features though. If you absolutely need common synchronous trigger to a chain of GPIB instruments which is quite seldomly absolutely required, you'll have it in next version V3.
Interesting. I built an AR488 a while back (https://github.com/Twilight-Logic/AR488) and it worked alright for my needs. I'd be interested to see a comparison of the two projects.
Here a comparison from a user: https://github.com/xyphro/UsbGpib/discussions/47
Ooh! The faster speeds would be very welcome, I was bothered by the slowness of the AR488 but I assumed that was just how GPIB was (I had no baseline to compare to). I'll switch over when I get a chance.
That user's project also looks very interesting - My TDS684A's CRT seems to have died, and rather than fix it I could switch to using a software scope.
The upcoming V3 adapter reaches even more than 1 MByte/s with my fastest instruments. Unless you connect long GPIB cables to it, because capacitive load slows down GPIB as it self regulates speed down in the way GPIB is designed.
Am I wrong in understanding that each physical device supports only a single GPIB device at a time? The enumeration and discovery scheme is certainly novel, but one device per hardware would seem to prevent using some of GPIB’s advanced features like parallel polling and low latency triggers.
Glad to see there's a REV 3 in progress that would support ethernet. That's the one thing that would make me go out of my way to build one of these.
Isn't this a better link? https://github.com/xyphro/UsbGpib/blob/9a8c18a7be1b17127496e...
At least it renders the Markdown.
I cut my teeth on IEE-488. I didn’t realize that it was still a thing.
There’s a fairly large second-hand market for old electronics test equipment. A lot of that stuff only had GPIB ports, even well into the 90s. Cheap Chinese entrants (Rigol, Siglent, etc.) only within the last decade started making an impact
Linux mainline kernel just had support for GPIB added. https://hackaday.com/2025/12/16/after-decades-linux-finally-...
Maybe someonw can explain me, but I never understood the appeal of GPIB for modern instruments (legacy instruments are of course "excused"). Electrically is a terrible interface that introduces ground loops with the control computer. Speed are laughable and it requires exensive and exotic adapters with complex sw stack (I wish this projects good success, it's needed!). Ethernet in comparison tick all my boxes. It's electrically decoupled by default (just use UTP cables), crazy cheap, very fast and with sane sw stack thanks to vxi-11. You can even bypass visa if you wish and open a plain TCP socket, no need for any library. What am I missing?
> What am I missing?
Not much, but consider latency: You can use the Group Execute Trigger (GET) to simultaneously trigger multiple instruments with both very low latency and very low latency dispersion. Think, easy-to-use sub-microsecond synchronization.
Ethernet and USB 4 may have orders of magnitude more bandwidth, but can’t achieve the same multi-device synchronization capability without side channel signals.
Now, sure, you can add the same capability with a programmable pulse generator connected via coax to the trigger input of all your instruments, but GBIP lets you do that with just the data connection (and you don’t always have a spare trigger channel). The only other protocols I know of with similar capabilities are PXI and PXIe, which are “PCI(express) in an incompatible form-factor, plus some extra signals for real time synchronization”.
If you buy used equipment which doesn't have Ethernet or your company wants you to ise the stuff that is in the Lab since 10+ years there's simply no other choice. Or companies that see Ethernet as a potential security attack vector. It's indeed not that GPIB is better than Ethernet. In tiny aspects that's argueable, but as general statement true.
Nothing, other than perhaps just much high-quality legacy equipment is out in the field that still works fantastically.
very impressive. better than anything on the market either NI or Keysight.
I strongly suspect that this does not meet the strict timing requirements that GPIB has. Putting this on your bus is likely to violate both the T1 hard timing requirements and the impedance requirements.
Use of the "standard" set of 74-series buffers that everybody uses would meet impedance requirements and would also allow the usage of a much faster MCU which likely could be made to adhere to the strict T1 timing requirements (with the caveat that most microcontroller USB stacks are piles of garbage that demand that they get interrupt priority even when you tell them otherwise).
For a situation where the instrument is directly connected to the adapter like here there is no difficulty in fast T1 timing on a MCU. V3 will have btw. fully compliant GPIB electrical specs without 74 series buffers. 48mA drivers are not required for a direct connection scenario as V2 supports. VIH is a bit violated, though not practically meaningful. So far I heard of no device not working after over 6 years and those who did not in early stages I managed to get running with sw updates. This is not a one shot plain textbook GPIB simple thing implementation, it's years of iterations, debug, improvement.