Personal tools
The Open Lighting Project has moved!

We've launched our new site at This wiki will remain and be updated with more technical information.

RDM Discovery


Revision as of 20:10, 20 October 2011 by Nomis52 (talk | contribs)
Jump to: navigation, search

This documents various scenarios that should be considered when writing software that performs RDM Discovery. Unlike DMX, RDM is bi-directional, which means bad devices can trigger bugs in the controllers causing them to crash or go in to an infinite loop.

This page is not a substitute for the E1.20 standard, which takes precedence over all information presented here. It simply presents situations which designers of controllers should consider when writing their software.

Process Overview

Failure Modes

Responders that reply outside their range

Responders that don't reply to Mute

Some responders may not reply to the MUTE_DEVICE message. This case must be differentiated from the case where the MUTE_DEVICE message is corrupted or lost so the responder never replies. The pseudo-code in the E1.20 standard attempts to mute each device up to 10 times before continuing.

Responders that don't mute

Not to be confused with the scenario above, some responders may acknowledge the mute request but continue to respond to discovery requests. If there is only one responder that behaves this way controllers should be able to succeed,

Responders that 'disappear'

Proxied Devices

The E1.20 states that a proxy shall not provide more than one DISC_UNIQUE_BRANCH response at once. This means that once the proxy has been located and muted, controllers must continue to

Example Implementation

The implementation of the RDM discovery algorithm as used in the Open Lighting Architecture can be seen here