E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   Discovery procedure clarification (http://www.rdmprotocol.org/forums/showthread.php?t=1158)

truten March 21st, 2013 02:19 AM

Discovery procedure clarification
 
Hello everybody,

While i was searching some information (total newbie to RDM) to complete the application I was writing for a responder i encountered this forum so I'll try to take advantages of your knowledge :p

The question is about the discovery procedure:I've read the ANSI E1.20-2006 but I still miss something.
After a discovery is done how all the responder pass to a mute state to an unmute one?
I have a Goddard DMXter4 RDM and after sniffing it, it seems that at the end of the procedure it broadcast a RESET_DEVICE but this command isn't indicated as required in the E1.20 so i'm a bit confused.

Also in the DMXeter4 when i mute/unmute a device from the RDM menù it also send a RESET_DEVICE to the specific responder. Is this correct? Because since RESET_DEVICE clear the mute flag i don't understand the logic and I'm even more confused.

Thanks in advance to anyone will respond. It will be a great help for me.

sblair March 21st, 2013 04:06 AM

Welcome to the forums!

Generally when once a device is discovered and muted the controller leaves it in the muted state. This makes it easy for the controller to quickly discover any other device that comes online between discovery polls.

When muted, the controller can still communicate and the device will respond to all other PIDs. The only PID that is affected by the mute is the discovery unique branch PID.

The device can simply be unmuted without having to do a RESET_DEVICE to accomplish that when desired.

The DMXter is a bit special in that it is more of a diagnostic tester than a normal controller so it may do somethings differently. I think it may send an UNMUTE command to the device so that when it is then plugged back into the normal controller it will get properly re-discovered.

It sounds very odd that it would be sending a command to reset the device though. I certainly don't recall seeing that behavior before.

The software developer for the DMXter visits the forums so I'm sure he'll probably be able to respond within the next day or so.

truten March 21st, 2013 04:43 AM

Dear Scott, thank you.

It's clear that I misread or I didn't fully understand the ANSI correctly since I thought that once the responder was muted it shouldn't respond until it was unmuted with the proper command...
Big mistake.

Now the discovery make more sense :p

Regarding the Goddard I'm quite sure that it send a RESET_DEVICE when in the RDM discovery menu you choose to mute a specific device.
Anyway this will not be a problem any-more since it should be solved as soon I fix the discovery.

Again thank you. :)

ericthegeek March 21st, 2013 10:55 AM

How are you determining what PIDs the DMXter is sending? The DMXter should only send a RESET_DEVICE when explicitly told to do so from the "Setup Device" menu, and never from the Discovery menu.

You will see IDENTIFY_DEVICE and DEVICE_MODEL_DESCRIPTION packets when browsing the list of devices to mute.

After doing a "Mute Device", go into the "Advance RDM":"Browse Packet History" menu and you can see the last few hundred packets that the DMXter has sent, and the associated response. This may help you determine what's happening.

Make sure you're handling broadcast packets properly. The DMXter does a number of broadcast SET IDENFITY_DEVICE packets, and I've frequently seen responders that have a problem with this.

ericthegeek March 21st, 2013 07:02 PM

2 Attachment(s)
Here are two packet histories from a DMXter4.

"DMXter4 Discovery.txt" shows the DMXter running full discovery for a single device. There's one request/response pair per line. Following along the packet sequence, you'll see:

A: Broadcast Unmute (TN 00h)
B: Discover Unique Branch - Binary Search (TNs 01h-55h)
C: Mute the device (TN 56h)
D: Discover Unique Branch - No further Devices found (TNs 57h-93h)

"DMXter4 Mute Device.txt" shows the result of running "Discover Devices":"Mute Device". The first 4 requests show the user browsing the list of responders for the correct responder to mute, and the last packet is the actual mute when a responder is chosen.

Hopefully these examples will help you figure out what's happening. If not, post some packet captures and we might be able to give you some guidance.


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

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