RS-485 Line Biasing
Finally tracked down the source of my RS-485 communication problems, manifested by slave responses containing spurious characters, dropped entirely, or garbled beyond recognition. Server commands were always fine; data was complete and checksummed correctly. The source of the problem came down to one fundamental issue, exacerbated by a silly wiring mistake.
I’m using the MAX3162 to create a full-duplex RS-485 communication channel between a PC and my Ifos project, but neglected to bias the receiver line. (Other chips, such as the MAX3535 or MAX13080, handle this automatically.) This had occurred to me—especially since every online RS-485 discussion eventually mentions it—so I added the fail-safe biasing resistors RUP and RDN. Unfortunately, I added them to the wrong line, biasing the transmitter instead of the receiver. Oops. When that didn’t work, I spent hours trying to fix a line impedance problem that wasn’t there, and in the process swapped DY and DZ. Oops.
When I switched slave tranceivers, the problem went away for a while, but only because the transmit portion was always enabled. THAT broke as soon as I tried to put two slaves on the bus, of course, since both thought they had the talking stick, but I had to actually do it before it really sank in. Switching back to a tri-state tranceiver reintroduced the communication problem because the bus would “float” when no slaves were transmitting, making it susceptible to random noise.
I’m sure anyone with a bit of RS-485 experience would have avoided the whole fiasco completely, but at least now I have a bit of RS-485 experience myself.