Yet Another USB GPIB Interface (yaugi)

[essele]

I know there are quite a few of these being developed, but I thought this was sufficiently different to warrant publishing.



As the name suggests this is a USB to GPIB interface, along the lines of the Prologix adapter (or many other examples.)

The reason I started building this was that I couldn't find anything that was sensibly priced or easy to use and it seemed like a fun and fairly straighforward project ... there is no commercial intent here, I'm very happy to open source it if anyone finds it useful.

The basic idea is:

- Driven by a PSoC 4200L MPU
- No interface chips (to keep the cost down)
- Supports USBUART already, potential for USBTMC
- EEPROM support for storing settings
- Potential to hardware accelerate the GPIB handshake
- More usable interactive interface (for setup etc)
- Open drain GPIO's allow detection of GPIB device
- Low cost, not much more than the CPU and connector.

The PSoC has everything pretty much built in including full speed USB, so UART over USB capability and potential for USBTMC, it should be able to do both at the same time with a composite device configuration.

As far as cost goes ... there's not a lot to it... the CPU, the main connector, a 10-way programming header, the USB socket, a poly-fuse, a diode, and a few decoupling capacitors ... the led's and button are optional and not used at the moment.

Using mouser/digikey etc, even for a one-off, it should be not far off £10 in components, and with connectors from eBay or Aliexpress you can shave another couple of pounds off. Five boards from JLCPCB are $2 plus shipping. It's pretty easily hand soldered.

Obviously without the standard GPIB interface IC's it's not technically meeting the GPIB spec, so it won't support a full length bus with lots of devices ... I've only tested with one device currently, but I would be suprised if it didn't work with a handful and sensible cable lengths.

The programmable hardware aspect of the PSoC means that you can build the handshake into hardware and acheive improved speeds, certainly better than you get with bitbanging ... I haven't done this yet, it's next on my list.

Currently I'm implementing the Prologix command set, and I've added some features to make the interactive experience a bit better, simple command line editing, last command recall etc. It won't be used once in an automated system, but it makes setting it up and testing much easier.

I've also added a few other bits to improve usability, for example the option of auto read-after-write only if the last command included a "?".

I've only tested it against a 34401 so far, I've got a few other devices to test with (K2000, Prema DMM, Datron calibrators) but I certainly don't have a wide range, so this is somewhere I could do with some help, specifically with more complex devices, subaddressing, binary data transfers etc.

Next things I'm planning on looking at:

- Finish off command set
- Hardware acceleration of handshake / DMA data transfer
- Bootloader support to allow firmware upgrade over USB
- Design of a new board to fit into a sheilded connector (potential)
- USBTMC and Composite USB

If there's any interest, I'll stick the code and KiCad files into GitHub ... if not, that's fine also!

Lee.

[sokoloff]

Very nice; there’s definitely going to be interest here!

[Black Phoenix]

One more here interested.

[Magnificent Bastard]

I'm interested also-- please do post on GitHub, as there are many more people that will no doubt be interested!

[essele]

Great - I’ll try to get it all uploaded tomorrow!

[JBeale]

Looks like a very reasonable design. I think the people who would be using this kind of DIY interface board probably don't have a big rack of GPIB devices to control.  Given the cost of just one genuine GPIB cable, you might as well use one board per instrument, instead of using more GPIB cables.

[Bicurico]

Hi.

I am definitely interested.

One important aspect for me is the transfer speed.
The chinese cloned Agilent USB GPIB adapters achieve quite high transfer rates.
Being able to build something similar speed-wise would be great.

The other aspect is of course how to communicate through this adapter. Would it simulate a RS232 or RJ45 port?

Regards,
Vitor

[ebclr]

Another interested,  with PSoC, will be even better

[artag]

One important aspect for me is the transfer speed.
The chinese cloned Agilent USB GPIB adapters achieve quite high transfer rates.
Being able to build something similar speed-wise would be great.

What would you test speed against ?
I did some measurements on the AR488 adapter described elsewhere and was getting about 44us per handshake. This is very misleading though - it was reading the *idn response from an HP53131A and the HP is limiting the speed before the AVR bitbanger does. And then there's all the overhead of setting up the transfer (addressing) and sending the data back to the host.

So the overall speed of the transaction will work out way slower than this 22k/s, but the actual micro is capable of going faster against a faster instrument. It really needs to be measured against something doing much longer transfers without the instrument limiting it. I'm unlikely to get to the sub microsecond times that full bus IEEE-488.2 speed would permit but I can probably improve on what I'm seeing now. Maybe 100k ?

I don't think I've got anything suitable : the instruments I have with display screens that might do a big screen dump have ethernet and USB, not GPIB. Can you suggest a test subject ?
 

[pigrew]

Very nice, I like it.

I recently implemented USBTMC/USB488 as part of the "tinyusb" stack (which I've been using with the STM32), though it isn't at all optimized for speed. USBTMC is complicated if one wants to fully meet the specification (the reset/clear/abort states are tricky).

The USBTMC spec describes communication with only a single device. However, it does leave the opportunity open for vendor messages which could be used to change the address on the bus. Parallel poll may also need a special vendor command.  On the other hand, the whole adapter might be cheap enough (< US$20) that it would be reasonable to give each device its own adapter (reducing the need for special commands). Though for properly implement triggering, one really does want all the devices connected on the same bus.

I'd be happy to look over a proposed interface on how to map USB488 to be a GPIB controller, or write up a draft if you're interested.

(And as a sidenote, I had been considering developing an adapter along the same lines, except using a STM32 and with the SN75ALS161/SN75ALS162 driver ICs.)

What would you test speed against ?
I did some measurements on the AR488 adapter described elsewhere and was getting about 44us per handshake. This is very misleading though - it was reading the *idn response from an HP53131A and the HP is limiting the speed before the AVR bitbanger does. And then there's all the overhead of setting up the transfer (addressing) and sending the data back to the host.

So the overall speed of the transaction will work out way slower than this 22k/s, but the actual micro is capable of going faster against a faster instrument. It really needs to be measured against something doing much longer transfers without the instrument limiting it. I'm unlikely to get to the sub microsecond times that full bus IEEE-488.2 speed would permit but I can probably improve on what I'm seeing now. Maybe 100k ?

12 Mbps (full speed) USB sends packets every millisecond. One shouldn't expect full-speed USB to have a latency any better than this. High speed (480 Mbps) USB can have latencies of 125us (micro-frame), or maybe 1us for interrupt tranfers. One should be able to get bulk transfers up to maybe 5 Mbps over full speed USB. So, maybe this is the direction future development... to implement a high-speed USBTMC based adapter. (Or maybe you're only counting the timing of talking to the device, not the extra latency due to USB... anyway, it's something to think about)

[Theboel]

Interested 

[james_s]

Looks nice and clean. Personally I would have used a standard USB type B rather than the fragile mini or micro given how big and chunky GPIB stuff is. Also if the connectors are on the other side of the PCB it would probably be easier to put it in an enclosure. I suppose in a pinch some big heatshrink tubing would probably sufficiently protect it though.

[maginnovision]

I'd probably modify to use through hole for USB and solder a cable. Looks good though.

[chickenHeadKnob]

To essele

  What is the part number of the right angle gpib connector you are using and does the hole pattern align to a 0.1 inch grid, that is match a perf board? I ask because the NorComp connectors I was looking at don't align. thanks.

I was hoping to avoid buying an extra solder cup connector  just for prototyping .

[essele]

So the connector is a NorComp one I'm afraid, so you are correct the pins are not on a 0.1" pitch.

Also, for note, the symbol and footprint you can get from Mouser is wrong ... firstly the pin numbering is incorrect, and when corrected (based on pin 1) it's then back to front.

The first problem is the reason I have v1.1 of the board, and the second problem is the reason the connector is on the back -- I seem to not be learning from my schoolboy errors! ;-)

I've also grabbed a few connectors from eBay, which are a little cheaper (but same pitch):

https://www.ebay.co.uk/itm/Centronics-Plugs-Sockets-PCB-PCB-R-Angle-and-Ribbon-Cable-Mount-14-50-Way-EB/391507935311?ssPageName=STRK%3AMEBIDX%3AIT&var=660671677953&_trksid=p2057872.m2749.l2649

... and I'm just waiting for some from Aliexpress, which are a great price if they are ok:

https://www.aliexpress.com/item/32795413098.html?spm=a2g0s.9042311.0.0.5f974c4dp84EeU

On the USB connector ... this was originally just an experiment, the longer term plan was/is to build this into one of those shielded connectors with the usb cable soldered on. I'm waiting for some of those to arrive to see if it will all fit.

The timing questions are interesting ... I'm going to connect up a scope later and see if I can get a good view of timing, as with @artag I suspect I will also be limited by the device I'm using at the moment.

EDIT: I'm seeing good bursts of about 23uS per handshake during either *IDN? or READ?, although some bytes are much slower than that ... all of which I think is the device. It manages around 12uS per handshake for the four bytes sent to change talker/listener. All of this is with a 2uS settle time. If I get a chance later today I'll try some other devices, this was a 34401A.

[artag]

I've had (male, straight and RA) GPIB connectors from that ebay vendor and am very happy with them. Not sure who the manufacturers are - there's no logo on them - and they have a screw thread in the lugs (unlike the Norcomp ones I can see at Digikey).

They have the usual pitch, not 0.1". However, my first prototype used a right angle connector (which therefore has quite long pins) and I cut away part of the plastic bracket to free the pins up. They could then be pulled far enough apart to fit perf board.

I've also got a few spare pcbs from my first revision of the board : it was designed to be easy to track rather than efficient in operation and I'm happier with the second version. But those will work perfectly to adapt the microribbon pinout to a 24 pin DIP.

 

[essele]

Just soldered some test wires on and looked at the whole handshake ... it was taking about 6us to do the handshake (for receiving), but with a few inlines that's now about 4us ... but it is indeed the 34401A that's adding all of the delays, there's about 19us from NDAC/NRFD to the next DAV, although sometimes more than double that.

Ignoring device added delays and if you assume 2us for data settling (I'm not looking at the data lines), then this would be approximately an 8us best case, so theoretically about 120kbytes/s with bit banging. (Notwithstanding getting that data over USB.)

I've just tried a Keithley 220 ... it's nice that it just worked!  However the best case byte I see there is about 180us, again with some much slower, in response to just about anything (haven't read the programming details, it always seems to return the same stuff.)

[artag]

That ties up nicely with what I saw on the AVR - of the 44us, about half was waiting for the response. The AVR code is written for clarity rather than speed which also makes it nicely adaptable for different pinouts, but I would think it could be brought closer to your 6us.

I'm interested in trying this on a Cypress FX2 - it's what the HP (and clone) interfaces use, albeit with extra hardware. The FX2 has its own handshake assist logic but I don't know if it's sufficient to do the GPIB handshake yet.

However, shaving a few more us off the handshake has limited returns if the typical instrument is fairly slow. It's only worth doing (other than for the satisfaction!) if there's some common device that has a lot of data to transfer and the hardware to do it fast. I would think some NI ADC would do - they did after all develop the short-cut handshake in IEEE488.2 and claim up to 4Mbytes/s, I think -  but unfortunately high speed NI ADCs are likely to be rare, expensive, and completely obsoleted by modern SDR hardware that takes advantage of USB3 speeds. A scope is perhaps the most likely candidate - common enough to be in use by amateurs and, up to 2000 or so, still likely to have a GPIB interface.

[Fraser]

I needed a USB to GPIB adapter a few years ago. There was very little choice at the time and I managed to buy a used ICS clone of the official NI unit. It is not a 100% compatible clone though.

I looked at the Prologic unit but, at the time, it was not compatible with the software I was using.

I am pleased to see this excellent project as I feared that GPIB had been effectively abandoned in recent years. Great work 

Fraser

[Bicurico]

One important aspect for me is the transfer speed.
The chinese cloned Agilent USB GPIB adapters achieve quite high transfer rates.
Being able to build something similar speed-wise would be great.

What would you test speed against ?
I did some measurements on the AR488 adapter described elsewhere and was getting about 44us per handshake. This is very misleading though - it was reading the *idn response from an HP53131A and the HP is limiting the speed before the AVR bitbanger does. And then there's all the overhead of setting up the transfer (addressing) and sending the data back to the host.

So the overall speed of the transaction will work out way slower than this 22k/s, but the actual micro is capable of going faster against a faster instrument. It really needs to be measured against something doing much longer transfers without the instrument limiting it. I'm unlikely to get to the sub microsecond times that full bus IEEE-488.2 speed would permit but I can probably improve on what I'm seeing now. Maybe 100k ?

I don't think I've got anything suitable : the instruments I have with display screens that might do a big screen dump have ethernet and USB, not GPIB. Can you suggest a test subject ?

Sorry, I forgot to explain my "needs"!

I use the GPIB interface to connect to older spectrum analyzer like the HP8594E or R&S CMU200/CRTU (technically not a spectrum analyzer, but offers this mode). What I do is to capture the trace, which is normally composed of around 500 samples. These are sent in plain text and this means a few kb per sweep.

It would be nice if the GPIB interface would not be the bottleneck in this transmission, so that my software can render the spectrum as fast as possible.

Take a look at my blog for further information:

https://vma-satellite.blogspot.com/

Regards,
Vitor

[artag]

Thanks, Vitor.

What interface are you using at present, and what speed does it achieve ?

[dietert1]

GPIB is dead because it is so awfully slow, except for reading old DVMs and frequency counters. If you ever downloaded a DSO screen dump via GPIB you know what i mean. I think these yaugi projects are for somebody interested in learning details of this legacy data bus. Implementing it on a professional level including some API including reasonable exception handling is more than a man year. Also i remember that it needs to be largely configurable to work with all/many different devices, not just the ones you happen to use for test. One needs a logic analyzer and a HP 59401A or NI Measurement & Automation Explorer.

If you have an application where you can't avoid using GPIB, keep away from the troubles of a partial implementation, but get one of those used HP USB adapters or a NI GPIB-ENET. My personal opinion.

Regards, Dieter

[essele]

Ok, I've done a bit of a bulk upload without a lot of sanity checking so it will need cleaning up over time, but I'll start working off of this version now...

https://github.com/essele/yaugi

It is very much work-in-progress and not very tidy ... and you will need a PSoC Programmer if you want to use this (I'm using the MiniProg3, but there are a few choices if you want to make a cable up or change the header on the board.)

The current approach is focused on interactivity, so you get some extra debug and there is some processing on the GPIB data so it's not suitable for binary data as it stands. I'll make the interactive bit a config option soon which should get it into a position where it could pass binary data ok.

I'm slowly working my way through the ++ command set, just added eot_enable and eot_char ... lots still to do.

[Bicurico]

Thanks, Vitor.

What interface are you using at present, and what speed does it achieve ?

I am using an Agilent 82357B USB-GPIB Interface.

They cost around 70 Euro + Tax from Chinese sellers.

Some say they are cloned, other says they are refurbished.

Mine came in a sealed box with Agilent CD-ROM containing Connection Expert and certificates. The device looked as new, but might have been used before.

My guess is that they are refurbished.

Anyway, the speed is around 1.15MB/sec.

Regards,
Vitor

[pigrew]

The USBTMC spec describes communication with only a single device. However, it does leave the opportunity open for vendor messages which could be used to change the address on the bus. Parallel poll may also need a special vendor command.  On the other hand, the whole adapter might be cheap enough (< US$20) that it would be reasonable to give each device its own adapter (reducing the need for special commands). Though for properly implement triggering, one really does want all the devices connected on the same bus.

Replying to myself after reading a bit more, I'm thinking that implementing multiple-device USBTMC is not a good idea. The reason to use USBTMC is so that the adapter can be used with VISA without needing to write any extra host drivers.The USBTMC spec doesn't provide a way to support multiple devices. USB does support having composite interfaces, but most microcontrollers limit the number of USB endpoints to around 8, which would only support one or two USBTMC interfaces per USB device. "advanced" GPIB features such as parallel poll, SRQ, GET, multiple-device commands, secondary controller, etc. would need to be avoided.

There is work on extending pyvisa to support Prologix interfaces, but this is only for pyvisa, and not NI or Keysight VISA.

The feasible ways to make an open-source VISA-compatible GPIB adapter without needing to write any host-side driver code, seem to be (1) Reuse an existing adapter USB interface, like that of the NI or Keithley USB adapters, (2) use USBTMC with a single connected instrument, or (3) Use Ethernet, having an array of ports (one for each instrument), exposed as VXI-11 devices or repurposing the interface of an existing gateway.