E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old September 23rd, 2014   #1
tharron
Junior Member
 
Join Date: Sep 2014
Posts: 10
Default EUID Decode Errors

Hi folks,

I'm working on implementing an RDM client and have gotten most of the way where I need to be. My client responds to the Un-Mute and Discovery packets just fine, but although the DUB response looks fine via packet sniffer (I'm using a DMXter4RDM) I can't get any controllers to accept it. The controller continues all the way down the binary search tree and I keep telling it I'm here, but it never sees a valid packet.

Does anyone have any ideas of where I can look? I'm hard-coding my UID to the same value as a known-good device (HE Labpack). The pre-amble bytes, the encoded UID bytes and checksum bytes all match what is sent by the HE device according to the sniffer, but the controller still rejects it anyway.

Best I can tell my timing is fixed, although I admit I had some issues before that appear to be solved. I'm just not sure where to look next.
tharron is offline   Reply With Quote
Old September 23rd, 2014   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Welcome to the RDM forums. Eric is the resident expert on the DMXter4RDM and will probably respond soon as well.

If all the bytes match then it sounds like it is a timing issue. My first guess would be that you aren't responding back quick enough.

Also, when you respond to the DUB you aren't sending a BREAK first are you? DUB responses are always Break-less. Have you had any luck getting the DMXter to discover you at all?
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old September 23rd, 2014   #3
tharron
Junior Member
 
Join Date: Sep 2014
Posts: 10
Default

Thanks sblair,

I made certain to leave the Break and MAB out of my DUB response.

My original timing issue was due to how the original code responds to regular DMX packets. I wouldn't respond for something like 6ms, but I updated the routine to respond more promptly. I don't have scope shots handy, but the UART started sending out data something like ~200uS after the controller finished.

I have had zero success in it discovering me, but it does follow the tree all the way down to my UID before finally giving up. I think I'm sending it something like two dozen "I'm here!" responses, and according to the sniffer every single one has a decode error on the EUID. That's not surprising as it should be the exact same packet each time.

I don't know if it will help, but here are the raw contents of a response packet from the sniffer:

FEh FEh FEh FEh FEh FEh FEh AAh EAh 5Dh EFh 55h AAh 55h AAh 55h AAh 57h EEh 75h AEh 57h EFh FDh

My UID is currently hard-coded as 0x48 0x45 0x00 0x00 0x02 0x64 (MSB to LSB).
tharron is offline   Reply With Quote
Old September 23rd, 2014   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
Send a message via AIM to sblair Send a message via MSN to sblair
Default

So first off, it sounds like it is seeing the response if it keeps branching down the tree deeper. Do you see the controller keep branching all the way until it gets down to the lowest level of n and n+1 as the UID it is testing?

If so, when it gets to the lowest level, do you ever see the controller trying to send a MUTE command? When you respond to the DUB message your UID is always within the range being requested in the DUB message correct?
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old September 23rd, 2014   #5
tharron
Junior Member
 
Join Date: Sep 2014
Posts: 10
Default

Quote:
Originally Posted by sblair View Post
So first off, it sounds like it is seeing the response if it keeps branching down the tree deeper. Do you see the controller keep branching all the way until it gets down to the lowest level of n and n+1 as the UID it is testing?
It is seeing a response, but not a valid response. According to the sniffer I think I am seeing something like ~25 responses from the client.

Quote:
Originally Posted by sblair View Post
If so, when it gets to the lowest level, do you ever see the controller trying to send a MUTE command? When you respond to the DUB message your UID is always within the range being requested in the DUB message correct?
The last DUB packet the controller sends has the lower range equal to the upper range - this was contrary to how I read the spec in that I expected the n,n level to send a MUTE packet rather than another DUB packet. In the PDL sent by the controller I do see the same UID for the upper and lower range in that final packet and a 0x0001 for the PID.
tharron is offline   Reply With Quote
Old September 23rd, 2014   #6
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Ok, so just to be clear when you get to the very bottom, the UID in the PD section of the DUB matches your UID?

There is no hard requirement for how a controller implements its discovery process but there are recommendations made in the spec for how it can be done.

Hopefully Eric will be online this evening and will have some pointers as well.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old September 23rd, 2014   #7
tharron
Junior Member
 
Join Date: Sep 2014
Posts: 10
Default

That's correct - it matches my UID (not the off-by-one error I saw discussed in a different thread).

To clarify my problem the sniffer tells me that every single response packet has an "EUID Decode Errror" (the typo is Goddard's, not mine). For all ~25 responses I thumb through I see this error when browsing the packet history. It seems the controller physically receives them, laughs and tosses them aside.
tharron is offline   Reply With Quote
Old September 23rd, 2014   #8
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Just on a little bit of a tangent here, have you tried sending a MUTE request directly from the DMXter to your UID? You should be able to send it to a specific UID. It would be useful to know that you're able to send get a normal request/response through.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old September 23rd, 2014   #9
tharron
Junior Member
 
Join Date: Sep 2014
Posts: 10
Default

I'm by no means proficient with the DMXter yet, but I tried building up a MUTE packet by hand and the feedback I see on the DMXter is "ACT,CANT DECODE EUID". I set a breakpoint in my client code to see if I was forming a response, but I don't think the controller sent the packet correctly. I'll have to try building this up again tomorrow, and I'll let you know the results.

Thanks so much for your feedback so far!
tharron is offline   Reply With Quote
Old September 24th, 2014   #10
tharron
Junior Member
 
Join Date: Sep 2014
Posts: 10
Default

This morning I sent this packet:

CCh 01h 18h 56h 4Ch 2Fh 34h 4Bh 53h 47h 44h 00h 40h 41h 34h 03h 01h 00h 00h 00h 10h 00h 02h 00h 03h DEh

I verified that I am receiving this packet in this order in my processor.

I then scoped the response packet attached. Unless I'm mistaken the timing according to the analyzer should be OK? To clarify, when I send the packet via the DMXter its screen shows

BUILD CUSTOM REQUEST
ACT,CANT DECODE EUID

*edit* I've corrected a mistake I found where the Response Type was not being properly updated. In the photo it shows as 0x1, but I've fixed that to show the ACK instead of ACK_TIMER.
Attached Images
File Type: jpg mute_reply_sept24.jpg (75.7 KB, 232 views)

Last edited by tharron; September 24th, 2014 at 11:31 AM.
tharron is offline   Reply With Quote
Old September 24th, 2014   #11
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

Use the "View Previous Response" function in the DMXter to look at the actual data received by the DMXter. This will tell you if the data it received from the wire matches what you think you're sending.

You can get to this by pressing the RED key from any RDM menu option.

"EUID Decode Error" means the DMXter's RDM controller saw activity on the wire during the Discovery Response Period, but that it could not find a valid EUID in the data. It could be that the checksum does not match or some similar issue.

A common problem is the responder turning off the 485 line driver's transmit enable signal before the last byte has been fully sent. You need to make sure that all 8 bits have been shifted out along with the stop bits before turning off the transmitter.
ericthegeek is offline   Reply With Quote
Old September 24th, 2014   #12
tharron
Junior Member
 
Join Date: Sep 2014
Posts: 10
Default

I just corrected another minor issue with the response packet for DISC_MUTE and I think my device is now relaying valid response packets for the mute command; however, looking at the packet history I'm not sure what the DMXter is doing.

I manually set up the UID and then sent a MUTE packet via the DMXter. I can tell the light identifies(why?), but the DMXter reports WRONG PDL FOR PID. If I click the Yes button again I see the destination UID as well as NOT RESPONDING.

After this I went and checked the packet history, and the first thing I see is a good response from the mute packet. Above that is a broadcast identify packet, a device model description packet, an identify packet response (I think this is the response packet the "wrong" PDL) and finally another broadcast identify device.

Quote:
"EUID Decode Error" means the DMXter's RDM controller saw activity on the wire during the Discovery Response Period, but that it could not find a valid EUID in the data. It could be that the checksum does not match or some similar issue.
Please confirm that an invalid checksum could cause the decode error? I have double- (and triple- and quadruple- and...) checked my checksum code, but while I am fairly confident it's OK I'm even more confident about the encoding of the UID.

Quote:
A common problem is the responder turning off the 485 line driver's transmit enable signal before the last byte has been fully sent. You need to make sure that all 8 bits have been shifted out along with the stop bits before turning off the transmitter.
I was actually running into this problem previously, but I noticed it pretty quickly and it looks like everything is making it out of the transmitter before I disable it.
tharron is offline   Reply With Quote
Old September 24th, 2014   #13
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

Go into the discovery menu, then run "Send Single DUB" (I don't recall the exact menu name but it'll be similar to that).

Then, run "View Previous Response"

This will show you the exact data that the RDM Controller received from the 485 wire. Does it match what your responder is sending? If the response data is too early or too late, the DMXter won't accept it.

If you have a USB terminal attached, you can press RED and then select "Send All to USB". This will give you a record of everything that's happened recently, including packet data. You can post that here for further discussion.
ericthegeek is offline   Reply With Quote
Old September 24th, 2014   #14
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

Quote:
Originally Posted by tharron View Post
I tried building up a MUTE packet by hand and the feedback I see on the DMXter is "ACT,CANT DECODE EUID".
For mute packets, you'll want to use the "Unicast" packet type in "Build Custom Packet", and not DUB. The DUB packet type should only be used for Discover Unique Branch requests. Mute and Unmute and unicast packets, even though they have a Discovery Command Class.

But, it may be easier to just go into the Discovery menu and use the "Mute" and "unmute" options there rather than trying to build it youself. (I think this will work if you manually add the UID to the table of devices).
ericthegeek is offline   Reply With Quote
Old September 24th, 2014   #15
tharron
Junior Member
 
Join Date: Sep 2014
Posts: 10
Default

Good news! I found a couple (silly) mistakes in my DUB packet creation routine that were causing the checksum to be incorrect. Your hint earlier was especially useful as I went through that with a fine-tooth comb.

It looks like I'm able to respond to the Mute request as well. I haven't fully implemented a lot of the other features yet, but this is a HUGE step forward. Thanks folks!
tharron is offline   Reply With Quote
Old September 24th, 2014   #16
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

Glad you found it!

"Build Custom Request" on the DMXter is a really powerful feature, but it takes some time to learn. It can be... confusing... at first.

We'll be here if you have more questions as you get further into your development.
ericthegeek is offline   Reply With Quote
Old September 24th, 2014   #17
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Glad to hear you found it! Let us know of any other questions you have as you move forward!
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old September 24th, 2014   #18
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

...and the spelling error has been fixed.
ericthegeek 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
Errors and Sub Device All Call SeanSill RDM General Implementation Discussion 2 July 19th, 2013 01:48 PM
errors when testing discovery redwind RDM General Implementation Discussion 1 July 20th, 2011 12:05 PM


All times are GMT -6. The time now is 04:48 PM.


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