AR488 Arduino-based GPIB adapter

[WaveyDipole]

Many thanks for creating and sharing this!

You're welcome.

Communication with my HP 4192A impedance analyzer sees to work fine, but when I sent *IDN? to a Keithley 2001, the first 1 to 3 characters of the response were always wrong. Same with a Keithley 2010.

I just tried it again:

*idn?
++read
OEITHLEY INSTRUMENTS INC.,MODEL 2010,0632912,A15  /A02
fetch?
++read
m9.59916086E-01
:SENS:FUNC?
++read
bVOLT:DC"

Edit: I just noticed that the Keithley's display twitches when I send the ++read command. The instrument also clears the "REM" indicator, so it goes out of remote mode. Hmmm. Did I make a mistake in the wiring?

I have noted this and have logged an issue. I'm not sure how I'm going to diagnose this as I do not have a Keithley or Keysight device, but thany you for providing the DEBUG7 output in your subsequent post.

https://github.com/Twilight-Logic/AR488/issues/5

There maybe some timing parameters that need to be fine-tuned. For me it worked just fine with HP 3457A, but when I hooked it up to HP53310A, it would sometimes have problems, reading only the first character of the instrument's response string. If I upload the original Girlando's sketch to the same board, it works fine.

That is also very interesting to note. I have noticed that occasionally prototype board wiring can be quite prone to loose connections and noise which can cause problems, but it is noteworthy that Emanuelle's sketch works OK on the same board. Reading just the first character is a bit odd too. Timing may well be the issue but I will investigate.

[Kleinstein]

AFAIK GPIB uses open collector drivers and pull ups. Depending on the length of cable and instruments attached this can slow down the bus. Though maybe not part of the GPIB specs, it may thus be a good idea to have the option to run slower if needed.  Usually it's better to run slow than with errors.

Also the choice of the pull up resistors may have an effect.

[coromonadalix]

would it be ok to add some buffer chips / line drivers ??  would it help ?

[maxwell3e10]

Of course one should have proper line drivers, but the whole beauty of this approach is that it requires nothing more than a small Arduino board. So I think its better to slow down the interface, one rarely needs full speed.

[Kleinstein]

The AVRs output drivers are relatively powerful and can drive quite some current.
There are special driver chips, mainly SN75161+75162. However these chips tend to cost more than the mega88 µC and are more difficult to get. So directly using the µC is not such a bad idea for a low cost solution, especially with the µC in a DIP socket.
The AVR also has schmidt-trigger inputs, so not so bad for the input side.

I don't think the direct solution would be that much slower. The limiting part is often the signal coming back up through the pull up resistors - so not much a driver could do there (except to add some active drive instead of the standard pull up). The input levels might be slightly better with the special chips.

For protection it might be a good idea to have a power supply to the AVR that is not too powerful, so that in case of a ESD or similar spike an SCR latchup would not cause a permanent damage, but just short out the supply in a way that it can recover. So a low current regulator could save the chip.

[Miti]

The line drivers are essential in daisy chain configuration. Can this adapter be used to drive multiple daisy chained  devices or in star configuration only?

[WaveyDipole]

I think I had read somewhere that the collector current on the Arduino IO pins cannot handle more than maybe two or three devices.

Regarding the The SN75161+75162. chips, these require at least two control lines each in addition to the 16 GPIB signal and data lines that are being buffered. The number of IO pins required exceeds that available on the 328p as used on the UNO or the NANO. Currently only pin D6 and pin D13 are spare. Of these, pin D13 also connects to the internal LED which could be removed to allow unimpeded use of the pin. However, pins 0 and 1 are reserved for the serial IO and are not available to use. This means we would need a board with more IO pins such as the Mega 2560, but I guess it could be done.

[maxwell3e10]

At a few $/µC, it is much cheaper than a proper GPIB cable. So its not obvious that one would even want to have multiple devices connected to the same controller. It is  only necessary for group trigger commands. Maybe better think of it as a GPIB-to-USB port converter individual to each device. Even better if it can be loaded with custom macros for that instrument. The key to low-cost solution is avoiding a custom circuit board.

[texaspyro]

The key to low-cost solution is avoiding a custom circuit board.

Not really.  A custom PCB would run around $2-$5 each depending upon quantity... well worth it as a time saver.  Connecting 20+ wires to an Arduino is a tedious, error prone, unreliable task.

[maxwell3e10]

Not really.  A custom PCB would run around $2-$5 each depending upon quantity... well worth it as a time saver.  Connecting 20+ wires to an Arduino is a tedious, error prone, unreliable task.

Plus shipping, plus whoever wants to do it on a regular basis would need to charge something for their time. There have been a few attempts at such effort, I don't think they have been sustained for a long time. Its better to have a standard commercial hardware platform and then one can have open-source software that a few people contribute to.  Of course one can also offer a complete product with a nice 3D printed case.

[texaspyro]

The circuit board could just have a place to plug in the Arduino board and break out the pins to a GPIB connector or to a ribbon cable connector (with a GPIB connector on the end of a ribbon cable).   Assuming the board is 4 square inches OSHPARK will ship you three of them for $20 (including shipping).   Chinese suppliers could do 10+ of them for the same price or less.   I don't know how you value your time, but that is a bargain.

If somebody laid out a board they could post the Gerbers or Eagle .brd file and anybody could send those off and have the boards made.

[maxwell3e10]

Still one would have to get the driver chips, populate the board, solder the connector wires or find a PCB-mounted connector.

This is about as simple a soldering project as it gets:

[GregDunn]

Still one would have to get the driver chips, populate the board, solder the connector wires or find a PCB-mounted connector.

This is about as simple a soldering project as it gets:

Agreed - I don't mind having a spare board for each meter, and if someone like me can open the box, program the board, and errorlessly wire up a connector in a couple of hours it's clearly a win.  If someone wants to spend the time to design, prototype, debug, manufacture and distribute a better version for $5 delivered, feel free to let us know.  Meanwhile, I'm using this one and getting work done.

[macboy]

AFAIK GPIB uses open collector drivers and pull ups. Depending on the length of cable and instruments attached this can slow down the bus. Though maybe not part of the GPIB specs, it may thus be a good idea to have the option to run slower if needed.  Usually it's better to run slow than with errors.

Also the choice of the pull up resistors may have an effect.

Yes, it is specified to use open collector I/O with Thevenin termination to +5v (3k1) and to ground (6k2) which results in ~ 3.3 V floating voltage on the bus. The logic levels are the same as TTL, which means that >= 2.0 V shall be interpreted as a high and <= 0.8 V shall be a low.  Very importantly, these voltages do not match the Arduino CMOS logic inputs, where > Vcc/2 (so 2.5V) is a high and < Vcc/2 is a low. The use of TTL-input buffers is a good solution. Powering the Arduino from a lower Vcc might also work (e.g. 4.0 V, so that Vcc/2 is 2.0 V). I'd also recommend adding termination to the Arduino side of the bus, even if it is only pull-up resistors, which will help to drive the high (floating) voltage higher.

After addressing the voltage input level issue, there is no need to worry about bus speed. GPIB uses two-way handshaking, and since the handshake lines use the same termination and logic levels as the data lines, the handshake signals should propagate as fast (or slow) as the data, ensuring synchronization. Adding some delay between seeing DAV (Data Available/Valid) asserted and reading the bus might help, but it is the data source's job to insert a delay between putting data onto the bus and asserting DAV.

[Kleinstein]

The input level can be even worse: to get a sure high the AVR powered with 5 V might need up to 70% of VCC and this 3.5 V. A little more than 2.5 V (e.g. 2.75 due to a typical 0.5 V hysteresis) is just the typical value.  A slightly lower voltage could help, but increase the chance to get current through the diodes towards VCC. Extra pull ups sound like a good idea and could solve some of the issues.

The main driver to consider in the instruments would be SN75160/75161, these seem to give a high level of some 3.5 V with no load - so just border line for the AVR.

As the cable is quite expensive, I would also consider the main use with a single instrument, with a fixed cable / plug. The low side drive should be still powerful enough to also work with more instruments (e.g. 5 ). The problem is more that with more instruments the high level may not be that good anymore, especially with another instrument connected by not powered.

External drivers would need more control signals. I don't think the LED would be a problem to use that IO pin as an output - so this pin would be usable. One might have to drop one of the less important handshake signals for an extra control.  With extra drivers it would be only logical to have a board made that could than also include the µC and maybe UART to USB bridge or possibly opto-couplers for the UART.

Ideally the handshaking would take case of the speed / delay. However with logic levels just at edge the transition from L to H might take considerable longer than the other way or on the handshake line. So some extra delay may help.

[Tj138waterboy]

Thanks to all that are making the code and sharing the knowledge. I am slowly in the process of making my own adapter for a 3478A and did a quick draft of a arduino nano V3 module with the ieee-844 male pcb connector from https://www.eztapzmarket.com/index.php?main_page=product_info&products_id=432924. Price is currently under $10 for just the ieee-844 part but I did see them cheaper on ebay. Be warned that this is just a draft and im no expert in pcb layout and design but maybe someone can optimize and make smaller. Updated footprints to match Arduino Nano V3.

[oPossum]

with the ieee-844 male pcb connector from https://www.eztapzmarket.com/index.php?main_page=product_info&products_id=432924. Price is currently under $10 for just the ieee-844 part but I did see them cheaper on ebay.

Starting at $4.29 qty 1 from the major suppliers

https://octopart.com/search?q=112-024-113R001

[maxwell3e10]

I brought my simply-wired Arduino Nano to work and tested it with a variety of instruments. Note that I was using Girlando's code, http://egirland.blogspot.com/2014/03/arduino-uno-as-usb-to-gpib-controller.html
Also note that he has updated his code within the last few months to fix a couple of small bugs.
With that code I was able to communicate with all instruments I tried without obvious errors. See log below. So I think from the hardware perspective, direct wiring of Arduino to GPIB is good enough, at least to drive one instrument at a time.

[coromonadalix]

For more I/O   maybe an stm32 blue pill could do ??  they're sold pretty cheap ??

Nice job  tj138, could be a nice daughter board, i would buy you 2 boards

[Tj138waterboy]

Thanks for the compliment but I am not selling the boards it was more of a side project to see if anyone thought it would be a good idea. Im not 100% sure if it is going to work or not I will be ordering the board and connectors from jlcpcb this weekend I was kind of waiting on the guys that currently have used wires straight to the connector from Arduino Nano 2 bless off on if it is 100% safe not to have any pull up or pull down resistors on any of the pens also I was thinking about the option of a heartbeat sensor flash status indicator LED as well. I am not sure which lines wood even be used for the status LED or if it would need an extra line of code in the Arduino. If anyone has suggestions feel free and I will modify the board and if anyone wants these schematics let me know

[texaspyro]

Once it gets verified as working, post the Gerber files here so that anybody that wants one can send them off to their favorite PCB maker.

[GregDunn]

Just as a comparison, I programmed one of my UNO boards with AR488 and the other with GPIB6.1 to test them with my setup.  The GPIB6.1 seems to be slightly more user-friendly when communicating, but the AR488 added features are definitely worth having.  With ++auto 3 and ++read, I can log data quickly and not even have to send a native command to the target instrument if I don't want to.  Also, the GPIB6.1 sometimes sends a garbage character back with the instrument's response initially.  I also am having intermittent responses via GPIB6.1 (sometimes a native command won't work) whereas AR488 hasn't given me that problem.  I am using the exact same board and GPIB connector, FYI.

For others using a Mac, I strongly recommend using an official UNO (or a clone) which uses the ATmega16U2 as the USB-serial chip.  I have tried a CH340-series version UNO clone and it just does not work, despite multiple workarounds and drivers on two completely different computers.  One driver (the recommended version, in fact) crashed the Arduino IDE badly.

[texaspyro]

For others using a Mac, I strongly recommend using an official UNO (or a clone) which uses the ATmega16U2 as the USB-serial chip.  I have tried a CH340-series version UNO clone and it just does not work, despite multiple workarounds and drivers on two completely different computers.  One driver (the recommended version, in fact) crashed the Arduino IDE badly.

I have noticed that a lot of the Linux CH340 drivers will not set the baud rate on CH340 clone chips...  there may also be other incompatibilities.

[artag]

Earlier versions of the linux CH340 drivers would only set a limited range of baud rates. It's definitely OK with a 4.9 kernel but I'm not sure when it changed. I think I had problems with 3.something.

[artag]

I'm looking at porting this to an Arduino prop micro or something else with a built-in USB port. The motivation is to avoid problems with serial port handshaking by moving the serial device into software.

However, it does require changing the pin mapping because the SRQ and ATN lines used in the existing layout don't have a pin-change interrupt on the atmega32u4. It would be great if they could be the same on as many variants as possible.

Would it be a big problem to move the SRQ and ATN pins to port B ? That's Uno / Nano pins in the range 8-13.