View Single Post
Old March 21st, 2016   #2
Task Group Member
Join Date: Aug 2008
Posts: 369

There's no "right" way to do it. There are successful splitters using all kinds of different architectures: Pure hardware, Pure software, Mixed hardware+software.

Your major constraints are:
Section 4.2.2: Data Delay of 88us or less
Section 4.2.4: Break Shortening of 22us or less
Section 7.5: DUB Preamble shortening

Getting a splitter mostly right is easy. The challenge is in the error handling, especially in the presence of noise and/or line drivers that create an edge on the 485 wire when they are enabled or disabled.

The other thing to be aware of is that splitters often expose problems in other RDM equipment. Splitters have to be relatively strict about timing. But many controllers and responders are forgiving about timing. That means that you can take a controller and responder that work fine together, put a splitter inline between them, and they stop working. It looks like the splitter is causing the problem, but it's really a timing problem in one of the other devices. Unfortunately, it's usually the splitter manufacturer that gets the nasty phone call when this happens. Good error indicators and logging can be invaluable in troubleshooting problems like this.

Finally, make sure you consider the case where you have multiple responders on the 485 bus connected to the "input" of your splitter. A common mistake is to AND all of the downstream ports together during the discovery response period, and drive that AND Gate's output back to the controller. But this means you're always driving the input bus, and you'll collide with any other responders on the input segment that are also trying to respond.
ericthegeek is offline   Reply With Quote