Linux gpib also supports my adapter natively with a special linux gpib firmware you can download from the page above. It also supports multiple instruments connected to one adapter then.

As I have a CMU200 myself I was majorly interested in getting it to work too :-)

I know that very well. Ethernet=security concern. Connecting your shiny new scope to company network=no way. Hard to discuss arround it in company environments or push for split network topologies.

Yes, those cables are often called "garden hose cables". The only benefit of that bus infrastructure under a nowadays view is that it gives the ability to synchronously trigger multple instruments which is very rarely used or required.

The step to go to ARM or risc v based controllers is easy. That's what I did with V3. Gives a tremendous performance boost and costs 1/2 of that old AVR.

I'm curious what MCU you landed on, but also a suggestion. If you could move the pictures to a different repo (or branch at least) that would make much easier to download. Even now a shallow clone takes ≈20 MB.

Yes, it is easier to fall into the trap of getting a clone, even if you think you buy an original one.

A good way around application overloaded applocation stacks is R&S Visa which is lean and mean while still exposing full visa to applocations like labview. Or going with something like python usbtmc. If you also have other instruments to control e.g. with usb or ethernet you'll likely anyway look into a visa.

Works even well on Mac and Raspberry PI btw :-)

Actually world would need an open source visa stack. Right now you find many applications doing their own thing, but then not supporting vxi11, hislip or usbtmc. Visa is something which solved that problem for years already but the most standard package NI Visa is overloaded and scaring people away. For that reason I propagate the usefulness of R&S Visa a lot. Lean and mean, supporting all OS and procotocols as it is supposed to be.

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.

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.

> Or companies that see Ethernet as a potential security attack vector.

It's sad how true this is. VXI gets corporate IT all prickly. An airgapped lab network would be safer but somehow they hate that idea even more.

GPIB isn't even on their radar. Test to your heart's content. It's not a "network".

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.

HPIB/GPIB itself should be reasonably fast, I think NI had some later revisions that were even faster. If I had to guess there will be two big hardware bottlenecks with the open source dongles: almost all of the 8-bit and cheaper ARM boards only do USB FS (12 Mbps, so 1MByte is pushing it) and most of those boards don't have any hardware acceleration for managing a parallel bus like GPIB. Even switching up to a Mega/Due form factor means you could potentially read the status and entire data byte in one read.

FWIW I'm working on a buzzword compliant stack for ARM MCUs interleaved with writing some HALs for Embassy. It'll be interesting to see how it compares. While I'm waiting on a replacement Chinese clone I decided to order a few more boards (Atmel, NXP, Renesas, STM), level shifters, transceivers, and whatnot from DigiKey to play around with.

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.