Avoiding RS485 bus contention

Go To Last Post
50 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have some devices that use rs485 to communicate via half duplex. I wrote my own serial protocol that listens for an address and has a couple ways to check for valid packets (stop bit, length, cs, etc). It works all fine and dandy, but I am wondering how to avoid a situation where multiple devices try to tx at the same time.

Right now, when my slave devices all receive power, they will transmit a 'status' update to the master telling it that they exist on the bus. I also have a timer running on each device that periodically transmits the status after initial power-up to act as a 'keep alive' so the master knows that they are still powered and active. The problem is that if all the devices power on at the same time, there will be a massive bus conflict. There will also be more conflicts if the timer of the slaves are synced and they try to transmit their keep-alive at the same time. I have a fault pin on the RS485 chip that can generate an interrupt when a conflict exists, but I have no idea how I should handle the conflict.

Are there any rules of thumb, or standards that people use to solve this?

Chris

Chief Tinkerer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The old standard is to precede any slave transmission initiative by a random period of time. Any transmission conflict (detected by hardware or by lack of answer) must be followed by a retransmission (after the same random time interval)

Look how the old 10BASE2/10BASE5 Ethernet technology implements collision management.

Dor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

my approach : the master send a "global request", each unit, when detect this packet, send his answer (if any) after a delay = 10 + (4 x his_address)(msec).Te bigger address (225 in my network) answer after ~1sec.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ethernet uses 'binary exponential backoff'. When collision is detected, both nodes generate a random number from 0 to 1 and retry. If collision detected, generate random wait from 0 to 2 tofs. (Tof is the time for the pulse to propaget down to the end of the segment. 10usec I think). They keep backing off up to 10 bits. (delay of 1024 x 10usec max)

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use a 'polling' (request and reply) technique.
ie. the master is the only device that initiates comms with the slaves.
The slaves send stuff to the master only when explicitly addressed.
A timeout timer in the master and slaves is used to detect loss of comms.

Like all techniques, there are advantages and disadvantages.
Advantages :
No need to worry about bus contention and retries.
Fairly quick to discover if there is a faulty slave or link.
Slaves can detect if the master has failed.

Disadvantages :
If there many slaves it could take a long time to talk to them all.
Extra CPU load on the master to do the comms and process the replies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
my approach : the master send a "global request", each unit, when detect this packet, send his answer (if any) after a delay = 10 + (4 x his_address)(msec).Te bigger address (225 in my network) answer after ~1sec.

I like this global request sent by master.
I would add a "synch packet" to the protocol in which any slave could answer whatever they want to send after a similar formula. But the time to answer could be even half a byte times its address.
The idea is, it will reply the slave which has something to say, not all of them. This is good when a slave is just connected. The lower address will have higher priority.
In other words, each slave will have the opportunity to send a sort of interrupt to the master.
Of course, the master will still have its way to individually address the slaves.
George.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If all the slaves have the recieve on, they are all abundantly aware that the packet they have started receiving is not addresses to them after they have received the first couple of bytes. So you cant start timing the address based delay to start sending the response until the last byte of the packet being received is done.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Agree with you. When I said fraction of byte, I meant the time after the master sends all bytes. Then the slaves decode it and realize it is a synch packet. Then after a delay, (which can be a fraction of a byte) the first slave as a window to start sending. If it does not, then the second has its window after two time intervals and so on. IF one of the slave sends, then it is up to the master what's next.
George.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@ Banoli:

Why did you revive this 5 year old thread ?

 

But I couln't help replying.

This circuit is wrong in soo many ways...

 

Your circuit also looks .... unrealistic.

Adding 4 different IC's and a bunch of passive's to try to detect collisions. Really?

 

I also believe the circuit does not work at all. have you tested it?

It does not work because your 20 Ohm protection resistors filter out the collisions on the RS485 bus.

(Even more if the other side also has those resistors)

So even if there is a collision the RS485 transceiver does not see it.

 

As a matter of fact even without the resistors the cable resistance itself is often so high you can't detect collisions reliably.

Trying to do this on a RS485 bus is just silly anyway.

If you really want this then use CAN or something similar.

 

75176 Really? I thought those all burnt out 20 years ago.

 

Those 10k resistors (on all node's ? ) load the bus too much. Not a bright idea.

 

I'm not really sure how much those 20 Ohm resistors attenuate the drivers, but you should put the transorbs between the resistors and the transceivers, to lower the amont of power they have to disspate during a fault.

 

A common fault is to touch the A/B lines to hard power supply somewere (for example 24V).

In that case your transorbs will just vaporize if they are on the connector side of the bus.

 

Another Idea:

Replace the 20 Ohm transistors with PPTC's. They have a few ohm resistance when cold (helps with ESD) and they limit the fault current during The fault condition described above.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Sure looks like one to me as well.

 

JIm

 

EDIT:  Crap, I deleted his post(s).  OOPS

 

Paulvdh wrote:
75176 Really? I thought those all burnt out 20 years ago.

 

Nope, they are alive and well....I still use them on occasion too...old timer nostalgia I guess.

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Last Edited: Mon. Aug 28, 2017 - 12:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of the  ways of avoiding bus contention (or, rather, detecting it after it has happened) is to read back what you transmit. If the two don't match, then someone else is also transmitting.  The other device should detect that event if it also uses read-back. If there is a collision, then wait a random time, listen for activity, then try transmitting again. The two devices will wait different times and the second one to try to retransmit will detect the activity of the one that is transmitting and should hold off until the channel appears clear. This is called CDMA, "carrier detect multiple access". Note that this "random wait" does not have to be rigorously random - a sequential lookup table is quite sufficient.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Mon. Aug 28, 2017 - 01:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
One of the ways of avoiding bus contention

As I said before (#9), this does not work on RS485. When 2 drivers are fighting each other there is usually enough cable resisance between them so that they both read back the data they are sending themself. You will need CAN or similar for this to work.

 

At some point I thought of connecting TxD to the Driver Enable and the data to GND (or Vcc) to the Data input of the RS485 driver.

This would create an "active" and a "passive" state Just as with CAN.

The resistors between A and B also need a change then. One connects A to Vcc, the other connects B to GND.

Never implemented it though.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At some point I thought of connecting TxD to the Driver Enable and the data to GND (or Vcc) to the Data input of the RS485 driver.

That's been done.  I recall seeing it on Freaks a few years ago.  Can't find it now.  However, you still have a 120 ohm terminal resistor between A and B, but there are added resistors to Vcc/Gnd as you say to form a pull-apart network.  In effect, it's the differential equivalent of an open-collector bus.  Driven low (A < B), pulled high (A > B).  This facilitates collision detection as discussed above.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
As I said before (#9), this does not work on RS485. When 2 drivers are fighting each other there is usually enough cable resisance between them so that they both read back the data they are sending themself.

Really?  So all the proponents here over the years that read-back what they are sending to detect collisions are all just fooling themselves?

 

I guess then I'm glad I have been bivouacked in the other camp, with TE and /RE tied together.

 

Paulvdh wrote:
75176 Really? I thought those all burnt out 20 years ago.

If a vanilla "classic" 75176, one needs to have lots of power all around. 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@theusch

Reading back your own data on a RS485 network  is probably about 80% useless.

And the whole collision detection thing is overrated anyway.

Once a collision is detected you are to late.

Collision avoidance is a lot smarter.

In my RS485 homework (Which I call "Mumarnet") I use a 115k2 baudrate.

When a node wants to send something it listens to the bus for 80us (Bit longer then a byte) and when it determines the bus is free it takes posession of the bus and starts sending after 3  CPU cycles.

so you have a <1us window in which multiple nodes could try to send and generate collisions.

 

This works very good. I once did a test with half a million packets sent in 15 minutes, on a bus with 5 or 6 nodes.

I had 3 lost packets.

And you should always have provisions for chekcing damaged packages (CRC) & complete packet loss (timout, resend, etc) on a robust RS485 network.

 

Main disadvantage of the not sogood & old 75176 is that they tend to let out the smoke a lot faster then newer ones.

But they are cheap, maybe so cheap that they are still competivie even afer adding extra protection hardware.

The silly thing is, if you look at mouser / digikey / octopart / whatever there are several hundreds (or so) different RS485 drivers, all pin compatible with the 75176.

How many variations can an engineer come up with?

 

@joeymorin.

Yep, you say it with nicer words than I did.

Keeping the termination resistors between A and B or splitting them to Vcc & GND is probably both possible.

But I just realised that if you use the classical way, with 2 resistors to pull A and B apart with a few 100mV offset. Then you can use a window comparator to check if the bus is occupied.

Not sure if it's worth the extra hardware though.

 

LOL,

the post which revived this 5 year old thread has been deleted :)

Kudos to Jim.

Shall we let it go back to sleep, or keep on rambling?

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Mon. Aug 28, 2017 - 08:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
And you should always have provisions for ...

Well, yeah.  But other than saying

Paulvdh wrote:
Reading back your own data on a RS485 network is probably about 80% useless. And the whole collision detection thing is overrated anyway. Once a collision is detected you are to late.

...you didn't really address

theusch wrote:
So all the proponents here over the years that read-back what they are sending to detect collisions are all just fooling themselves? I guess then I'm glad I have been bivouacked in the other camp, with TE and /RE tied together.

 

I guess one could read it as agreement with "fooling themselves".

 

Re "too late" -- wait a minute; hold on.  You go on to say

Paulvdh wrote:
And you should always have provisions for...

 

So, too late for what?  In your example you have collisions, and recover.

 

Paulvdh wrote:
When a node wants to send something it listens to the bus for 80us...

In a prior millennium when I was learning Ethernet, it used "programmable backoff", implemented in various manners. (Doesn't CAN work that way as well?)

 

Typically my RS485 setups are master-slaves.  Theoretically, there is only a problem when a node gets stuck with TE on.  That's what watchdogs are for...

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When a node wants to send something it listens to the bus for 80us (Bit longer then a byte) and when it determines the bus is free it takes posession of the bus and starts sending after 3  CPU cycles.

Great, and how do you know if there is a short on the line? Silence on the bus could mean just that.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the bus is shorted, then all bets are off.
@paulvdh- in the early 80's there was a 485networking system for Kaypro cp/m machines that used comparators. It was the first time i saw 75176.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Great, and how do you know if there is a short on the line? Silence on the bus could mean just that.

IIRC, js, you are one of those that listens to what you send.  If so, I'm glad you saw the thread.  Do you have any comments on

Paulvdh wrote:
As I said before (#9), this does not work on RS485. When 2 drivers are fighting each other there is usually enough cable resisance between them so that they both read back the data they are sending themself.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I listen to what I send only because when I started to use RS485 (a long time ago) I was told that it was a way to check for collisions (very unlikely on a single master system) or shorted cables or shorted receivers.

 

I used to work on Emergency Warning and Evacuation systems, the RS485 would run in "fire proof" MIMS cable, and the resistance would be a lot less that say CAT5 cable, so maybe Paul is correct in what he says, never checked myself. I used to have a programmer to do all the dirty C work.....

 

Then you have systems where the hardware has resistors in series with the line (2 x 10R-22R??) in this case even with a shorted line it is possible that one could read back whatever is sent out.

 

RS485 receivers may just still work with about 200mV signal but I still think that reading back what one sends is good way to check for line shorts.

 

But hey, I'm a pensioner now...... cheeky

 

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
LOL, the post which revived this 5 year old thread has been deleted :) Kudos to Jim.

That was an accident! angry

 

Paulvdh wrote:
As a matter of fact even without the resistors the cable resistance itself is often so high you can't detect collisions reliably.

Cannot disagree with you more on that.  IF the resistance of the wire is that high, you are using the wrong wire.  Even 1000 feet of Cat5 you can tell if the other end is shorted.

 

 

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim my point above about the board having 2 x 10-22 Ohms resistor in series with the line and chip would mean that the receiver would see at least 20-44R in series with the short, so you COULD send data out to a shorted line OUTSIDE the board but the chip could still read a valid data.

 

So it would depend on the design of the RS485 circuits, if no resistors are used as newer chips no longer require them then a short could be detected, if using the resistors then it may not.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@js,

I am not disagreeing with you.  I disagree with Paul's comment regarding cable resistance.

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Jim.

I hope you do agree that if 2 RS485 drivers are enabled at the same time you will not have proper voltage levels on the cable, regardless of cable quality and such.

In my book that means that if you know the voltage levels are not proper, you should not rely ( or even try) to read them (i.e, collision detection on a RS485 bus).

 

I wonder why you disagree, sure, you can measure a short in a CAT5 cable with a dmm, even if it is a few hundred meters away but that is not the point here. So I ask, what do you mean with

jgmdesign wrote:
Even 1000 feet of Cat5 you can tell if the other end is shorted.
I certainly can't tell by just lookin at the cable if there is a short that far away.

 

When I was designing my first RS485 network I did a bunch of tests and I was unpleasantly suprised that collisions could not be detected reliably, and I gave up on trying to do that pretty quick.

But those tests were 10+ years ago and the details are a bit fuzzy.

 

https://en.wikipedia.org/wiki/Ca...

Cat5 has a DC loop resistance (single wire) of up to 0.188 Ohm/m

So if you take a relatively short piece of cable of 10m ( is that 33feet ) that's 3.76 Ohm. (there and back again).

 

The good old SN75176 has an output current of 60mA max (short circuit current max 250mA) and has an input hysteresis voltage of 50mV.

So even if there is a dead short 10 meters down the cable it can easily generate a voltage of 60mA * 3.76 Ohm = 135mV at the place the signal is inserted in the cable.

(Not counting contact resistance in connectos, pcb traces or the chip bondwires, whatever those resistances may be).

RS485 receivers are pretty good at measuring small input voltage differentials.

 

And if you add a 2nd driver to the equasion (Different brand/model etc) it gets ... complicated / fuzzy / ... interesting?

 

So if you still disagree, please do a test yourself on a decent run of cable. Short it at one end and see if you can detect with the same RS485 transceiver that is driving the cable.

And don't forget to put a proper osciloscope on the cable. If you get bit errors it is probably due to reflections.

Damn. keep the test simple. Just put a RS485 transceiver on a breadboard, no uC required, Measure voltage differential on the cable with a DMM, or even only the receiver output with a led.

With DC you don't have to worry about reflections either and no need to pull out the 'scope.

 

And I think adding 100mA PPTC's to the A & B lines on each transceiver is a pretty good idea (First saw in on youtube / MikesElectricStuff) Just measured some and they have a DC resistance of  2.2 Ohms (cold) and even that is enough to make collison detection useless on RS485.

(Would it be fair to say there are 4 of them in series during a collision ?)

 

Would those 2.2Ohm PPTC's have a significant effect on insertion loss?

----

A bit later...

Just realised (again?) that collision avoidance does not work properly with high bit rates and long cables.

In that situation signal levels wil also be added and subracted all over the cable during a colision, but I'm working with a gentle 115k2 and about 20m of cable only.

A RS485 tansceiver can probably detect that

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Wed. Aug 30, 2017 - 02:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hope you do agree that if 2 RS485 drivers are enabled at the same time you will not have proper voltage levels on the cable,.......you should not rely ( or even try) to read them (i.e, collision detection on a RS485 bus).

But that's the point of reading back what you sent, if this condition exists and the data is read back incorrectly then you know that something is wrong.

 

However I do agree that if you have the following circuit (widely used by many with up to 22R resistors):

 

 

then a short on the line would be buffered by, in this case, R15 and R16, and if the resistors are 22R or higher then that's the load the driver will see and most likely (or not) will read back the correct data even with a short.

 

However using more expensive drivers like a MAX13080E or similar that are "±15kV ESD-Protected, Fail-Safe, Hot-Swap, " etc. that do not require the resistors or Transorbs for protection the short will kill the signal or severely mess it up so that by reading back the data on can see that something is wrong.

 

But hey, whatever one if comfortable with. wink
 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 I said that if the resistance of the wire is that high you are using the wrong wire to begin with.  And I also did not say you can detect a short with the driver chip either.

 

Paulvdh wrote:
jgmdesign wrote: Even 1000 feet of Cat5 you can tell if the other end is shorted.

 

I certainly can't tell by just lookin at the cable if there is a short that far away.

 

Where did I say that you/I could.  Thats why one should carry a DMM/AMM with them.

 

I was calling out the resistance of the wire being used, not collision detection itself...should have pruned off the last part of what I quoted.  I still stand by my statement that if the resistance of the wire is extremely high you are using the wrong wire type for the task/length you are communicating over.

 

Back to the issue of Collision detection....

 

Since Paul put up that detailed post regarding wire resistance and collision detection I elected to try one of his tests in a very simplistic approach as there is not much bench space and grabbed a few vendors differential transceivers and a breadboard, and 42 metres of Cat5e.  The cat5 measured 8 ohms with 120 ohm resistors at each end with the far side shorted together.

 

The setup is pretty crude, but it's accurate.  /RE is grounded, DE is tied to VCC.  10k pullup on RO, 10k pull down on DI.  Scope on RO

I do this with an SN7515, a MAX485 as thats all I have in 5v laying around within easy reach.

 

With nothing connected to the A and B pins I tie DI to +5 and RO goes to logic 1, disconnect DI from VCC and RO goes back to logic low.

 

Connect the 'shorted' cable to the A and B pins and repeat the Vcc-Ground-Vcc stimulus to DI and RO tracks DI.  In both the 176, and the MAX485 they get noticeably warm to the touch.  Differential voltage measured across A and B is about 500mv....certainly within spec

 

I then grabbed another spool of Cat5e with about 13 metres of line left and put the resistors in place and shorted the far end.  Repeated teh stimuli pattern and RO tracked DI, but now both driver chips are really getting warm/hot.  Differential voltage dropped down to a little under 380mv...still in spec

 

Lastly I dead shorted A and B and applied the stimulus again and RO still tracked DI, but now the driver is REALLY HOT!  Datasheet for MAX says it will shutdown in this case.

Differential voltage is at 20mv.....Way below spec, yet RO still tracks DI.

 

 So with no other transceiver on the line a single driver can indeed make it look like things are fine on the bus based on reading back the output

 

 

For my simulated collision detection I have a 500hz square wave as my 'host' feeding a transceiver with monitoring on the RO pin.  /RE is tied low.  DE is tied high.  The 'nuisance' node is a simple driver configured as I noted in the tests above, also with /RE tied low, and DE tied to Vcc.

 

Test 1.  Host driver is 75176.  Nuisance driver is MAX485.

I could not see the square wave on the scope.  Just little spikes here and there.  On the nuisance the RO pin was sitting on Vcc or Ground depending on how I tied the local DI.  In this case the 'host' connected to the 75176 would detect a collision should a node start transmitting while it is in the process of sending out it's own data.

 

Test2. Host driver is MAX 485.  Nuisance driver is 75176.

I could see the square wave on the scope clearly and with no signs of signal distortion regardless of the state of DI on the remote nuisance input on teh hosts RO pin.  The RO output on the nuisance on the other hand was showing a lot of noise which was the 500hz square wave and depending on the state of the DI pin the noise would grow increasingly worse.  In this configuration the host would not detect a collision should the nuisance start transmitting while the host is sending data.

 

Test 3. Host driver is MAX 485.  Nuisance driver is MAX485.

I could see the 500hz square wave on the host RO pin on the scope clearly and with no signs of signal distortion regardless of the state of DI on the remote nuisance input.  At the RO pin on the nuisance node the pin would follow the state of the nuisance nodes DI pin.   In this configuration the host would not detect a collision should the nuisance start transmitting while the host is sending data.

 

Test 4. Host driver is 75176.  Nuisance driver is 75176.

I could not see the square wave on the scope cleanly.  Just a lot of noise on a dirty looking square wave. THis noise would change based on the state of the DI pin on the nuisance node.   The RO output on the nuisance on the other hand was showing a lot of noise which was the 500hz square wave and depending on the state of the DI pin the noise would grow increasingly worse.  In this case the 'host' connected to the 75176 would detect a collision should a node start transmitting while it is in the process of sending out it's own data.

 

So, these simple tests do validate some of what Paul has stated in his posts. 

 

Does this mean that to give yourself a better shot at detecting collisions we should go back to the old 75176?

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Last Edited: Wed. Aug 30, 2017 - 04:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@js

Waauw, that schematic sure is a good attempt at obfuscation.

How "widely used" are those resistors "up to 22 Ohm".

But nowaday's 100mA PPTC's seem a much better choice than 10Ohm "fusible resistors"

 

@Jim

Nice test!

jgmdesign wrote:
Does this mean that to give yourself a better shot at detecting collisions we should go back to the old 75176?

Nope.

It just means collision detection is over rated  (misleading) for RS485 and that is the main reason CAN was invented anyway.

You may also conclude that RS485 transceiver are really good at reconstructing low signal levels.

 

Sometimes I think about setting up a website with doing and documenting tests like these.

The Debouncing article from Jack Ganssle always comes to mind as an example of not being content with fiddling with software "untill it works" or playing copy cat, but doing some work and finding out what the real parameters are.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some 485 chips have 20mV detection vs the 485 spec 200mV. The lt1785 is one such chip. Also note its enable time is slow compared to the max485. You pay for its voltage and esd performance and yes, it delivers. It doesn't like 240vac on the bus - i had a customer try it 14 times.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
But nowaday's 100mA PPTC's seem a much better choice than 10Ohm "fusible resistors"
33 ohms max for one 250Vrms telecom PPTC.

Another way is by a Transient Blocking Unit (TBU) (MOSFET)

 

http://www.littelfuse.com/products/resettable-ptcs/telecom.aspx (250R)

Bourns

RS-485 Serial Port - ESD / EFT / Surge Protection

http://www.bourns.com/docs/Products-General/Bourns_RS-485_Serial_PortNote.pdf?sfvrsn=15ec44f1_8

(TVS, TBU, MOV)

(ESD, EFT, lightning)

(alternate is TVS and PPTC)

via http://www.bourns.com/products/circuit-protection/tbu-high-speed-protectors-hsps

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

that schematic sure is a good attempt at obfuscation.

How? It just shows a RS485 chip going to a RJ45 connector with protection and line biasing components mounted.

How "widely used" are those resistors "up to 22 Ohm".

Very widely, I have designed several boards for at least 2 clients with similar set up, their business is traffic control and signalling. Another company uses a similar set up but uses 22R resistors and diodes to VCC and ground for protection, their business is industrial controllers.

 

Maybe you may want to compare this schematic with those Bourns schematics posted above by gchapman or application notes from TI and others.

 

A TI application notes says

For transceivers with low ESD rating insert surge-rated 10Ω to 20Ω MELF resistors in series to the
transceiver bus terminals to reduce the remaining TVS clamp energy.

so what part is obfuscating?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What happens if someone connects 24Vdc to the bus? I sense smoke. For industrial controls 24Vdc is commonplace.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I sense smoke

and I have replaced many 10R resistors when I was doing some repairs but not many chips. wink

 

edit so I showed you mine you show me yours.....starting with Paul, show your favourite RS485 circuit that stands to the rigors of real life outside the lab or the home, we can all benefit from this.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Wed. Aug 30, 2017 - 11:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had the same problem so i put in polyfuses. Problem solved. As long as the 0V circuit was wired correctly, it would survive nearby lightning.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm doing a design at the moment where a board has 9 485 chips on it. Do we use the expensive ones with better specs or the cheapies? We're going to try both and zap the shite out of them and see how they survive. Both ESD and fast transient.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:

edit so I showed you mine you show me yours.....

 

This is somewhat snarky cheating, because this doesn't have a multidrop bus.  Every line is dedicated.  However, it does cheerfully throw 2MHz signals down 50 meters of cable...  They come out the other end rather nice, even when the cable is all just thrown in a box.

 

The board layout.  I stuck two boards on the same layoutAnd the schematic

 

 

Have fun,  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm doing a design at the moment

Which you will, of course, share with us once you do all the tests and pass..... cheeky

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of course I can't share the design, but i should be able to give some guidance on what actually works and what doesn't. 

Pretty well what Paul has said has been my experience as well. I think we all know 75176's without any protection do not last long out in the wild. Max485s and most others are much the same - you need protection. The Linear Tech LT1785 is quite robust. I've got 10+ years of product out in the field on long (1km+) busses in high lightning areas around the world and they survive without any extra protection devices. You pay about twice the cost of the 'usual' devices for these. I also have probably 15+ years of product alongside the other gear that use a MAX485 with 5V tranzorbs and 100mA polyfuses. This survives 24Vdc being applied and lightning abuse. Other anecdotal learning is you really need the 0V wire between devices. My reasoning is, in the case of a lightning strike nearby, this induces a transient into the cable. The tranzorbs on both ends effectively 'circulate' the fault current in the cable. I had one site in China that died due to lightning where the 0V wire was not provided. Both ends had the 485 chips damaged. The tranzorbs were ok. Hard evidence? Probably not. When you have a number of similar setups operating around the world and one fails, then that is some evidence. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mine were made to be indoors, so not lightning-proof, and no 'packetizing' at all - Just a few dedicated signals that had to run fast.  The chips I wound up using were rated for 4MHz, but the waveforms started to get a bit shonky at speed.  Since the customer spec was 1MHz (actually more like 800kHz) 2MHz is just fine fast enough.  Note the amusing propagation delay strictly due to lightspeed down 50m of cable.  Trivially measurable, even with my cheesy lil' scope.  S.

 

PS - I did hook up an 0V reference, and used five lines in the cable for it.  Originally I was going to throw all the power down the wire, but a bit of looking at it told me that the 12V rails (not used, but required) wouldn't quite be 12V at the long end, so I specified the use of another isolated power supply at that end.  Customer didn't mind.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
Mine were made to be indoors, so not lightning-proof, ...
Have been bit by a close proximity lightning strike resulting in damage to indoor equipment.

How :

Electrical surge via lightning

Surge current can enter by data and/or power.

Local surge suppression is adequate though suppression can be whole structure by the circuit breaker box.

 

B&B Electronics, now B+B SmartWorx

Advantech B+B SmartWorx

Ruggedizing USB Connections for Tough Environments

USB is ubiquitous, it’s useful and it’s here to stay. But it isn’t inherently rugged or reliable. It’s up to you to make it that way.

http://www.bb-elec.com/Learning-Center/All-White-Papers/USB/Ruggedizing-USB-Connections-for-Tough-Environments.aspx

Delta Lightning Arrestors

Total Residential Package

http://deltala.com/total-residential-package.php

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Definitely could have been.  But it wasn't included in the spec, and I wasn't getting paid to put it in.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@js,

Once you've been staring at the ciruit for some time it becomes obvious. The "obfuscation" part (for such a relative simple circuit) is partly because you can't see where the 10k resistors are leading to and the pull-down resistor (R21) has a lot of corners before it get's to the IC input it is pulling down.

Whenever I'm drawing a circuit I always put extra care in making my intention clear to even casual observers. Power always flows from top to bottom.

Signals (almost) always go from left to right. It oftens needs more space to draw a ciruit this way, but that's a small price to pay.

So He's how I draw it:

 

I just discovered an error in this circuit, which is of course quite obvious once you know it. Can you spot it? (Answer is below this post so don't read on if you want to take up the challenge.

 

About the 3rd GND / 0V wire.

This wire is always mandatory for a robust RS485 network.

RS485 transceivers are not opto isolators and they have a limited common mode range from -7 to +12V.

Mains powered power supplies can have significant leakage currents. As so nicely pointed out here:

http://www.avrfreaks.net/forum/m...

http://www.aplomb.nl/SMPS_leakag...

Some of Doc's measurements show 80Vac / 80uA leakage.

You don't want that  superposed on your singal wires.

 

This is also briefly addressed in TI snla049b "10 ways to bulletproof RS485"

http://www.ti.com/lit/an/snla049...

 

I have not designed much electronics, and my experience with RS485 is limited to my own designed home network (Which I call Mumarnet). Even this is in a home environment with only about 20m of cables I've had to replace my share of RS485 drivers over the years. Luckily they were all socketed DIP8 devices.

The circuit above is my first attempt of adding extra protection and that is why I find this thread so interesting.

I'm now finalizing the design and hope to order the PCB's from China within a few weeks.

 

A bit about the circuit, and why there are so many RS485 signals.

My self designed home network "Mumarnet" only uses 4 out of the 8 wires of the CAT5 Calbe. 2 for power and 2 for data.

The 4 spare wires are reserved for "local" "extra funcions".

I have a small Linux box which runs mpd and produces S/PDIF audio, which it puts through a RS485 driver and it uses wires 1 and 2 of the CAT 5 to distribute the audio to only a part of Mumarnet.

This DCX2496 (Behringer) node has an internal S/PDIF transformer (Actually AES/EBU), A RS485 driver has plenty of power to drive such a transformer but multiple of these transformers is a bit much, so I use a RS485 receiver and driver back to back (front to front?). Sure, Audio (but not power) can be distributed over WiFi nowaday's but good old fashioned wires still have their place, are quite a bit more reliable (except against vacuum cleaners mabye, depending on where you put the wires). Audio distribution over wires also eliminate any latency issues with distributed audio. The DCX2496 however also has a "link" bus to link multiple of these devices together, so you can copy settings from one of these devices to another, or control multiple of these from a single PC. The data part of Mumarnet itself is used (Via an AVR) to set the volume of the 6 DCX outputs (3x PGA2310) and turn the Stereo on/off (Everything except a few mA for the uC, which is powered from Mumarnet itself).

 

Answer:

The (cat5) cable on Mumarnet transmits signal and power. The resistance of CAT5 cable is however relatively high and you easily lose a few volts when used for power (As Scrounge #39 also discoverd) This is easily overcome by upping the voltage (Which also lowers current and voltage drop I.E. EtherCat uses 48V) and then adding a small SMPS on the "remote" end for your power. The problem is that you can have (upto a few) volts of difference in the ground potential between all the nodes distributed over the network. In itself this is not a problem for the RS485 transceivers because they are spec'd for common mode voltages between +12V and -7V. In the situation where the node near the power supply sends data to a node at the far end of the cable (Raised GND level) that far node sees the signal wires go negative, ad the single ended transorbs short these to the raised GND level and damage the signal integrity. Therefore these transorbs really need to be bipolar.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Addition to #42

In Mumarnet I use 2 RJ-45 sockets on each pcb which is convenient for using standard CAT5 cables but has 2 disadvantages.

1). When disconnnection nodes in the middle of the network you lose power/data to a part of the network

 (Can use a power supply on both ends of the network to mitigate).

2). The Power (Up to 1A @ 24V) has to go through all the connectors.

 

Making stubs on a continous CAT5 cable woud prevent this, but is quite a nuisance.

Does anybody know a convenient way to do this?

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:

2). The Power (Up to 1A @ 24V) has to go through all the connectors.

 

48V at 0.5A.  cheeky  Ethernet runs at that voltage-ish, so we know the cables and connectors are good for it.  Otherwise barrel connectors:

https://www.digikey.com/product-...

 

S.

 

Edited to add PS - It's a lot cheaper to make your own barrel connectors out of PCB mount ones than buy that thing.  Just don't get the power lines crossed.  S.

PPS - MUCH CHEAPER:  http://www.jameco.com/z/300-039-... S.

Last Edited: Fri. Sep 1, 2017 - 02:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My bad.  Cut, pasted, didn't test.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's actually a trailing space in the digikey link as well, but their server accepts it.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which is one reason why I shop at Digikey.  Their stock is pretty great, and their website is absolutely awesome.  Not always the cheapest, but their website for finding product is so totally cool I don't mind paying a bit of premium.  If anyone from Digikey is reading this, and thinking about cutting the web guys (and gals)'s budget, you will get what you deserve.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I happen to have a few of these:

and when you strip about 50mm of the outer mantle in the middle of a CAT5 cable you can put these quite easily in the cable to make stubs for little uC modules.

But I have to experiment a bit more. The tool I have to push the wires into the slots is of quite low quality.

I'm also not sure if these connectors are for solid wire or for stranded wire.  or maybe they can be used for both?

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They are for solid wire. You can try stranded but it may not be reliable

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user