Samsung Ex-Link Commands: Pinout, Hex Codes and a Checksum Worth Verifying

Ex-Link vs MDC: Make Sure You Have the Right One

Samsung runs two completely incompatible serial protocols:

If your panel has a normal DB9 serial port, you want the MDC protocol, not this page. Ex-Link is what you use when the only control port on the back of the TV is a 3.5 mm jack labelled Ex-Link or Service.

A word of advice before you start: a consumer TV in a permanent installation is a compromise. Ex-Link is undocumented by Samsung for public use, the codes vary between model years, and the port sometimes disappears entirely in a firmware update. If the client will fund a commercial panel, that is the better answer — MDC is documented, stable and designed for this.

The Pinout Problem

This is where most Ex-Link projects stall, and it is the single most searched aspect of the protocol.

Ex-Link uses a 3.5 mm jack carrying serial signals, so you need a 3.5 mm to DB9 adapter cable. Samsung shipped an official dongle with some models; third-party cables exist.

Do not assume the tip/ring assignment. Which conductor carries TX, which carries RX and which is ground varies between model generations. A cable that works on one Samsung will do nothing on another, and because both ends look identical there is no visual clue.

Two practical consequences:

• If you are buying a cable, buy one listed for your specific model year.

• If you are making one, get the pinout from the service documentation for your exact model — not from a forum post about a different one.

The failure mode is silence, which is indistinguishable from every other Ex-Link problem. If you cannot confirm the pinout, you cannot rule the cable out, and you will waste the rest of the session chasing command syntax that was never the issue.

Serial Settings

Commands Must Be Sent as Hex

Ex-Link codes are raw bytes. Sending them as ASCII characters will not work.

This bears repeating because the codes are usually published as text like 08 22 00 00 00 01 D5, and it is natural to paste that string into a terminal. Doing so transmits twenty text characters. You must switch your tool into HEX send mode so seven actual bytes go out.

Frame Structure

08  22  |  cmd  sub  val1  val2  |  checksum
└──┬──┘    └────────┬────────┘      └───┬──┘
 header          payload             1 byte

Every Ex-Link frame starts with 0x08 0x22, carries four payload bytes, and ends with a checksum.

The Checksum Is a Two's Complement

The last byte is not a simple sum. It is the value that makes the whole frame add up to zero:

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

Verified against published codes:

Three independent codes, three matches. The rule holds.

The power-on code that fails its own checksum

The code circulated everywhere for TV On is:

08 22 00 00 00 02 D6

It does not satisfy the checksum rule.

sum(08 22 00 00 00 02) = 0x2C
(0x100 - 0x2C) & 0xFF  = 0xD4      ← not 0xD6

Since the same rule verifies correctly against the other three codes, one of the two bytes in this frame has been copied wrong somewhere upstream, and everyone has been copying it since. Working backwards, there are two candidates:

We have not been able to verify which is correct against real hardware, so we are not going to state one as fact. If you have a Samsung TV with an Ex-Link port, Samsung's own SamTvControlLite test utility will settle it in about a minute — connect to the Ex-Link jack, send both candidates, and see which one powers the set on.

This is a good illustration of a broader habit worth adopting: when a published control code fails its own protocol's checksum rule, trust the rule, not the table. Command tables get copied between forums for years without anyone recomputing them.

Known-Good Codes

Because you now have the checksum rule, you can validate any other code you find before trusting it — which is more useful than a longer table you cannot check.

Reading the Reply

A successful command returns a short acknowledgement, for example 03 0C F1.

One documented quirk worth knowing: the reply to Power Off is a consistent three-byte code, while the reply to Power On returns long strings of inconsistent data with no identifiable pattern. If you are writing a parser that waits for a fixed-length acknowledgement, power-on will look like a failure even when the TV turns on.

Do not gate your control logic on parsing the power-on reply. Send the command, wait, and confirm the state some other way.

Why Your Ex-Link Command Does Nothing

1. The cable pinout is wrong for your model year. The most likely cause, and the hardest to rule out.

2. You sent the codes as ASCII text. Switch to HEX send mode.

3. Wrong protocol family. A commercial panel needs MDC.

4. The checksum is wrong — including the case where you copied a bad code from a table. Recompute it with the rule above.

5. Deep standby. Same story as every display: if the TV powers down its serial receiver in eco standby, power-on can never work while power-off works fine.

6. The port was disabled by a firmware update. This genuinely happens on consumer sets and there is no fix from your side.

With SoftControl

SoftControl sends Ex-Link frames as raw serial or TCP bytes with hex entry, and its command tester shows both the bytes transmitted and the raw reply — which is what you need to tell a real acknowledgement apart from the ragged power-on response described above.

For commercial panels see the Samsung MDC protocol, and for RS-232 fundamentals see the serial communication guide.