View Single Post
Old June 25th, 2022   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote