Searching \ for '[PIC]:Thoughts on RS485 collision detection' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=rs485
Search entire site for: 'Thoughts on RS485 collision detection'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:Thoughts on RS485 collision detection'
2001\07\16@212317 by Brandon Fosdick

flavicon
face
For my project that uses an RS485 network I was planning to use a token
ring system so I don't have to deal with collision detection. But I got
to thinking about it and now I'm wondering if it might be worth doing.

The solutions I've seen posted so far (and on piclist.com) all seem to
be of the bitbang variety. Since I'm using 16F877's for this project it
seems like a waste to bitbang stuff when I have a nice USART to use. Has
anybody done this yet? I'm thinking that if I leave the receiver enabled
(im using a max487) the USART should receive a byte for every byte that
it sends. If the two bytes are different a collision has occured. First
off, that sounds too simple, like something that somebody has already
thought of and rejected. Second, whats a good way of handling back-off
and retransmission?

If all the devices are set for the same back off time, or time
increment, they'll just collide again. I guess I could implement a
random number generator, but I'd rather not. Is there a good way to
handle this?

How should retransmission be handled? Obviously the sending device needs
to retransmit the lost data, but how does the receiving device know that
a collision has occured? If it doesn't know there's been a collision it
might think the corrupted data is valid.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\16@213817 by David Duffy

flavicon
face
At 09:12 PM 16/07/01 -0400, you wrote:
>For my project that uses an RS485 network I was planning to use a token
>ring system so I don't have to deal with collision detection. But I got
>to thinking about it and now I'm wondering if it might be worth doing.
>
>The solutions I've seen posted so far (and on piclist.com) all seem to
>be of the bitbang variety. Since I'm using 16F877's for this project it
>seems like a waste to bitbang stuff when I have a nice USART to use. Has
>anybody done this yet? I'm thinking that if I leave the receiver enabled
>(im using a max487) the USART should receive a byte for every byte that
>it sends. If the two bytes are different a collision has occured. First
>off, that sounds too simple, like something that somebody has already
>thought of and rejected. Second, whats a good way of handling back-off
>and retransmission?

In practice, the local receiver will see an echo of what you sent even if
there was a collision. This happens because of the voltage drop in the
network cabling and due to the receiver only needing a small differential
voltage to make it work. It won't see the fault which is farther away.

>If all the devices are set for the same back off time, or time
>increment, they'll just collide again. I guess I could implement a
>random number generator, but I'd rather not. Is there a good way to
>handle this?

Do the nodes each have an address? If so, base the retry on the address.

>How should retransmission be handled? Obviously the sending device needs
>to retransmit the lost data, but how does the receiving device know that
>a collision has occured? If it doesn't know there's been a collision it
>might think the corrupted data is valid.

Frame the data in packets with unique start & end characters.
Is there a master in the system that can poll the slave nodes?
Regards...

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\16@221403 by Byron A Jeff

face picon face
On Mon, Jul 16, 2001 at 09:12:55PM -0400, Brandon Fosdick wrote:
> For my project that uses an RS485 network I was planning to use a token
> ring system so I don't have to deal with collision detection. But I got
> to thinking about it and now I'm wondering if it might be worth doing.

Debatable. There are no gurantees on correct collision detection with
EIA-485 (it's no longer RS (Recommended Standard). It's a standard now.
Also it'll slow down your overall throughput. Finally can you be absolutely
sure how the receiver on the UART will react to incorrect
data coming in? Collision detection is an iffy proposition at best.

The fundamental flaw of a single channel EIA-485 system is that there is
no inherent signalling attached. So signalling must be implemented. There
are a few possibilities, a couple that you've already named:

1) None (Point to Point). The ring you described above. But it defeats the whole
  advantage of having EIA-485 in the first place.
2) None (collision). See comments above.
3) In band. Basically implement your token ring on the standard bus. The load
  of point to point transfers can be lessened by enabling 9 bit transfers
  and the address detection system built into the USART. This way folks will
  listen for their addresses only when the 9th bit is set, and can ignore
  data packets not addressed to them. Actually a fairly cool system that
  requires no additional hardware. The only costs are the extra bit transmitted
  cutting into throughput and the amount of time required to address a target
  (nearly 1ms at 9600 BPS)
4) Out of band signalling. The choice I hope to implement. I've described it in
  a previous post found here:

  http://www.infosite.com/~jkeyzer/piclist/2001/Feb/2727.html

  note that the username and password are the name of this list.

  Short summary: add a second signalling channel and use Time Slots to
  determine who transmits next. No collisions. For fairness each node has
  a Already Transmitted Slot that is after all of the primary slots. If
  the signalling channel is clear then the ATS is reached then all nodes
  in the ATS can move back to their primary slot. So even if every node wanted
  to transmit all the time, negotiation would be fair.

  Good point: it can be fast if the time slots are small. Another good point
  is like the inband above the UART can be turned off if you don't get the
  slot. It can even be coupled with the 9 bit addressing above once the
  transmitter is choosen. Bad points: requires extra hardware and extra
  software to implement.

So those are some ideas. But trying to do collision in software probably isn't
a real good idea. Ethernet works because the collision system is designed in the
hardware.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\16@223649 by Gennette, Bruce

flavicon
face
For the back off time I suggest you use each device's ID number.  Then place
the faster re-trying devices in the most important parts of your network.
Simple, effective and intutitive for the installer, lower numbers mean
better comms, higher numbers mean lower priority.

As to the echo verification method - its is used in several places.  One
that comes to mind is Texas Instruments graphical calculators - they use a
simple 3 line, 2 way, echo verification comms setup; see their site for
details.
You could expand this with the IEEE-488 Talker/Listener scheme where an
extra line is pulled low by *ANY* device to initialize comms with the Master
(who then sets up a private conversation by telling all other Slaves to
UNListen until the bus is released).

Bye.

{Original Message removed}

2001\07\17@083400 by Olin Lathrop

face picon face
> For my project that uses an RS485 network I was planning to use a token
> ring system so I don't have to deal with collision detection.

That's going to be tough because RS-485 is a multidrop bus, not a ring.  You
could implement a ring from individual point to point RS-232 connections,
but that would require two UARTs per node.

> The solutions I've seen posted so far (and on piclist.com) all seem to
> be of the bitbang variety. Since I'm using 16F877's for this project it
> seems like a waste to bitbang stuff when I have a nice USART to use. Has
> anybody done this yet?

I'm not exactly sure what your question is but, yes, of course, many people
have written code for the built in UART.  I've done this many times myself,
including some RS-485 bus applications.

> I'm thinking that if I leave the receiver enabled
> (im using a max487) the USART should receive a byte for every byte that
> it sends.  If the two bytes are different a collision has occured.

RS-485 isn't designed electrically for this sort of thing.  For one thing,
the local node may see its own output signal correctly, but other nodes that
are also driving the bus might not.  Secondly, multiple transmitters can
cause high currents.  Basically, I wouldn't do this.

> Second, whats a good way of handling back-off
> and retransmission?

RS-485 isn't suited for this.  If you want arbitrary peer to peer
communication with no master, look into CAN.  It is designed for exactly
this kind of operation.

> If all the devices are set for the same back off time, or time
> increment, they'll just collide again. I guess I could implement a
> random number generator, but I'd rather not. Is there a good way to
> handle this?
>
> How should retransmission be handled? Obviously the sending device needs
> to retransmit the lost data, but how does the receiving device know that
> a collision has occured? If it doesn't know there's been a collision it
> might think the corrupted data is valid.

This wheel has already been invented a few times.  Check out how ethernet
and CAN do it, or the "global serial bus" on some Intel embedded processors
like the 80C152, although I don't know if that last one is still supported.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, spam_OUTolinTakeThisOuTspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\17@091344 by Byron A Jeff

face picon face
On Tue, Jul 17, 2001 at 07:59:05AM -0400, Olin Lathrop wrote:
> > For my project that uses an RS485 network I was planning to use a token
> > ring system so I don't have to deal with collision detection.
>
> That's going to be tough because RS-485 is a multidrop bus, not a ring.  You
> could implement a ring from individual point to point RS-232 connections,
> but that would require two UARTs per node.

Actually it doesn't. A true single direction ring can be made with a single
USART. Consider this:

----------+   +-----------+   +----------+   +-----------
         |   |           |   |          |   |
       ________        ________       ________
       | R   X|        | R   X|       | R   X|
       --------        --------       --------

Each node has a single USART where the transmitter of one is paired with
the receiver of the next. It can even be done with EIA-485 but each node
would require two transceivers instead of one.

It can be done. Probably isn't practical for the application though.

>
> > The solutions I've seen posted so far (and on piclist.com) all seem to
> > be of the bitbang variety. Since I'm using 16F877's for this project it
> > seems like a waste to bitbang stuff when I have a nice USART to use. Has
> > anybody done this yet?
>
> I'm not exactly sure what your question is but, yes, of course, many people
> have written code for the built in UART.  I've done this many times myself,
> including some RS-485 bus applications.

I think he was referring to collisions, not using the USART itself.

>
> > I'm thinking that if I leave the receiver enabled
> > (im using a max487) the USART should receive a byte for every byte that
> > it sends.  If the two bytes are different a collision has occured.
>
> RS-485 isn't designed electrically for this sort of thing.  For one thing,
> the local node may see its own output signal correctly, but other nodes that
> are also driving the bus might not.  Secondly, multiple transmitters can
> cause high currents.  Basically, I wouldn't do this.

Agreed.

>
> > Second, whats a good way of handling back-off
> > and retransmission?
>
> RS-485 isn't suited for this.  If you want arbitrary peer to peer
> communication with no master, look into CAN.  It is designed for exactly
> this kind of operation.

I wouldn't go this far. EIA-485 can work fine if a token bus protocol is
implemented on top of standard multidrop connection. It can simulate
arbitrary peer to peer quite easily. However as I pointed out in my other
post, that adding a signalling channel out of band from the data can
reduce the amount of negotiating time and the amount of dead time from passing
the token to nodes who don't need to transmit.

{Quote hidden}

But each of these implement collisions in the hardware level. EIA-485 does not.
So those solutions will not apply.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\17@101830 by Douglas Butler

flavicon
face
> You
> could implement a ring from individual point to point RS-232
> connections,
> but that would require two UARTs per node.
>
Not usually.  You only need two UARTS if you want a bidirectional ring.
Many sensors are wired as a RS-232 ring with one UART.  The receiver
listens to the left, and the transmitter talks to the right.

Sherpa Doug

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\17@151252 by Brandon Fosdick

flavicon
face
Olin Lathrop wrote:
>
> > For my project that uses an RS485 network I was planning to use a token
> > ring system so I don't have to deal with collision detection.
>
> That's going to be tough because RS-485 is a multidrop bus, not a ring.  You
> could implement a ring from individual point to point RS-232 connections,
> but that would require two UARTs per node.

Maybe "token ring" isn't the right term for what I'm thinking cause I seem to
have sent everybody on a different path. "Token ring", as I understand it, isn't
a network topology, its a communications protocol. We use it on several of our
robots (http://www.ssl.umd.edu) and I think it was used for PC's back in the heyday of
coax cabled LAN's, but that was before my time.

The system I'm refering to, whatever its called, involves a series of nodes on a
multi-drop broadcast network that need to communicate peer-peer. A node can only
communicate when it has the "token", when its done with the network it gives the
token to another node which then either uses the network or passes the token on
to the next node. The token tends to move around the network in a ring, hence
"token ring". Obviously there are some problems with this system, but it works
for simple networks.

> RS-485 isn't suited for this.  If you want arbitrary peer to peer
> communication with no master, look into CAN.  It is designed for exactly
> this kind of operation.

I've thought about CAN, but haven't looked into it much. Maybe I'll take a
second look. Thanks.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\17@152714 by Dale Botkin

flavicon
face
On Tue, 17 Jul 2001, Brandon Fosdick wrote:

> Olin Lathrop wrote:
> >
> > > For my project that uses an RS485 network I was planning to use a token
> > > ring system so I don't have to deal with collision detection.
> >
> > That's going to be tough because RS-485 is a multidrop bus, not a ring.  You
> > could implement a ring from individual point to point RS-232 connections,
> > but that would require two UARTs per node.
>
> Maybe "token ring" isn't the right term for what I'm thinking cause I seem to
> have sent everybody on a different path. "Token ring", as I understand it, isn't
> a network topology, its a communications protocol. We use it on several of our
> robots (http://www.ssl.umd.edu) and I think it was used for PC's back in the heyday of
> coax cabled LAN's, but that was before my time.

It's both a protocol and a topology.  It's a token-passing protocol on a
ring network.  Regardless of the fact that TR networks are usually (now)
cabled with Cat-5 and RJ45 connectors, it's a ring.  The earlier wiring
schemes used shorting connectors that would bypass an unplugged node, now
I think the switches take care of it for you.  In any case, the token is
passed from node to node in series on a ring network.

> The system I'm refering to, whatever its called, involves a series of nodes on a
> multi-drop broadcast network that need to communicate peer-peer. A node can only
> communicate when it has the "token", when its done with the network it gives the
> token to another node which then either uses the network or passes the token on
> to the next node. The token tends to move around the network in a ring, hence
> "token ring". Obviously there are some problems with this system, but it works
> for simple networks.

I think that's a valid concept, it's just not "token ring".  It's a
token-passing protocol on a bus network.  Now all you have to do is figre
out an addressing scheme so a node knows who gets the token next.

Dale
--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\17@153509 by Garber, Mike

flavicon
face
<snip>

{Quote hidden}

By every node monitoring what's going on, they keep a map of active node #s
Every once-in-a-while, when a station has the token, if there's a gap between his node# and his sucessor
he does a "solicit-for-sucessor" to one of the non-active ones.  That way new node #s get picked up.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\17@155136 by Brandon Fosdick

flavicon
face
Byron A Jeff wrote:
> I wouldn't go this far. EIA-485 can work fine if a token bus protocol is
> implemented on top of standard multidrop connection. It can simulate
> arbitrary peer to peer quite easily. However as I pointed out in my other
> post, that adding a signalling channel out of band from the data can
> reduce the amount of negotiating time and the amount of dead time from passing
> the token to nodes who don't need to transmit.

This is what I had in mind. I don't need much bandwidth so I'm not too worried
about signaling overhead.

In such a system is a token managing node usually employed or is each node given
an address to pass the token to when its done? I'm wondering how hard its going
to be to add new nodes later.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\17@160206 by Brandon Fosdick

flavicon
face
"Garber, Mike" wrote:
> By every node monitoring what's going on, they keep a map of active node #s
> Every once-in-a-while, when a station has the token, if there's a gap between his node# and his sucessor
> he does a "solicit-for-sucessor" to one of the non-active ones.  That way new node #s get picked up.

Hadn't thought of that, but I like it. Reminds me of ARP in a way.

Instead of each node maintaining a map of the entire network, what if it just
maintained the number for its successor? Then handle gaps as you mentioned
above. The last node will have to remember the first node as its successor.
Also, it would be nice for a node to send its new successor the number of its
old successor.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\17@210912 by Olin Lathrop

face picon face
> It's both a protocol and a topology.  It's a token-passing protocol on a
> ring network.  Regardless of the fact that TR networks are usually (now)
> cabled with Cat-5 and RJ45 connectors, it's a ring.  The earlier wiring
> schemes used shorting connectors that would bypass an unplugged node, now
> I think the switches take care of it for you.  In any case, the token is
> passed from node to node in series on a ring network.
>
> > The system I'm refering to, whatever its called, involves a series of
nodes on a
> > multi-drop broadcast network that need to communicate peer-peer. A node
can only
> > communicate when it has the "token", when its done with the network it
gives the
> > token to another node which then either uses the network or passes the
token on
> > to the next node. The token tends to move around the network in a ring,
hence
> > "token ring". Obviously there are some problems with this system, but it
works
> > for simple networks.
>
> I think that's a valid concept, it's just not "token ring".  It's a
> token-passing protocol on a bus network.  Now all you have to do is figre
> out an addressing scheme so a node knows who gets the token next.
>
> Dale

I agree with what Dale said about token rings.  Real token rings are, well,
rings.  The early ones like Primenet, Apollo domain, and IBM token ring used
coax cables.  Each node had an in and out connection.

You could try to simulate this on a multi drop bus, but I think you are
asking for trouble.  In a real token ring, a node that is off has relays
that disconnect the node and close the ring as if nothing is there.  This
will be difficult to do in your scheme.  How will each node know who the
next node to get the token is?  There would probably have to be a timeout if
a node was given the token but showed no activity.  Then what?  Who decides
to pass the token to the assumed next node after that.  What if the node
that is supposed to pass on the token meanwhile goes off the bus?  There are
reasons people don't do this.

Multi drop busses usually either have a single master like IEEE-488, IIC,
USB (at the broad overview level) and most RS-485 implementations (although
that is not part of the standard), or collision detection with random
backoff like ethernet, or collision detection with a priority scheme like
CAN.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\17@213712 by Olin Lathrop

face picon face
> In such a system is a token managing node usually employed or is each node
given
> an address to pass the token to when its done? I'm wondering how hard its
going
> to be to add new nodes later.

For what it's worth, here is how I dealt with a RS-485 system where nodes
needed to be hot swappable:

Each node on the bus had a separate address.  Node 0 was the bus master and
was always present.  Nodes 1-N were slaves.  The master kept a list of
active nodes on the bus and gave each one a chance to talk in circular
fashion as fast as the bus bandwidth allowed.  If a node failed to respond
to three times in a row, the master crossed it off the list and the node
would not receive further requests to send.  Every once in a while, the
master would ping one of the addresses that it currently thought was
inactive.  If it got a response, that node would be added to the active
list.

This particular system used 4 bit node addresses, so there could only be a
maximum of 15 slave nodes.  The master pinged an inactive address once every
100mS, and the response timeout was 3mS so only about 3% of the bandwidth
was used to find newly active nodes and a new node would be discovered
within 1.6 seconds.  The system worked very well and nodes were indeed hot
swappable.  Newer versions of this system will probably use CAN because both
the 15 maximum slave nodes and the 115.2K bits/second will probably become
limitations as more things are asked from this bus than originally intended.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinspamKILLspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\20@220903 by Brandon Fosdick

flavicon
face
Olin Lathrop wrote:
> Multi drop busses usually either have a single master like IEEE-488, IIC,
> USB (at the broad overview level) and most RS-485 implementations (although
> that is not part of the standard), or collision detection with random
> backoff like ethernet, or collision detection with a priority scheme like
> CAN.

After reading over Microchip's CAN application notes and datasheets I've
decided that CAN is an easier solution for what I'm doing. However, I
haven't been able to find any info on transmission length vs
transmission speed. I only need 9600bps over about 60ft. Anybody know
for sure if that will work?

Also, whats a good source for small quantities of CAN tranceivers in the
US? Digikey doesn't appear to carry any. Pioneer Standard has the
Phillips part mentioned in one of the application notes. Is there a
particular part/supplier that is known to work well?

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu


2001\07\21@120629 by Olin Lathrop

face picon face
> After reading over Microchip's CAN application notes and datasheets I've
> decided that CAN is an easier solution for what I'm doing. However, I
> haven't been able to find any info on transmission length vs
> transmission speed. I only need 9600bps over about 60ft. Anybody know
> for sure if that will work?

The NMEA2000 standard defines a CAN implementation for marine use.  I'm sure
these guys have done their homework.  NMEA2000 runs at 250Kbits/sec at a
maximum bus length of 200 meters.  The standard also mentions that future
versions might support some of the following bit rates and lengths:

 Kbits/sec   Meters
 ---------   ------
      1000       25
       500       75
       250      200
       125      500
        62.5   1100

These values are probably very conservative.  If you are using decent cable,
then I would use these values to indicate the length you can use safely
without having to do any analisys yourself.  In other words, 1Mbit/sec
should be fine within a single machine or whatever.  You probably need to
use lower speed between machines, accross the factory floor, etc.  Then
again, CAN is probably not the right choice for those kinds of applications.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, EraseMEolinspam_OUTspamTakeThisOuTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\21@162905 by Brandon Fosdick

flavicon
face
Olin Lathrop wrote:
{Quote hidden}

Thanks. It looks like I shouldn't have any problems since this is just
for inside my house and I'm using CAT5 for everything.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\21@175903 by Patrick J

flavicon
face
CAN speed vs distance:
1Mbit/s - 25 m
800kbit/s - 50 m
500kbit/s - 100 m
250kbit/s - 250 m
125kbit/s - 500 m
50kbit/s - 1000 m
20kbit/s - 2500 m
10kbit/s - 5000 m

There ya go!

{Original Message removed}

2001\07\21@191411 by Patrick J

flavicon
face
OK, I might be totally off but how about _avoiding_ collision instead of
detecting it ?

Say all pics on the bus have ID:s #1..#5, and that also represent their priority
on the bus.
Now, for a pic to be allowed to send it must wait the number of mS that is equal
to its
ID number (2mS for pic with ID=2 in this example) AFTER the LAST detected
transmission
on the bus, before it starts to send.

This would mean that pics w high priority (low ID and therefor short wait time)
can
'sneak' in before a low priorty pic which is still waiting before send.
In principle a low priority pic can be 'starved' (no data) but if one can asume
the
high priority pics can behave and not take up all of the bus it should work.


> Olin Lathrop wrote:
> > Multi drop busses usually either have a single master like IEEE-488, IIC,
> > USB (at the broad overview level) and most RS-485 implementations (although
> > that is not part of the standard), or collision detection with random
> > backoff like ethernet, or collision detection with a priority scheme like
> > CAN.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\22@035418 by Chris Carr

flavicon
face
I have only been half following this thread so my apologies if I have got
hold of the wrong end of the stick.

I have implemented a somewhat similar system on RS485 using a Slotted Aloha
Protocol. It works very well  on low throughput systems and is quick and
cheap to implement.

I was originally going to use CAN for the system and even invested in a
MCP2510 Development Kit. Only then did we get the Standards and when we
started reading them it slowly became clear that CAN is only a transport
media same as RS485 (except it includes error checking, collision detection
etc etc) You still have to overlay it with a Communications Protocol. The
idea of using CAN was rapidly dropped as the complexity could not be
justified for that project.

In the end we delivered a complete working system using Slotted Aloha for
the estimated cost of developing just one Station using CAN.

Just sometimes, it's worth going back to the 60's in order to go forward
into a profitable future    8-)

In case you were wondering, the cost of the MCP2510 Development Kit was
included in the cost of the system.  The one thing that troubles me is that
the customer was just a little too happy when he was presented with the
Bill, I'm sure we undercharged him.

Regards

Chris Carr

{Original Message removed}

2001\07\22@050843 by Spehro Pefhany

picon face
At 08:51 AM 7/22/01 +0100, you wrote:
>
>In case you were wondering, the cost of the MCP2510 Development Kit was
>included in the cost of the system.  The one thing that troubles me is that
>the customer was just a little too happy when he was presented with the
>Bill, I'm sure we undercharged him.

Note to self:  *Always* grumble when quotes or bills are presented for any
largish amount of money.  ;-)

Purchasing agents are pre-programmed to clutch for their heart and say
things like "are you CRAZY!!!" when you tell them something will cost
$xxx K or whatever... they may not understand what it is you are doing, but
they do understand that the first price won't likely be the lowest possible
;-)

Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamspam_OUTinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\22@142931 by Brandon Fosdick

flavicon
face
Chris Carr wrote:
>
> I have only been half following this thread so my apologies if I have got
> hold of the wrong end of the stick.
>
> I have implemented a somewhat similar system on RS485 using a Slotted Aloha
> Protocol. It works very well  on low throughput systems and is quick and
> cheap to implement.
>
> I was originally going to use CAN for the system and even invested in a
> MCP2510 Development Kit. Only then did we get the Standards and when we
> started reading them it slowly became clear that CAN is only a transport
> media same as RS485 (except it includes error checking, collision detection
> etc etc) You still have to overlay it with a Communications Protocol. The
> idea of using CAN was rapidly dropped as the complexity could not be
> justified for that project.

I'm not familiar with Slotted Aloha, can you provide more details?

Implementing a comm protocol on top of CAN doesn't look that difficult,
but I could be missing something. If I was going to use 485 I'd have to
write the adressing/arbitration protocol and the comm protocol. Only
having to write one of those sounded a lot easier to me. Then again, I
don't know what slotted aloha involves. Since I'm going to be
transmitting mostly event based information, the CAN method of typing
messages as opposed to addressing them is appealing.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\22@152320 by Chris Carr

flavicon
face
> >In case you were wondering, the cost of the MCP2510 Development Kit was
> >included in the cost of the system.  The one thing that troubles me is
that
> >the customer was just a little too happy when he was presented with the
> >Bill, I'm sure we undercharged him.
>
> Note to self:  *Always* grumble when quotes or bills are presented for any
> largish amount of money.  ;-)

We are talking Yorkshire Farmers here, when they grumble about the Bill you
know they are happy. When they look at in silence and continue looking at
it, you know they are not happy. If they start sucking their teeth then you
know you are in trouble. 8-)

Chris

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\22@160506 by Byron A Jeff

face picon face
On Sat, Jul 21, 2001 at 05:35:54AM +0200, Patrick J wrote:
> OK, I might be totally off but how about _avoiding_ collision instead of
> detecting it ?
>
> Say all pics on the bus have ID:s #1..#5, and that also represent their priority
> on the bus.
> Now, for a pic to be allowed to send it must wait the number of mS that is equal
> to its
> ID number (2mS for pic with ID=2 in this example) AFTER the LAST detected
> transmission
> on the bus, before it starts to send.
>
> This would mean that pics w high priority (low ID and therefor short wait time)
> can
> 'sneak' in before a low priorty pic which is still waiting before send.
> In principle a low priority pic can be 'starved' (no data) but if one can asume
> the
> high priority pics can behave and not take up all of the bus it should work.

It's always better if the protocol guarantees that starvation won't occur
instead of making it voluntary for high priority nodes behave.

Take a look back earlier in this thread when I proposed a secondary slot that
comes after all of the primary slots. Each node moves to that slot after
transmitting from the primary slot. These secondary nodes remain in that mode
until no primary wants to transmit. Then all of the secondaries can move back
to their primary slot. This enforces fairness when all the nodes want to
transmit and is more efficient than token ring when nodes do not need to
transmit.

But I agree that collision advoidance is a good idea.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\22@161125 by Byron A Jeff

face picon face
On Sun, Jul 22, 2001 at 02:17:55PM -0400, Brandon Fosdick wrote:
> Chris Carr wrote:
> >
> > I have only been half following this thread so my apologies if I have got
> > hold of the wrong end of the stick.
> >
> > I have implemented a somewhat similar system on RS485 using a Slotted Aloha
> > Protocol. It works very well  on low throughput systems and is quick and
> > cheap to implement.
> >
> > I was originally going to use CAN for the system and even invested in a
> > MCP2510 Development Kit. Only then did we get the Standards and when we
> > started reading them it slowly became clear that CAN is only a transport
> > media same as RS485 (except it includes error checking, collision detection
> > etc etc) You still have to overlay it with a Communications Protocol. The
> > idea of using CAN was rapidly dropped as the complexity could not be
> > justified for that project.
>
> I'm not familiar with Slotted Aloha, can you provide more details?

That's what search engines are for. I plopped slotted aloha into google and
10 pages of entries popped out.

It's a collision detection system that forces each node to transmit on an
agreed upon boundary with fixed message sizes. In this way collision detection
can be guranteed because multiple transmitters will all transmit at the same
time.

The only question I had is how does EIA-485 transceivers guarantee reports of
collisions? I thought that multiple transmitters on the bus would not guarantee
a known state on the line.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\22@162131 by Douglas Wood

picon face
I have a curcuit that utilitizes a full-duplex, multi-drop 485 network with
collision detection/avoidance. I could forawrd you a copy if you'd like...

Douglas Wood
Software Engineer
@spam@dbwoodKILLspamspamkc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://epicis.piclist.com

{Original Message removed}

2001\07\22@164235 by Scott Dattalo

face
flavicon
face
On Sun, 22 Jul 2001, Byron A Jeff wrote:

>
> Take a look back earlier in this thread when I proposed a secondary slot that
> comes after all of the primary slots. Each node moves to that slot after
> transmitting from the primary slot. These secondary nodes remain in that mode
> until no primary wants to transmit. Then all of the secondaries can move back
> to their primary slot. This enforces fairness when all the nodes want to
> transmit and is more efficient than token ring when nodes do not need to
> transmit.

When this last came up a year or two ago, this is a solution that you
and I both suggested. I've implemented this and it does work. However,
instead of having every node operate at a secondary arbitration slot,
I had only a few assume this role. This was because a few devices were
dedicated masters. In my case, the Baud rate was 38.4 and the
arbitration slot was one bit time ~26 uS. This worked fine for 100m
runs. When the network was extended with fiber (fiber was used for
isolation and not speed), it was necessary to extend the arbitration
slot time to two bit times when the distance was greater than 100m.
This worked well for 300m, after which I had no more fiber available.

Incidently, an IC pin proved invaluable for this project.

Scott

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\22@193640 by Olin Lathrop

face picon face
> That's what search engines are for. I plopped slotted aloha into google
and
> 10 pages of entries popped out.
>
> It's a collision detection system that forces each node to transmit on an
> agreed upon boundary with fixed message sizes. In this way collision
detection
> can be guranteed because multiple transmitters will all transmit at the
same
> time.
>
> The only question I had is how does EIA-485 transceivers guarantee reports
of
> collisions? I thought that multiple transmitters on the bus would not
guarantee
> a known state on the line.

They don't.  I hadn't heard the term "slotted aloha" before either, but this
sound pretty bogus applied to RS-485.  I also don't understand why he thinks
CAN is harder.  You need to make your own protocol layer either way.  CAN
takes care of collision detection and error handling for you while RS-485
doesn't.  A pure peer to peer network sounds much easier to do with CAN.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, KILLspamolinKILLspamspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\22@211229 by Patrick J

flavicon
face
Yes, Id like that very much !
TIA
/PJ

----- Original Message -----
> I have a curcuit that utilitizes a full-duplex, multi-drop 485 network with
> collision detection/avoidance. I could forawrd you a copy if you'd like...
>
> Douglas Wood
> Software Engineer
> RemoveMEdbwoodTakeThisOuTspamkc.rr.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\22@221146 by Patrick J

flavicon
face
From: "Byron A Jeff"
> On Sat, Jul 21, 2001 at 05:35:54AM +0200, Patrick J wrote:
> > I might be totally off but how about _avoiding_ collision instead of
detecting it ?
> > Say all pics on the bus have ID:s #1..#5, and that also represent their
priority on the bus.
> > Now, for a pic to be allowed to send it must wait the number of mS that is
equal to its
> > ID number (2mS for pic with ID=2 in this example) AFTER the LAST detected
> > transmission on the bus, before it starts to send.
> > In principle a low priority pic can be 'starved' (no data) but if one can
asume
> > the high priority pics can behave and not take up all of the bus it should
work.

> It's always better if the protocol guarantees that starvation won't occur
> instead of making it voluntary for high priority nodes behave.

Not always; that costs more and is more complicated ?
This idea is intended for a friendly bus (low traffic)

> Take a look back earlier in this thread when I proposed a secondary slot that
> comes after all of the primary slots. Each node moves to that slot after
> transmitting from the primary slot. These secondary nodes remain in that mode
> until no primary wants to transmit. Then all of the secondaries can move back
> to their primary slot. This enforces fairness when all the nodes want to
> transmit and is more efficient than token ring when nodes do not need to
> transmit.
> But I agree that collision advoidance is a good idea.

Well, I take it that for these 'slots' to be implemented you would haveto use a
extra line to syncronice the PICs on the bus ? My schedule is intended to work
with the tx/rx lines only. Must be the simplest and cheapest way to get the PICs
talking on the bus. All u do is to wait the time the ID states then send. Should
be ideal when theres little traffic on the bus.
/PJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\22@233817 by David P. Harris

picon face
Hi-
Could that be put into the PICLIST archives?  Else, I would like a copy too,
please.
Thanks, David

Patrick J wrote:

> Yes, Id like that very much !
> TIA
> /PJ
>
> {Original Message removed}

2001\07\24@122132 by Byron A Jeff

face picon face
On Mon, Jul 23, 2001 at 04:12:43AM +0200, Patrick J wrote:
> From: "Byron A Jeff"
> > On Sat, Jul 21, 2001 at 05:35:54AM +0200, Patrick J wrote:
> > > I might be totally off but how about _avoiding_ collision instead of
> detecting it ?
> > > Say all pics on the bus have ID:s #1..#5, and that also represent their
> priority on the bus.
> > > Now, for a pic to be allowed to send it must wait the number of mS that is
> equal to its
> > > ID number (2mS for pic with ID=2 in this example) AFTER the LAST detected
> > > transmission on the bus, before it starts to send.
> > > In principle a low priority pic can be 'starved' (no data) but if one can
> asume
> > > the high priority pics can behave and not take up all of the bus it should
> work.
>
> > It's always better if the protocol guarantees that starvation won't occur
> > instead of making it voluntary for high priority nodes behave.
>
> Not always; that costs more and is more complicated ?

The costs are pretty much the same. The only difference is that instead of
handling priority/fairness in the applications layer, it is handled at the
data link layer.

> This idea is intended for a friendly bus (low traffic)

A situation that can get very unfriendly if for any reason that application
decides it needs to transmit all the time. With the secondary slot scheme
everyone is bandwidth limited.

{Quote hidden}

Signalling can be done inband. Every hardware USART checks for spurious start
bits. When a start bit is seen, it's checked again somewhere between 1/3 and
2/3 of the bit width to make sure that it's valid. If the start bit is invalid
at the second check, it is ignored.

So in band signalling can be done by manipulating the transmit line in
intervals smaller than 1/3 of the bit time. For example everyone can monitor
their RX line for two blips within 1/3 of a bit time. This can signal the
negotiation and all of the UARTS will ignore it.

It does add some programming complexity. But I'm pretty sure it would work.

I do admit that my plan was to add a second signalling channel simply because
it's easier to implement and monitor.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body



'[PIC]:Thoughts on RS485 collision detection'
2001\08\22@074011 by Wollenberg, Frank
flavicon
face
On Sunday, July 22, 2001 10:24 PM, Douglas Wood [TakeThisOuTdbwoodEraseMEspamspam_OUTKC.RR.COM]
wrote
>
> I have a curcuit that utilitizes a full-duplex, multi-drop
> 485 network with
> collision detection/avoidance. I could forawrd you a copy if
> you'd like...
>
What solution do you have, hardware or software ?
BTW i'm interested in how do  you solve the problem "collision
detection/avoidance".
Frank
----------------------------
GSP Sprachtechnologie GmbH
Frank Wollenberg
HW-Entwicklung
Tel.:   +49 (0)30 769929-78
Fax:    +49 (0)30 769929-12
eMail:  RemoveMEf.wollenbergspamTakeThisOuTgsp-berlin.de


--
GSP Sprachtechnologie GmbH
Teltowkanalstr.1, D-12247 Berlin
Tel.:  +49 (0)30 769929-0
Fax:   +49 (0)30 769929-12
eMail: InfoEraseMEspam.....gsp-berlin.de
Web:   http://www.gsp-berlin.de

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\08\22@084729 by Tom Mariner

flavicon
face
I generally implement a hardware solution that uses the RS-232 ports to both
read and write at the same time for RS-485 products in a CSMA/CD
arrangement.

The software does the heavy lifting by checking if a sent message has a) a
bit corrupted, b) a byte corrupted or c) a checksum sent wrong (all by
employing a task to read my own outgoing message.) On the incoming, either
anomalies in the received message (illogical length, etc.) or bad checksum
will trigger a collision detection / corrupted signal. Then the program
falls into Ethernet mode and jams the line for a while to warn everyone that
something bad has happened. Then the sending station waits a random amount
of time (that's the collision avoidance part) before resending.

The code always varies depending upon the application, hardware, language,
etc. Haven't had much luck with token passing schemes.

Tom

> {Original Message removed}

2001\08\23@061004 by Wollenberg, Frank

flavicon
face
Hi Tom,
I understand. It's a implementation of CSMA/CD like in ethernet
applications.
But
- how do you make a back off on bit corruptions ? Do you check the
transmitted bit against the received bit on the TTL side with a XOR gate and
then generates an interrupt ?
- how do you defined the jam signal ? Sending a break condition, sending a
number of 0's or what else ?

In the past time, there was a discussion about collisions in a RS485 network
(was this in this thread?).
The result was, that in this case the differential voltage on the RS485
lines is not defined. This is the same, what i have seen in my application.
I have done a CSMA/CA implementation on RS485 (i'm currently porting this on
a half-duplex FSK-Modem, therefor only CSMA/CA). All sender are synchronous
to each other. Each packet has a pending CRC. When more than one node are
sending, a) the packet was corrupted, b) a high or low was dominant, c)
simply receiving garbage, and d) the CRC was ok, but the payload not. The
latter case i didn't expected, but the possibility for it was very very low.
Additional hint: I have used a LT1785 with external pull-up/down resistors
for True-Failsafe. On additional test adapters, i've used a SN75176B. On
collision, the TI chip has given me a complete different data packet as the
nodes with the LT chip has seen !!!

Frank
---------------------------
GSP Sprachtechnologie GmbH
Frank Wollenberg
HW-Entwicklung
Tel.:   +49 (0)30 769929-78
Fax:    +49 (0)30 769929-12
eMail:  EraseMEf.wollenbergspamgsp-berlin.de


--
GSP Sprachtechnologie GmbH
Teltowkanalstr.1, D-12247 Berlin
Tel.:  +49 (0)30 769929-0
Fax:   +49 (0)30 769929-12
eMail: RemoveMEInfoEraseMEspamEraseMEgsp-berlin.de
Web:   http://www.gsp-berlin.de

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\08\23@062729 by Alan B. Pearce

face picon face
>> I have a curcuit that utilitizes a full-duplex, multi-drop
>> 485 network with
>> collision detection/avoidance. I could forawrd you a copy if
>> you'd like...
>>
>What solution do you have, hardware or software ?
>BTW i'm interested in how do  you solve the problem "collision
>detection/avoidance".

Check out this document for one way of doing it. The serial interface does
run at a funny baud rate, but the principals apply to almost any system that
runs on a CDMA principle.

http://www.digitrax.com/loco1hdr.htm

The instructions and commands transmitted across the network as defined in
the document are trade property, but the implementation is applicable to
everything from Ethernet to what you are trying to do.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspamspammitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...