E1.20 RDM (Remote Device Management) Protocol Forums

-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   Maximum number of Sub-Divices? (http://www.rdmprotocol.org/forums/showthread.php?t=1099)

Martin.nielsen July 1st, 2011 03:15 AM

Maximum number of Sub-Devices?
From E1-20-2010 I find the following:

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?


Best regards

ericthegeek July 1st, 2011 09:02 AM


Originally Posted by Martin.nielsen (Post 2190)

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.


Originally Posted by Martin.nielsen (Post 2190)
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).

sblair July 1st, 2011 01:19 PM


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.

Martin.nielsen July 4th, 2011 12:22 AM

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

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?


ericthegeek July 4th, 2011 09:43 AM

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.

Martin.nielsen July 4th, 2011 11:45 PM

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


mike_k September 1st, 2011 11:51 PM


Originally Posted by ericthegeek (Post 2194)

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.

dangeross September 2nd, 2011 07:07 AM

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

sblair September 2nd, 2011 01:53 PM


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.


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