Serial Terminal Software for AV: PuTTY, Tera Term, Hercules and RealTerm Compared

Why This Is the First Tool You Should Reach For

When a device does not respond, the highest-value diagnostic step is to take the control system out of the equation entirely: connect a laptop directly and send the command by hand.

The logic is simple. If a terminal can drive the device, then the cable, the serial parameters, the device configuration and the command string are all proven — and the fault is in the control system's configuration. If the terminal cannot, stop looking at software altogether.

This one habit resolves more commissioning problems than any other, and it takes two minutes.

The Question That Decides Which Tool: Text or Binary?

This is the whole selection criterion, and getting it wrong wastes an afternoon.

Some AV protocols are readable text you can literally type:

PWR ON          Epson
power "on"      Sony
ka 00 01        LG
*pow=on#        BenQ
(PWR 1)         Christie

Others are raw bytes that cannot be typed at all:

AA 11 FE 01 01 11        Samsung MDC
02 00 00 00 00 02        NEC projector
08 22 00 00 00 01 D5     Samsung Ex-Link
01 03 00 00 00 01 84 0A  Modbus RTU

PuTTY — by far the most commonly recommended terminal — cannot send arbitrary bytes. It sends the characters you type. Type AA 11 FE into PuTTY and you transmit eight ASCII characters (0x41 0x41 0x20 0x31 0x31 …), not three bytes.

So the recommendation splits cleanly:

If you keep exactly one tool on your commissioning laptop, make it one that can do hex.

The Tools

PuTTY — text protocols, serial and TCP

Free, tiny, no installation, and it does both serial and raw TCP, which makes it genuinely useful given how many AV devices accept the same commands over both transports.

• Serial: connection type Serial, set the COM port and speed, then configure data bits/parity/stop bits under Connection → Serial.

• TCP: connection type Raw — not Telnet. Telnet mode inserts protocol negotiation bytes that corrupt AV commands.

• Turn on local echo (Terminal → Line discipline) or you will not see what you type.

Limitation: no hex entry, and no way to send a lone CR versus CR+LF reliably. For a protocol that is picky about terminators — Sony's ADCP, where \r and \n behave differently across generations — this matters.

Tera Term — text protocols with scripting

More capable than PuTTY for serial work: explicit control over transmit line endings (CR / LF / CR+LF), a send-file function, and a macro language for repeatable test sequences.

Being able to choose the terminator explicitly makes Tera Term a better default than PuTTY for AV, and it can send a prepared binary file, which is a workable if clumsy route to sending bytes.

Hercules SETUP utility — the AV all-rounder

Free, portable, and it covers serial, TCP client, TCP server and UDP in one window with separate tabs. That combination is unusually well matched to AV work, where you may need to test a projector over serial, a media player over TCP and a lighting controller over UDP in the same afternoon.

It supports hex entry using a $XX escape syntax, so binary protocols are reachable.

The TCP server and UDP tabs are the standout feature: they let you receive. When you are integrating a third-party system that is supposed to send commands to your control software, Hercules lets you stand in for the control software and see exactly what arrives — including whether it has a terminator. That is often the fastest way to settle a "we definitely sent it" argument. See UDP works but TCP doesn't.

RealTerm — built for binary

Purpose-built for binary and hex work: hex display, hex send, control-character visibility, and capture to file.

If you spend your time on Samsung MDC checksums, Modbus frames or NEC packets, RealTerm shows you the bytes as bytes rather than as mangled text. Its interface is dense and dated, but for binary debugging nothing else is as direct.

CoolTerm — cross-platform, hex-capable

The best option on macOS, and available on Windows and Linux too. Hex send and hex display, plus a clean interface. If your commissioning laptop is a Mac, this is the answer.

A note on "AV" terminal apps

Various vendor-specific test utilities exist — Samsung's SamTvControlLite for Ex-Link, for instance. They are worth using when you have one, because they encode the device's quirks for you. But they only cover that vendor, so they supplement a general terminal rather than replace it.

Setting Up for a Test

1. Find the COM port. Device Manager → Ports (COM & LPT). Remember that a USB-to-serial adapter gets a different COM number on a different USB socket — see null modem vs straight-through.

2. Set the serial parameters. Most AV gear is 9600/8/None/1. The notable exceptions:

• Sony ADCP: 38400/8/Even/1

• NEC projectors: often 38400

• Modbus RTU: frequently even parity

• Legacy Barco: 19200 default

3. Turn on local echo so you can see your own typing.

4. Set the terminator explicitly — CR, LF, CR+LF or none. This is not a detail; it is one of the three main reasons commands fail. See command format.

5. Send a query first, not a power command. A status query is safer and more informative — it tells you the link works without changing anything in the room, and it works in states where power commands may be refused.

The ideal first test is a protocol's cheapest possible message:

• Epson: a bare CR should return :

• PJLink: connecting alone should produce a greeting

• BenQ: a malformed command returns Illegal format, which still proves the link

Getting an error reply is a success, in the sense that it proves everything below the command layer works.

Reading the Result

That last row deserves attention. Seeing your command come back is ambiguous: it can be your terminal's local echo, or it can be a Panasonic projector telling you it is in standby and refusing the command. Turn local echo off once to tell the two apart.

With SoftControl

SoftControl's command tester covers the same ground inside the product — text and hex payloads, per-device serial parameters including parity, and a view of the request as text, as bytes and as hex alongside the raw reply.

The reason to keep a standalone terminal anyway is isolation: when you want to prove a device works independently of any control software, a terminal is the neutral witness. Use the terminal to establish ground truth, then move the known-good command into the control system.

For the physical layer see null modem vs straight-through, and for command content see terminators, ASCII vs HEX and checksums.