We've launched our new site at www.openlighting.org. This wiki will remain and be updated with more technical information.
Difference between revisions of "Responder Testing FAQ"
From wiki.openlighting.org
| (4 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
==== Is this a E1.20 Compliance Test? ==== | ==== 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 industry is reasonably small. | + | No. There is no known industry standard compliance tests for [[E1.20]]. Developing these sort of tests is expensive and the 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 ? ==== | ==== How is this related to PLASA and the PLASA Standards Group ? ==== | ||
| Line 32: | Line 32: | ||
== Technical Questions == | == Technical Questions == | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==== I make RDM Controllers and I'd like to have my device supported ==== | ==== I make RDM Controllers and I'd like to have my device supported ==== | ||
| Line 46: | Line 40: | ||
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. | 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 ==== | ==== 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 start a discussion on the | + | 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 start a discussion on the [http://www.rdmprotocol.org/ RDM Protocol Forums]. |
Latest revision as of 19:17, 9 November 2012
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 industry is reasonably small. These tests check a wide range of behavior, but do not perform extensive testing of the E1.20 timing requirements.
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 and a system on which to run OLA.
Can I send my equipment somewhere to have it tested?
Yes. You can send RDM responders to us (located in California) 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. If you provide us with a way to upgrade firmware on your devices we'll 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?
We'll do the best we can to explain the expected behavior and why tests fail. We don't provide consulting services but can recommend freelance RDM developers.
Can I pay someone to perform testing for me?
Not at the moment. We may provide this service in the future.
Technical Questions
I make RDM Controllers and I'd like to have my device supported
The fastest way is to write the code yourself. Failing that, if you provide the hardware we can work on supporting it.
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 start a discussion on the RDM Protocol Forums.
