HN Reader

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.

Ooooo, and it supports secondary addressing? NONE of the low-cost interfaces support secondary addressing! (At least last time I looked around!)

That's a big deal for those of us with R&S CMU200's / CRTU's, which require secondary addressing to make it act like a spec-an with tracking generator. And I see that in your list of tested equipment!

Fantastic. And the price of prebuilt units is super reasonable. I'm in.

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-...

If you control your application stack, you can pivot from expensive NI GPIB hardware to something cheaper. Besides prices, you get the advantage of not requiring a 1.5GB Windows-only NI MAX install on a PC just to connect to the device.

Since I hadn't heard of open source hardware, I bought 5 of these [0] instead around 2020 and they've been reliable for daily lab use. You just connect to them over TCP and send a couple of commands to select the GPIB addr to correspond with; after that, you can send SCPI commands the same way you always do.

[0]: https://prologix.biz/

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.

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.

Isn't this a better link? https://github.com/xyphro/UsbGpib/blob/9a8c18a7be1b17127496e...

At least it renders the Markdown.

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.

I cut my teeth on IEE-488. I didn’t realize that it was still a thing.

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?

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).