Help understanding an rdm response - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · June 25th, 2022

Most of the Wireless RDM systems do act as a Proxy. RDM Responders have to respond within about 2ms, but most wireless systems take longer then that to get the data across the wireless link, so it acts like a proxy, and thus has to ACK_TIMER most (non discovery) requests.

Proxies really complicate RDM controllers. For early RDM development, when you're just getting started, I'd recommend that you work with a direct, hard-wired connection to the responders (no proxies, no splitters, no inline devices). Once you have that working well, then you'll have enough understanding of the protocol to add proxy support.

Proxies aren't the only application for ACK_TIMER, but they are by far the most common; it's unusual to see ACK_TIMER used elsewhere.

For what you're doing, take a look at the "Tools" menu on:
http://rdm.openlighting.org/

Specifically, the "Packet Dissector":
http://rdm.openlighting.org/tools/packet-extractor

This will give you a human readable breakdown of each packet in your hexdump.

What's odd with your hexdump is that the controller does a "Get DMX_START_ADDRESS", but when it subsequently sends the "Get QUEUED_MESSAGE", the response is a "Get Response SUPPORTED_PARAMETERS", and data within that supported parameter list is 0x0065.

There are several problems with that: 0x0065 isn't a valid PID, and most responders will have a MUCH longer list of PIDs.

It appears that something is wrongly responding with a SUPPORTED_PARAMETERS (0x0050) instead of "DMX_START_ADDRESS" (0x00F0)

I'll also note that you shouldn't send "Get DMX_START_ADDRESS" a second time after the first one was ACK_TIMER'd. Instead, you should wait the requested amount of time (200ms in this case), and get the response using an ACK_TIMER. In other words: You should eliminate the request on line #7 of your dump.

Some people think that you can send the same request a second time, and that you'll get the answer immediately this time (without an ACK_TIMER), but this isn't a good idea. This would require proxy to cache the prior response, but the proxy has no way to know how long the cached data is valid for. It risks sending outdated date.

stevec · June 25th, 2022

Many thanks for the reply. I forgot about the open lighting tools although I have been using olad for testing stuff.

rdm is just a mass of information to try and absorb in a reasonable amount of time, but at least now after one week I can work with most of the radio only pieces of equipment that pass through the workshop. I am a subcontractor and usually only called in when there is a problem and I am busy!

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Switch to Linear Mode Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Understanding the timing based on the RDM standard	dannito	RDM Timing Discussion	3	February 18th, 2015 11:05 PM
Enttec RDM USB Pro not decoding get response	dtewksbury	RDM General Implementation Discussion	14	December 17th, 2013 09:00 AM
Uniquely defining the RDM response of devices	Andy Macdonald	RDM General Implementation Discussion	6	February 9th, 2009 02:24 PM

June 25th, 2022	#1
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	Most of the Wireless RDM systems do act as a Proxy. RDM Responders have to respond within about 2ms, but most wireless systems take longer then that to get the data across the wireless link, so it acts like a proxy, and thus has to ACK_TIMER most (non discovery) requests. Proxies really complicate RDM controllers. For early RDM development, when you're just getting started, I'd recommend that you work with a direct, hard-wired connection to the responders (no proxies, no splitters, no inline devices). Once you have that working well, then you'll have enough understanding of the protocol to add proxy support. Proxies aren't the only application for ACK_TIMER, but they are by far the most common; it's unusual to see ACK_TIMER used elsewhere. For what you're doing, take a look at the "Tools" menu on: http://rdm.openlighting.org/ Specifically, the "Packet Dissector": http://rdm.openlighting.org/tools/packet-extractor This will give you a human readable breakdown of each packet in your hexdump. What's odd with your hexdump is that the controller does a "Get DMX_START_ADDRESS", but when it subsequently sends the "Get QUEUED_MESSAGE", the response is a "Get Response SUPPORTED_PARAMETERS", and data within that supported parameter list is 0x0065. There are several problems with that: 0x0065 isn't a valid PID, and most responders will have a MUCH longer list of PIDs. It appears that something is wrongly responding with a SUPPORTED_PARAMETERS (0x0050) instead of "DMX_START_ADDRESS" (0x00F0) I'll also note that you shouldn't send "Get DMX_START_ADDRESS" a second time after the first one was ACK_TIMER'd. Instead, you should wait the requested amount of time (200ms in this case), and get the response using an ACK_TIMER. In other words: You should eliminate the request on line #7 of your dump. Some people think that you can send the same request a second time, and that you'll get the answer immediately this time (without an ACK_TIMER), but this isn't a good idea. This would require proxy to cache the prior response, but the proxy has no way to know how long the cached data is valid for. It risks sending outdated date.

June 25th, 2022	#2
stevec Junior Member Join Date: Jun 2022 Posts: 2	Many thanks for the reply. I forgot about the open lighting tools although I have been using olad for testing stuff. rdm is just a mass of information to try and absorb in a reasonable amount of time, but at least now after one week I can work with most of the radio only pieces of equipment that pass through the workshop. I am a subcontractor and usually only called in when there is a problem and I am busy!