Disc_Unique_Branch response
 

Is the response packet for a Discovery a message unto itself or is it the Packet Data of a normal response except for no "break" preamble?

Larry,

Welcome to the forums! The response packet to the DISCOVERY_UNIQUE_BRANCH message is always just a packet data encoded as specified with no BREAK.

To anything else on the wire, it just looks like a single DMX packet with a very long delay in the middle of it.

It may all seem a bit convoluted, but this was done to maintain compatibility with legacy DMX devices that have older UARTs in them that would see the BREAK and then misinterpret the collisions on the wire as a null START code and then interpret following data as DMX data for the fixtures and cause glitching.

Removing the break and then doing the 0xAA, 0x55 encoding causes the enough transitions on the line, even with collisions, that the Discovery collisions of everyone responding back can not be mistaken for a BREAK and null START Code...

Hope that helps explain it.

Just for clairity, let me restate my question. The documentation indicates that the "response type" should be set to ACK but the data diagram for the response on page 33 does not look like any other response diagram. Does the response contain the leading 24 bytes of an RDM Message Packet followed by the 24 bytes of encoded data and a normal checksum or just the encoded data as defined on page 33? What do you mean a long delay in the middle?

There are 3 Discovery related messages: UNIQUE_BRANCH, MUTE, and UNMUTE.

The MUTE and UNMUTE messages are like normal PID's and have an ACK Response Type along with the normal header and message structure of any other message.

UNIQUE_BRANCH is a special beast as it is the only message can result in expected collisions on the line that could cause issues for some legacy devices. Therefore it's response is different from any other message and it ONLY responds with the encoded data as detailed in Table 7-1. There is no BREAK and no other packet header sent other than the data indicated in that table.

For any other device sitting in the middle of the wire the UNIQUE_BRANCH message will just have the appearance of a single packet rather than a normal request/response transaction of 2 packets as it would be for the other PIDs.