Samsung MDC Protocol: Packet Structure, Checksum and RS232 Commands

MDC Is Binary, Not Text

MDC (Multiple Display Control) is Samsung's protocol for commercial signage displays, and unlike most projector protocols it is binary. There are no ASCII words to type. Every message is a short sequence of raw bytes ending in a checksum you have to compute.

That sounds harder than it is. The packet is five fields, the checksum is a sum, and once you understand the structure you can build any command yourself rather than hunting for it in a table.

Important: MDC is for Samsung's commercial displays (the QM, QB, UD, ME series and similar). Consumer Samsung TVs use a completely different protocol called Ex-Link over a 3.5 mm jack — see Samsung Ex-Link commands if that is what you have.

Packet Structure

┌──────┬─────────┬──────┬─────────────┬──────────┬──────────┐
│Header│ Command │  ID  │ Data Length │  Data…   │ Checksum │
│ 0xAA │  1 byte │1 byte│   1 byte    │ N bytes  │  1 byte  │
└──────┴─────────┴──────┴─────────────┴──────────┴──────────┘

The Checksum Rule

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

Worked example, power on to broadcast:

Command      0x11
ID           0xFE
Data Length  0x01
Data         0x01
             ─────
Sum        = 0x111
& 0xFF     = 0x11    ← checksum

Full packet: AA 11 FE 01 01 11

Samsung's own documentation phrases the rule as "if it exceeds two digits, the number in the first digit is discarded" — which is the same thing as taking the low byte. 0x111 becomes 0x11.

Here is the whole protocol as six lines of code:

def mdc_packet(cmd, dev_id, data=b''):
    body = bytes([cmd, dev_id, len(data)]) + data
    return b'\xAA' + body + bytes([sum(body) & 0xFF])

mdc_packet(0x11, 0xFE, b'\x01')   # AA 11 FE 01 01 11  power on
mdc_packet(0x11, 0xFE, b'\x00')   # AA 11 FE 01 00 10  power off

Ready-Made Packets

All of these were computed with the rule above — verify any of them by hand if you like:

Note the last one: a query carries no data bytes, so Data Length is 0x00 and the checksum is 0x00 + 0xFE + 0x00 = 0xFE.

Send raw bytes. A frequent mistake is sending the ASCII string "AA11FE010111" — that transmits twelve text characters, not six bytes. In a debugging tool, switch the send mode to HEX. And do not append a carriage return: MDC frames are length-delimited, and a trailing 0x0D corrupts the next packet.

Wiring and Serial Settings

Only three signals are used:

Samsung specifies a maximum cable length of 4 metres. This is far shorter than the 15 m people assume for RS-232, and it is a real constraint in a signage wall where the control PC is in a rack across the room. If you need distance, use an RS-232-to-IP gateway rather than a long serial run — a marginal cable produces intermittent failures that look like firmware bugs.

Broadcast ID 0xFE: The Debugging Trap

Setting the ID byte to 0xFE addresses every display on the chain regardless of its configured ID. That is genuinely useful for "all screens off at closing time".

But broadcast packets get no acknowledgement. Every display executes the command and none of them reply.

This creates a nasty debugging experience: you send AA 11 FE 01 01 11, see no response, and conclude the link is dead — while all four displays quietly turn on behind you.

When commissioning, address a single display by its real ID so you get an ACK back. Switch to broadcast only once you have confirmed the link works. Getting this backwards costs an hour of chasing a cable that was fine.

The Menu Setting That Blocks Everything

This is the number one cause of "MDC does not work at all" and it has nothing to do with your code.

On the display: Home → ID Settings → PC Connection Cable → select "RS232C cable".

Until you do this, the display ignores the serial port entirely. Many Samsung commercial panels default to expecting control over a different path, and the RS-232 port sits there electrically live but logically disconnected. No amount of correct packets will produce a response.

If a Samsung display is not responding and your checksum is right, go check this setting before anything else.

Why Power Off Works but Power On Doesn't

This is the classic Samsung symptom and it is worth stating plainly: power off is easy, power on is the hard one.

The reason is the same across all display brands — in deep standby the panel powers down its control receiver, so there is nothing listening to hear the wake command. The display must be configured to keep the RS-232/network receiver alive while in standby.

Look for a standby or power-mode setting on the display and set it away from the deepest eco option. The symptom is unmistakable: AA 11 FE 01 00 10 turns the screen off perfectly, and AA 11 FE 01 01 11 does nothing afterwards.

Why Your MDC Command Gets No Response

1. PC Connection Cable is not set to RS232C. See above.

2. You used broadcast ID 0xFE and expected an ACK. Broadcast never replies.

3. You sent ASCII text instead of raw bytes. "AA11..." is twelve characters.

4. Checksum is wrong. Recompute — remember the header is excluded.

5. You appended a carriage return. MDC frames have no terminator.

6. Cable longer than 4 m, or a straight-through cable where a crossover is needed.

7. The display is in deep standby. Power-on will never work until the standby mode is changed.

8. Wrong protocol family entirely. If it is a consumer TV, you need Ex-Link, not MDC.

With SoftControl

MDC's checksum is exactly the kind of thing that is tedious by hand and trivial for software. SoftControl sends raw TCP, UDP or serial bytes with hex entry, so you paste the packet and it goes out as bytes — and the command tester shows both the hex sent and the raw reply, which is how you tell "no ACK because broadcast" apart from "no ACK because nothing is listening".

For the wider display and projector picture see the projector control guide, and for RS-232 fundamentals see the serial communication guide.