MediaWiki API result

This is the HTML representation of the JSON format. HTML is good for debugging, but is unsuitable for application use.

Specify the format parameter to change the output format. To see the non-HTML representation of the JSON format, set format=json.

See the complete documentation, or the API help for more information.

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Robe_Universal_Interface",
        "continue": "gapcontinue||"
    },
    "query": {
        "pages": {
            "1957": {
                "pageid": 1957,
                "ns": 0,
                "title": "Responder Testing FAQ",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "== General Information ==\n\n==== Is this a E1.20 Compliance Test? ====\n\nNo. 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. \n\n==== How is this related to PLASA and the PLASA Standards Group ? ====\n\nAlthough 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.\n\n== Testing Devices ==\n\n==== Can I run the tests myself? ====\n\nYes. You need one of the [[#Which RDM controllers are supported?| supported controllers]] and a system on which to run [[OLA]].\n\n==== Can I send my equipment somewhere to have it tested? ====\n\nYes. 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.\n\n==== I'll only send RDM responders if you pay a deposit, sign an NDA etc. ====\n\nSorry, this is a best effort volunteer service. We don't have the financial or legal resources to get into this. \n\n==== Can someone work with me to debug my responder? ====\n\nWe'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.\n\n==== Can I pay someone to perform testing for me? ====\n\nNot at the moment. We may provide this service in the future.\n\n== Technical Questions ==\n\n==== I make RDM Controllers and I'd like to have my device supported ====\n\nThe fastest way is to write the code yourself. Failing that, if you provide the hardware we can work on supporting it.\n\n==== Why isn't signal timing checked? ====\n\nSimply 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.\n\n==== Why are the tests so strict? ====\n\nThe 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.\n\nThis 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.  \n\n==== I disagree with the output of a test / I disagree with the interpretation of the standard ====\n\nWhere 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]."
                    }
                ]
            },
            "2181": {
                "pageid": 2181,
                "ns": 0,
                "title": "Responder Testing with the Raspberry Pi",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "[[Image:Raspi_Colour_R.png|right]]\n\nThis tutorial describes how to run the [[RDM_Responder_Testing| RDM Responder Tests]] on the [http://www.raspberrypi.org/ Raspberry Pi]. \n\n== Required Hardware ==\n\nAlong with the hardware in the [[OLA_Raspberry_Pi#Getting_Started | Getting Started]] section, you'll need one of the USB RDM controllers listed on the [[RDM Responder Testing]] page.  It's recommended that you attach the controller through a powered USB hub.\n\n== Installation ==\n\nFollow the method described at the [[OLA_Raspberry_Pi| OLA on  Raspberry Pi]] page. It's recommended that you use the ''Binary Packages Image'', unless you have a good reason for doing otherwise.\n\n== RDM Hardware Setup ==\n\n\nAt this point you can connect your RDM responder to RDM controller and connect the controller to the PI (again using a powered USB hub is strongly recommended). If you're using [[DMXter4 RDM]] or [[MiniDMXter]] you need to put the DMXter into dongle mode before powering on the Pi. From the RDM menu on the DMXter, hold the left and right buttons and then hit the center button. The display should change to \"USB Dongle Mode\".\n\n== Configuration ==\n\nOnce all the steps on the above page have been completed, there is one more step to enable the tests. SSH to the Pi device and run:\n\n<pre>\nsudo dpkg-reconfigure  ola-rdm-tests\n</pre>\n\nWhen prompted if you want to start the RDM Responder tests at boot, select ''Yes''. You should then see:\n\n<pre>\n[ ok ] Starting OLA RDM Test Server: rdm_test_server.py.\n</pre>\n\nand get back to the command prompt.\n\n== Patching a Device ==\n\nYou need to patch your USB RDM controller to a universe. Connect to the OLAD web console at http://192.168.1.200:9090 (replace 192.168.1.200 with the IP Address of your device). Click on 'Add New Universe' and select the device you want to use for RDM testing.\n\nOnce the USB device is patched, you're ready to start running the tests.\n\n== Running the Tests ==\n\nEverything is setup at this stage. You can connect to the RDM Responder Test UI on your device by opening a web browser and typing  http://192.168.1.200:9099 (replace 192.168.1.200 with the IP Address of your device and note the port number change to 9099). The guide to the [[Using_the_RDM_Test_UI | RDM Responder Test UI]] explains how to run the tests. Alternatively you can run the tests from [[Running_the_tests|the command line]]."
                    }
                ]
            }
        }
    }
}