View Single Post
Old September 13th, 2020   #6
Task Group Member
Join Date: Aug 2008
Posts: 369

Originally Posted by Andrew_Parlane View Post
So by an "simple" splitter what you mean is:
Starts in forward data flow mode, ignoring everything from the controller.
When it sees a falling edge from any command port it swaps to backward data flow.
When it next sees a falling edge from the responder port it switches back to forward data flow, and repeats.
A simple splitter sits with all ports in tri-state until it sees a falling edge on one port. It then starts driving the data from that port to the other ports until the source port goes idle for about 100us. Then it goes back to tristate and waits for another edge (which may come from the same port, or a different port). This technique works best if you have a delay line.

Standalone 485 splitters that do this have existed for decades, and work with many industrial protocols.

Originally Posted by Andrew_Parlane View Post
Then the edge detection should be filtered for glitches. For non-discovery responses this is fine because that (let's say 2us) filter eats into the break time, which is no issue because you can shorten the break by up to 22us. However in discovery responses that 2us filter eats into the start bit of the first preamble of the DUB response, which is potentially a problem. You're permitted to eat the first byte of that, but since we are not protocol aware we don't know what we are receiving.
As you say, the two rules are: You can shorten the break by 22us. And you can remove 0 or 1 byte from the discovery response.

But: Look at the DUB response preamble waveform: 0xFE is 00111111111 binary on the wire (if you include the start bit and 2 stop bits). With a scope, that looks like an 8 us low followed by a 36 us high.

If you shorten the first byte of the DUB response by 2us it will corrupt the preamble data byte. But if you shorten it by 8us to 36us it will effectively remove the entire first byte (you'll eliminate the first two zero bits, leaving behind some extra one bit that will look like an idle to the receiver).

Combine these two and you can shorten the beginning of a response by 8 to 22us without needing to know whether it's a DUB response (without a break) or a normal response (with a break).

The standard has all of the elements necessary to allow both protocol-aware, and non protocol-aware, inline devices. There are many different ways to put the pieces together and get a functional design. It does take a while to think it through (my first splitter made all of these mistakes and more...)
ericthegeek is offline   Reply With Quote