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 March 25th, 2009   #1
zshenker
Junior Member
 
Join Date: Feb 2008
Posts: 3
Default RDM Discovery - Effect of Manufacturer IDs

Hi,

I have been considering the Binary Search process that is used in RDM discovery and have some concern as to the additional overhead that could occur as a result of Manufacturer IDs being close to each other.

Based on my calculations if there were two manufacturers with IDs one higher than the other(i.e. 0x3805, 0x3806) just to get to the manufacturer we would explore 15 branches of the binary tree. If there are multiple fixtures from the manufacturer we would need to explore even further down the tree.

If some measure was taken to ensure Manufacturer IDs where assigned in a more evenly distributed manner it appears that this would significantly reduce the number of branches of the binary tree that need to be explored.

I would be interested in hearing others views on this issue and ways of improving the discovery process in general.

Regards,
Zac Shenker
zshenker is offline   Reply With Quote
Old March 25th, 2009   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

If you're doing an exhaustive discovery (full binary search with no shortcuts), there are some data dependencies. Depending on which leaf nodes of the tree are populated, discovery can require different numbers of packets. For example, finding six sequential UIDs will be faster than finding six UIDs with different Vendor IDs.

Finding two devices where the *high* bit of the UID is different would take longer because you have to descend one branch all the way to the bottom, then work your way all the way back up to the top of the tree and decent the other branch all the way to the bottom.

Realistically though, all of this is academic. There are numerous shortcuts you can take to speed up discovery so you don't have to fully walk every populated branch of the tree. One such shortcut is to try and decode responses you get even when you're not at the bottom of tree. If the responders statistically vary their timing, it's possible to get 2, three or more fully formed responses in a single discovery reply period.
ericthegeek is offline   Reply With Quote
Old April 9th, 2009   #3
dangeross
Junior Member
 
Join Date: Feb 2009
Posts: 13
Default Multiple Discovery Responses

If the first responder can start its response right at the 176uS Min time from Table 3-4 and transmit the response with a 0S inter-slot time this will take 1.1mS. If the second responder can start its response immediately after the first response and transmit with no inter-slot delay the second response will end 2.376mS after the controllers EOP. A third responder can not respond because it would have to start its response after the 2mS Max time. I don't know if there are any controllers that could handle 2 discovery responses returned to one discovery request.
dangeross is offline   Reply With Quote
Old April 10th, 2009   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

dangeross,

This is why in the Discovery flowcharts and pseudocode we include the step of retesting the same branch after muting a device to ensure that there are no other devices that are lurking in the same branch.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old April 10th, 2009   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Table 3-2 Note 3 includes up to 700uS of system delay, so even if the responder starts sending within the 2.0mS allowed by Table 3-4, it may not reach the controller until 2.7mS, which allows for a 3rd response.

In addition, inline devices can drop up to 7 bytes from the discovery response, so the minimum Discovery Response length at the controller is (17*44uS)=748uS. This allows a 4th response. It's VERY unlikely to happen, but possible.
ericthegeek 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


All times are GMT -6. The time now is 01:48 PM.


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