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 January 23rd, 2012   #1
PeakPaul
Junior Member
 
Join Date: Jan 2012
Location: Buxton, Derbyshire
Posts: 5
Default Where to start.....

Hi All,

I'm new to this forum, had a fairly good look around the different topics, but I was wondering where to start with RDM.

There is a lot of good info on here, I have the rdm.h header file that was posted, and I bought a copy of the 2010 spec.

I'm looking to implement RDM as a responder for an existing LED stage lighting fixture, but only need very basic RDM functionality to start with (DISCOVERY, SET / GET DMX ADDRESS, SUPPLY PRODUCT INFO).

With the timing aside, what are the basic commands I need to process/ respond to?

Thanks - Paul.
PeakPaul is offline   Reply With Quote
Old January 23rd, 2012   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Paul,

Welcome! Obviously you need to pay attention to the physical layer and very carefully to the timings in order for your device to play well with the others. You'll also want to make sure you parse and pay attention to all the fields in the message header properly.

As far as what messages to implement it really depends on you. The absolute minimum required messages are indicated by the "Required" column of Table A-3. For your device, that would be the 3 Discovery messages, DEVICE_INFO, SOFTWARE_VERSION_LABEL, DMX_START_ADDRESS, IDENTIFY_DEVICE. There are some others that are dependant requirements. Meaning they are required if you implement certain other messages, so review the requirements indicated by that column.

Once you get the basic messages working, most find that implementing additional messages is very easy and they often implement as many as they can that are useful for their product.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 24th, 2012   #3
PeakPaul
Junior Member
 
Join Date: Jan 2012
Location: Buxton, Derbyshire
Posts: 5
Default

Thanks Scott,

On the physical layer timings issue, it doesn't look a lot different to Standard DMX except for responses have a 176us min break as opposed to 88us, and there are some max times now introduced which DMX were probably ignored.

I found the following in the Enttec Sniffer Manual:

PACKET TYPE MIN TIME MAX TIME
DMX 512 - Break 88 us
RDM Any - Break 176us 352us
RDM Discovery Response 176us 2.8ms
RDM Controller Request 3ms 1s
RDM Controller Discovery 5.8ms 1s
RDM Responder Response 176us 2ms

Anything else to look out for?

Paul.
PeakPaul is offline   Reply With Quote
Old January 24th, 2012   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Quote:
Originally Posted by PeakPaul View Post
I found the following in the Enttec Sniffer Manual:
Don't rely on any third party documents. Tables 3-1 through 3-4 in the E1.20-2010 standard are the official timing requirements. RDM Timing is very strict, plan on spending lots of time with an oscilloscope.

Other things to watch out for:
Make sure you handle Broadcast and Vendorcast packets properly. You must not respond to a broadcast and you have to be ready for a new packet within 176 microseconds. A common problem is for responders to take too long to process a broadcast and thus miss a new packet that arrives shortly after the broadcast.

Pay close attention to the semantics of ACK_TIMER and ACK_OVERFLOW if you use those features.
ericthegeek is offline   Reply With Quote
Old January 24th, 2012   #5
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

To further what Eric said, to answer the question which requirements are important in the standard, they ALL are.

Every sentence and requirement that was written in the standard is there for a reason and was the result of much discussion. I can't stress the importance of reading the standard closely and following the details.

Please do not rely on 3rd party documentation like the Enttec manual for determining requirements. By doing that, at best, you'll only be compatabile with their product.

Another point worth mentioning, the Enttec Sniffer is a great debugging tool, but do NOT rely on it's analysis of the timing. We have found that it is frequently incorrect in regards to doing detailed timing analysis. For that, you're best bet is using an Oscilloscope.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old March 2nd, 2012   #6
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default Where to Start

Paul - welcome.

Take a look at my posts regarding the next RDM developers conference and Plugfest, here in the UK in April 2012.

This would be an excellent event to attend if you are new (or old) to the world of RDM!

Peter
prwatE120 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


All times are GMT -6. The time now is 02:55 AM.


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