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 1st, 2011   #1
Martin.nielsen
Junior Member
 
Join Date: Oct 2008
Location: Denmark
Posts: 5
Send a message via Skype™ to Martin.nielsen
Default Maximum number of Sub-Devices?

From E1-20-2010 I find the following:
Quote:
The 16-bit sub-device field provides a range of 512 valid sub-devices, addressed from 1 - 512. The value of 0xFFFF is reserved as a SUB_DEVICE_ALL_CALL. A value of 0x0000 shall be used to address the root or base properties of the device that do not belong to any sub-device module.
What about values from 513-0xFFFE?
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 07:03 AM.
Martin.nielsen is offline   Reply With Quote
Old July 1st, 2011   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 379
Default

Quote:
Originally Posted by Martin.nielsen View Post
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?
Sub-devices were primarily intended for dimmer racks, strip lights, and other devices that have a number of repeating units that need to be configured individually (different Personality, DMX addresses, etc.). If each sub-device takes one DMX slot, 512 is the maximum number that can fit on a universe (since DMX has 512 slots in a Null Start Code packet).

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.

Quote:
Originally Posted by Martin.nielsen View Post
Are there any plans to change this?
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).
ericthegeek is offline   Reply With Quote
Old July 1st, 2011   #3
sblair
Administrator
 
Join Date: Feb 2006
Posts: 438
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
sblair is offline   Reply With Quote
Old July 4th, 2011   #4
Martin.nielsen
Junior Member
 
Join Date: Oct 2008
Location: Denmark
Posts: 5
Send a message via Skype™ to Martin.nielsen
Default

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 01:42 AM.
Martin.nielsen is offline   Reply With Quote
Old July 4th, 2011   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 379
Default

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 10:23 AM.
ericthegeek is offline   Reply With Quote
Old July 5th, 2011   #6
Martin.nielsen
Junior Member
 
Join Date: Oct 2008
Location: Denmark
Posts: 5
Send a message via Skype™ to Martin.nielsen
Default

Thanks Eric!
I believe this will work!
I will get back if I run into problems implementing the proxy

/Martin
Martin.nielsen is offline   Reply With Quote
Old September 2nd, 2011   #7
mike_k
Task Group Member
 
Join Date: May 2009
Location: Gothenburg
Posts: 40
Default

Quote:
Originally Posted by ericthegeek View Post
If you don't have any electronically readable ID in the devices, then the proxy can just make up UIDs for them.
Just have in mind that the UID shall be unique. So that if you have two of your root devices in the same system, they may not expose one each of your devices as the same UID.
Might sound obvious, but worth pointing out.
__________________
Michael Karlsson
LumenRadio AB
mike_k is offline   Reply With Quote
Old September 2nd, 2011   #8
dangeross
Junior Member
 
Join Date: Feb 2009
Posts: 13
Default

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
dangeross is offline   Reply With Quote
Old September 2nd, 2011   #9
sblair
Administrator
 
Join Date: Feb 2006
Posts: 438
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
sblair 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 07:43 AM.


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