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 March 21st, 2013   #1
truten
Junior Member
 
Join Date: Mar 2013
Posts: 2
Default 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

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.
truten is offline   Reply With Quote
Old March 21st, 2013   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 421
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin

Last edited by sblair; March 21st, 2013 at 05:13 AM.
sblair is offline   Reply With Quote
Old March 21st, 2013   #3
truten
Junior Member
 
Join Date: Mar 2013
Posts: 2
Default

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

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.
truten is offline   Reply With Quote
Old March 21st, 2013   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 362
Default

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 is offline   Reply With Quote
Old March 21st, 2013   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 362
Default

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.
Attached Files
File Type: txt DMXter4 Discovery.txt (9.8 KB, 319 views)
File Type: txt DMXter4 Mute Device.txt (549 Bytes, 428 views)
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
RDM Controller timing clarification Dan Scheurell RDM Timing Discussion 4 May 15th, 2014 11:34 PM


All times are GMT -6. The time now is 02:58 PM.


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