|
RDM Physical Layer/Hardware Discussion Discussion and questions relating to the physical or hardware layer of RDM. |
|
Thread Tools | Search this Thread | Display Modes |
July 7th, 2012 | #1 |
Junior Member
Join Date: Jul 2012
Posts: 4
|
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. |
July 7th, 2012 | #2 | ||
Task Group Member
Join Date: Aug 2008
Posts: 379
|
Quote:
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:
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). |
||
July 7th, 2012 | #3 |
Junior Member
Join Date: Jul 2012
Posts: 4
|
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 |
July 7th, 2012 | #4 | ||
Task Group Member
Join Date: Aug 2008
Posts: 379
|
Quote:
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:
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. Glad we could help. |
||
July 9th, 2012 | #5 |
Junior Member
Join Date: Jul 2012
Posts: 4
|
Got it! Thank you for the thoroughness and attachment, very helpful.
Eric M |
July 9th, 2012 | #6 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
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. |
July 10th, 2012 | #7 |
Junior Member
Join Date: Jul 2012
Posts: 4
|
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. |
July 10th, 2012 | #8 | |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
Quote:
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) 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. |
|
July 10th, 2012 | #9 |
Administrator
|
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 |
July 12th, 2012 | #10 | |
Junior Member
Join Date: Jul 2012
Posts: 6
|
Quote:
Thanks, jpk |
|
July 12th, 2012 | #11 | |
Administrator
|
Quote:
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 |
|
July 12th, 2012 | #12 | |
Junior Member
Join Date: Jul 2012
Posts: 6
|
Quote:
Does anyone offer internally switched Command Port termination? Thanks, jpk |
|
July 12th, 2012 | #13 | |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
Quote:
"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. 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. |
|
July 13th, 2012 | #14 | |
Junior Member
Join Date: Jun 2006
Posts: 14
|
Quote:
Good to see you posting under your true name/company affiliation Nicolas Moreau www.enttec.com |
|
July 21st, 2013 | #15 | |
Junior Member
Join Date: Jul 2012
Posts: 6
|
Quote:
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 |
|
Bookmarks |
Thread Tools | Search this Thread |
Display Modes | |
|
|
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 |