![]() |
|
RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard. |
![]() |
|
Thread Tools | Search this Thread | Display Modes |
![]() |
#1 | |
Junior Member
|
![]()
From E1-20-2010 I find the following:
Quote:
Why is the number of sub-devices limited to 512 when there is room for 65534? Is it perhaps to limit the time it takes finding the sub-devices? Are there any plans to change this? thanks Best regards Martin Last edited by Martin.nielsen; July 25th, 2011 at 06:03 AM. |
|
![]() |
![]() |
![]() |
#2 | |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
![]() Quote:
There are hypothetical cases where you might want more than 512, such as a sensor only sub-device. That kind of application is rare, and setting a reasonable upper bound on the number of sub-devices seemed like a reasonable tradeof to account for controllers with limited memory. Unlikely. Changing this would have significant compatibility implications. What is your application? There may be another way to solve the problem. If you need to represent more than 512 sub-devices, your responder could represent itself as a managed proxy that is proxying for an arbitrary number of devices. Or you could make it a multi-port responder. This also has the advantage that it doubles the available bandwidth (which can be important if you need to monitor a large number of sensors with a reasonable update rate). |
|
![]() |
![]() |
![]() |
#3 |
Administrator
|
![]()
Martin,
Eric is correct. There were a lot of concerns about sub-devices becoming unmanageable from a controller if it was left unbounded. The logic of limiting to 512 sub-devices was that of being 1 channel per sub-device for dimmers or LED's being the minimum. At that point you would have consumed the entire universe of data. What kind of issue are you dealing with? As Eric said there are a number of ways it can probably be solved easily.
__________________
Scott M. Blair ![]() RDM Protocol Forums Admin |
![]() |
![]() |
![]() |
#4 |
Junior Member
|
![]()
Thanks for the responses guys
![]() My setup is the following: A root device with a single DMX/RDM responder port. This port is of course to communicate with the RDM controller. The root device could potentially be having several (more than 512) subdevices attached to it using a propriatary protocol on its command port. The subdevices havent got UIDs. (This could perhaps be implemented though - but only if this is the only way to make it work) ![]() I guess for the proxy approach to work my subdevices should all be having UIDs so that the root device can present them to the RDM controller - correct? /Martin Last edited by Martin.nielsen; July 4th, 2011 at 12:42 AM. |
![]() |
![]() |
![]() |
#5 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
![]()
This is a perfect application for a proxy. You can use any proprietary protocol you want for your devices, the proxy then does whatever it needs to so it can represent those devices as an RDM device.
A proxy seems complicated at first, but it's not really that complex. The proxy just looks for multiple UIDs and responds for the devices it is proxying. You have to make a few tweaks to your discovery routines (make sure the mute response flags are correct), but they are minor. Edit: You don't need to have a UID for each proxied device. If your devices have a serial number in EEPROM, the proxy can use that to assign a UID to that device at runtime. If you don't have any electronically readable ID in the devices, then the proxy can just make up UIDs for them. Ideally, the same device would be assigned the same UID all of the time, but what you do on the proprietary side of the proxy is up to you. Last edited by ericthegeek; July 6th, 2011 at 09:23 AM. |
![]() |
![]() |
![]() |
#6 |
Junior Member
|
![]()
Thanks Eric!
I believe this will work! I will get back if I run into problems implementing the proxy ![]() /Martin |
![]() |
![]() |
![]() |
#7 | |
Task Group Member
Join Date: May 2009
Location: Gothenburg
Posts: 40
|
![]() Quote:
Might sound obvious, but worth pointing out.
__________________
Michael Karlsson LumenRadio AB |
|
![]() |
![]() |
![]() |
#8 |
Junior Member
Join Date: Feb 2009
Posts: 13
|
![]()
Just my two cents worth but I do a lot of work with fountains and a lot of it is bit addressed devices. So I propose considering push the sub device limit out to 4096 in the next revision. I feel this is a practical limit since 512 bytes time 8 bits equals 4096 possible units single bit width of information transmitted in a DMX packet
|
![]() |
![]() |
![]() |
#9 |
Administrator
|
![]()
Dangeross,
We capped it at 512 because that assumes each sub-device uses a single DMX channel. Each universe of DMX512/RDM can handle a maximum of 512 slots of data. It is common that each slot is used to manipulate a single property, whether that is a dimmer, color scroll, or moving light parameter. The implementation you're suggesting requires a controller that deals with programming properties as bit addressed fields, which outside of proprietary systems, just doesn't exist in the wider market. For highly proprietary systems there are many ways of solving this such as just adding multiple root devices. The intent of RDM, and even that of DMX, is not to address every possible system that could be conceived, but to address the needs for the 95% of the market. There are going to be unique custom systems that do fall into that other 5%, but there generally is enough flexibility in the protocol that there are still ways to make the unique custom systems work too.
__________________
Scott M. Blair ![]() RDM Protocol Forums Admin |
![]() |
![]() |
![]() |
Bookmarks |
Thread Tools | Search this Thread |
Display Modes | |
|
|