E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old July 19th, 2006   #1
sondericker
Banned
 
Join Date: Jun 2006
Posts: 11
Exclamation Mute Response Question

I'm not sure, but I think I have found something that needs to be brought up.

(I know this sounds like a Zen koan)
Should an already muted responder respond to a mute command?

I believe the answer is a resounding no. Here is why:

Lets say that responders a, b and c are on a universe and are being discovered. If the wire-or of the discover next responses of a&b make a valid message which looks like the response of c the system will believe it found c and then mute it. That is fine, but if a muted c responds again to a mute it will block a&b from ever being discovered. You end up in a loop and it looks like c is un-muting itself constantly. You'll think you're just discovering c over and over again.

I believe a solution is for an already muted device to not respond to a mute command, and therefore it would signal that what looked like a valid discover next response is really a collision.

Is this really an issue or am I missing something?
sondericker is offline   Reply With Quote
Old July 21st, 2006   #2
R_Goddard
Task Group Member
 
Join Date: Jul 2006
Posts: 10
Default You would respond

OK,
I am not Scott, and can’t quote RDM off the top my head. However, I think this question has gotten several different messages confused. Or I don’t understand the question . . .

The ONLY command sent with a broadcast address that is EVER responded to is ‘Discovery Unique Branch’(7.5) A responder only responds if:
a) The responder is un-muted
b) The responder’s UID is within the address range asked for in the ‘Dis Unique Branch Message’. It responds only with the special message of TABLE 7-1.

The Discovery Mute Message (7.6) only responds to a non broadcast message sent to its UID, if asked it should respond. If it responds due to an apparently valid but in fact corrupt mute message, this fact will be apparent to the controller because the response contains a source UID. The controller should always check to see that any response comes from the expected place. (NOTE it may ACT, IE mute in response to a broadcast message.)

A response to a mute message says nothing about the presence of other devices in an address range. It simply confirms that a particular device is at a specific UID and has muted.

‘Discovery Unique Branch’ must continue to probe an address range until there are no ‘Discovery Unique Branch Response’ messages, the format of which is laid out in table 7-1. It should be expected that you sometimes mute a real device but not the one you expected.

I hope this helps.
__________________
***************************************
Bob Goddard
Goddard Design Co.
www.goddarddesign.com
sales@goddarddesign.com
***************************************
R_Goddard is offline   Reply With Quote
Old July 21st, 2006   #3
sondericker
Banned
 
Join Date: Jun 2006
Posts: 11
Default

Bob,

I don't think I explained my point well enough. My question to do with a problem caused by collisions from discovery branch commands forming valid packets. Let me elaborate:

In the situation described the responders A & B respond to a discovery branch message and collide. The collision causes that response to appear to be a valid response from responder C. The controller then sends a discover mute to responder C thinking it got a valid response from C. The controller then continues the discovery process, gets another collision between A & B which erroneously appears to be a valid response from responder C and the whole cycle repeats forever.

Short of the controller knowing that this can happen and ignoring responses from responders that should have already been been muted the system will be in a loop with no way out. It will appear as if responder C is continually un-muting itself. I believe a better way to solve this problem would be if a muted device does not respond to a discovery mute command as there are valid ways for a device to become unmuted during the discovery process.

John Sondericker
sondericker is offline   Reply With Quote
Old July 23rd, 2006   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 438
Send a message via AIM to sblair Send a message via MSN to sblair
Default

John,

Have you actually seen this occur? It's not a scenario that has ever been witnessed to my knowledge yet. I have a really hard time believing it can occur given that not only does the Encoding have to match but also there is a Checksum involved. So it would align just right that when decoded not only the UID comes out as a valid UID, but it would have to match the Checksum for the packet as well! I think I have better odds at winning the lottery than getting that situation to occur if I wanted to.

You can't expect Muted devices to ignore responding to the Mute command. For one, the standard isn't written that way. Second, the expectation throughout the standard is that whenever you are communicating with a device directly is that you get some type of a response back. It is possible that some controllers may even use the Mute command as a simple heartbeat to make sure the device is still on the network. (This isn't encouraged, but it is something that people have talked about in the past).

The scenario that you discuss can be handled if you see it as a real issue. After making X number of attempts at muting the device and it continues to respond to UNIQ_BRANCH messages, then keep Branching further. At some point you'd get to the bottom of the tree and be able to individually mute the devices.

Again, I don't see it as a real issue as long as you are verifying the checksums though to know when to discard bad packets.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old July 24th, 2006   #5
sondericker
Banned
 
Join Date: Jun 2006
Posts: 11
Wink

Hi Scott,

Yes, I believe I have seen this occur. It stumped us for a few days in fact. It happens if you have just the right 3 UID's that are numerically close to one another. The "wire-or" that makes A&B look like C changes the checksum perfectly, as it is only one bit that changes in the message and one bit that changes in the checksum. A's UID is one bit off of that of C and B's UID is also one bit off of C. We're using a very high speed processor with interrupt driven serial algorithms so the response synchronization across multiple responders is very tight.

We'll deal with it by having the controller notice when its happening and continue to branch. I hope -- unless I'm totally mistaken somehow -- that this thread will some day save someone some frustration.

-John Sondericker
Wybron, inc.
sondericker is offline   Reply With Quote
Old July 28th, 2006   #6
dfleenor
Task Group Member
 
Join Date: Jun 2006
Posts: 8
Default

The only controller I've written is the RAD which always goes to the bottom of the tree. If this problem occurs on fast-discovery we should probably write up a description and add it to our knowledge base along with the solution (if a device appears to respond to a discovery message after being muted, branch further down the tree). Do we have a knowledge base as part of this forum?
dfleenor is offline   Reply With Quote
Old July 30th, 2006   #7
sblair
Administrator
 
Join Date: Feb 2006
Posts: 438
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Doug,

We don't have a knowledge base here yet, but it is part of the plan for the site here.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old September 19th, 2006   #8
endoftheworld
Junior Member
 
Join Date: Jul 2006
Posts: 6
Default discovery collisions making sense

Since the past month or so, this has been bugging us while trying to implement a RDM library. Initially we thought it was a bug in the code, but to my surprise, having dug up this thread .... coinicidences aren't that rare.

We have ended up with exactly similar situation(s), where collisions from Device A and B (having pretty close Device ID's) turn up as having good checksum !!

In our case in fact, the "collision packet" that does have a good checksum, decodes to a device id that doesn't even exist (but is close to the existing ones) ... thereby implying that somehow ... response packets from A and B come in at exactly the same timeframe on top of one another, forming this collison packet .

It'll be interseting to know if anybody else has replicated this scenario ?
It might turn out to be a shortcoming of the entire discovery process.

Cheers

www.enttec.com
endoftheworld is offline   Reply With Quote
Old September 20th, 2006   #9
porubat
Junior Member
 
Join Date: Sep 2006
Posts: 9
Send a message via ICQ to porubat Send a message via Skype™ to porubat
Default

I had the same situation with two or more Devices.
porubat is offline   Reply With Quote
Old September 20th, 2006   #10
sblair
Administrator
 
Join Date: Feb 2006
Posts: 438
Send a message via AIM to sblair Send a message via MSN to sblair
Default

I would be curious if you could provide the actual UID's of the device and the bogus UID that is being detected. It would be easier to then reconstruct to see how it is happening.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old September 21st, 2006   #11
porubat
Junior Member
 
Join Date: Sep 2006
Posts: 9
Send a message via ICQ to porubat Send a message via Skype™ to porubat
Default

when I have begun whit RDM implementation i used a simple converter with an PIC processor, but the conversion from fixtrure to the commputer was slow. Then i used little bit upgraded OPEN DMX USB. When I implemented the discovery methods, sometimes I had the situations that the collision packet had good checksum, but I catched collisions to. Finaly I have implemented the discovery in this way: I'm searching throught the tree in the active branches (multiple response or discovery respons in the branch). As lately as at the top of the tree I store the UID and mute the device
.
Tomas
porubat is offline   Reply With Quote
Old September 22nd, 2006   #12
sondericker
Banned
 
Join Date: Jun 2006
Posts: 11
Default

Try this:

Pick a UID that has its last 2 bits as zero's and will create a discovery response that has its checksum containing its last 2 bits zeros.

lets say 0xaabbccddeef0 does that. (I don't have the time to find a real one, you might have to jimmy some other bits to get the checksum to end in two zero bits but no problem right?)

Now lets say the system has the following devices attached:

0xaabbccddeef1
0xaabbccddeef2

A perfectly aligned discover next response will appear to have not been a collision but instead it will look like a response from 0xaabbccddeef3.

(this assumes that the line forms a positive or, it might actually work in the reverse, where 0's dominate)

In any case, trying to mute a device that isn't actually on the link is frustrating to say the least.
sondericker is offline   Reply With Quote
Old September 25th, 2006   #13
porubat
Junior Member
 
Join Date: Sep 2006
Posts: 9
Send a message via ICQ to porubat Send a message via Skype™ to porubat
Default

I think the first thing is to get some right UID and the second is to try to mute the device and get right response from it.
porubat is offline   Reply With Quote
Old January 21st, 2007   #14
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

Although might be frustrating, does it not give you a clear indication of failure, since there will be NO response and you experience a timeout?

Quote:
In any case, trying to mute a device that isn't actually on the link is frustrating to say the least
I accept you have a more interesting time when, in scanning for a-b, c (which does exists) appears to reply due to collissions between a-b

Peter
prwatE120 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
broadcast Disvovery Mute/Unute berntd RDM Interpretation Questions 2 April 8th, 2008 11:07 PM
Discovery Response Preamble prwatE120 RDM General Implementation Discussion 0 January 20th, 2007 01:22 AM
Sub-device response to SET/GET DMX512 start address p_richart RDM Interpretation Questions 2 September 29th, 2006 10:27 AM
Discovery Mute/Un mute nic123 RDM Interpretation Questions 1 June 14th, 2006 11:28 AM


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


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