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

Investigation of quarter-wave folded balun operation

For a about a month, I've been trying to understand how the quarter-wave folded balun works. There are some explanations online, such as this one at Stack Exchange or this one at antenna-theory.com. There are many others as well.

I kinda sorta understand what those explanations are getting at, but I still felt like I didn't really understand what is going on. The explanations seem to rely on experience and intuition of people who have worked with these things. I don't have that that experience or intuition, so I tried modelling the situation to gain insight. All computations in this article are made with scikit-fem.

So what is a quarter-wave folded balun and what is it used for? In short, a balun is a device for converting single-ended signals to differential signals, and back again. Though, what exactly a single ended signal or a differential signal means differs from situation to situation. Talking about signal as voltage, then typically a single ended signal has two conductors, one of which carries the signal, while the other one is a reference level (like ground). In a differential signal one has three conductors (or just two, because of a caveat), in which one conductor carries a positive signal, one carries a negative signal and the third one is the reference. The caveat in this case is, that the reference level can be inferred as the average of the two signal levels, and the reference conductor is not strictly needed.

Coaxial cables are often used as feedlines for antennas. They have the nice feature, that when the currents in the coax are differential, i.e. the current in the shield is equal but opposite to the current in the inner conductor, and when the shield is at ground potential, then the eletromagnetic fields carrying the signal are entirely contained within the coax. This means that passing the cable near metals, or touching the cable by hand doesn't affect the signal it carries. If the currents are not balanced, though, then external fields are produced. These fields will interact with the surroundings, changing the signal carried. The fields also radiate, causing the coax itself to act as an antenna, changing the overall behavior of the system.

So how is it possible that the currents in the coax are not equal? I mean, where else could the current from the inner conductor go other than to the shield? Well, the currents can return through some other conductor, such as the ground. For instance, in the case of an antenna the currents will vanish into thin air and pass to ground through the radiation resistance. If the impedance to ground from the terminals of the antenna are equal, then driving the antenna differentially (with respect to ground) will result in an equal but opposite current in the terminals, and thus also in the feed line. However, since the coax shield needs to remain at ground potential to avoid an external electric field, it isn't possible to have the shield directly drive one side of a differential signal. This is where the balun steps in. The balun will take in a single-ended signal from the coax, and transform it into a differential signal, which is suitable for the load.

To begin the investigation, let's look at the bare coax setup below (figure modified from the work of Omegatron on Wikimedia Commons).

Baseline setup without the balun

The source is single ended, which feeds the inner conductor on the left side of the coaxial cable. The frequency from the source is 868 MHz. The source also has an output impedance of 50 ohms, which is the same as the coax characteristic impedance. The coaxial cable shield is connected to ground at the left side. The load is on the right side of the coaxial cable. It consists of two 25 ohm resistors: one is connected between the coaxial inner conductor and ground and the other is connected between the coaxial shield and ground. This load looks like a 50 ohm resistor for differential signals and like a 25 ohm resistor for single-ended signals. Further, to control stray capacitances and inductances, and to act as a reference, the cable is placed over a ground plane.

The situation is modeled as a multiconductor transmission line. You should check out my previous post about the subject, which is way more involved regarding the mathematics and modelling. The transmission line parameters were computed using FEM. Dimensions and materials used were those of RG-316 coax suspended 20 mm above the ground plane.

Simulating this configuration we notice that there is a significant dependence on the length of the coaxial cable. I don't think this comes as a huge surprise for anyone with experience with transmission lines and coaxial cables. It turns out, that by choosing the coax length properly, the load can be matched to the coax to get a very good power transfer. However, it doesn't seem possible to both match the load to the coax and prevent external fields.

As a first example at 860 mm length there is very poor matching of the load. No current is passing in the shield-side load resistor. This results in a large current imbalance between the conductors, and leads to large induced voltages in the shield. There are thus both large magnetic and electric fields external to the coax. Some quantitative parameters to characterize this situation:

• Maximum common-mode current amplitude in coax: 14.47 mA
• Maximum voltage amplitude in coax shield: 6.92 V
• Common-mode current to load: 14.47 mA
• SWR: 2.00

Voltage and current distribution in coax of length 860mm

The situation is quite different at 946mm length. Here current flows to the load from both the inner conductor and the shield, and the currents are approximately equal and opposite, which results in a mostly balanced current in the coaxial cable. However, the differential signal at the load is achieved through a voltage oscillation in the shield, which leads to a significant electric field external to the coax. The observed parameters at this situation are

• Maximum common-mode current amplitude in coax: 1.05 mA
• Maximum voltage amplitude in coax shield: 0.50 V
• Common-mode current to load: 0.053 mA
• SWR: 1.00

Voltage and current distribution in coax of length 946mm

Computing the monitored parameters over a range of coax lengths reveals a pattern, which repeats every half wavelength. We also observe, that there is no length which would get rid of the significant voltage in the shield. The best one can do is what is represented by the 946mm coax length case.

Observed parameters against coax length

Next, we'll look at the same situation with the quarter-wave folded balun. See the illustration below (figure again modified from the work of Omegatron on Wikimedia Commons).

Quarter-wave folded balun setup

The feed and load remain exactly as in the first case. What has changed, however, is the addition of a shorting stub, which connects the inner conductor of the coax to the shield of the coax. This shorting piece is made of the same type of coax, but doesn't have its inner conductor connected anywhere. This situation can be modelled as two multiconductor transmission lines connected at the shorting wire interface. We have a 2-conductor (plus ground) line on the left side and a 3-conductor (plus ground) line on the right side. At the interface, we require compatibility conditions of the voltages and currents:

• Inner conductor voltage is continuous
• Inner conductor current is continuous
• Shield voltage is continuous
• Left shield current = right shield current + shorting current
• Shorting voltage equals shield voltage

The suitable shorting wire piece is approximately a quarter of a wavelength at the desired operating frequency (here 868 MHz), thus the reason for calling it a quarter-wave folded balun. However, the velocity in the inner of the coax and in the shorting wire are not the same. The shorting wire is surrounded in large by air, thus the velocity is close to the speed of light, whereas the inner has a velocity factor of about 0.7. A quarter wavelength at the speed of light is about 86 millimeters, while at velocity factor 0.7 it is about 60 millimeters. It is thus not immediately clear what the actual length for the shorting wire should be. To understand how the shorting length affects the performance, we can compute the same observed parameters for a sweep over the length.

Sweep over shorting length for a coax with overall length 860mm

Sweep over shorting length for a coax with overall length 946mm

The common mode currents and the shield voltage all decrease as the length of the shorting wire is decreased. However, at very short shorting lengths, the SWR becomes very bad. Though it seems that the design is quite forgiving when it comes to the exact shorting length. That is, we get a decent SWR over a large range of lengths. There is a trade-off, however, between achieving the best SWR and getting a lower common-mode current.

The optimal SWR of very close to unity is achieved with a shorting length of 61.5mm, which is slightly more than quarter wavelength at the coax propagation speed. At this shorting length, we observe the following parameters for the 860mm coax length:

• Maximum common-mode current amplitude in coax: 0.17 mA
• Maximum voltage amplitude in coax shield: 0.080 V
• Common-mode current to load: 0.22 mA
• SWR: 1.00

For 946mm, we observe the following:

• Maximum common-mode current amplitude in coax: 0.016 mA
• Maximum voltage amplitude in coax shield: 0.0077 V
• Common-mode current to load: 0.040 mA
• SWR: 1.00

Allowing for a slightly worse SWR and choosing the shorting length as 40mm gives considerably better common-mode behavior. At 860mm:

• Maximum common-mode current amplitude in coax: 0.058 mA
• Maximum voltage amplitude in coax shield: 0.028 V
• Common-mode current to load: 0.080 mA
• SWR: 1.32

And at 946mm:

• Maximum common-mode current amplitude in coax: 0.0056 mA
• Maximum voltage amplitude in coax shield: 0.0027 V
• Common-mode current to load: 0.024 mA
• SWR: 1.31

The correct shorting length is thus not at all clear. However, as long as the shorting length is sensible, the balun does seem to work as intended, reducing the coax common-mode current and shield voltage down to about one one-hundredth of just the bare coax. Now we just need to understand how it works.

The following are visualizations of system with a shorting length of 40mm.

Sweep of overall coax length with shorting length at 40mm

Voltage and current profiles in the system with 860mm coax length and 40mm shorting length

Voltage and current profiles in the system with 946mm coax length and 40mm shorting length

The following are computed with shorting length 61.5mm.

Sweep of overall coax length with shorting length at 61.5mm

Voltage and current profiles in the system with 860mm coax length and 61.5mm shorting length

Voltage and current profiles in the system with 946mm coax length and 61.5mm shorting length

At 61.5mm shorting length, the shorting wire appears to only interact very weakly with the inner conductor: almost no current is flowing through the connection between the inner and the shorting. This gives some insight to the operating mechanism of the balun. It shows that the inner conductor plays only a minor role in the operation, and the main interaction is between the shield and the shorting wire.

It seems to work by having the shorting wire and coax shield form a resonator through capacitive and inductive coupling. When current oscillates back and forth in the shorting-shield resonator, the voltage at the load end of the system oscillates differentially. This oscillation is sustained with only tiny kicks of current from the inner conductor. The closer the shorting length is to the quarter wavelength, the less of a kick is needed from the inner conductor and the closer to zero the shorting current is on the right. The oscillation voltage is differential with respect to the ground plane due to symmetry of the system.

Although the inner conductor is very loosely coupled with the resonator, all the energy in the resonator needs to still come from it. This is because the resonator is shorted at the left end, and while there is a lot of current flowing, the voltage there is zero. On the right end, however, the short-inner connection has a non-zero voltage and also nothing is preventing current from flowing. The only reason current is not flowing in the 61.5mm shorting length example is because the system is driven at the resonant frequency, any lower or higher and we'd see power transferring in and out during the cycle.

When feeding the system with a wave packet, we can observe the resonator starting and stopping oscillation. The following shows a Gaussian wave packet with a characteristic time of 1ns at 868MHz passing through a 946mm long coax with a 61.5mm shorting wire.

In the video, you can see the resonator picking up speed a bit slower than the wave packet would otherwise move, and also the resonator keeps going for a bit longer than the wave packet would. Though this these aren't as clearly visible in the video as I had hoped for.

To really see how the resonator ramps ups and down, let's take a closer look at the power driven to the resonator. This power is computed as the shorting wire voltage times shorting wire current conjugate at the right end. Plotted below is the power against time in the simulation shown in the video above. We see that when the oscillation is ramping up, there is a positive power transfer to the resonator, and when the oscillation is dying out, power is transferred from the resonator back to the coax.

Power to (from) the resonator as a function of time in the simulation shown earlier

To be honest, I still don't fully understand how the balun works. I do not have enough insight or intuition of the situation that I could come up with the design myself, and although I can show it working, I can't explain it in simple terms. In conclusion, it's all a bit of black magic and voodoo.