E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old August 29th, 2013   #1
LarryDew
Junior Member
 
Join Date: Aug 2013
Posts: 4
Default 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?
LarryDew is offline   Reply With Quote
Old August 29th, 2013   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
sblair is offline   Reply With Quote
Old August 30th, 2013   #3
LarryDew
Junior Member
 
Join Date: Aug 2013
Posts: 4
Default

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?
LarryDew is offline   Reply With Quote
Old August 31st, 2013   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
sblair is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

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


All times are GMT -6. The time now is 04:13 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.