View Single Post
Old August 28th, 2020   #3
Junior Member
Join Date: Aug 2020
Posts: 4

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,

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?
Andrew_Parlane is offline   Reply With Quote