|
RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product. |
|
Thread Tools | Search this Thread | Display Modes |
June 25th, 2022 | #1 |
Junior Member
Join Date: Jun 2022
Posts: 2
|
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. |
Bookmarks |
|
|
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 |