For Sale: OSHW GPIBUSB Adapter

[scasagrande]

Hey everyone! Some of you may have been following the few posts that I've made about my OSHW GPIBUSB adapter on the projects board. Well, its finally done!

I wanted to give the forum members here the opportunity to get their hands on any before I start putting this up on other websites. Dave's videos have been great for helping nurture my love for electronics, so I only felt it fair to give the members here first shot. This will be my first time shipping anything, so it might take an extra day to correct anything that I did not account for.

I have 15 adapters all assembled and tested. Cost is $60 CAD plus shipping. If you are from Canada, add 13% for HST. For shipping, options are either FedEx (both ground and express) or Canada Post. An exact number will be given after you contact me and let me know what shipping method you would like.

Payment is through Paypal.

If you are interested, please email me at scasagrande at galvant dot ca.

Thanks everyone for supporting me, my new business (Galvant Industries), and OSHW!


Features

• Connect your computer to your instruments' GPIB port by USB
• USB-B connector
• Cross platform - works on Windows, Linux, and OSX
• Cross language - works with any programming language able to connect to serial ports
• Includes pre-written python classes for easy communication with instruments
• Upgradeable firmware - Useful to add new features and bug fixes easily
• Both assembled and PCB manufactured in Canada

Items of note:

• Currently does not support service request. Will be added at a later date.
• Contains lead (Pb). Soldering was done using 63/37 solder.
• All source can be found at github.com/Galvant
• Does not include USB cable

[Andy]

Great work! A couple of questions:

How does the software on the PC side work? Does the device just show up as a COM port? I'm not very familiar with GPIB, but I own a HP 3478A which has GPIB connectivity. I've wanted to buy an adapter to experiment with it, but up until now, the cheapest I could find was the $150 Prologix adapter.

Also, how much would shipping cost to Australia?

Thanks,
Andy.

[Andy]

Ok episode 1 just answered my first question. It does present itself as a serial port.

[scasagrande]

Thanks for the questions!

As you found out, yes it just presents itself as a virtual serial port. Anything software combination that can read/write to serial ports can communicate with this adapter.

I don't own a HP3478A, but I do own a Keithley 195 (both from the same era). They both are from before communication commands were standardized. Take a look at my keithley195.py python class in the comm_code repository. They require a little extra playing with compared to slightly more modern instruments.

Shipping to Austrailia, by Canada Post air (basic shipping, 5-10 business days travel) will be $15.

[free_electron]

A couple of questions. I see a lot of these 'garage-brew' gpib adapters. (this may sound a bit as a rant , and it is...)

- How come NONE use the correct bus drivers ? ( SN75162 and 163 ). You are violating the GPIB signal levels and bus load capability. I foresee major trouble if you have 5 or 6 machines hooked up with some 10 feet of gpib cables, possible even before that. This may work fine with one machine.. but hook up a few ( especially the older ones ) and it'll go to snot. These driver chips are cheap. Do yourself a favor and put them on the board.

- is there a VISA or GPIB32 compatible driver for these things ? If not, it is pretty much useless. All existing instrumentation system assumes you either expose the unit through a VISA layer as ::USB::BUS0//Device..... and so on. Or they interact with GPIB32.DLL. If you have a 'real' gpib board (National , CEC , Agilent, ICS, and others) they ALL suppor tthe GPIB32.DLL and the VISA interface. The VISA protocol is an ascii level system that allows you to commincate in a hardware independent way. I don't care if it gets sent over GPIB , ethernet usb or whatever... here is a command string and i t needs to go there. done. I would suggest you investigate making a VISA plugin for your board ( you have the advantage you use an FTDI chip. VISA supports serial ports out of the box, all you would need is to make your command parser in the PIC software be VISA compatible. (i have seen cheapo GPIb adapters that use HID transport and even one that 'emulates' USB on an atmel cpu (obdev USB stack.. Bweuaaark.. ). those are really horrible.)

just an idea. it would make your board stand out over all the others as none of them are compatible with the real world. they are all 'kludges' thrown together.

[amspire]

A couple of questions. I see a lot of these 'garage-brew' gpib adapters. (this may sound a bit as a rant , and it is...)

- How come NONE use the correct bus drivers ? ( SN75162 and 163 ). You are violating the GPIB signal levels and bus load capability. I foresee major trouble if you have 5 or 6 machines hooked up with some 10 feet of gpib cables, possible even before that. This may work fine with one machine.. but hook up a few ( especially the older ones ) and it'll go to snot. These driver chips are cheap. Do yourself a favor and put them on the board.

I can't speak for Steve, but I have fiddled with a GPIB design, and for simple use, the outputs of many processors such as the Atmel can be made to function close enough to the standard. Definitely is not going to damage anything. Yes Steve can get the correct IC's, but the project is opan source, anyone can add them to their own board of they want.

This adapter is probably not aimed at professional users who would be running 6 machines and 10 feet of cable. Those users probably can afford the more expensive solutions.

- is there a VISA or GPIB32 compatible driver for these things ? If not, it is pretty much useless. All existing instrumentation system assumes you either expose the unit through a VISA layer as ::USB::BUS0//Device..... and so on. Or they interact with GPIB32.DLL. If you have a 'real' gpib board (National , CEC , Agilent, ICS, and others) they ALL suppor tthe GPIB32.DLL and the VISA interface. The VISA protocol is an ascii level system that allows you to commincate in a hardware independent way. I don't care if it gets sent over GPIB , ethernet usb or whatever... here is a command string and i t needs to go there. done. I would suggest you investigate making a VISA plugin for your board ( you have the advantage you use an FTDI chip. VISA supports serial ports out of the box, all you would need is to make your command parser in the PIC software be VISA compatible. (i have seen cheapo GPIb adapters that use HID transport and even one that 'emulates' USB on an atmel cpu (obdev USB stack.. Bweuaaark.. ). those are really horrible.)

just an idea. it would make your board stand out over all the others as none of them are compatible with the real world. they are all 'kludges' thrown together.

Again I cannot speak for Steve, but the fact that it does NOT use Visa drivers is a really big plus to me.  As long as the operating system you connect it to is able to recognize the USB virtual serial port, then you can talk to the instrument.

If you want Visa compatibility, the market is already well served with a number of very mature adapters from well resourced companies. I think Steve said he may look at an Ethernet version and that would be even better as it means you could use any device with an Ethernet or Wireless Ethernet connection to talk to your GPIB instruments. Absolutely no drivers needed, so this would include things like mobile phones and tablets.

Visa is a really great idea with a horrible implementation, and at the end of a day, all many of us want to do is to set a multimeter to the 10V DC range with a 10 mains cycle averaging period, and then download a bunch of readings. I have a Time Electronics programmable resistance box that only has about 4 GPIB commands - the main one being that of you send R123456, it sets the resistance to 123,456 ohms. Definitely don't need Visa for that.

If you want to fully control your spectrum analyzer from a Labview panel, you will want one of the commercial adapters with the full VISA support.  A lot of GPIB commands are pretty basic stuff even without Visa and IEEE488.2, particularly for people with 1970's and 1980's style used HP gear.

If Steve wants to try and support Visa then great, but I would imagine it could be hard for him to verify that Visa support is fully working. Trying to offer Visa support could turn into a bit of a nightmare if it does not fully work.

Richard.

[free_electron]

Fully understood, the only reason i am posting this is the following : many GPIB capable machines come with free software from the manufacturer. Buy a used Agilent machine and there is a good chance you can get a free piece of software that works perfectly with the machine.... provided you can talk using an 'official' channel such as either visa or gpib32.dll.
I , for one, hate to have to reinvent the wheel. If i can use that free piece of software i will do that. i don;t wat to wast time having to make my own script trying to figure out how to download a binary waveform.

Simple example. I have a used 33120 AWG and an scope. using the Benchlink software from agilent ( free ) i can simply grab the scope trace, do some operations and send it to the AWG for playback. Beautiful ! ... provided i hav a 500$ gpib board @!#$%^&^%$# not beautiful ! i paid 100$ for the scope and about 200 for the AWG ...

If i could only have a 'hobby price level' gpib board that is compatible i would be golden. and having the board being compatible with VISA or GPIB-32 does NOT preclude you being able to write your own drivers.

That is my frustration with all these 'hobby gpib' boards. Why not put in 20 cents more parts, make it compliant by having the real driver chips on board. And crowdsource some firmware that can handle the visa interface. ( its a stupid ascii command parser , so instead of 'inventing' your own command set , simply use an existing one)
I don't have the time to make my own board and write my own pic firmware and visa driver. I have real agilent USB<>gpib boards (PCI usb and ethernet). so i have no interest in this project, apart from trying to convince some small tweaks that would make it better than all the others already out there.

My point is : if you are going to release something , make it compatible with the rest of the world. It does no good making something that is a 'kludge' and only works for simple things.

already not having SRQ is annoying... can we do binary trasnfers ? lot's of spectrum analyzers etc can send over binary datastreams holding for example TIFF images... I have not seen a single 'homebrew' board that know how to handle such transfers. Logic analyzers use that too. they send over compressed data. if you want to reuse this in a pattern generator : you are stuck.

I am not dissing the efforts of 'scasagrande'. I think its great there is another hobby usb<>gpib adapter. All i'm trying to do is poke and prod so it rises 'above' all the others already out there.
Otherwise it is 'just one more'...

[Bored@Work]

VISA is one of the things that made the once so simple GPIB so incredibly annoying. In the good old days of 8 bit home computers people already did GPIB, but since it became a "professional legacy" interface, all kinds of complications are piled on top of it. And companies like NI are charging you through the nose (just check what NI wants for a clone of a classic GPIB controller http://sine.ni.com/nips/cds/view/p/lang/en/nid/10626 28 Euro.

If you don't like the hobby interfaces, buy one of the professional interfaces, or do your own highly professional, 5000 lines of firmware interface.

[scasagrande]

A couple of questions. I see a lot of these 'garage-brew' gpib adapters. (this may sound a bit as a rant , and it is...)

- How come NONE use the correct bus drivers ? ( SN75162 and 163 ). You are violating the GPIB signal levels and bus load capability. I foresee major trouble if you have 5 or 6 machines hooked up with some 10 feet of gpib cables, possible even before that. This may work fine with one machine.. but hook up a few ( especially the older ones ) and it'll go to snot. These driver chips are cheap. Do yourself a favor and put them on the board.

I hooked up my revA board a few months ago to several instruments with a decent length of cable and did not experience any issues. Perhaps some will appear if you start pushing the limit of the spec. I'll keep those drivers in mind for next time, I wasn't aware of them. This project started off as a lot of firsts for me, and I do not claim to know everything. I only claim to have come a long way from where I was.

- is there a VISA or GPIB32 compatible driver for these things ? If not, it is pretty much useless. All existing instrumentation system assumes you either expose the unit through a VISA layer as ::USB::BUS0//Device..... and so on. Or they interact with GPIB32.DLL. If you have a 'real' gpib board (National , CEC , Agilent, ICS, and others) they ALL suppor tthe GPIB32.DLL and the VISA interface. The VISA protocol is an ascii level system that allows you to commincate in a hardware independent way. I don't care if it gets sent over GPIB , ethernet usb or whatever... here is a command string and i t needs to go there. done. I would suggest you investigate making a VISA plugin for your board ( you have the advantage you use an FTDI chip. VISA supports serial ports out of the box, all you would need is to make your command parser in the PIC software be VISA compatible. (i have seen cheapo GPIb adapters that use HID transport and even one that 'emulates' USB on an atmel cpu (obdev USB stack.. Bweuaaark.. ). those are really horrible.)

Fully understood, the only reason i am posting this is the following : many GPIB capable machines come with free software from the manufacturer. Buy a used Agilent machine and there is a good chance you can get a free piece of software that works perfectly with the machine.... provided you can talk using an 'official' channel such as either visa or gpib32.dll.
I , for one, hate to have to reinvent the wheel. If i can use that free piece of software i will do that. i don;t wat to wast time having to make my own script trying to figure out how to download a binary waveform.

I originally started this project because of my frustrations with the various drivers. I'm a graduate (MSc Physics) student at the University of Waterloo. About a year ago I was tasked with setting up all the equipment for this experiment. So I grabbed our NI GPIBUSB-HS, hooked it up, and found that drivers don't exist for Debian based Linux distributions. So I thought, alright, I'll just install a Red Hat based one, which are supported. I got the drivers installed. But then I found that the Linux version of these drivers don't include Matlab bindings. We had to use Matlab for this project. At this point I went ahead and installed Windows just so we could actually do some work.  I decided to make my own, using FTDI chips for VCOM,  and just implement my own basic set of commands.

Perhaps in the future I will make it VISA compatible along side the simple commands. But as they say, you've eventually gotta get your product out there. But, my original idea came from lab work, where we had to automate several instruments from scripts. Starting your script off making a serial object or making a visa object doesn't change much.

Simple example. I have a used 33120 AWG and an scope. using the Benchlink software from agilent ( free ) i can simply grab the scope trace, do some operations and send it to the AWG for playback. Beautiful ! ... provided i hav a 500$ gpib board @!#$%^&^%$# not beautiful ! i paid 100$ for the scope and about 200 for the AWG ...

If i could only have a 'hobby price level' gpib board that is compatible i would be golden. and having the board being compatible with VISA or GPIB-32 does NOT preclude you being able to write your own drivers.

I wasn't originally aware that I could make it compatible without writing my own drivers. Again, perhaps in the future I will include that functionality along side with the current implimentation.

That is my frustration with all these 'hobby gpib' boards. Why not put in 20 cents more parts, make it compliant by having the real driver chips on board. And crowdsource some firmware that can handle the visa interface. ( its a stupid ascii command parser , so instead of 'inventing' your own command set , simply use an existing one)
I don't have the time to make my own board and write my own pic firmware and visa driver. I have real agilent USB<>gpib boards (PCI usb and ethernet). so i have no interest in this project, apart from trying to convince some small tweaks that would make it better than all the others already out there.

I did a quick search for those drivers; seems to be a lot more than 20 cents. The pullup resistors that I'm using are much cheaper than that chip. If I can fit it in the next revision, I probably will.

The firmware is up on github.com/Galvant, and I'm open to people submitting changes. If someone wants to work on it, and they produce some new functionality, they just need to let me know.

My point is : if you are going to release something , make it compatible with the rest of the world. It does no good making something that is a 'kludge' and only works for simple things.

already not having SRQ is annoying... can we do binary trasnfers ? lot's of spectrum analyzers etc can send over binary datastreams holding for example TIFF images... I have not seen a single 'homebrew' board that know how to handle such transfers. Logic analyzers use that too. they send over compressed data. if you want to reuse this in a pattern generator : you are stuck.

I am not dissing the efforts of 'scasagrande'. I think its great there is another hobby usb<>gpib adapter. All i'm trying to do is poke and prod so it rises 'above' all the others already out there.
Otherwise it is 'just one more'...

The SRQ line is hooked up, the functionality just hasn't been implemented. It has a bootloader, and again, the firmware is up on github. I know that it won't take much time to add it in, but I decided not to yet for two reasons. First, its not an important feature for most people. So I decided to save time and do it later. Second, I will need to test it, and I haven't looked yet in the depths of the manuals for the few pieces of equipment that I have at home to see if they have some sort of simple SRQ command for me to test.

If you watched my youtube videos you will see that it does support reading binary blocks from my Tek scope.



Thanks for your feedback and I'll keep your comments and suggestions in mind for future revisions. Right now, it does what I want it to for a reasonable price.

[amspire]

The IEEE488.1 electrical spec is fairly broad.  I think the only part of the spec the Atmel output cannot comply with is the 48mA  sink current at less then 0.5V. Atmel do not actually spec their outputs for 0.5V but it will almost certainly achieve well over 10mA which is enough to drive at least 4 other GPIB instruments. The GPIB spec alloes either open collector drivers or for better performance, tristate drivers. The Atmel output works well for a tristate driver. SRQ, NRFD and NDAC are meant to be open collector and not tristate, but all you need to do to emulate this in an Atmega is to set the line as in input when you want it high. Set it as a low output when you want it low. Good enough.

So the only two things you are likely to get from using the driver chips is perhaps a more electrically rugged output, and the ability to drive more attached GPIB instruments.

One of the toughest parts of the protocol for a microcontroller to manage without extra hardware is the need in the spec  to respond to the ATN line within 200nS, but as long as the micro is the GPIB controller, it sends the ATN signals rather then receiving them so that is not a problem.

I do not know your parts BOM, but I imaging that adding the driver chips could just about double the parts cost, and add 150mA or more to the current consumption. Maybe you should, but you seem to have it working.

Richard.

[scasagrande]

The IEEE488.1 electrical spec is fairly broad.  I think the only part of the spec the Atmel output cannot comply with is the 48mA  sink current at less then 0.5V. Atmel do not actually spec their outputs for 0.5V but it will almost certainly achieve well over 10mA which is enough to drive at least 4 other GPIB instruments. The GPIB spec alloes either open collector drivers or for better performance, tristate drivers. The Atmel output works well for a tristate driver. SRQ, NRFD and NDAC are meant to be open collector and not tristate, but all you need to do to emulate this in an Atmega is to set the line as in input when you want it high. Set it as a low output when you want it low. Good enough.

That's pretty much what I'm doing with the PIC. Set the pins as input for high, low for low.

I do not know your parts BOM, but I imaging that adding the driver chips could just about double the parts cost, and add 150mA or more to the current consumption. Maybe you should, but you seem to have it working.

I know where I can shave a little bit of cost for the next revision, which might make room for the 'proper' drivers. One of the most obvious changes would be to replace the FT232R with the new FT230X (cheaper and smaller).

[baljemmett]

The SRQ line is hooked up, the functionality just hasn't been implemented. It has a bootloader, and again, the firmware is up on github. I know that it won't take much time to add it in, but I decided not to yet for two reasons. First, its not an important feature for most people. So I decided to save time and do it later. Second, I will need to test it, and I haven't looked yet in the depths of the manuals for the few pieces of equipment that I have at home to see if they have some sort of simple SRQ command for me to test.

If you can't find a simple way to generate SRQs, then I'd be happy to test any updated firmware for you -- my HP 3478A has a whole slew of events that trigger them, including power-up and front-panel request, so it would be easy enough.  I was going to have a pop at writing some SRQ support myself in my copious free time, but you naturally have a head-start and if it's on your to-do list...

(Of course, as you're obviously aware I haven't even bought one yet, but I have just shot you an e-mail about shipping!)

[amspire]

The IEEE488.1 electrical spec is fairly broad.  I think the only part of the spec the Atmel output cannot comply with is the 48mA  sink current at less then 0.5V. Atmel do not actually spec their outputs for 0.5V but it will almost certainly achieve well over 10mA which is enough to drive at least 4 other GPIB instruments. The GPIB spec alloes either open collector drivers or for better performance, tristate drivers. The Atmel output works well for a tristate driver. SRQ, NRFD and NDAC are meant to be open collector and not tristate, but all you need to do to emulate this in an Atmega is to set the line as in input when you want it high. Set it as a low output when you want it low. Good enough.

That's pretty much what I'm doing with the PIC. Set the pins as input for high, low for low.

I forgot you are using a PIC 18F4250 rather then an Atmel chip. That is more like 8.5mA minimum sink current on the outputs, so a worse case chip may struggle with more than 3 GPIB devices connected. A typical chip will probably do a lot more.

Richard.

[free_electron]

i would adapt the board and put the driver footprints on there. people that want to instll the driver chips solder them on if not : a few simple resisotr packs will do the work.

as for SRQ's. Those are extremely usefull. For example. you have a lab setup. All of a sudden one power supply goes in over current. You want to react and shut down very fast. simply tell ALL your power supplies that, if overcurrent trips : send me an SRQ ..
your SRQ handler now only needs to contain an emergency escape routine that addresses all supplies and turns them off and stops your script.

That is what SRQ's are for. instead of having to 'poll' al your machines.. simply program their SRQ control register with the conditions under which you want an alert. and then trap and handle it.

I do this by default in a testsetp. I have a board in the oven running hot and the chip decides to commit suicide... instead of starting a fire and frying me test board  my power supply will trip, my escape handler kicks in turns off all supplies and sources and programs the oven temp to ambient.

[chrome]

So this is open source right? Is there a schematic, like a pdf or something.

[scasagrande]

i would adapt the board and put the driver footprints on there. people that want to instll the driver chips solder them on if not : a few simple resisotr packs will do the work.

as for SRQ's. Those are extremely usefull. For example. you have a lab setup. All of a sudden one power supply goes in over current. You want to react and shut down very fast. simply tell ALL your power supplies that, if overcurrent trips : send me an SRQ ..

Once I'm done with the blank boards that I currently have, I'll will probably include the driver chips for the next model.

And yes, there are lots of uses for SRQ. I just haven't gotten around to doing it yet!

So this is open source right? Is there a schematic, like a pdf or something.

You can find everything at github.com/Galvant including a PDF and PS version of the schematic.

The SRQ line is hooked up, the functionality just hasn't been implemented. It has a bootloader, and again, the firmware is up on github. I know that it won't take much time to add it in, but I decided not to yet for two reasons. First, its not an important feature for most people. So I decided to save time and do it later. Second, I will need to test it, and I haven't looked yet in the depths of the manuals for the few pieces of equipment that I have at home to see if they have some sort of simple SRQ command for me to test.

If you can't find a simple way to generate SRQs, then I'd be happy to test any updated firmware for you -- my HP 3478A has a whole slew of events that trigger them, including power-up and front-panel request, so it would be easy enough.  I was going to have a pop at writing some SRQ support myself in my copious free time, but you naturally have a head-start and if it's on your to-do list...

(Of course, as you're obviously aware I haven't even bought one yet, but I have just shot you an e-mail about shipping!)

I'd love to have help test and develop this functionality! Keep in touch!

[scasagrande]

Just got a picture from forum member baljemmett showing the adapter off in action!

[scasagrande]

Here's another picture from Sweden!

[nctnico]

Interesting project. Binary transfers don't seem very difficult to implement.

[scasagrande]

Interesting project. Binary transfers don't seem very difficult to implement.

I can download the waveform from my Tek224 via binary transfer no problem at all! I showed it off in action in my first youtube video (on the revA board).

[nctnico]

Hmmm. What is free_electron ranting about missing binary transfers then

[scasagrande]

Hmmm. What is free_electron ranting about missing binary transfers then

In one of my replies I mentioned to free_electron that it does indeed support transferring binary information from the instruments. In my generic instrument.py python class I implemented a binary block transfer method to make it easy for everyone to do so.

[f4eru]

For the people trying to use this with VISA :
(personally i avoid visa. Always.)
VISA can adress a serial port. This adapter can talk to a serial port.
Both should be naked GPIB commands so should work for most of the basic stuff....

Someone tested that ?