This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C24CC5.B7957990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit My thanks to everyone who has given me advice on this question -- really good info. I have speadsheeted the options, feel free to post corrections or additions: RS-485 RS-485 RS-485 CAN CAN I2C 75176 SN65LBC184 MAX485 MCP2510 18F448 P82B96 ~ max length ft @ ~500bts/hz 4000 4000 4000 2000 2000 1000 ~ max nodes 64[?] 128 128 100 100 1028 chip count 2 2 2 3 2 2 noise immunity high high high high high low transient suppression low high high high high low anti collision no no no yes yes yes disabled node dropout no no no yes yes no parts readily available yes yes yes yes no yes cost USD (quant 25) 5.86 7.08 7.21 9.09 7.45 7.34 Notes 16F877 16F877 16F877 16F877 82C250 w/ active 82C250 pull up I have gotten the other parts of my project worked out but this decision is a tough one. I can't just breadboard two or three nodes to determine if 25 (or more) PICs would be happy talking with each other. In a short time I have seen this list has a lot of experience and brain power so I'll share my current thinking for feedback. In this project, any node can randomly create an event that other nodes would want to know about. These events would happen about one every fifteen minutes or so. Events have different priorities. Sounds exactly like CAN territory but the 18F448 is currently scarce and the MCP2510 solution uses more precious pcb real estate and the additional cost adds up in large quantities. I think this is my choice if I can get enough of the 18F448 chips. I don't see any advantage of I2C over CAN w/18F448. The cost of RS-485 using the 75176 is certainly attractive. Using one master to poll all the others every second to determine a once in 5-15 minute event has occurred then the master telling each of the slaves the event occurred does not make sense to me. The suggestions from Douglas Wood and Dwayne Reid of having a node check the net for activity twice before transmitting is intriguingly simple. I especially like Dwayne's idea of every node waiting a different length of time. I would change that to adding the event priority (high priority = lower number) to the node id to determine the wait time. That way, a higher event priority would get transmitted first. I would also include nodes acknowledge all understandable transmissions using the same wait scheme with only one acknowledgement sent. This way, node 0 would normally send the acknowledgement but if node 0 went belly up, node 1 would take over, etc. If a node found the network to be busy, it would wait for the acknowledgment before starting a transmission. If two nodes tried to transmit at the same time, the message would not be understandable; they would not get an acknowledgement and would resend. If I can be convinced this would be reliable, it would be the way I'd go. So Douglas and Dwayne, do you have much real experience with this wait scheme? Are messages lost? Does anyone else have ideas or even better experience with this? TIA Nelson BTW: I went to the Mchip Masters conference thinking I would learn how to use these things -- I didn't. Following the piclist beginners guide and reading the piclist posts the last several weeks have been the best learning I have gotten so far. Thanks to all! ------=_NextPart_000_0013_01C24CC5.B7957990 Content-Type: text/plain; name="RS485 vs CAN vs I2C.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="RS485 vs CAN vs I2C.txt" "RS-485=0A= 75176" "RS-485=0A= SN65LBC184" "RS-485=0A= MAX485" "CAN=0A= MCP2510" "CAN=0A= 18F248" "I2C=0A= P82B96*" "~ max length ft=0A= @ ~500bts/hz" 4000 4000 4000 2000 2000 1000 ~ max nodes 64? 128 128 100 100 1028 chip count 2 2 2 3 2 2 noise immunity high high high high high low transient suppression low high high high high low anti collision no no no yes yes yes disabled node dropout no no no yes yes no parts readily available yes yes yes yes no yes cost USD (quant 25) 5.69 6.91 7.04 8.92 7.30 7.17 Notes 16F877 16F877 16F877 "16F877=0A= 82C250" 82C250 w/ active pull up ------=_NextPart_000_0013_01C24CC5.B7957990-- -- 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