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 13th, 2011   #1
head_up
Junior Member
 
Join Date: Mar 2011
Posts: 7
Question RDM Discovery packets

hi! i'm new here, and my english is not vary good, but i hope you will excuse my little (and not so) language-mistakes.
I have implemented standart DMX device and it work fine - i'm detecting BREAK correctly with gpio as interrupt and using timer to measure the time ot the BREAK. The sequence is:
1) RX pin as gpio, detecting falling edge
2) RX pin as gipo, detecting rising edge, check the time and if correct - i allow UART to work and make some inits for data storage buffers.
3) after complete frame is received (less or equal to 513) i reinit the RX pin as gpio and waiting again for falling edge (reset sequence)
But now i must implement RDM too on this device. And i'm little confused - ok, all RDM frames begin with the same reset sequence, BUT DISC_UNIQUE_BRANCH have no BREAK in the frame stucture. So i can't use my "reset sequence".
How must i handle the receiving of DMX data starting with BREAK and RDM packets without BREAK? I have some ideas how to do this, but i'm not sure what is the right and (almost) every time work correct sequence of actions for receiving mixed RDM and DMX data.
head_up is offline   Reply With Quote
Old March 13th, 2011   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Welcome to the forums!

If you are implementing a responder, which is what it sounds like from your post, then you don't really need to detect or listen to the other discovery response traffic. To an observer on the wire, the Discovery Unique Branch message coming from the controller and all the responses coming from the devices will just look like a single frame of data with a large interframe delay.

Any packets of data that a responder would need to monitor will all be preceded with the proper reset sequence. Only splitters, inline devices, and controllers must be capable of handling the breakless response from the Discovery Unique Branch message.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old March 14th, 2011   #3
head_up
Junior Member
 
Join Date: Mar 2011
Posts: 7
Default

Thanks! In some cases my device act like proxy, so i must be able to listen without-break frame, but i think it is clear how to do this. In fact it was my mistake about receiving break - you are right, it will be found like in chain with the request from the controller if some one listen the line.
The second question is - what can be the delay between controller request and my respond for DISC_UNIQUE_BRANCH message? This is important for me because my mcu have realy many tasks and some time it is possible to have big delay betweeb reqyest and mt answer. In the other case: if i'm discovering responders connected to my ports - how many time i must wait for answer (it must be the same time)?
And something strange for me - when the controller discover me and everything is fine whit out connection (he know me). Ok, after this the controller can require from me a list of connected devices - so the procedure of discovering of connected device must be done by me after i'm initialized by the controller OR i must do this procedure and discover the connected devices after i'm powered on? Or i must periodicaly discover the connected devices and renew the list and indicate this to controller by QUEUED_MESSAGE? The last one is hard for me and i'm not sure how often i must do this check for new/disconnected devices?
head_up is offline   Reply With Quote
Old March 14th, 2011   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

The spacing of packets is detailed in Section 3.1.2 and Section 3.2.2 in the standard. The time from the controller sending the DISC_UNIQUE_BRANCH message to a response is between 176us and 2ms. A responder can not respond sooner than 176us and no latter than 2ms. A controller must listen for responses for up to 2.8ms to allow for system delay through splitters and inline devices (See line 1 of Table 3-2).

As far as when to discover the devices connected to you it is pretty much up to you when you initiate that. There are others here that have implemented proxy devices that may have some suggestions from their own experience. QUEUED_MESSAGE is really a cornerstone of system functionality so I would strongly encourage you to support them. Queued Messages are a good way to alert the controller more devices have been discovered.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old March 15th, 2011   #5
head_up
Junior Member
 
Join Date: Mar 2011
Posts: 7
Default

Thank you, sblair, your answers are realy important for me. 2.8 ms is realy hard, i must implement this subroutine as "very high priority task" in some manner - may be immediately after the message is received in the interrupt subroutine. I'll implement QUEUED_MESSAGE when i want to inform the controller about new devices connected to some one of my ports.
But the question is when i must make search procedure about new devices connected to me - after i'm initialized or after power up and how often must i do this search and update the list of devices - 1 min, 10 min or rear?
Now i can't understand the idea of PortId in Controller Generated Messaged - ok, the controller can send to me this and i can recognize it, but when i answer with respond i can't return the port number - so if i haven't claims about the port originated this message can i just leave without attention this field?
head_up is offline   Reply With Quote
Old March 15th, 2011   #6
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

To clarify, a responder MUST respond within 2ms. A controller must listen for a response for up to 2.8ms.

It is up to you when you discover devices connected to you. Generally it is something that you want to have some user configurable options for. Typically I'd suggest doing a discovery shortly after you first come up and then you can do an ongoing discovery when you want. I'd suggest no more frequently than once/minute or so. It's also a good idea to do it whenever you see the controller above you doing discovery as well. If the controller above you is hardly ever doing discovery then there isn't much need in you doing it more frequently than it. Again, user configurable options here are a good idea.

Port ID can be useful in some larger systems, especially for dimmer racks that consume multiple universes of DMX for it to understand the source where it's data is originating. If you don't make use of the Port ID field as a responder receiving it you can choose to ignore it. On the Controller-side, you need to properly generate the correct Port ID though.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old March 15th, 2011   #7
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

A responder has to *start* responding within 2ms of receiving a DUB request (Table 3-4 line 2).

A controller must listen for DUB responses for 5.8ms (Table 3.2 line 2).
ericthegeek is offline   Reply With Quote
Old March 17th, 2011   #8
head_up
Junior Member
 
Join Date: Mar 2011
Posts: 7
Default

People, thank you for your support! You are the last hope of any RDM developer :D

Lets go ahead: Now i'm discovered by the controller, so i have stable communication.
But there are some mistakes for me about the data exchange:

1) i have 3 custom PIDs, N1 and N2 are support only SET (E120_CC_SET), N3 support only GET (E120_CC_GET). The controller continue to request information from me about this PIDs and i'm sending the description any time. And the strange is - the controller sometime try to GET PIDs N1 and N2. But i haven't support for them and i'm not answering. Is this correct? Because sometime the controller says "Device Dropped (..some info..) ". I'm looking the transfer of data with sniffer and the only requests i'm not answering are this GETs and DMX_START_ADDRESS (now i answer and to this request). And this is the second question:

2) DMX_START_ADDRESS in E120_DEVICE_INFO/E120_DMX_START_ADDRESS requests is set to 0xFFFF), if i correctly understand the documentation. I'm not supporting any DMX data for my needs, i will only send this data to devices connected to me. Is this 0xFFFF correct answer? I'm not sure how to understand DMX512 Footprint (of 0) - what this field mean?

3) ok i'll be proxy device, i identify my self with E120_PROXIED_DEVICES and E120_PROXIED_DEVICE_COUNT supported PIDs (for now fake, 0 devices reported every time). i also set the Bit 0 Managed Proxy Flag (bit 0) in Control Field of mute/un-mute requests. Is this enough for the controller to understand what i'm? Because E120_PROXIED_DEVICES and E120_PROXIED_DEVICE_COUNT are never reached in my code - no request about them

I have and other questions, but later ... !

Edit: E120_PRODUCT_CATEGORY_DATA i reported for E120_DEVICE_INFO request, is this correct for proxy device? I know - i want too many information from you, but i need it realy. Thanks again!

Last edited by head_up; March 17th, 2011 at 08:19 AM.
head_up is offline   Reply With Quote
Old March 17th, 2011   #9
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Quote:
Originally Posted by head_up View Post
1) i have 3 custom PIDs, N1 and N2 are support only SET (E120_CC_SET), N3 support only GET (E120_CC_GET). The controller continue to request information from me about this PIDs and i'm sending the description any time. And the strange is - the controller sometime try to GET PIDs N1 and N2. But i haven't support for them and i'm not answering. Is this correct?
No, that is not correct. You should send a NACK response with a reason code of UNSUPPORTED_COMMAND_CLASS

Quote:
Originally Posted by head_up View Post
2) DMX_START_ADDRESS in E120_DEVICE_INFO/E120_DMX_START_ADDRESS requests is set to 0xFFFF), if i correctly understand the documentation. I'm not supporting any DMX data for my needs, i will only send this data to devices connected to me. Is this 0xFFFF correct answer? I'm not sure how to understand DMX512 Footprint (of 0) - what this field mean?
You are correct, if your device does not use any Null Startcode DMX data, then you send the DMX512 Footprint to 0, and the DMX512 Start Address to 0xFFFF in the DEVICE_INFO response.

You do not have to support the DMX_START_ADDRESS PID.

Quote:
Originally Posted by head_up View Post
3) ok i'll be proxy device, i identify my self with E120_PROXIED_DEVICES and E120_PROXIED_DEVICE_COUNT supported PIDs (for now fake, 0 devices reported every time). i also set the Bit 0 Managed Proxy Flag (bit 0) in Control Field of mute/un-mute requests. Is this enough for the controller to understand what i'm? Because E120_PROXIED_DEVICES and E120_PROXIED_DEVICE_COUNT are never reached in my code - no request about them
Not all controllers support the E120_PROXIED_DEVICES feature. Some controllers use these PIDs, but they are not required too.

You must also respond to DISCOVER_UNIQUE_BRANCH requests on behalf of your proxied devices, so a controller that doesn't support the E120_PROXIED_DEVICES PIDs will find the devices on the far side of your proxy that way.

Quote:
Originally Posted by head_up View Post
Edit: E120_PRODUCT_CATEGORY_DATA i reported for E120_DEVICE_INFO request, is this correct for proxy device? I know - i want too many information from you, but i need it realy. Thanks again!
That is fine.
ericthegeek is offline   Reply With Quote
Old March 18th, 2011   #10
head_up
Junior Member
 
Join Date: Mar 2011
Posts: 7
Default

Thanks, ericthegeek, u rescue me from long hours cursing!

Today's question is ( the beer is from me ) :
For now i can't support E120_QUEUED_MESSAGE (not listed in E120_SUPPORTED_PARAMETERS respond), but i will add support later, for now the controller is sending to me requests which are with PD 0x02 (E120_STATUS_ADVISORY !? why this ?! ) at ~1 sec. I'm not sure, but i think this is like "Are u here?". Is this correct? For now i'm answering with NACK - but the controller continue to send me this requests... is this problem or i must respond with STATUS_MESSAGES with a PDL of 0x00?

I thing support of queued messages is absolutely mandatory for proxy device, but for now i can't add it (for some other reason). When i must respond the list of devices and the list is too long for single message - can i use for now E120_RESPONSE_TYPE_ACK_OVERFLOW ? i think this is very close to E120_QUEUED_MESSAGE support about this data stream.
head_up is offline   Reply With Quote
Old March 18th, 2011   #11
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Quote:
Originally Posted by head_up View Post
Thanks, ericthegeek, u rescue me from long hours cursing!
Happy to help. There are quite a few knowledgeable people who read this forum. We all want RDM to succeed.

Quote:
Originally Posted by head_up View Post
the controller is sending to me requests which are with PD 0x02 (E120_STATUS_ADVISORY !? why this ?! ) at ~1 sec. I'm not sure, but i think this is like "Are u here?". Is this correct?
Many controllers periodically poll every RDM responder to make sure it is still connected. A controller can use a variety of PIDs to do that polling. Some use MUTE, some use GET QUEUED_MESSAGES, some use GET STATUS_MESSAGES. All it's doing is making sure that the responder is still connected. If doesn't matter if the responder NACKs, or ACKs; Any response tells the controller that the responder is still connected.

Quote:
Originally Posted by head_up View Post
For now i'm answering with NACK - but the controller continue to send me this requests... is this problem or i must respond with STATUS_MESSAGES with a PDL of 0x00?
If you don't support queued messages at all, then your behavior is correct. You can NACK the request.

That changes once you add support for Queued Messages. If you receive a GET QUEUED_MESSAGES PID from the controller, and you don't have any messages to deliver, then you have to respond with a STATUS_MESSAGES response (E1.20-2006 section 10.3.1).


Quote:
Originally Posted by head_up View Post
I thing support of queued messages is absolutely mandatory for proxy device, but for now i can't add it (for some other reason).
An RDM responder (including a proxy) must be able to respond to any valid RDM request within 2ms (Table 3-4 line 2). If the devices you are proxying for can always provide the info you need in that time, then you don't have to support queued messages. But, if getting the info you need from the far side of the proxy can take longer than 2ms, you must ACK_TIMER to request and queue up the proper response as soon as the information becomes available.

If you are doing an RDM to RDM proxy, then you must support queued messages. The responder on the far side of the proxy can take the full 2ms to respond, which leaves you no time to pass it along to the controller.

If your list of proxied devices can change, then you must support queued messages. You have to queue a PROXIED_DEVICE_COUNT PID message any time your list of supported parameters changes if you are acting as a managed proxy.

Quote:
Originally Posted by head_up View Post
When i must respond the list of devices and the list is too long for single message - can i use for now E120_RESPONSE_TYPE_ACK_OVERFLOW ? i think this is very close to E120_QUEUED_MESSAGE support about this data stream.
Yes, if your list of PROXIED_DEVICES is too large for a single packet, then you must use ACK_OVERFLOW.
ericthegeek is offline   Reply With Quote
Old March 20th, 2011   #12
head_up
Junior Member
 
Join Date: Mar 2011
Posts: 7
Default

Thanks again, ericthegeek! Your answer is realy helpful and i need it realy much! I like DMX and RDM - they look to be simple and effective realization of almost full lighting control.
May be the question is stupid or come too late when i'm already in the protocol development level, but ... there is something in the timing that i can't understand:
How to detect the correctly packages with length less than 513 bytes (possible RDM, but not only!) if i can't explore it "on the fly"?
The interslot delay in RDM systems must be no more than 2.1 ms, ok - if i must answer to the controller no later than 2 ms it is in fact impossible - i'm waiting 2.1 ms after the last rx byte and if there is no other byte for this time i try to explore the packet - if it is correct RDM packet, i will answer to the controller. Now this method work fine - the controller is accepting my answers. But is this correct - to handle one packet as not-full DMX512A (possible RDM or other unknown package) if there is time-out over 2.1 ms for interslot delay?
How u do this in the real RDM systems?
If i use this time-out as reference for non-DMX package - this may be will not work with old DMX system where the timing for interslot delay can be 1s?!
This is something strange for me and i found it like possible problem. If you can explain me how to do this correctly it will be great!

Last edited by head_up; March 20th, 2011 at 07:19 AM.
head_up is offline   Reply With Quote
Old March 20th, 2011   #13
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

> i'm waiting 2.1 ms after the last rx byte and if there is no
> other byte for this time i try to explore the packet - if it is
> correct RDM packet, i will answer to the controller.

This is not correct. You must respond a a request within 2.0ms of receiving the request (table 3-4). If you wait longer than that the controller may consider the response to be lost. You can't use a timeout to reliably detect the end of a request.

For RDM to work, you have to look into the packet as you receive it. After you've received a break followed by 3 bytes, you have to look at the packet data to see if you've received an RDM Startcode (0xCC), Sub-Startcode (0x01), and Length. Once you know the request's length, then you can count how many more data bytes you need to receive.

> If i use this time-out as reference for non-DMX package
> this may be will not work with old DMX system where the
> timing for interslot delay can be 1s?!

You must always be looking for both a break, and a data byte. You don't know ahead of time which you'll receive. When you receive a falling edge, it may be the start bit for the next data byte, or it may be the start of a break.
ericthegeek is offline   Reply With Quote
Old March 22nd, 2011   #14
head_up
Junior Member
 
Join Date: Mar 2011
Posts: 7
Default

This is realy strange! I do exactly as u say - i have receiver and the receiver treat the delay over 2.1 ms as error in interslot delay. Now i explore the packet "on the fly" and the receiver act correctly. I can answer soon after the request is received - in fact near 1.3 ms after the last byte. And I have a DMX-RDM usb sniffer too (enttec) so i can look what happen on the line. And what to see - if i answer in less than 2 ms after the request is received - there is flag "timing error" on my answers! Wow ?! But the controller accept my answers as normal. I try to delay my answers - more than 2 ms, more than 3 ms and there is no error - sniffer say "ok", the controller work too! Is the sniffer full with bugs or there is something other?! You are right - in the specification is clear described - the answer must be in time between 176us and 2 ms, but in fact my sniffer is founding this like error... i'm confused and surprised! May be i must return to enttec this sniffer for 600E ?! Deam...
If i can i will attach the screenshots from the sniffer later, now i can't transfer files between the computers.

Edit: Or in fact the problem is in my head - may be the times in the sniffer packet list are between the start of request and the respond, so may be i'm under 176 us with my respond... i will do some measurement with mcu timers.

Edit2: mmm, yes, the problem is in my head, everything is fine! Thanks, ericthegeek && sblair, now i can go ahead!

Last edited by head_up; March 22nd, 2011 at 06:23 AM.
head_up is offline   Reply With Quote
Old March 22nd, 2011   #15
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

The Sniffer is a great and useful tool for developing RDM. HOWEVER, the timing information on it is not very accurate. Most folks on here use the Sniffer to look at the packets and data on the wire but do not rely on it for any timing analysis at all. For timing, using a scope or a Goddard DMXter-4-RDM are the most reliable methods.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair 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
Captured RDM packets chris RDM General Implementation Discussion 2 February 11th, 2009 02:02 PM
Time between controller packets Dan Scheurell RDM Timing Discussion 1 April 1st, 2007 11:38 PM


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


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