E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old June 25th, 2022   #1
stevec
Junior Member
 
Join Date: Jun 2022
Posts: 2
Default Help understanding an rdm response

Hi, this is my first post here and my apologies for it being so long.
If the formatting of the post is borked I will try and correct it asap.

If it is ok I would appreciate some brief comments about the following rdm transactions.

I am trying to add rdm capability to a handheld dmx tester I make for the guys here in our workshop to use.

It is just a spare time interest for me making these things and I am only a few days into trying to understand the technical side of the rdm protocol.

One problem I have, is a limited variety of responders to test against, and I have managed to brick a dimmer by sending a malformed set command.
I have blanked the UID because it is a commercially sold piece of equipment.


Code:
     0  1  2   3                                    15  16 17 18    20 21    23
    ----------------------------------------------------------------------------
1  |CC 01 24  FF FF FF FF FF FF  7F FE 00 00 00 01  08  01 00 00 00 10 00 01 0C   00 00 00 00 00 00  7F FF FF FF FF FF  0E 09
2  |FE etc. response
3  |CC 01 18  xx xx xx xx xx xx  7F FE 00 00 00 01  09  01 00 00 00 10 00 02 00          03 4B
4  |CC 01 1A  7F FE 00 00 00 01  xx xx xx xx xx xx  09  00 00 00 00 11 00 02 02   00 08  03 57
   |
5  |CC 01 18  xx xx xx xx xx xx  7F FE 00 00 00 01  0A  01 00 00 00 20 00 F0 00          04 4A
6  |CC 01 1A  7F FE 00 00 00 01  xx xx xx xx xx xx  0A  01 00 00 00 21 00 F0 02   00 02  04 51
   |
   |
7  |CC 01 18  xx xx xx xx xx xx  7F FE 00 00 00 01  0B  01 00 00 00 20 00 F0 00          04 4B
8  |CC 01 1A  7F FE 00 00 00 01  xx xx xx xx xx xx  0B  01 01 00 00 21 00 F0 02   00 02  04 53
   |
   |
9  |CC 01 18  xx xx xx xx xx xx  7F FE 00 00 00 01  0C  01 00 00 00 20 00 20 00          03 7C
10 |CC 01 1A  7F FE 00 00 00 01  xx xx xx xx xx xx  0C  00 01 00 00 21 00 50 02   00 65  04 16
   |
11 |CC 01 18  xx xx xx xx xx xx  7F FE 00 00 00 01  0D  01 00 00 00 20 00 20 00          03 7D
12 |CC 01 1A  7F FE 00 00 00 01  xx xx xx xx xx xx  0D  00 00 00 00 21 00 50 02   00 65  04 16
   |
13 |CC 01 18  xx xx xx xx xx xx  7F FE 00 00 00 01  0E  01 00 00 00 20 00 80 00          03 DE
14 |CC 01 1A  7F FE 00 00 00 01  xx xx xx xx xx xx  0E  01 00 00 00 21 00 80 02   00 02  03 E5

I think line 4 response to the mute command shows that I am dealing with a proxied device which I presume is correct because I am communicating via a big name brand rdm enabled radio Tx to the radio Rx enabled responder(dimmer).

I repeat the GET DMX_ADDRESS after a delay between line 5 and line 7.

I don't understand line 10, is the 0x0050 a valid response to the GET QUEUED_MESSAGE request

All I am trying to get in this whole deal is the DMX address which is 0x0065 and for some reason it appears twice.

I feel that the responder is not 100% ok because if I connect to it directly by cable I get the DMX address at the first request but in all the following transactions with the piece of equipment it never changes the transaction number, it stays firmly on 01.

Am I fighting two battles here trying to understand the rdm protocol and dealing with less than optimal responses.

Thanks for any thoughts on this.
stevec is offline   Reply With Quote
Old June 25th, 2022   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 373
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
Old June 26th, 2022   #3
stevec
Junior Member
 
Join Date: Jun 2022
Posts: 2
Talking

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!
stevec is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

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


All times are GMT -6. The time now is 09:31 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2022, vBulletin Solutions, Inc.