Difference between revisions of "Gpibgrok"

From sigrok
Jump to navigation Jump to search
Line 41: Line 41:
* [http://www.datasheetarchive.com/dl/Datasheets-112/DSAP0051077.pdf Fairchild 96LS488]
* [http://www.datasheetarchive.com/dl/Datasheets-112/DSAP0051077.pdf Fairchild 96LS488]
* [http://www.datasheetarchive.com/dl/Datasheets-24/DSA-476449.pdf NEC uPD7210C/D]
* [http://www.datasheetarchive.com/dl/Datasheets-24/DSA-476449.pdf NEC uPD7210C/D]
* [http://www.datasheetarchive.com/dl/Datasheets-313/195317.pdf National NAT9914]
* [http://www.datasheetarchive.com/dl/Datasheets-313/195317.pdf National Instruments NAT9914] ([http://sine.ni.com/nips/cds/view/p/lang/de/nid/11153 NI page], [http://www.ni.com/pdf/products/us/4gpib705.pdf NI datasheet])


(pretty much all of them are no longer available)
(pretty much all of them are no longer available)

Revision as of 02:29, 28 May 2012

This page documents some ideas and information for a GPIB-USBTMC hardware interface.

Motivation

There are many ways to communicate with devices that have a GPIB port, and sigrok aims to support as many of them as possible (see IEEE-488). However in this day and age the only reasonable interface for this would have to use a USB device port, since USB host ports are so ubiquitous. The USB standards include a device class specifically made for test and measurement, called the USBTMC class.

Yet most of the GPIB-USB interfaces available don't use this device class; they typically use either a proprietary protocol or serial emulation. There is only one GPIB-USBTMC interface that we know of: the TEK-USB-444 from Tektronix, and it's ridiculously overpriced at around $740.

We think we can make a GPIB-USBTMC interface that is:

  • 100% free and open source, hardware and firmware/software
  • 100% standards-compliant
  • Considerably cheaper than anything else out there (less than $50)

In addition, since we'd be making essentially a "server-side" i.e. USB device-side implementation of the USBTMC protocol, this code would be reusable in projects such as Das Oszi.

Hardware design

  • Using an ARM Cortex-M3 microcontroller would get us:
    • Built-in USB
    • Plenty of horsepower to handle the throughput a GPIB device will reasonably need
    • Many different implementations to choose from, and many inexpensive development boards
    • Can start with an existing development board + GPIB connector
  • Voltage levels on GPIB pins is "negative logic with standard TTL levels": true <= 0.8V, false >= 2.0V. (to be verified)

Software

Due to the long history of the IEEE-488 and SCPI standards, there are many devices out there supporting some earlier version of the protocol, and these will typically support commands that are vendor-specific, and syntax that is not compliant IEEE-488. Therefore supporting various device-specific or vendor-specific "quirks" will likely be a big part of real-world use-cases.

Components

GPIB connectors

  • Right-angle PCB mounted male

GPIB protocol chips

(pretty much all of them are no longer available)

GPIB transceiver chips

Resources