Hardware design questions

[ELMVideo]

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.

[ericthegeek]

Originally Posted by ELMVideo

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.

Originally Posted by ELMVideo

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).

[ELMVideo]

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

[ericthegeek]

Originally Posted by ELMVideo

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.

Originally Posted by ELMVideo

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.

Originally Posted by ELMVideo

Thanks again,

Glad we could help.

[ELMVideo]

Got it! Thank you for the thoroughness and attachment, very helpful.
Eric M

[ericthegeek]

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.

[ELMVideo]

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

[ericthegeek]

Originally Posted by ELMVideo

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)

Originally Posted by ELMVideo

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.

[sblair]

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.

[jpk__]

Originally Posted by sblair

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

[sblair]

Originally Posted by jpk__

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.

[jpk__]

Originally Posted by sblair

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

[ericthegeek]

Originally Posted by jpk__

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.

Originally Posted by jpk__

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.

[nic123]

Originally Posted by jpk__

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

[jpk__]

Originally Posted by nic123

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.