Difference between revisions of "Gpibgrok"

From sigrok
Jump to navigation Jump to search
m (Bert moved page GPIB-USBTMC to GPIBGROK without leaving a redirect)
m (Bert moved page GPIBGROK to Gpibgrok without leaving a redirect)
(No difference)

Revision as of 00:27, 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

GPIB protocol chips

(pretty much all of them are no longer available)

GPIB transceiver chips

Resources