RDM Discovery - Effect of Manufacturer IDs

[zshenker]

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

[ericthegeek]

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.

[dangeross]

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.

[sblair]

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.

[ericthegeek]

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.