How GPIB really works

In a post long ago I wrote about having built a serial ULI GPIB interface adapter, and about some of the troubles I had with the original firmware of that adapter. I meant to fix those issues in the firmware, but I've come to realize that ULI is never going to properly work over serial, and I'll need to come up with a custom solution and to re-write the firmware.

To do that, I've researched how GPIB actually works. A bit surprisingly, the resources available on the topic are pretty bad. I thought that there'd be several detail resouces on the subject. I even acquired a copy of the original IEEE-488-1978 standard, and while it helped, it is written in (IMHO) a very difficult to understand way. In the end I've tried to piece together the information from several sources and from testing with how my GPIB enabled instruments behave. This post is mainly me documenting my findings to myself for later reference.

Basic behavior

There is at most one talker on the bus at a time, while there can be several listeners. The controller determines which device is the talker and which are listeners at any given time. Almost always the controller is either the talker or a listener on the bus.

Data output by the talker on the bus is read in by all of the listeners. This would allow e.g. a measurement device to produce output as a talker and a data recording device to collect it as a listener. In my use cases, the data would be always between a single instrument and the controller. I would consider it to be very rare these days, that data would get passed directly from one instrument to another.

The controller can act as a talker and as a listener, but in addition it can send commands.

The signals

All signals, including data lines, operate with inverted logic. That is, a high level voltage is a 0 and a low level voltage is a 1. In particular, control lines are asserted when a low voltage level is present and deasserted when a high voltage level is present. The logic level voltages themselves are TTL.

When used as outputs, the signals are driven with one of two driver types. Some signals are open-collector with weak pull-ups, while others are push-pull driven. The data lines use both driver types in different conditions, while for the other lines the driving scheme is fixed. All lines are high-impedance on a device, when they are used as inputs.

Open-collector drive is used to produce a wired OR on the bus for certain lines. In this case the low level (value 1 or asserted state) is the dominant state.

ATN

Attention. Asserted by the controller to signal the sending of a command on the data lines. This line is push-pull driven by the controller and is high-impedance on the other devices.

IFC

Interface clear. Asserted by the controller to asynchronously reset the bus logic in devices. This line is push-pull driven by the controller and is high-impedance on the other devices.

REN

Remote enable. Asserted by the controller to cause addressed devices enter remote operation mode (local user interface disabled, except for go to local key). This line is push-pull driven by the controller and is high-impedance on the other devices.

SRQ

Service request. Asserted by any device requesting an interrupt from the controller. Reason is device dependent. This line is open-collector driven by every other device on the bus except for the controller. It is high-impedance on the controller.

EOI

End or Identify. This signal has two meanings.

End: Can be asserted by a talker to indicate the last byte of a data transfer.  It is push-pull driven by the talker and is high-impedance on the other devices. It appears to be talker implementation specific if it is asserted at all, as well has how it is interpreted by listeners when it is asserted. As an example, my Racal-Dana 1992 does not assert EOI when talking, but does accept EOI as an end-of-line indicator if it is asserted. However, it also accepts CRLF as an end-of-line even without EOI asserted.

Identify: Asserted by the controller to request parallel polled devices to identify if they have a service request. It is push-pull driven by the controller and is high-impedance on the other devices. Parallel poll in general seems to be very rarely used, and is up to the controller to use it anyway. So when programming a controller, the whole functionality can be omitted.

NRFD

Not ready for data. Asserted by any listener on the bus, which is not ready to receive data. This line is open collector driven by all listeners on the bus, while it is high impedance for others. Since the asserted state is dominant, the bus will show NRFD as asserted if any one listener is not ready.

DAV

Data valid. Asserted by the talker to indicate that the data lines contain valid data, which should be accepted by the listeners. The talker waits for the NRFD signal to become deasserted before asserting DAV. This line is push-pull driven be the talker while it is high impedance on other devices.

NDAC

Not data accepted. Asserted by any listener on the bus, which has not yet accepted the valid data on the bus. This line is open collector driven by all listeners on the bus, while it is high impedance for others. Since the asserted state is dominant, the bus will show NDAC as asserted if any one listener has not accepted the data. After all listeners have accepted the data, the talker knows to de-assert the DAV line and prepare the next data.

D1 through D8

Data lines. These contain the data that is being sent. It is important to note that data lines also operate with inverted logic. The lines are push-pull driven by the talker, or open collector driven by polled devices when a parallel poll identify is requested by the controller. For other devices, the lines are high impedance.

Handshaking

At the core of transmitting data and commands is the three-way handshake process. This allows the data to be transmitted asynchronously, and following the limitations of the slowest device involved with the transfer.

Handshake timing

The listeners first deassert their pull of the NRFD line when they become able to receive data. When the last of the listeners releases the line, the line goes high (deasserted). This signals the talker that they can now transmit data. Before beginning the transfer, the talker should check that NRFD and NDAC are not both high, as that would be an indication that there is no-one listening (though at least my Racal-Dana 1992 does not do such checking).

The talker then sets the data on the data lines (remembering that the logic is inverted) and asserts the DAV line to indicate valid data (note: data can be set on the data lines already before NRFD goes high, as long as data is stable when DAV is asserted). There should be a delay of at least 1.5us between setting the data on the data lines and assertion of DAV to ensure the settling of the data lines (required by the standard).

Asserting the DAV line will signal the listeners to receive the data. When a listener has accepted the data, it will again assert the NRFD line (i.e. pull it low) to indicate that they are not ready for new data and will release their pull on the NDAC line. The NRFD line on the bus will thus become again asserted as soon as the first listener has accepted the data, but the NDAC line will become deasserted only after the last listener has accepted the data.

When the NDAC line becomes deasserted, it signals the talker that all listeners have accepted the data, and the talker will deassert the DAV line. After this, when the listeners are again ready to receive more data, they will again release their pull on NRFD line and the cycle begins again.

Exactly the same handshake cycle is used for transmitting commands when the ATN line is asserted. In that case however, the talker is the controller and the listeners are all devices on the bus.

Commands

As said, the commands are sent by the controller on the data lines together with the ATN asserted. Asserting the ATN line will instantly (<200ns) cause the other devices to release the bus for the controller to talk.

The command will be transmitted on the data lines of the bus following the handshaking protocol. The controller acts as the talker, while the other devices will act as listeners. Each command that the controller sends is a single byte.

A large portion of the commands are reserved commanding specific devices to become listeners or talkers. The addressing is also used together with the addressed group of commands, which only affect devices which have been addressed. Each addressable device on the bus has a GPIB address. The GPIB address of a device is a 5 bit value between 0 and 30 (with value 31 reserved for a special purpose).

Some sources say that address 0 is often reserved for the controller itself, but this makes no sense to me. The controller is the only one addressing the other devices, so it has no need for an address. I guess it makes sense in the weird situation, where there are several possible controllers that need to address each other.

Listen - 0x20+GPIB address - MLA

A device will become a listener if it receives the listen command with its address.

In the GPIB nomenclature the value "0x20+GPIB address" is called the listen address of the device, which is a bit misleading since this is actually the full command for the device to begin listening. Upon reception of its listen address, a device will stop being a talker (if it was one) and begin acting as a listener.

To set a device as a listener, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Send the value "0x20+GPIB address" (MLA) on the data lines using the handshake protocol
3. Deassert ATN (and set proper bus directions)

The configured device will handshake data sent on the bus and interpret them in a device dependent way.

Unlisten - 0x3f - UNL

All devices currently listening will stop listening when they receive the unlisten command. The unlisten command is basically the listen command issued for address 31, which is why no device can have GPIB address 31.

Talk - 0x40+GPIB address - MTA

A device will become a talker if it receives the talk command with its address.

In the GPIB nomenclature the value "0x40+GPIB address" is called the talk address of the device. Upon reception of its talk address, a device will stop being a listener (if it was one) and begin acting as a talker. Upon reception of a talk address of any other device it will cease acting as a talker (if it was one).

To set a device as a talker, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Send the value "0x40+GPIB address" (MTA) on the data lines using the handshake protocol
3. Deassert ATN (and set proper bus directions)

Untalk - 0x5f - UNT

The current talker will stop talking when it receives the untalk command. The untalk command is essentially just the talk command issued for address 31.

Interface clear

Asynchronously reset the GPIB interfaces of the devices on the bus. To perform the clear, the controller asserts the IFC control line for more than 150 microseconds. Devices forget their listen/talk status etc. Measurement etc. states of the instruments may be retained.

Remote control

Enabling remote control of devices uses its own REN control line. As long as the REN line is asserted, the devices which have been put into remote control stay in remote control. When the REN line is deasserted, then all devices go back to local control asynchronously.

To set a specific device to remote control, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Assert REN
3. Send the value "0x20+GPIB address" (MLA) on the data lines using the handshake protocol
4. Deassert ATN (and set proper bus directions)

Any device addressed to listen while the REN message is asserted goes into remote control. The addressed devices will remain listeners. The controller can send the UNL command if the devices shouldn't be a listeners at this time. The device will remain in remote mode for as long as REN is asserted or a go to local command is issued (either via manual entry from keypad or through command).

Local lock out - 0x11 - LLO

Will cause the go to local (or equivalent) button to be disabled on the from front panels of all instruments. This command does not inherently take devices to remote control, and doesn't an effect if the device is not taken to remot control.

To cause a specific device to enter remote control with local lockout, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Assert REN
3. Send the value 0x11 (LLO) on the data lines using the handshake protocol
4. Send the value "0x20+GPIB address" (MLA) on the data lines using the handshake protocol
5. Deassert ATN (and set proper bus directions)

After the LLO command has been issued with REN asserted, any following listen command will place a device into remote control with go to local disabled. The controller can send the UNL command if the device doesn't need to be a listener at this time. The device will remain in remote control as long as REN is asserted or a go to local command is issued. As long as REN is asserted, any device transitioning to remote control will have their go to local disabled. To re-enable the go to local buttons, REN needs to be deasserted.

Go to local - 0x01 - GTL

Will cause the addressed devices to go back to local control even when REN is asserted.

To send the GTL command to a specific device, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Send the value 0x3f (UNL) on the data lines using the handshake protocol
3. Send the value "0x20+GPIB address" (MLA) on the data lines using the handshake protocol
4. Send the value 0x14 on the data lines using the handshake protocol
5. Deassert ATN (and set proper bus directions)

Device clear - 0x14 - DCL

Will cause a power-on-reset type resetting of device functions for all devices on the bus. Racal-Dana 1992 will only perform this reset if it is under remote control, but I'm unclear if this is common (IEEE-488-1978 specifies this without remote). In any case, the devices at least don't need to be addressed to follow the command.

To clear devices on the bus, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Send the value 0x14 (DCL) on the data lines using the handshake protocol
3. Deassert ATN (and set proper bus directions)

Selected device clear - 0x04 - SDC

Will cause a power-on-reset type resetting of device functions for the devices addressed to listen on the bus.

To clear a specific device on the bus, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Send the value 0x3f (UNL) on the data lines using the handshake protocol
3. Send the value "0x20+GPIB address" (MLA) on the data lines using the handshake protocol 
4. Send the value 0x04 (SDC) on the data lines using the handshake protocol
5. Deassert ATN (and set proper bus directions)

Group execute trigger - 0x08 - GET

Causes a trigger event to be issued to the devices addressed to listen on the bus. What the trigger means is device dependent. On the Racal-Dana 1992 it triggers a single shot measurement.

To issue a trigger to a specific device on the bus, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Send the value 0x3f (UNL) on the data lines using the handshake protocol
3. Send the value "0x20+GPIB address" (MLA) on the data lines using the handshake protocol 
4. Send the value 0x08 (GET) on the data lines using the handshake protocol
5. Deassert ATN (and set proper bus directions)

Serial poll enable - 0x18 - SPE

Causes all devices on bus to send status messages instead of data, when commanded to talk.

This is used by the controller to determine which device asserted the SRQ line. The other mechanism for determining this is the parallel poll, but it seems rather obscure and rarely worth the effort.

To find the devices, which asserted the SRQ, the controller does the following

1. Assert ATN (and set proper bus direction)
2. Send the value 0x3f (UNL) on the data lines using the handshake protocol
3. Send the value 0x5f (UNT) on the data lines using the handshake protocol
4. Send the value 0x18 (SPE) on the data lines using the handshake protocol

To poll whether device with GPIB address X asserted SRQ:

1. Assert ATN (and set proper bus direction)
2. Send the value "0x40+X" (MTA) on the data lines using the handshake protocol
3. Deassert ATN (and set proper bus direction)
4. As a listener, receive the single byte status message from the talker using the handshake protocol

The status message byte holds the the SRQ status as bit 6. The controller polls each device, until if finds the one that asserted the SRQ. The status byte may also contain other device dependent information.

Serial poll disable - 0x19 - SPD

Causes all devices on bus to again send data instead of status messages, when commanded to talk.

Other commands

Parallel poll configure - 0x05 - PPC (Parallel poll stuff...)

Parallel poll enable - 0x6X - PPE (Parallel poll stuff...)

Parallel poll disable - 0x7X - PPD (Parallel poll stuff...)

Parallel poll unconfigure - 0x15 - PPU (Parallel poll stuff...)

Take control - 0x09 - TCT (Cause another controller to become the controller)

Interface ICs

The common interface ICs used for GPIB communications are the Texas Instruments SN75160B, SN75161B and SN75162B.

The SN75160B is an octal tranceiver, which is commonly used for the data bus signals. It allows setting the data lines into receive or transmit via the talk enable (TE) signal (TE=high, transmitting toward GPIB). When in transmit mode, the bus-side output can be set as either push-pull or open-collector via the pullup enable (PE) signal (PE=high, outputs are push-pull). The datasheet of the IC is annoyingly unclear on these aspects. It is important to note that a high value on one side of the tranceiver is transmitted as high value on the other side. That is, there are no inverters in the interface to account for the inverted logic on GPIB.

The open-collector drive capability of the data lines seems to be used only for the parallel poll feature. For the sole controller on the bus, the data lines are always either push-pull driven toward the bus or used as inputs. That is, PE can be kept constantly high.

The SN75161B and SN75162B are tranceivers for the GPIB control lines. One difference between the two is than the SN75162B includes a separate direction control for ATN/SRQ and REN/IFC, while on the SN75161B there is a single control for all four. They also seem to have different drive circuitry for some of the lines. My interface is built using an SN75162B, so I'll only cover it here.

The direction of the controller lines ATN, SRQ, REN and IFC are controlled via the DC and SC lines.

• When SC is high, REN and IFC are push-pull outputs toward the bus.
• When SC is low, REN and IFC are inputs from the bus.
• When DC is low, ATN is a push-pull output toward the bus and SRQ is an input from the bus.
• When DC is high, ATN is an input from the bus and SRQ is a open-collector output toward the bus.

For the sole controller on the bus, the SC line can be kept constantly high and the DC line can be kept constantly low.

The direction of the handshake lines NRFD, DAV and NDAC are controlled via the TE line.

• When TE is high, DAV is a push-pull output toward the bus, while NRFD and NDAC are inputs from the bus.
• When TE is low, DAV is an input from the bus, while NRFD and NDAC are open-collector outputs toward the bus.

Similar to the SN75160B, there are no inverters inside the SN75162B to account for the inverted logic of the GPIB.

Resurrecting my Timex Datalink 150

I used to wear a Timex Datalink 150 wrist watch daily from about 1997 to 2008. In 2020, I wanted to get it up and working again. This is a record of what I did to achieve that.

The watch was originally introduced in 1995 (I think), and had some very interesting and unique features at the time. It was the third iteration of the Timex Datalink line, after Datalink 50 and Datalink 70. The line of watches were able to store phone numbers, appointments, to-do lists, anniversaries and alarms. The number (50, 70, 150) in the Datalink line model numbers referred to the approximate amount of phone numbers the watch could store. Compared with the older Datalink 70 model, the Datalink 150 doubled the amount of EEPROM available for the data (from 1kB to 2kB), but also added support for what Timex called wristapps.

The wristapps were small pieces of software, which were loaded in the RAM of the watch, and which could actually be executed. This allowed extending the features of the watch, such as adding a stopwatch or a countdown timer mode. A number of wristapps were delivered with the watch, but Timex also sold additional ones. The wristapp was stored always in a fixed location in RAM, so only one wristapp could ever be loaded at one time. Also, there was only 804 bytes total in the user RAM area, which was also shared by the melody configuration. The melody defined what the watch beeps sounded like (alarm, appointment notification, etc). With the default melody, the maximum wristapp size was about 760 bytes.

The data were transmitted to the watch optically by pointing the watch at a CRT monitor of a PC and running a proprietary piece of software (on Windows), which displayed a flashing line pattern representing the data to be transmitted. The watch would receive the data through a photodetector eye located in the watch face.

A CRT really is required, as the upload process exploits the raster scanning of the CRT to cause sudden changes in brightness. Active matrix LCDs don't scan, and would be too slow anyway. However, LCD monitors were not unheard of even at that time (in laptop computers), and Timex sold a separate notebook adapter to allow using the watches with laptop computers. The notebook adapter connected to the serial port of the computer, and used a flashing LED to transfer the data.

Trying to use the watch these days is quite difficult. A CRT is hard to come by, and even if you had one, the software doesn't run on modern version of Windows (i.e. XP or later). The software does work in some versions of NT, but only with the notebook adapter, which appears to be quite expensive today. Finally, the closed source nature of the software isn't ideal either.

Between 1996 and 2002, Tommy Johnson, Karl R. Hakimian, David Fries, Frank Denis, Steaphan Greene, Harold Zatz (and possibly others) reverse engineered the watch transfer protocol and wrote an open source implementation of the data transferring software, called simply datalink. This work is the most important piece in using the watch with modern computers. This work is available on GitHub.

The open source datalink software has three methods for getting the data to the watch. There is an SVGAlib based CRT flasher for Linux PCs, an OpenGL based CRT flasher for SGI machines and a RS232 UART based LED flasher for Unixlike OSs. None of these really work with modern machines, unfortunately. The first two fail due to the requirement of a CRT (not sure if svgalib still works either). The LED flasher requires an RS232 port, which is also quite rare. Although it might still be possible to use that approach with a USB based RS232 adapter.

Clearly flashing an LED was the way to go. However, I wanted to offload the timing generation to external hardware instead of essentially bit-banging it as the datalink software LED flasher does. This called for a microcontroller, which would at least partially understand the transfer protocol.

I wanted to be sure of the correct timing in the data framing. For this purpose, I installed the original Timex Datalink software on a Windows 95 virtual machine, and took screenshots of the output it was producing. Since the software used the standard 640x480 VGA modeline, I could determine the row numbers on which the output was produced to determine the proper timing to use with the LED.

Sync frame containing bytes 0x55 0x55 as sent by the Datalink software on Windows 95

The way the transmission works is the following:

• A frame may contain zero, one or two bytes.
• Bits are transmitted least significant bit first (the order in the raster scan: top to bottom)
• A bit value 0 is transmitted as a white line, a bit value 1 is transmitted as a black line.
• Transmission of the first byte is started by a white line on row 79 (1-indexed)
• The bits of the first byte follow on lines 94, 109, 124, 140, 155, 171, 186, 202 (1-indexed)
• Transmission of the second byte is started by a white line on row 264 (1-indexed)
• The bits of the second byte follow on lines 279, 295, 310, 326, 341, 357, 372, 388 (1-indexed)
• If only one byte is transferred in the frame, it is in the place of the first byte.
• When zero bytes are transferred in the frame, the frame is entirely blank.

The 640x480 VGA timing is such that each row takes 31.778 us, of which the visible part takes 25.422 us. The bits follow each other with an average bit period of 15.45 rows, which equals about 491 us. When the bit is a 0, the signal is asserted for the entire visible part of the row, i.e. for 25.422 us.

The gap between the bytes is almost exactly 3 bit periods. Thus from the start of the first byte to the end of the second byte, there are a total of 21 bit periods, i.e. 10.310 ms. A full frame takes 16.683 ms, which means that there is an additional delay of 6.373 ms between the end of the second byte of a frame and the beginning of the first byte of the next frame.

Rounding and consolidating the numbers give for example the following practical framing scheme, which is within the margins accepted by the watch:

• Bit period 490us
• Value 0: 30us signal asserted, followed by 460us signal deasserted
• Value 1: 490us signal deasserted
• A frame has exactly 34 bit periods, and consists of the following bits
1. Start bit of first byte (sent as value 0 if at least one byte in this frame)
2. Bit 0 of first byte
3. Bit 1 of first byte
4. Bit 2 of first byte
5. Bit 3 of first byte
6. Bit 4 of first byte
7. Bit 5 of first byte
8. Bit 6 of first byte
9. Bit 7 of first byte
10. Dummy bit (always sent as value 1)
11. Dummy bit (always sent as value 1)
12. Dummy bit (always sent as value 1)
13. Start bit of second byte (sent as value 0 if two bytes in this frame)
14. Bit 0 of second byte
15. Bit 1 of second byte
16. Bit 2 of second byte
17. Bit 3 of second byte
18. Bit 4 of second byte
19. Bit 5 of second byte
20. Bit 6 of second byte
21. Bit 7 of second byte
22. Dummy bit (always sent as value 1)
23. Dummy bit (always sent as value 1)
24. Dummy bit (always sent as value 1)
25. Dummy bit (always sent as value 1)
26. Dummy bit (always sent as value 1)
27. Dummy bit (always sent as value 1)
28. Dummy bit (always sent as value 1)
29. Dummy bit (always sent as value 1)
30. Dummy bit (always sent as value 1)
31. Dummy bit (always sent as value 1)
32. Dummy bit (always sent as value 1)
33. Dummy bit (always sent as value 1)
34. Dummy bit (always sent as value 1)

To initialize data transmission, the watch must receive a number of preamble frames containing the bytes 0x55,0x55. This makes the watch sync to the stream and start beeping. Then, right before actual data transmission starts, about 25 start of transmission frames, containing the bytes 0xaa,0xaa, are transmitted. I'm not sure of the exact number required, but 25 seems to work well. The actual data transmission then starts.

The data is transmitted in packets. Each packet begins with a byte describing the length of the packet in bytes and ends with two CRC bytes. The transmitted length value includes the CRC bytes and the length byte itself. After each packet, a few empty frames (about 10, but again exact number not known) must be transmitted, during which the watch accepts the previous data and emits a beep. An empty frame is one with no data bytes, and thus is a blank screen. The CRC bytes are already calculated by the datalink utility, so the uploader only needs to understand the packet length to add the empty frames after each packet.

To further understand the data format itself, John Toebes has a description of the download protocol and the packet formats. Though I'm not sure if he's correct about the sync bits part. Toebes is also the author of the assembler for these devices, and his site is the best all-round resource regarding the watches. Even more detail is found in the source code of the datalink utility.

I hacked an implementation together using an STM32 BluePill board (STM32F103C8 uC). Since code space or efficiency were not critical, I used FreeRTOS to make the software a bit faster to develop. You can find my implementation on GitHub. The project uses the uC USB capability for receiving the data, presenting as a USB CDC device. It then blinks an LED connected to PB9.

Datalink uploader