View Single Post
Old September 8th, 2020   #5
Junior Member
Join Date: Aug 2020
Posts: 4

Sorry for the slow reply, I didn't get a chance to look at this last week, and wanted to make sure I understood everything properly before responding.

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.

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. Taking 2us out of a start bit may well cause issues with the controller, and cause it to think there was a collision, when in fact there was none. One fix would be to have a few us delay on the bus, so that when you turn the bus around you don't drop anything, unfortunately our hardware doesn't have support for that.

The other issue I see with this approach is that when in forward data flow with the controller transmitting, that data gets forwarded out of the command ports, so if you are also monitoring the command ports for Rx, you'll see the data you just forwarded. So you have to determine what's a falling edge from an actual responder and not forwarded data.

Another problem is that inline devices often expose problems with other RDM devices. Most controllers only listen when they are expecting a response, so if a responder yacks when it shouldn't the controller won't hear it and it doesn't matter. Same with responders, if they get a bunch of garbage, they can just ignore it and wait for a new break. But inline devices have to watch everything that's happening, and make decisions on that activity.

The point you made in the linked thread about the splitter manufacturer being blamed for badly behaved responders is a very good point, and I liked your comment about disabling that port and informing the controller about why.

Consider this scenario: Your UART mis-frames on some noise following the request's break, so you read the length shifted by 3 bits. The responder doesn't mis-frame and sees a valid 30 byte request, so it starts responding with a long response. In the meantime, you're waiting for 240 bytes from the responder, but you never get them, so you timeout after a few ms and return to forward flow. The controller also times out because you're in forward flow and it can't hear the responder. So the controllers starts sending more data. You now have a collision on the downstream segment, and probably some flashing lights. It's even worse if the controller sends another request immediately. You see that new request, and turn around based on the activity from the responder that is still sending its long response to the previous request.

What's the alternative to this?

In your scenario, the splitter is in forward data flow waiting for a bunch of data from the controller that's not going to arrive. The responder sends a reply, but that gets ignored because we're in forwards data flow. At some point the controller times out and sends another break and the splitter resets it's state machine and starts the new packet. The responder may or may not be transmitting at this point, which could cause collisions on that command port.

With CRC checking in the splitter we instead have: If the splitter does exactly the same as before until it gets to the CRC, it checks that and finds it's wrong so does nothing and doesn't turn around, waiting for the next frame from the controller. The responder doesn't see the CRC error and starts responding, the data is ignored because we're in forwards data flow. The controller times out, sends another frame, collisions may occur on the command port.

The behaviour is exactly the same whether or not you check the CRC in that case.

The opposite case is similar, if we miss read the length as shorter than actual. In this case if the splitter doesn't check the CRC then we turn around too early and drop part of the request. The responder doesn't see a valid packet and drops it, at some point the splitter times out and goes back to forward data flow (hopefully before the controller sends another frame).

The other potential issues is if the splitter sees something as a DUB when actually it's non-discovery or vice versa.

If the splitter thinks it's a DUB and therefore follows the discovery turn around rules from section, but actually it's not a discovery request. Then we run the risk of cutting off half of the responder's reply or in the case of no reply, potentially switching back to forward data flow in the middle of the controllers next request.

That scenario seems unlikely because you'd have to error on the PID and the CC, but it's easy enough to check that CRC and so I guess we may as well.

You've given me plenty to think about,
Andrew_Parlane is offline   Reply With Quote