|
RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product. |
|
Thread Tools | Search this Thread | Display Modes |
August 29th, 2013 | #1 |
Junior Member
Join Date: Aug 2013
Posts: 4
|
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?
|
August 29th, 2013 | #2 |
Administrator
|
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.
__________________
Scott M. Blair RDM Protocol Forums Admin |
August 30th, 2013 | #3 |
Junior Member
Join Date: Aug 2013
Posts: 4
|
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?
|
August 31st, 2013 | #4 |
Administrator
|
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.
__________________
Scott M. Blair RDM Protocol Forums Admin |
Bookmarks |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
DISC_UNIQUE_BRANCH dest UID (section 7.3) | berntd | RDM Interpretation Questions | 5 | October 15th, 2008 09:06 PM |
Mute Response Question | sondericker | RDM Interpretation Questions | 13 | January 21st, 2007 10:14 AM |
Discovery Response Preamble | prwatE120 | RDM General Implementation Discussion | 0 | January 20th, 2007 12:22 AM |