EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: LightBlue on July 16, 2015, 11:31:45 am
-
Hello all,
I've got an RS485 driver and receiver connected by 20m of Cat 6 ethernet cable. Both ends terminated with 120ohm (not quite matched I know). I used a pseudo-random bit stream to generate an eye diagram and check the quality of the signal at the receiver inputs and it all looks good. The driver end has "fail safe" resistors fitted. The data rate is ~1.6Mb/s. Please assume that the cable will be 120ohm unshielded twisted pair and it's non-negotiable.
I want to look at the effect of electrical noise. I don't have much test gear available so I coiled the 20m of cable and laid it on the bench and put a desk lamp in the middle. Carefully holding the light switch at the mid point makes it arc nicely and generates lots of noise. I don't know if it's the type of noise I want, but let's just pretend it is.
Now, when I'm transferring data and looking at the eye diagram (see attached), there is no differential noise. If you probe the differential lines individually you can see the common-mode noise, so I know it's there.
When the driver is disabled and the bus is idle, I can see the noise appear differentially (see the attached oscilloscope capture: Ch1 is the noise measured with a differential probe, Ch2 is the RS485 clock (for reference) and Ch3 is the output of the receiver).
My question is: Why is there differential noise when the driver is disabled and the bus is idle?
I've read Howard Johnson's books and Henry Ott's book and have an idea of what it might be. I think that common-mode noise is coupling into the "balanced" RS485 bus. The bus is not perfectly coupled and the noise bounces back and forth and some of it is converted to a differential current. The is what I see on the oscilloscope and what the causes the receiver to trigger. I assume that when the bus is active, the driver provides a low-impedance path to 0V for the common-mode noise but when the bus is inactive and the driver is disabled there is nowhere for the noise to go. If so, is one solution to split the termination resistor and fit a capacitor to 0V to provide common-mode termination (http://www.ti.com/lit/an/slla272b/slla272b.pdf (http://www.ti.com/lit/an/slla272b/slla272b.pdf), figure 5). Why don't the "fail safe" pull-up/down resistors help?
If you're firmware orientated, how do you deal with erroneous bits? I might need to know!
James
-
When the bus is idle, the common mode impedance is much higher, because only the fail safe resistors drive a voltage onto the cable. With the driver enabled it has a much lower impedance and therefore the cable has a low impedance conection thrue the driver and its power supply into gnd.
-
Try adding a high frequency terminator across the pair at both ends, by using a 120 ohm resistor with a series capacitor. The size of the cap will depend party on the data rate you need.
-
For testing, its probably worth using a more reproducible noise source that operates hands free. Try a couple of turns of wire in a coil of the same diameter as the coiled cable laid on top of it in series with an electromechanical buzzer.
You can also try dialling a mobile phone placed near the driver or receiver to see if you have a major RF susceptibility problem.
-
Thanks for your replies so far.
I've found a web page by Frank Rysanek (http://www.fccps.cz/download/adv/frr/RS485/RS485.html (http://www.fccps.cz/download/adv/frr/RS485/RS485.html)) that gives practical demonstrations of different types of termination, including common-mode.
I'm going to try and measure the common-mode impedance in the lab tomorrow and then terminate appropriately. Hopefully that should make a noticeable improvement.
James
-
I normally suggest the termination resistor be split in two, and the center tap be grounded with a 0.01uF cap or such. If the fail-safe resistors are equal, they will bias the line (open state) midway, which is also the average when transmitting, so there won't be any startup transients associated with the cap.
Actual CM impedance is likely in the 100-300 ohm range in real situations (depends widely on how the cable is routed, near what wires, over what chassis and at what distances), so this will tend to under-terminate it, however that might be helpful because it gives something for ferrite beads to work against.
Without any CM termination, the receiver (or both, when open-state) is completely at the mercy of what CM noise is present, and FBs will do nothing.
Needless to say(?), you want the CM range to be linear, no protection diodes conducting in that range. So that rules out unidirectional TVSs or clamp diodes, but bidirectional TVSs of 6-10V (i.e., at, or outside, the nominal CM range of RS-485) will help protect the receiver.
By the way, this is one reason why CM chokes are unsuitable for USB (no RX termination, diff or CM), and why USB must be absolutely 100% grounded and shielded.
Tim
-
I've measured the differential and common mode impedances as described here: http://www.fccps.cz/download/adv/frr/RS485/RS485.html (http://www.fccps.cz/download/adv/frr/RS485/RS485.html). The differential impedance was 116ohm and the common-mode impedance was 139ohm.
I terminated both ends of the cable with a T of two 56ohm resistors and a 110ohm resistor to 0V via a 4n7 capacitor (I had a reel on the bench).
The first oscilloscope trace is without common-mode termination: the receiver output glitched multiple times every time I flicked the light switch.
The second trace is with common-mode termination: the differential noise (Ch1) still looks really bad but the it took 5 minutes of switching the light on and off to make the receiver output glitch and then it was only one small pulse.
I was disappointed because the common-mode termination didn't appear to reduce the differential noise but since the receiver output doesn't trigger I can only assume that I'm not probing the circuit correctly.
I think my problem as solved and I will implement common-mode termination but I would like to understand why the oscilloscope showed differential noise in both cases - I don't like leaving things unexplained!
James
-
If you're firmware orientated, how do you deal with erroneous bits? I might need to know!
You can,t you handle it at the protocol level using preamble postamble and crc or other form of checksum over the entire message.
Bitfaults and the whole message is discarded.
Therefore critical messages should always be acknowledged by the receiver.
-
I know this is a silly question, but you seem to be using three traces, which suggests you're not using a differential probe... how are you probing the differential data pair?
-
Clip a few turns of ferrite bead on there, and try to tie up the lamp and its cord real good with your data cable. I'll bet you'll have an even harder time finding glitches.. :)
-
I know this is a silly question, but you seem to be using three traces, which suggests you're not using a differential probe... how are you probing the differential data pair?
Ch1 uses a differential scope probe connected across the RS485 data lines (A and B).
Ch2 and Ch3 use single-ended oscilloscope probes. Ch3 is the single-ended logic output from the receiver chip. Ch2 shows the RS485 clock and is useful for comparing the length and frequency of glitches to real data.
-
ok, that makes sense....
I was worried that you may have inadvertently pulled one side of the pair 'off balance' !
you obviously have a good idea of what you're doing.
How about decoupling caps near the transceiver chips?