E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Physical Layer/Hardware Discussion

RDM Physical Layer/Hardware Discussion Discussion and questions relating to the physical or hardware layer of RDM.

Reply
 
Thread Tools Search this Thread Display Modes
Old July 7th, 2012   #1
ELMVideo
Junior Member
 
Join Date: Jul 2012
Posts: 4
Default Hardware design questions

Hi all,
I have 2 questions about hardware design.

1. I'm designing a one in two or more output circuit. Just to verify - the input whould be terminated to 120 ohms and each output should have the biasing network?

2. Using the 75176 IC's, the output of each IC "R" (receive data) outputs will need to 'simulate' a collision merging all of the data streams, (for the discovery mode). My intention is to connect a 100ohm resistor to each output merging into a single bus-would this be an good approach? Or would a multi input AND gate work?

Thank you in advance, any assistance or recommendations would be appreciated.
ELMVideo is offline   Reply With Quote
Old July 7th, 2012   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

Quote:
Originally Posted by ELMVideo View Post
1. I'm designing a one in two or more output circuit. Just to verify - the input whould be terminated to 120 ohms and each output should have the biasing network?
What you're describing is usually called an RDM Hub or RDM Splitter.

It's generally a bad idea to have a single DMX input with fixed termination unless you're absolutely certain your device will always be the last device in the DMX daisy chain. Generally it's best to have a male input connector with a passive female "through" connector (sometimes called "loopthrough").

You can then offer switchable termination, or end users can plug an external terminator into the loopthrough when it's the last device in the chain.

Quote:
Originally Posted by ELMVideo View Post
2. Using the 75176 IC's, the output of each IC "R" (receive data) outputs will need to 'simulate' a collision merging all of the data streams, (for the discovery mode). My intention is to connect a 100ohm resistor to each output merging into a single bus-would this be an good approach? Or would a multi input AND gate work?
A resistive combining network by itself won't work. For an N output splitter, you'd have N-1 outputs driving the line high and only 1 driving low during a normal RDM response.

You need some kind of logic managing the "Transmit Enable" and "Receive Enable" of each 485 line driver. I've seen the logic implemented with a microcontroller, with a PLD, and with a state machine.

Once you have that, you can use either a passive combining network, or an AND gate for the data signals.


When designing a RDM Hub, make sure you pay attention to the break shortening restrictions in the E1.20 document. Also, during the discovery response period, you either have to shorten the discovery response by one full character (lop off an entire 0xFE from the beginning of the response), or by a minuscule amount (the 75ns limit in section 4.2.3).
ericthegeek is offline   Reply With Quote
Old July 7th, 2012   #3
ELMVideo
Junior Member
 
Join Date: Jul 2012
Posts: 4
Default

Thank you Eric J. for the responses.

As for question 1 above, I'm asking in a general sense. The E1.20 document shows a reference circuit with Rt2 (120 ohm) and the biasing network, I just want to make sure I'm understanding where the two belong. The biasing network should be (for a 1 in 2+ out circuit) on the 2+ outputs (simulating controllers) and the (switchable) termination on the one input of this type of circuit?

Per question 2, I've designed the circuit with a microprocessor to handle the "Transmit Enable" and "Receive Enable" data direction etc., as for the 485 IC's (75176) the 'R' data out of theses IC's need to combine to 'simulate' a collision. Just to verify,

Quote: Once you have that, you can use either a passive combining network, or an AND gate for the data signals.

so each "R" output (Receive data of a 75176 IC) tieing to a 100 ohm resistor and then the resistors connected together and tied to the "D" input of the 'main' 75176 IC would suffice?

Thanks for the note on the timing, I'll make note of it.

Thanks again,
Eric M



ELMVideo is offline   Reply With Quote
Old July 7th, 2012   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

Quote:
Originally Posted by ELMVideo View Post
As for question 1 above, I'm asking in a general sense. The E1.20 document shows a reference circuit with Rt2 (120 ohm) and the biasing network, I just want to make sure I'm understanding where the two belong. The biasing network should be (for a 1 in 2+ out circuit) on the 2+ outputs (simulating controllers) and the (switchable) termination on the one input of this type of circuit?
Yes, you are correct.

The formal RDM terminology is "Command Port" and "Responder Port". A 1-in, 2-out RDM splitter would have 2 Command Ports and 1 Responder Port. The two command ports would have the line biasing network described in Figure 2-1 with R1, Rt1, and R2 built into the splitter for each port.

The 1 responder port may have the switchable 120 ohm termination.

See the attached diagram for details.

Quote:
Originally Posted by ELMVideo View Post
As for the 485 IC's (75176) the 'R' data out of theses IC's need to combine to 'simulate' a collision. Just to verify,
You can combine them to simulate a collision internally, but you don't have to.

In RDM, collisions will only occur during the discovery response period. On a single 485 segment, the effects of a collision are primarily analog with multiple 485 line drivers driving both high and low.

But, when you have a splitter, there can can be one or more responders on each 485 segment connected to the splitter. That means each segment will have its own analog effects. So which should you pass back to the responder port? You can AND all of the downstream segments together and drive that on to the responder port. Or, you can pick any segment that has activity (Typically the first falling edge on any downstream segment) and pass that segment back to the upstream port. Either is fine. The console should interpret *any* activity as a positive response and continue further down the discovery tree.

Technically picking one port rather than ANDing them all together can result in slightly faster discovery because it will cut down on the number of collisions. The first port to see a response may have a clean DUB response that the controller can decode and then mute the device directly, and other ports won't have a chance to interfere. But it practice the difference is minimal. (In the attached diagram, if responders #2, #3, and #4 all tried to respond, and the top port on the splitter triggered first, the controller would see a clean DUB response from #2 since #3 and #4 wouldn't have a chance to collide)

One thing to watch out for: You need to make sure that you account for other responders being present on the same segment as you splitter's upstream port. You can't just blindly turn on the Transmit Enable for the responder port during the discovery response period because it can mask valid responses from other devices. You have to wait until you see an edge on one of the downstream ports and then turn on Transmit Enable.

Using the diagram, if only #1 is responding to a DUB request, the splitter should not turn on its transmit enable.


Quote:
Originally Posted by ELMVideo View Post
Thanks again,
Glad we could help.
Attached Images
File Type: jpg rdm_system.jpg (26.0 KB, 661 views)
ericthegeek is offline   Reply With Quote
Old July 9th, 2012   #5
ELMVideo
Junior Member
 
Join Date: Jul 2012
Posts: 4
Default

Got it! Thank you for the thoroughness and attachment, very helpful.
Eric M
ELMVideo is offline   Reply With Quote
Old July 9th, 2012   #6
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

Once you have your device working, I'd encourage you to do a lot of testing with as many different devices as you can (controllers and responders).

Building a hub turns out to be one of the more difficult RDM devices. It's relatively easy to get *mostly* right, but handling all of the corner cases and error conditions can be a challenge, especially when you have to consider mis-behaving responders (truncated responses, responders that respond to broadcast, etc.). I have yet to see anyone get it completely right on their first try.

There will likely be another plugfest in Jan 2013. You may want to consider attending since it's a good opportunity to test with a wide variety of equipment. Also, there are several people who have built splitters that read this forum. If you have specific questions, we may be able to answer them for you.
ericthegeek is offline   Reply With Quote
Old July 10th, 2012   #7
ELMVideo
Junior Member
 
Join Date: Jul 2012
Posts: 4
Default

Good advice.

Is there any inexpensive PC controller software to use as a test platform?
Do you know where the plugfest would be held?

Eric M

Last edited by ELMVideo; July 10th, 2012 at 09:20 AM.
ELMVideo is offline   Reply With Quote
Old July 10th, 2012   #8
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

Quote:
Originally Posted by ELMVideo View Post
Is there any inexpensive PC controller software to use as a test platform?
Realistically, you'll need a few different controllers. Different pieces of test equipment excel in different areas.

The cheapest RDM controller I know of is DFD's RAD. But it's not exactly full featured.

I'm partial to the DMXter4, it's the only controller I know of that gives you full control over signal timing, and accurate timing analysis, which is especially important when you're testing a RDM hub.

I'll let others weigh in on the strength's/weakness of various other options.

(In the interest of full disclosure: I have worked for Goddard Design)

Quote:
Originally Posted by ELMVideo View Post
Do you know where the plugfest would be held?
The next plugfest will likely be held in Late January 2013 near Dallas, TX, USA. The formal schedule hasn't been set yet, so that is subject to change.

Watch the PLASA TSP meeting schedule for details.
http://tsp.plasa.org/tsp/meetings/index.php
There'll also be an announcement on this forum.
ericthegeek is offline   Reply With Quote
Old July 10th, 2012   #9
sblair
Administrator
 
Join Date: Feb 2006
Posts: 419
Send a message via AIM to sblair Send a message via MSN to sblair
Default

The two I generally go with is the DMXter4 and the Enttec Sniffer. The Sniffer is great as it essentially Wireshark for RDM which is very helpful. I use the Enttec Controller quite a bit as well (even though it is a bit buggy) as the UI is more friendly for basic message testing.

The only thing that does hardcore timing tests well and good abuse tests is the DMXter4.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old July 12th, 2012   #10
jpk__
Junior Member
 
Join Date: Jul 2012
Posts: 6
Default

Quote:
Originally Posted by sblair View Post
The two I generally go with is the DMXter4 and the Enttec Sniffer. The Sniffer is great as it essentially Wireshark for RDM which is very helpful. I use the Enttec Controller quite a bit as well (even though it is a bit buggy) as the UI is more friendly for basic message testing.

The only thing that does hardcore timing tests well and good abuse tests is the DMXter4.
Can you confirm if the enttec unit has correct Command Port biasing? The enttec pro unit I have here doesn't.
Thanks, jpk
jpk__ is offline   Reply With Quote
Old July 12th, 2012   #11
sblair
Administrator
 
Join Date: Feb 2006
Posts: 419
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Quote:
Originally Posted by jpk__ View Post
Can you confirm if the enttec unit has correct Command Port biasing? The enttec pro unit I have here doesn't.
Thanks, jpk
Good question. I can't recall for certain if it does. I'm pretty certain that Eric or one of the other more HW oriented guys will know.

The model I've always used is the RDM USB Pro. Because the same box can be used inline running the Sniffer app or as a Controller I'm thinking that it doesn't have the proper Command Port biasing otherwise it would likely be overterminating the line when used in series.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old July 12th, 2012   #12
jpk__
Junior Member
 
Join Date: Jul 2012
Posts: 6
Default

Quote:
Originally Posted by sblair View Post
Good question. I can't recall for certain if it does. I'm pretty certain that Eric or one of the other more HW oriented guys will know.

The model I've always used is the RDM USB Pro. Because the same box can be used inline running the Sniffer app or as a Controller I'm thinking that it doesn't have the proper Command Port biasing otherwise it would likely be overterminating the line when used in series.
Is there anything in the standard about marking Command Ports with/without termination or can we safely assume anything on the command end marked E1.20 compliant must be a Command Port and thus is terminated correctly? Terminating with bias outside the box is a little tricky
Does anyone offer internally switched Command Port termination?
Thanks, jpk
jpk__ is offline   Reply With Quote
Old July 12th, 2012   #13
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

Quote:
Originally Posted by jpk__ View Post
Is there anything in the standard about marking Command Ports with/without termination or can we safely assume anything on the command end marked E1.20 compliant must be a Command Port and thus is terminated correctly?
The standard says (emphasis added):
"Command ports shall include the line biasing network."

"Command ports may be designed with means to disconnect the line biasing network."

A command port that does not offer the line bias would not meet the standard. But, don't assume the BIAS is always present. The means to disconnect the bias may be internal jumpers that you can't see without opening up the product. A previous user could have disabled it without your knowledge.

Quote:
Originally Posted by jpk__ View Post
Does anyone offer internally switched Command Port termination?
The DMXter4 uses relays to Add/Remove the BIAS network as appropriate. There's also a software override to let you remove the BIAS network for testing special cases.
ericthegeek is offline   Reply With Quote
Old July 13th, 2012   #14
nic123
Junior Member
 
Join Date: Jun 2006
Posts: 14
Default

Quote:
Originally Posted by jpk__ View Post
Can you confirm if the enttec unit has correct Command Port biasing? The enttec pro unit I have here doesn't.
Thanks, jpk
Yes Jason, the PRO does have proper biasing. The DMX USB Pro has bias + source termination, the RDM USB Pro has none as it would over bias the line if it did.
Good to see you posting under your true name/company affiliation

Nicolas Moreau
www.enttec.com
nic123 is offline   Reply With Quote
Old July 21st, 2013   #15
jpk__
Junior Member
 
Join Date: Jul 2012
Posts: 6
Default

Quote:
Originally Posted by nic123 View Post
Yes Jason, the PRO does have proper biasing. The DMX USB Pro has bias + source termination, the RDM USB Pro has none as it would over bias the line if it did.
Good to see you posting under your true name/company affiliation

Nicolas Moreau
www.enttec.com
Hi Nicolas,
I took another look at the DMX USB Pro I have here and don't see anything like the source termination specified in [2.5 Command port reference circuit]. Maybe I'm missing something obvious here which you could enlighten me about.

If the Enttec RDM USB Pro has no termination then how does it comply when used as a command port? Or is this device purely an RDM sniffer only?

Fixed my signature btw.
__________________
Jason Kyle - http://DMXking.com
jpk__ 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
Detailed questions on STATUS_MESSAGES eldoMS RDM General Implementation Discussion 2 September 2nd, 2011 03:14 PM
Cable shield connection questions berntd RDM Physical Layer/Hardware Discussion 0 May 26th, 2008 12:22 AM
Anybody actually doing any opensource RDM design percramer RDM General Implementation Discussion 0 September 19th, 2006 12:14 PM
Welcome to the RDM Physical Layer / Hardware Discussion Forum sblair RDM Physical Layer/Hardware Discussion 0 May 31st, 2006 11:57 PM


All times are GMT -6. The time now is 10:56 AM.


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