Why Your AV Command Format Is Wrong: Terminators, ASCII vs HEX and Checksums

The Cable Is Fine. The Format Is Wrong.

Once you have ruled out wiring and serial parameters, almost every remaining "device does not respond" comes down to one of three things:

• The terminator — how the device knows your command ended

• ASCII versus binary — whether 01 means two text characters or one byte

• The checksum — computed with the wrong rule, or appended in the wrong byte order

None of these produce an error message you can read. The device simply ignores you, which is why they consume so much time. This page puts all three side by side across the brands so you can recognise which one you are in.

For the physical layer first, see null modem vs straight-through.

Part 1: Terminators

There is no industry convention. Here is what ten protocols actually do:

The two failure modes

Missing terminator. The device holds your command in its buffer waiting for the end marker that never arrives. Nothing happens, and often the next command you send gets concatenated onto the first, so both fail.

Extra terminator. On length-delimited protocols like Samsung MDC and NEC, a trailing 0x0D is a stray byte. It corrupts the current frame or, worse, gets treated as the first byte of the next one — producing intermittent failures that look random.

The single most common instance of this: using a println-style call instead of a write-bytes call. println silently appends CR/LF. On Epson that is correct. On NEC it destroys the packet.

Part 2: ASCII Digits vs Binary Bytes

This is the subtlest of the three because the same value looks identical on paper.

When a manual says the Set ID is 01, that can mean either:

ASCII  : the characters '0' and '1'  →  0x30 0x31   (two bytes)
Binary : the value one               →  0x01        (one byte)

Brands split roughly down the middle:

People coming from Samsung MDC to LG send binary and get silence. People coming from LG to MDC send the text "AA11FE010111" — twelve characters instead of six bytes — and get silence. Both are the same mistake in opposite directions.

The Optoma tilde trap

Optoma's tables print power-on as hex 7E 30 30 30 30 20 31 0D. The leading 7E looks like a binary lead byte, which invites the conclusion that the rest is binary too.

It is not. 7E is simply the ASCII character ~, and everything after it is ASCII: 30 is 0, 20 is a space, 0D is CR. Sending 7E 00 00 00 00 01 0D as raw bytes fails.

Optoma's documentation adds a second trap: it writes commands as ~XX00 1 where XX is a placeholder for the projector ID. Send that literally and you transmit 7E 58 58 … — the letters XX — addressing a projector that does not exist.

Part 3: Checksums

Four different rules appear in common AV gear. Every one of them is easy to verify by hand, and you should, because command tables get copied between forums for years without anyone recomputing them.

Rule 1 — Sum modulo 256 (Samsung MDC)

Add every byte except the header, keep the low byte.

Power on, broadcast:
  0x11 + 0xFE + 0x01 + 0x01 = 0x111
  0x111 & 0xFF              = 0x11
  Packet: AA 11 FE 01 01 11

Samsung phrases it as "if it exceeds two digits, the first digit is discarded" — the same thing.

Rule 2 — Sum of preceding bytes (NEC projector)

Add everything before the checksum, keep the low eight bits.

Power on : 02 + 00 + 00 + 00 + 00 = 0x02  →  02 00 00 00 00 02
Power off: 02 + 01 + 00 + 00 + 00 = 0x03  →  02 01 00 00 00 03

The power-on frame is a coincidence worth noting: the checksum happens to equal the first byte, which makes people think it is a repeat. Power off proves the rule.

Rule 3 — Two's complement (Samsung Ex-Link)

The checksum is the value that makes the whole frame sum to zero.

checksum = (0x100 - sum(first six bytes)) & 0xFF

TV Off  : sum(08 22 00 00 00 01) = 0x2B  →  0xD5   ✓
HDMI 1  : sum(08 22 0A 00 05 00) = 0x39  →  0xC7   ✓
TV Tuner: sum(08 22 0A 00 00 00) = 0x34  →  0xCC   ✓

This rule is why we can tell you that the widely-copied Ex-Link power-on code 08 22 00 00 00 02 D6 is wrong — by the rule it should be D4. Three other codes verify correctly, so the error is in that one frame, not the rule. See Samsung Ex-Link commands.

Rule 4 — CRC-16 (Modbus RTU)

Polynomial 0xA001, initial value 0xFFFF, and — the part that catches everyone — appended low byte first, unlike every other multi-byte field in Modbus.

Read 1 holding register from slave 1:
  Body: 01 03 00 00 00 01
  CRC : 0x0A84
  Frame: 01 03 00 00 00 01 84 0A
                            ^^ ^^ low byte, then high byte

If your routine produces 0A 84, the byte order is reversed and no device will ever answer. See Modbus RTU vs TCP.

Note also that Barco's legacy 33-byte packets require recalculating the checksum for each projector address — which is why generic tables for old Barco gear rarely work unmodified.

Diagnosing Which One You Have

Work through this in order:

1. Does the device reply with anything at all?

A reply — even an error — proves the cable, baud rate, parity and framing all reached the parser. Now you are debugging content, not connection. Brands that tell you why:

BenQ's three-way distinction is the most useful in the industry — Block item means your command was fine but the timing was not.

2. Complete silence? Then the frame never parsed. Check, in this order: terminator → ASCII/binary → checksum.

3. Works sometimes? Suspect an extra terminator bleeding into the next frame, or a length-delimited protocol receiving stray bytes.

4. Worked on the bench, fails on site? That is usually not format — see null modem vs straight-through for cable length and termination.

The Habit Worth Adopting

When a published control code fails its own protocol's checksum rule, trust the rule, not the table.

Every checksum rule above can be checked in under a minute with a calculator. Command tables circulate for years between forums, vendor KBs and PDFs, and nobody recomputes them. We found one wrong code doing exactly this check while writing these pages.

With SoftControl

SoftControl accepts both text and hex payloads per command, computes Modbus CRC for you, and its command tester displays the request as text, as bytes and as hex, plus the raw reply. That three-way view is precisely what separates "my terminator is wrong" from "my checksum is wrong" from "nothing is listening" — three problems with identical symptoms and completely different fixes.

For the protocol overview see AV control protocols explained, and for verifying with a terminal before blaming the control system see serial terminal software for AV.