FAQ

General Information

Is this a E1.20 Compliance Test?

No. There is no known industry standard compliance tests for E1.20. Developing these sort of tests is expensive and the entertainment lighting industry is reasonably small. These tests check a wide range of behavior, but do not perform extensive testing of the E1.20 timing requirements.

How is this related to PLASA and the PLASA Standards Group ?

Although some of the test developers sit on the PLASA Control Protocols Working Group and/or various Task Groups, this effort is in no way affiliated with PLASA.

Testing Devices

Can I run the tests myself?

Yes. You need one of the supported controllers (see next question) and a system on which to run OLA.

What USB Devices are supported?

• Number 1 Recommended! (includes RDM timing information)
• DMXter4 RDM / MiniDMXter
• Robe Universal Interface (latest firmware required)
• DMX USB Pro (2.4 firmware required)
• UltraDMX RDM Pro (1.3 firmware required. Also set USB Retry Count = 0)
• RDM-TRI

Can I run the tests over ArtNet?

Unfortunately not. RDM over ArtNet suffers from a number of problems, which make it impossible to adequately test RDM responders. Consider one example: ArtNet has no “RDM timeout’ response, so if no response is received by the ArtNet controller, the UDP packet may have been lost or the RDM responder may not have replied.

Can I send my equipment somewhere to have it tested?

Yes. You can send RDM responders to us (there are test developers with suitable equipment located in California, Pennsylvania and London) and we’ll run the tests and send you the output. You’ll either need to organize return postage, or agree to leave the hardware with us. Please provide a way to upgrade the firmware (hardware programmer or the required dongle) so we can test new firmware versions for you.

I’ll only send RDM responders if you pay a deposit, sign an NDA etc.

Sorry, this is a best effort volunteer service. We don’t have the financial or legal resources to get into this.

Can someone work with me to debug my responder?

See the Support page.

I make RDM Controllers and I’d like to have my device supported

The fastest way is to write the code that adds support for your device to OLA. Failing that, if you provide the hardware we can work on supporting it.

Technical Questions

What PIDs are covered?

As of  August 2013 the following PIDs from E1.20 & E1.37-1 aren’t tested:

• STATUS_MESSAGES
• STATUS_ID_DESCRIPTION
• SUB_DEVICE_STATUS_REPORT_THRESHOLD
• RESET_DEVICE

Why isn’t signal timing checked?

Simply because the developers haven’t had time to add this. The amount of information on signal timing is limited by what the RDM controller interfaces provide to the host PC. For now we recommend adding a inline RDM sniffer and using that to check for timing problems.

Why are the tests so strict?

The responder tests set a high bar for correct operation and exercise conditions that should not normally occur. Some manufacturers prefer to have relaxed rules for parsing parameter data. For example say a particular parameter request requires 2 bytes, obviously if 0 or 1 byte is sent the responder must return a NACK_FORMAT_ERROR. However if more than 2 bytes of data is sent, the responder can operate on the first 2 bytes, and ignore the rest of the data.

This type of behavior will cause a failure in the tests however it may be desirable in a production environment. To solve this apparent conflict, some manufacturers have introduced a manufacturer specific PID, STRICT_MODE, that toggles the responder between strict and relaxed command handling.

I disagree with the output of a test / I disagree with the interpretation of the standard

Where the E1.20 standard is ambiguous, the test output reflects the consensus reached by well respected engineers within the industry. If you think one of the test cases is wrong please email the RDM Testing List.