OSHW USB to GPIB Adapter

[scasagrande]

Hey everyone,

Just wanted to post here about my OSHW USB to GPIB adapter that I've been working on. This project started mid 2011, but hasn't changed much in a few months. I'm only now getting around to packaging up all the files to release them.

Recently I filmed my first youtube videos talking about this project. I go over the motivation and what functionality I put it. They're my first ones, go easy on me!

A few of the files need some more comments before I release them. I should be done within the next few days.

I am interested in selling this. If you guys are interested, post here or email me (stevencasagrande at the gmail). If we can get a few people, I can see how much it'll cost.

Oh, and before anyone mentions, yes I know the microcontroller that I'm using has built in USB. RevC will likely omit the FT232 to use the internal USB instead.

Thanks for checking out my work everyone.


 

[hardsoft]

Nice project.  I too like automating tests with Python but for the problems you've mentioned, I've always been stuck with using serial communication interfaces with PySerial and a bunch of USB to RS232 adapters, which can be painfully slow.  I'd be interested in seeing your code implementation once you're done.  Do you have a website?

I'm sure you could sell these pretty well by undercutting the ridiculously expensive NI parts.  It would be nice to one day have an open source suite of hardware and software tools (probably based on python, numpy, etc.) for automated testing that could take over the National Instruments and Matlab stuff for everyone without deep pockets.

[EEVblog]

Nice work, keep it up!

Dave.

[scasagrande]

Nice project.  I too like automating tests with Python but for the problems you've mentioned, I've always been stuck with using serial communication interfaces with PySerial and a bunch of USB to RS232 adapters, which can be painfully slow.  I'd be interested in seeing your code implementation once you're done.  Do you have a website?

I'm sure you could sell these pretty well by undercutting the ridiculously expensive NI parts.  It would be nice to one day have an open source suite of hardware and software tools (probably based on python, numpy, etc.) for automated testing that could take over the National Instruments and Matlab stuff for everyone without deep pockets.

Right now all I have is my blog (scasagrande.blogspot.com) but I do plan on getting myself a website soon enough. Biggest problem I'm having is coming up with a name for it!

I have a number of classes pre-programmed in python for various instruments that we have around the lab (I'm a MSc student at the Institute for Quantum Computing). I also have them in Matlab classes, but I originally did those for the NI adapter, so they will all need some tweaking before release.

Nice work, keep it up!

Dave.

Thanks Dave!

[amspire]

I have been working (now and then) on my Arduino-based GPIB to Ethernet converter, but you are obviously way ahead of me.

Is your GPIB converter currently for a single instrument only, or can you have multiple paralleled instruments?

It would be incredible if you could combine this hardware, with some tutorials on using Pyserial to talk your board and for getting data into Matlab.

I do not have Matlab, but hopefully I can use the same ideas with the open source Octave instead.

Many of the commercially available USB adapters are pretty incredible in how well they have implemented the GPIB spec, but you pay for it.  There hasn't been a decent Open GPIB project available yet that does not depend on special expensive NI IC's, so I really hope your board succeeds.

Richard.

[scasagrande]

I have been working (now and then) on my Arduino-based GPIB to Ethernet converter, but you are obviously way ahead of me.

Is your GPIB converter currently for a single instrument only, or can you have multiple paralleled instruments?

It would be incredible if you could combine this hardware, with some tutorials on using Pyserial to talk your board and for getting data into Matlab.

I do not have Matlab, but hopefully I can use the same ideas with the open source Octave instead.

Many of the commercially available USB adapters are pretty incredible in how well they have implemented the GPIB spec, but you pay for it.  There hasn't been a decent Open GPIB project available yet that does not depend on special expensive NI IC's, so I really hope your board succeeds.

Richard.

One of my next goals will be to do Ethernet to GPIB (thankfully most of the code will be reusable), but that will be after my OSHW function generator.

It works with multiple instruments connected. When directly interfacing with my controller, you have to first specify the GPIB address of the target by sending "+a:1" without quotes, and where 1 is the address. My python classes automatically handle all of that.

I include some basic examples with my python classes on how to use them. I do a basic *idn? query in one, transferring the 'scope waveform via binary and doing FFT (I've implemented binary block reading in the generic 'instrument' class, from which all others inherit from), and third transferring the currently displayed reading from my older Keithley 195. I'd probably do a more in-depth video tutorial to make sure everyone knows how exactly to use it.

Thanks for the good wishes!

[alm]

One of my next goals will be to do Ethernet to GPIB (thankfully most of the code will be reusable), but that will be after my OSHW function generator.

The GPIB part should be the hard part, bolting on any standard TCP/IP stack and ethernet MII/MAC should be fairly straightforward. Good luck with the project, most people undertaking it seem to spend much more time than expected getting it to work with various instruments. Gotta love standards.

It works with multiple instruments connected. When directly interfacing with my controller, you have to first specify the GPIB address of the target by sending "+a:1" without quotes, and where 1 is the address. My python classes automatically handle all of that.

Any particular reason why you chose to reinvent the wheel instead of just copying the Prologix protocol? Short of GPIB32/VISA support, this is the closest you get to a widely supported standard. There are even some open source language bindings available.

I include some basic examples with my python classes on how to use them. I do a basic *idn? query in one, transferring the 'scope waveform via binary and doing FFT (I've implemented binary block reading in the generic 'instrument' class, from which all others inherit from), and third transferring the currently displayed reading from my older Keithley 195. I'd probably do a more in-depth video tutorial to make sure everyone knows how exactly to use it.

A Keithley DMM wouldn't be my first choice for debugging a GPIB interface. Not that they're bad DMMs, but their GPIB implementation can be annoying. Fun like reporting an error several seconds and about five commands after the offending commands, or occasionally resetting and corrupting the output for one sample for no apparent reason when polled frequently. I tend to use HP equipment for debugging, since their implementation tends to be quite robust (being the inventors and all). Modern IEEE 488.2 or SCPI stuff is nicer than the old stuff when ROM was expensive and error handling was often limited to ignoring unknown commands.

GPIB can go much faster than 56k async serial. I've never measured it, but using GPIB was substantially faster than 38k4 RS-232 on the scopes I've used it on. I believe the theoretical limit is 1.8 MB/s for standard GPIB and even more for the high speed variant. Not sure how close real world instruments get to this. Prologix claim about 500kbps, but that's probably limited by the 8-bit AVR.

[scasagrande]

Thanks for the feedback!

I was attempting to keep the commands as shorts as possible, hence shortening it to +a: instead of ++addr: I believe it is for the Prologix adapter. I also didn't want it to look like I was directly copying them. However, if it helps I could switch it to just use the same commands.

Regarding the Keithley DMM, it wasn't my first choice. I was primarily testing on my Tek TDS 224. The purpose of the older DMM was to see how well it handled instruments built prior to the 488.1 revision.

Yes I know that GPIB can go much faster than 56k. The high speed version (if I recall correctly) is up to 8Mbps. The main problem is that I'm communicating with the computer at 115200 baud, which is about 115.2Kbps (or 0.12Mbps). I had to do some strange things to get the code to even approach that (I believe the compiler I'm using was doing some strange things...).

[edit] I just assumed that 115200 was the highest I could do, but looking around online seems to imply I can go higher than that...

[alm]

The FT232 can go much faster, not sure about the PIC you're using. It probably doesn't make sense for you to focus on speed at this point. Speed is going to be insignificant for the majority of applications. It's not like you're using this to run a factory to do production testing where every millisecond counts. The only application I can think of is downloading data from the scope, but when I used a serial connection at whatever the max speed it supported, it took about half a minute for a PCX screen shot, so 115k should be quite usable.

Was there actually a IEEE 488.1 revision? My understanding was that they just renamed the previous IEEE 488 standard to 488.1 when they introduced IEEE 488.2, although I guess there is some (especially HP) equipment that pre-dates IEEE 488, when it was still called HPIB.

[scasagrande]

Whoops, I was confused. You are correct, it was 488.2, which is what I meant in my previous post (I may have also misspoken in my videos -_- ).

[amspire]

ieee488 that became ieee488.1 is the hardware and handshake protocol spec. It is the most important one for GPIB converter.

ieee488.2 is the standardized instrument protocols. I have never seen it, so I am not sure if it contains anything relevant to the converter or not. ieee488.2 is particularly for the instrument designers, and most of the time, the job of the converter is to transparently pass messages in and out.

I gather that ieee488.2 does specify the minimum compatibility requirements that was left open in ieee488.1 so that is one thing that would be relevant to the converter. ieee488.1 specifies lots of different items of functionality, but doesn't say if any are required or not. You could probably design a ieee488.1 compatible interface that had no functionality at all!

The other thing ieee488.2 specifies is all the different string and binary data types that the converter has to pass. If the converter is designed to pass any data of any length, then you do not need to worry about that one.

Richard

[scasagrande]

Yeah, 488.2 mostly covers standard messages that instruments needs to respond to. That's why instruments prior to 488.2 all seem to have different ways to communicate.

[scasagrande]

I was slightly set back the other day when my temporary monitor started to show signs of failure (the left half no longer consistently works at all), but I still managed to make some progress. I added in tiny bootloader so the end user can upgrade the firmware. I had to reroute a few traces to make space for the restart button, but it looks like it'll all work out.

Thankfully I've replaced the monitor so now I can properly finish things up.