Why is a 0x7E dump not an RDM packet?
Host software talks to the dongle with its own serial framing. E1.20 lives on the DMX512 pair after the widget. Mixing those layers makes a checksum that never matches a lab book.
What is the USB PRO envelope?
Public widget API documents the same six parts: 0x7E, label, length LSB, length MSB, payload, 0xE7. Payload length is 0 to 600. That length is not E1.20 Message Length.
| Offset in wrap | This sample | Role |
|---|---|---|
| 0 | 7e | Widget start delimiter |
| 1 | 0x05 | Label (not RDM Start Code) |
| 2-3 | 0x1a 0x00 | Payload length 26 |
| 4 | cc | Inner PDU starts here in this sample |
| 30 | e7 | Widget end delimiter |
7e 05 1a 00 cc 01 18 09 c8 a0 10 00 00 09 c8 01 00 cd f9 01 01 00 00 00 20 10 00 00 05 30 e7
Why does this decoder refuse to unwrap?
isEnttecWrapped is true when length is at least 2, byte 0 is 0x7E, and the last byte is 0xE7. That test runs before DUB and before 0xCC. Unwrapping in a browser tool would hide a capture mistake.
Wrapped Load Example returns ENTTEC_WRAPPED (kind enttec). Received starts 0x7E and ends 0xE7. Expected bare E1.20 RDM PDU starting at 0xCC, or a DUB response starting with 0xFE/0xAA.
What happens if I checksum across 0x7E to 0xE7?
You sum widget bytes the E1.20 rule never included. This site never computes that total. Bare inner HEX still decodes: ok true, kind rdm.
Is replacing only the first and last byte enough?
If a dump merely starts 0x7E and ends 0xE7, this classifier still reports ENTTEC_WRAPPED (kind enttec). It does not look past the envelope for an inner 0xCC. Strip the wrap in capture software.
How do I get the inner PDU?
Drop 0x7E, label, two length bytes, and trailing 0xE7. Paste the remaining HEX if it starts CC 01 or FE AA. First three RDM bytes are on what CC 01 means. DUB encoding is on how to decode a Discovery Unique Branch dump.
Inner Load Example HEX:
cc 01 18 09 c8 a0 10 00 00 09 c8 01 00 cd f9 01 01 00 00 00 20 10 00 00 05 30
Frequently asked questions
Why is a 0x7E dump not an RDM packet?
0x7E and 0xE7 are USB PRO widget framing. E1.20 PDUs start 0xCC or a DUB 0xFE/0xAA body. The wrap is a host-to-dongle message.
Will this decoder unwrap ENTTEC 0x7E-0xE7?
No. It detects start 0x7E and end 0xE7, reports ENTTEC_WRAPPED, and stops. Checksum is never run on the envelope.
What is inside a USB PRO message?
Start 0x7E, a label byte, length LSB, length MSB, payload, end 0xE7. Label is not an RDM Start Code. Length is payload size, not E1.20 Message Length.
How do I decode the inner RDM?
Strip the five envelope bytes in your capture tool, then paste the inner CC 01 or FE AA PDU. HEX stays in this browser.
Can leftover widget bytes still PASS an RDM checksum?
Not here. Classification runs before checksum. A wrap that starts 0x7E and ends 0xE7 never reaches the 0xCC summer.