But are not the pull up and pull down resistors a form of damping anyway?
Look at the total damping needed for noise and activity seperatly for each specific design (Length and baud rate)
Put just enough pull up pull down for noise reasons. Then add Ac and/or DC shunting to as needed for baud rate activity and length as needed. Layer on my other idea for further power savings
Can have longer time constant turn off to turn on for reletively short off times betweent bursts of data. This will still provide noise damping while draining thru resistor but will be bipassed with a diode (and a smaller resistor)during turn on, or just two different shunt and series resistors alone.
How about a depletion mode fet with a charge pump to turn off the fet when activity (Data-AC Power)Is present. Idealy, within a few cycles of data would be ideal, the the pump power goes to zero. The highest data rate o1o1o1o could be a termination turn on method, then the slower data rates would sufice to keep the pump alive.
Termination is the cause of a lot of problems, and the solution to some as well.
For the purpose of eliminating reflections, Brian nailed it, you only need termination if the product of the cable length and the bit length will cause reflections to land in the middle of a bit (where a UART actually samples). This is very rarely the case with the speeds typical to 485.
There is a second element of noise reduction. This is true, but a bit overplayed in my opinion. The termination resistor creates a low impedance load for noise (which has a high impedance source relative to our desired signal). Makes things look good on a scope in those cases. But remember this is a differential receiver attached to a twisted pair. That common mode noise is eliminated by the differential receiver.
The nasty side effect of termination is that it messes up the biasing. Since the driver goes to a high impedance state between transmissions, the 485 network is floating. For that reason, most designs have pull-up and pull-down resistors on the receiver to pull the line to a known voltage between transmissions. Adding a DC termination resistor means you have to review the biasing of your network - something I rarely see people do in practice. Jordan's recommendation above of using an AC termination (capacitor and resistor combo) addresses this well as long as the values are chosen wisely with respect to number of nodes, cable load and bit rate.
Concerning termination: a good rule of thumb to follow is that if the propagation delay of the data line is less than one bit width, do not terminate. There is a big calculation that you can go through to figure this out, but I found that in most cases termination just complicates things.
Termination is required for some low baud rate RS-485 applications. If the network wires are not terminated and all drivers are off, the receivers may see data caused by electrical noise. It is much easier for noise to cause problems on the RS-485 network wires when nothing is driving them. A terminator will pull the network wires to known voltages when all drivers are off. A small deviation from the undriven terminator voltages (caused by electrical noise) will not cause random data at the receivers.
I agree that termination is not necessary with low bitrates ( less or equal 19.200) and short wires, but it helps in noisy ambient. The main function of termination is damping the reflections caused by different impedances.
The termination does not need to consume much energy - one may use a dynamic termination: a capacitor in series with the resistor, working perfect for AC signals.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.