Questions on In Line Devices

[Andrew_Parlane]

Thanks for the reply. You raise some interesting points. Glitches are something I hadn't thought much about, but I can see how they could be an issue. I think I can modify my design to deal with them correctly without too much effort.

Having built a fully protocol-aware transparent inline device, my advice is: Don't try to build a fully protocol-aware transparent inline device. The error handling will drive you nuts!

Unfortunately any transparent in-line device must be protocol aware right? You must at least check for the RDM start code and the length field, so that you know when to turn the bus around, you must also be able to tell if it's a discovery packet or not so you can follow the rules for discovery vs non-discovery turnarounds.

The "partial response" problem you mention here is one problem. The other is what to do when there's a checksum error in a request or response. It may look like a checksum error to you, but if the error is due to noise or analog effects on the 485 line it could still look perfectly fine to other devices.

A CRC error in a response shouldn't matter to you as an in-line device. By the time you've detected it, the data has already passed through and there's nothing you could do even if you wanted to. So I don't think there's any point even checking that, unless you want to do so for statistic generation purposes.


A CRC error in a request is interesting, although only in the case where the in-line device sees it as an error but the actual responders don't. Since theoretically you could interpret it as non-discovery request, whereas it's actually a discovery request, however I feel that's pretty unlikely, since you'd need to just happen to corrupt the 3 bytes of CC and PID.


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.



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.

You can't just look for a falling edge. You'll need a glitch filter to deal with noise and 485 line driver enable/disable transients.

The shortest valid low you should ever see on the 485 line is 4us. It's common to see glitches that are a few hundred nanoseconds long. Most 16x oversampling UARTs won't see them, but a timer or interrupt based edge detector will trigger on them.

If you see any events lows that are <1us you should filter them out and ignore them.

Agreed, I should be able to filter anything shorter than ~900ns without issues, and I think I have a software scheme to deal with anything up to about 2us, if there are glitches longer than that, then there's not much I can do.

There's no right answer to this question. If you have a good glitch filter, you can usually disable the other ports. However, there are some poorly behaved responders that will put a 1 to 2us glitch on the line even even when they are not responding. If you treat this as the start of a response, then you risk cutting off the port that has the real responder.

But, if you leave the other ports enabled and AND all of them together you risk allowing a glitch through from another branch that will corrupt an otherwise valid response.

However, some responders have a 1 to 2 ms interrupt that can trigger at any time during the response, including during a Break+MAB. Thus, it's best not to be too strict about enforcing the response's Break+MAB.

OK, that's good to know.


Thanks again,
Andrew

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?

[ericthegeek]

Originally Posted by Andrew_Parlane

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:
https://www.rdmprotocol.org/forums/s...ead.php?t=1248
In my responses I touch on the architecture for a "simple" splitter.

Originally Posted by Andrew_Parlane

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

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

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.