E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   Mute Response Question (http://www.rdmprotocol.org/forums/showthread.php?t=30)

sondericker July 19th, 2006 02:44 PM

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?

R_Goddard July 21st, 2006 02:19 PM

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.

sondericker July 21st, 2006 05:44 PM

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

sblair July 23rd, 2006 11:08 PM

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.

sondericker July 24th, 2006 10:35 AM

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.

dfleenor July 28th, 2006 12:42 PM

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?

sblair July 30th, 2006 12:41 PM

Doug,

We don't have a knowledge base here yet, but it is part of the plan for the site here.

endoftheworld September 19th, 2006 11:38 PM

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

porubat September 20th, 2006 08:52 AM

I had the same situation with two or more Devices.

sblair September 20th, 2006 04:58 PM

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.

porubat September 21st, 2006 03:21 AM

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

sondericker September 22nd, 2006 05:11 PM

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. ;)

porubat September 25th, 2006 02:12 AM

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. :)

prwatE120 January 21st, 2007 11:14 AM

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


All times are GMT -6. The time now is 05:43 AM.

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