CAN vs RS485 in high RF Envronments
CAN vs RS485 in high RF Envronments
(OP)
Hi,
I am trying to decide which interface to use - CAN or RS-485. The bus will be within a high power (50kW) broadcast transmitter operating in the AM band (500 - 1800 kHz). My main concern is the noise immunity of either standard. Any comments or suggestions you might have to sway me either way would be helpful. If this issue has been dealt with in a previous post please direct me to it.
Thanks
I am trying to decide which interface to use - CAN or RS-485. The bus will be within a high power (50kW) broadcast transmitter operating in the AM band (500 - 1800 kHz). My main concern is the noise immunity of either standard. Any comments or suggestions you might have to sway me either way would be helpful. If this issue has been dealt with in a previous post please direct me to it.
Thanks
RE: CAN vs RS485 in high RF Envronments
Frequency range, distance, error rate ?
If just inside, I would use fiber optics...
<nbucska@pcperipherals.com>
RE: CAN vs RS485 in high RF Envronments
Thanks
RE: CAN vs RS485 in high RF Envronments
RE: CAN vs RS485 in high RF Envronments
If you want to use conventional cabling, apart from the obvious point of using fully shielded cabling, you would be advised to mount the various circuitry which will generate/use the data in totally screened boxes or compartments. The connectors should be of the type that have in-built filters in the pins so that minimal r.f gets into any of the screened boxes. Ideally you should use opto-isolators as well, to prevent ground loops between screened sections.
RE: CAN vs RS485 in high RF Envronments
about the shielded box: The shield/connector GND must not be connected inside the box but to the outside for even
a 1/2 inch wire inside can act as a coupling loop and bring
the HF into the box...
You may want to add filter. So it can be done but I think
you will spend many times on labor what you save on the fiber parts.
<nbucska@pcperipherals.com>
RE: CAN vs RS485 in high RF Envronments
RE: CAN vs RS485 in high RF Envronments
Both use twisted pair and differential drivers (CAN over fiber is possible, btw.)
CAN has the protocol handling already built into the CAN engine of your micro. With RS485 you would need to define your own protocol and error handling in software, therefore CAN is a lot more convenient. It uses a 16bit CRC over the max. 8 byte long message. Of course, if you implement your own protocol in RS485 you can have 128byte messages with 32bit CRC or whatever you desire, it is just more work.
Just try CAN with completely optoisolated nodes and shielded twisted pair and proper grounding structure.
Use a CANalazyer (e.g.Kvaser) to check for errorneous messages, otherwise you won't know how good the connection is. CAN is a very robust protocol, and the CAN engine tries a number of times to get the message through. The first indication of a problem is an inexplicable connection slowness.
RE: CAN vs RS485 in high RF Envronments
RE: CAN vs RS485 in high RF Envronments
The main differences between a CAN and a RS485 transceiver:
The CAN transceiver works like a RS485 transceiver, just with a dominant '0' and a recessive '1' state. The RS485 transceiver has both states dominant, therefore only one transceiver at a time is allowed to transmit, which results in the typical RS485 master/slave bus configuration. CAN is a multi-master protocol.
(Dominant means that a transceiver is forcing the line to a certain state; any attempt of changing the state before the transceiver releases the line means short circuiting it, which is obviously not good.)
Theoretically, you can use CAN transceivers for RS485 networks (just don't mix RS485 and CAN transceivers on the same line). Likewise, you can create your own recessive/dominant bits with a RS485 transceiver, by tieing the TX line to the desired state and using the TX_enable line for signal transmission, e.g what the National DS36277 does for J1708 communication.
If you use RS485, be aware that you will have to implement all the low level protocol stuff in software, e.g.
- creating data packets from raw data,
- implementing a CRC (not a checksum) with a tested polynomal
- re-requesting errorneous data
- error handling
RS485 will also limit you to a master/slave protocol, i.e. one computer in your network will be the master that polls all the other nodes.
How many nodes will your system have?
If it is just a point to point connection between two computers, then you are actually looking for RS422, not RS485.