At least it renders the Markdown.
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".
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”.
GPIB GET works by first configuring a subset of bus devices as listeners and then sending a single-byte message (it’s an 8 bit bus, so one bus cycle) with the ATN line asserted. It’s intrinsically low latency without any special effort.
Whether that makes it worthwhile to put GPIB on a new instrument in 2025 is a different question. I’m only addressing “what does GPIB give you”?
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).
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.
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.
This is my first ever engineering project, as a newly-minted electrical engineer (downloads a PDF): https://littlegreenviper.com/wp-content/uploads/2022/07/TF30...
https://www.microchip.com/en-us/products/microcontrollers/8-...
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.
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.
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.
sansseriff•1mo ago