EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: jwhitmore on April 24, 2016, 08:04:58 pm
-
Long story short I've been called in on a project where they were having reliability problems with a network of RS485 sensors. I'm primarily SW but looked at their network topology and it was a mixture of a bus and a few stars in parallel. I told them I didn't think you could do that and checked on Internet and NO Rs485 is bus only. So they have to re-wire their sensors.
But now I'm thinking as a SW head that there must be an analyser of some description, preferably hand held, that you could connect and test the line and would tell you that there was too much noise or echo on the line? I'm finding protocol analysers but not electrical properties of the twisted pair.
Does such a tool exist? and if so what should I be searching for?
-
RS485 is just an electrical interface. You can run all kinds of digital protocols over it so you won't find an RS485 analyser. You need to figure out what kind of protocol the sensors use first and then analyse. You can have all kinds of electrical problems though. One of them is too much difference in ground level between the nodes; even though RS485 is a differential bus the ground level between the devices needs to be the same. RS485 is basically a 3 wire bus (ground, A and B). Another source of problems is that the bus is loaded to heavily (can be check using an oscilloscope), the bus is too long for the transmission speed, there are too many reflections (you have to run a very long bus at very high speed to get into transmission line problem territory) and/or you can have message collissions.
-
Hi
Just like Ethernet, there are several different parts to RS485. Ethernet has them all named out and defined as "layers". While the same principle applies, the serial com guys never seemed to get around to strict definitions of what is what. So, keeping layers out of the discussion (but understanding that's what is being looked at):
1) You have basic twisted pair wires. They have nice properties like leakage to ground, loss vs frequency and shorts between cables. You don't mention how fast you are going. If it's 50 megabits, you need cable that will handle that.
2) You have IC's that get the data on and off the wire. They have speed ratings. They also have ratings in terms of maximum voltage between the pairs and local ground. Some are happy at 60V, some are challenged past 10V. If this is a "wide area" system, big deltas are a reality.
3) Eventually you get to the software. When most people refer to RS485 they are talking about a half duplex protocol. One guy talks and everybody else listens. If two guys try to talk, you get a mess. The network topology (wires), and drivers, and firmware will dictate how fast you can go from device 1 talking to device 2 talking.
So testing:
For the basic cables, conventional cable test gear will do the trick. There is nothing really weird about RS-485 cabling.
Testing the second part (the drivers) is something you can do. I'd suggest that a "paper test" checking out the specs is a better use of time. You can then go back and measure ground potential (multimeter time) to see how bad things are compared to the spec.
The final part is software. Well, no, it's not *all* software. The simple answer here is a very normal receiver on the bus to be sure it clears in time. For more details, a scope with a *good* differential input is the next step up.
Lots of fun !!
Bob
-
The RS485 is what I'd call the physical layer all the sensors are running MODBUS half duplex at either 9600 or 19k2 (have to check but certainly no faster then 19k2 at present) The sensors are all under water so measurements at nodes might be difficult, as even if they're pulled out of water they're pretty well sealed.
My understanding of RS485 is that you can't run a Star topology because of echo on the line. So I was thinking if I sent a MODBUS frame to a none existent node, say address 0xB4, none of the sensors would respond, but you might with a scope be able to see the echo. My problem with a scope, as a dumb SW head, would be that I could not quantify the echo and decide if it was at an acceptable level. That's why I'd thought that there might be a test unit.
I know nothing about DSL broadband but would an engineer not have test equipment to test what you'll be able to squeeze out of the line, given it's inherent physical properties?
-
The RS485 is what I'd call the physical layer all the sensors are running MODBUS half duplex at either 9600 or 19k2 (have to check but certainly no faster then 19k2 at present) The sensors are all under water so measurements at nodes might be difficult, as even if they're pulled out of water they're pretty well sealed.
My understanding of RS485 is that you can't run a Star topology because of echo on the line. So I was thinking if I sent a MODBUS frame to a none existent node, say address 0xB4, none of the sensors would respond, but you might with a scope be able to see the echo. My problem with a scope, as a dumb SW head, would be that I could not quantify the echo and decide if it was at an acceptable level. That's why I'd thought that there might be a test unit.
I know nothing about DSL broadband but would an engineer not have test equipment to test what you'll be able to squeeze out of the line, given it's inherent physical properties?
Hi
A couple of key (and un-mentioned by me) issues with RS-485 at the wire level:
The ends of the bus need to be terminated. The nodes not at the end of the bus should not have termination resistors on them. The value of those resistors shows up as some absolute value in the IC data sheets. In the real world it has very little to do with the IC's and a whole lot to do with the cable being used. The purpose of the resistors is to terminate the twisted pair in it's characteristic impedance. A wonderful instrument called a TDR is often used to see how well they do this. The gotcha is that the TDR *assumes* a known impedance for the twisted pair. That's a cable data sheet number.
So, to answer your question, yes you can blast the cable and look for an echo. The proper gear is a TDR, If you do it with a node and a differential scope, you are building a TDR. Since you are running very slow speeds, the scope approach may be best.
Bob
-
Uncle_bob you're a star. Thanks a million for all that. Searching for TDR is way more fruitful then anything else I've tried. Now I know the technical language. Man those items are pricey. Think I'll be learning how to use my scope ;-)
-
My problem with a scope, as a dumb SW head, would be that I could not quantify the echo and decide if it was at an acceptable level. That's why I'd thought that there might be a test unit.
I know nothing about DSL broadband but would an engineer not have test equipment to test what you'll be able to squeeze out of the line, given it's inherent physical properties?
Bus health on the Fluke 125 would be a good start.
-
Hi
Ok, so what are you likely to run into playing with a TDR:
1) The signal travels about 1 meter (or 1 yard) every 5 ns. Don't get to crazy on precision there without data on the specific cable.
2) One bit time at 19.2 K baud is about 52 us.
3) A serial UART *should* tolerate 10 to 20% distortion on the signal.
4) Cable junctions can create "bump". Going from 120 ohm twisted pair to 50 ohm coax is one example of this.
5) Multiple reflections off of a discontinuity are the norm.
So, if you take the distortion tolerance to be 10 us, an echo to a point 1 km away ( 5 us out, 5 us back) would be at a 20% distortion timing allowance. The second echo off that "bump" would be outside the timing allowance. Is either one high enough level to create an error? That's why they make test gear.
====
Getting back to the practical side:
There will always be errors on a wide area bus. Bit error rates are one way to characterize this. A very normal thing to do is to establish a maximum allowed error rate. Once that is defined, the software is tailored to give appropriate performance with that error level present. A BERT (bit error rate tester) is the gizmo you use to validate this sort of approach.
Lots of fun.
Bob
-
What is the tolerance for common-mode voltage offset in separate stations on an RS485 network? They're supposed to be grounded together, but if the ground is carrying current there will be a voltage offset. I spent a while struggling with a ground lifting issue on a toy ROV application before deciding that the safest way forward was to isolate the RS485 transceivers via a DC-DC converter and opto couplers. A bit of a PITA for something supposed to be simple.
Edit: and how do you measure the actual common-mode voltage offset if you only have access to the bus in a few places?
-
What is the tolerance for common-mode voltage offset in separate stations on an RS485 network? They're supposed to be grounded together, but if the ground is carrying current there will be a voltage offset. I spent a while struggling with a ground lifting issue on a toy ROV application before deciding that the safest way forward was to isolate the RS485 transceivers via a DC-DC converter and opto couplers. A bit of a PITA for something supposed to be simple.
Edit: and how do you measure the actual common-mode voltage offset if you only have access to the bus in a few places?
Hi
With modern RS-485 chips, they design a pretty high level of input voltage tolerance into the chip its self. You can get IC's that are happy with a 50V common mode voltage. The approach is to ground each node locally and allow the IC's to handle any offset. That way you don't have all the isolation goop to deal with.
A pretty typical approach to common mode checks is to run a "spare pair" down the cable. You generally run multiple spares to allow for future problems with the cable. That is a carry over from wire line telephone practice. Since you have a pair sitting there, you ground it at one node and then wander around with your (high impedance) voltmeter. A ground to pair check lets you know how far off that node is. In a well though out system this is part of the install process. The gotcha is that the bus may go in before the heavy equipment is fired up. It all measures out fine at install and then goes nuts when the giant whatzit pulls a billion amps at turn on.
The same "spare pair" approach could be extended (with relays maybe) to multiple nodes and remote control. That sounds a bit exotic and (hopefully) un-needed. Of course, if you do have major power loads at each of you nodes, maybe you do need a voltage monitoring setup. An awful lot of this gets into systems design and not just RS-485 ...
Lots of Fun
Bob
-
Long story short I've been called in on a project where they were having reliability problems with a network of RS485 sensors. I'm primarily SW but looked at their network topology and it was a mixture of a bus and a few stars in parallel. I told them I didn't think you could do that and checked on Internet and NO Rs485 is bus only. So they have to re-wire their sensors.
Lots of stubs caused by star wiring is likely to cause problems. Looking at the line with a scope will give an indication of signal quality, though an RS485 receiver will get good data out of a fairly horrible looking bus waveform.