View Single Post
Old August 28th, 2020   #4
Task Group Member
Join Date: Aug 2008
Posts: 373

Originally Posted by Andrew_Parlane View Post
Unfortunately any transparent in-line device must be protocol aware right?
Not true at all! I know of 3 splitters out there that have no protocol awareness whatsoever, and I'm sure there are more. Two of those non-aware models are my favorite splitters. They are the "Keep It Simple" principle incarnate, and they tend to work well even in difficult installations. (One of those two favorites is one I built, so of course I think it's the best)

I've built both a fully protocol aware splitter, and a simple splitter. The simple one has nothing more than falling edge detector (with glitch filter of course) and a few 8 to 20us timers.

If you didn't find it already, make sure you've read this thread:
In my responses I touch on the architecture for a "simple" splitter.

Originally Posted by Andrew_Parlane View Post
I would also argue that the if the in-line device detects errors frequently enough to be annoying, then that would indicate a problem with your setup, either it's too prone to noise or something else on the bus is not compliant. If the in-line device were replaced by a normal responder in the same location it too would detect CRC errors at that point.
Spherical Cows, Frictionless Surfaces, and Error-Free communication lines. All three are nice theoretical abstractions that don't exist in the real word.

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.

Originally Posted by Andrew_Parlane View Post
So I don't think there's too much of an issue with invalid CRCs, I would propose that the in-line device shouldn't even check the CRC and just turn the bus around as normal and let the responder's deal with that. If they respond, then you're ready for them, if not, you revert back to forward data flow when you detect the start of a new break on the responder port.
To know when to turn the line around, you need to know when the request is finished. And to know when the request is finished you need to parse the length field. But to know if the length field is valid, you have to validate the checksum, otherwise you risk getting a garbage length field

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.

If you're going to use any data from the packet, you need to validate the checksum. And, because the RDM additive checksum is really weak (it's not a CRC), I recommend validating some other structural elements of the packet, such as the Length field matching the PDL+24. If the structural elements are wrong, treat it like a checksum error.

Originally Posted by Andrew_Parlane View Post
How often have you seen these 1us - 2us glitches? Could you comment on which fixtures do this? They may be useful to test with. Is it common enough a problem that this needs to be handled correctly? Or is it sufficiently rare that the problem can be ignored and listed as a know issue?
2-way radios and noisy VFD motor drivers are your opponent. It's more common to see glitches in the 100 to 500ns range than 1 to 2 us.
ericthegeek is offline   Reply With Quote