RDM Packet Decoder Online

What is an RDM packet decoder?

An RDM packet decoder turns pasted ANSI E1.20 HEX into named fields. It does not capture a live universe.

How do I decode RDM packets online?

Paste HEX, click Decode, read the field table. Parsing runs in this browser. There is no upload.

1. Paste the HEX dump. Spaces, 0x prefixes, commas, and newlines are stripped locally.
2. Click Decode. Parsing runs in this browser only.
3. Read the field table, checksum PASS/FAIL, and click bytes in the dump to see offsets.
4. Copy HEX or JSON if you need a local record. Download uses a browser Blob, not a server.

Load Example builds a GET IDENTIFY_DEVICE frame with the same encoder the tests use. For dump dialects see the hex dump guide.

What is the 0xCC field order?

Start Code 0xCC, Sub-Start 0x01, then Message Length, two 6-byte UIDs, TN, Port ID or Response Type, message count, sub-device, command class, PID, PDL, parameter data, two checksum bytes.

Message Length counts from Start Code through parameter data and excludes checksum. Parameter data is exactly PDL bytes. Checksum is unsigned 16-bit additive, big-endian.

The shortest valid 0xCC frame is 26 bytes: Message Length 24 and PDL 0. If Message Length does not equal the captured size minus two, this parser fails on length. If PDL does not equal Message Length minus 24, it fails on PDL.

How does Discovery Unique Branch differ from 0xCC?

DUB responses are not 0xCC frames. Checksum is the additive sum of twelve EUID bytes only, not the whole capture including 0xFE preambles.

They use 0xFE preamble bytes, a 0xAA separator, a 12-byte encoded UID, and a 4-byte encoded checksum. Each UID byte is a pair: value OR 0xAA and value OR 0x55. Decode AND-merges the pair.

What is an RDM UID?

A UID is six bytes: 16-bit manufacturer ID plus 32-bit device ID, shown as mmmm:dddddddd. This page splits those bytes. It does not look up vendor names.

Which command classes does this parser name?

DISCOVERY 0x10 / 0x11, GET 0x20 / 0x21, SET 0x30 / 0x31. Unknown command class bytes stay as the original byte.

Which PIDs does this table name?

20 E1.20-2010 standard PIDs from a hand-maintained JSON table. Manufacturer PIDs (0x8000-0xFFDF) and unknown values stay raw hex. A 2025-only PID shows as a number, not a guessed name.

How is the E1.20 checksum calculated?

Unsigned 16-bit additive sum of Start Code through Parameter Data, modulo 0x10000, excluding checksum slots. A miss prints expected versus received and stays FAIL.

Worked GET IDENTIFY and DUB 12-EUID windows are on how to calculate an E1.20 checksum.

What errors does this parser report?

Each item below is a code this parser actually emits. It is not a generic RDM FAQ copied from a forum.

• Truncated dumps shorter than 26 bytes for a 0xCC frame.
• Message Length that does not equal the frame size minus two checksum bytes.
• PDL that does not match Message Length minus 24.
• Checksum mismatch with expected versus received values printed.
• Discovery encoding missing 0xAA or using a broken EUID pair.
• DUB checksum that does not match the twelve encoded UID bytes.
• ENTTEC USB PRO wrappers that start 0x7E and end 0xE7. This tool will not unwrap them.
• Extra leftover bytes after a complete frame. Not silently parsed as the first 26 bytes.
• Start byte that is neither 0xCC nor a DUB 0xFE/0xAA pattern.

Frequently asked questions

See Privacy for cookies and advertising disclosure.

Privacy

HEX input, decode results, copied JSON, and downloaded JSON are processed only in this browser. There is no decode API, no account, no file upload, and no analytics or logging of your dump. The full policy is on the Privacy page.