Communication Protocol Needed

[Jamesthresher]

Hi All,

I am hoping that someone can help with a problem i have with a project i am working on.

The devices i am designing are essentially fancy relay controllers, the devices can operate independently, however i also need the ability to connect up to 6 of the devices together (although it could be any number of devices connected between 2 and 6, possibly more if needed). They are based on the Atmega328 micro.

Each device needs to be connected over a distance of no more than say 10 meters and if at all possible the protocol should be resilient to interference as these devices will be used in a high RF environment (1-500Mhz). I don't need a huge amount of bandwidth between the devices so speed is not a massive issue.

I've been struggling to come up with something suitable so i'm hoping that some of the very knowledgeable people that hang around on these forum's can help.

Thanks

[allanw]

RS-485?

[Jamesthresher]

RS-485?

Thanks, that looks like it should do the trick, i will look into it further.

[codeboy2k]

RS-485 might be a suitable electrical interface, but he still needs a protocol.  ModBus RTU is common on rs-485 but probably far too complex if all you want to send is some relay open/close commands, maybe some status.  Since it appears like you don't have to worry about being compatible with other bus protocols in the wild, and if your needs are really quite simple, I'd suggest a simple time-division multiplexing (TDM) scheme on a multi-drop RS-485 bus. There is only 1 master, all communications are initiated by the master, and the slave only reads and writes data during it's time slot. The time slot is easy to calculate based on the slave ID, all slaves first listen for the master to send a sync/heartbeat/command packet, which starts the slaves timing for when then can transmit data. Each slave that has data to send will only send it during it's time window.  [ slaveID  x length of slot ]. Commands to the slaves are always sent at the start of a cycle, initiated by the master. after all the slaves have sent data and the time has elapsed for a complete cycle, it starts again.

This kind of protocol can be low overhead, fast cycle times at high bit rates, and easy to implement on small memory micros.

[JohnS_AZ]

Wouldn't it even be simpler to do the 485 but use a polling protocol? Slaves only speak when spoken to.

Or you could consider DMX. Loads of existing hardware. http://en.wikipedia.org/wiki/DMX512

[RayJones]

CAN

Multimaster Multidrop slow down the bit rate if need be.

The major difference with CAN is the messages describe the payload, so it is not neccessarily a point to point protocol.
It is quite common for multiple nodes to react to the same data packet if required.

And it is also "pseudo" differential.

[tecman]

RS-485 is the simplest and lowest cost to deploy.  It can also be very robust.  We have used it for years with very good results.

Most RS-485 is based on master-slave.  Only one master, and only the master can initiate communications.

Try a simple protocol:

<SOH> <address of slave> <length of data or nothing if data can be fixed length> <data> <end of message and/or checksum>

Simplest can be:

SOH - 1 byte
addr slave - 1 byte
data - tbd
checksum - 1 or 2 bytes

response from slave:

<data> <end of message and/or checksum>

Works well and can be simple.  Only issue is that SOH is a hex_01  If your data contains hex_01 as valid data, then you will need to do one of two things:  Repeat 01 twice if it is data, and strip the second 01 at the slave, or use 9 bit protocol.  In 9 bit you can eliminate the SOH and use the 9th bit to indicate a new message.

Alternatively of you are sending defined data messages and you only need numeric data, you could limit to sending only ACSII numbers 0..9 and therefore not have the 01 (SOH) as a possible data value.

paul

[crusader66]

I am curious if you would find it much cheaper to buy a low cost PLC module such as AutomationDirect's Click Series C0-01DR-D, 8DC Input/6Relay output.  That one module addresses your entire relay requirement and adds the ability to monitor up to 8 inputs and contains a port to connect the PLC to ModBus.  Maybe your operating environment prevents a device such as this. 

You could wire the inputs to discrete switches or get a touchpanel interface to connect to the modbus port and write ladder logic to accept input from manual switches or from the touchpanel.  You could also add a subroutine to automate the 6 relay sequence (if there is one). 

I don't want to discourage a design project.  I just know that I get irritated by designing something and then figuring out I could have bought something fairly cheap that would have been easier to implement.  That particular PLC is around 100 dollars and software is free.  I believe Schneider has some DC input/Relay output modules that are also cheap and come with free software. 

[scrat]

CAN
[...]
And it is also "pseudo" differential.

What do you mean with " "pseudo" differential"? From what I see, there is a two-wire differential data line. Is it "pseudo" because of the common ground, so that driving is made by driving High/Low the line with respect to ground? However, receiving is differential...
Which are the main advantages/disadvantages of the physical layers of CAN towards RS-485?
Thanks.

[RayJones]

I refer to it as pseudo since a logical 1 (recessive state) has both lines sitting at the same sort of mid scale voltage (usually about 2.5V).

A 0 has one line driven towards ground, the other driven towards rail.

True differential sees a deliberate reversal of the lines relative to each other.

The inbuilt logic of the CAN controllers easily allow a multimaster system to be implemented due to the way the collision detection system works, and this relies on the way the differential bus is made to work. ie it idles at a recessive 1 level, and a 0 always wins if two masters attempt to drive opposing levels.

Another aspect of CAN is the messages identify the data, so nodes can simply push their status onto the bus without worrying about collisions (the controller holds off if a collision is detected) or master/slave polling strategies.

You may not need multimaster at the moment, but if you think it may come in handy CAN is worth considering.

[scrat]

I refer to it as pseudo since a logical 1 (recessive state) has both lines sitting at the same sort of mid scale voltage (usually about 2.5V).

A 0 has one line driven towards ground, the other driven towards rail.

True differential sees a deliberate reversal of the lines relative to each other.

The inbuilt logic of the CAN controllers easily allow a multimaster system to be implemented due to the way the collision detection system works, and this relies on the way the differential bus is made to work. ie it idles at a recessive 1 level, and a 0 always wins if two masters attempt to drive opposing levels.

Another aspect of CAN is the messages identify the data, so nodes can simply push their status onto the bus without worrying about collisions (the controller holds off if a collision is detected) or master/slave polling strategies.

You may not need multimaster at the moment, but if you think it may come in handy CAN is worth considering.

I see, thanks for the explanation. I wonder why they did end with such an electrical signalling: even if it was a real differential bus, it could have zero symbol as dominant and one as recessive... Of course, Bosch engineers surely made that choice for a reason.

[Bambur]

I would suggest to take (or make) a protocol with some error detection (and possibly correction) built-in, since you mentioned an RF-rich environment. You should decide how the physical layer looks like, i.e. how the connection works in terms of voltages and currents, and then decide on the logical layer, i.e. how the data is transmitted and received logically. For instance a cheap RS-232 or RS-485 would probably do well as the physical for slow data rates and short range connections. Using a CRC checksum with several sequential transmissions of the same message would be good enough to detect and drop corrupted messages with errors, besides it's easy and fast enough to do the CRC calculation in MCU.

[tecman]

I assume from the original post that the requirement is for a simple bus.  CAN is a more costly method since you need a CAN controller chip, a driver (interface) chip and much more code.  CAN has advantages of being more robust with error recovery, multi-master capabilities and a nice prioritized addressing scheme.  While all of this is nice, if it is not a demanding system and operating over a short distance, with only a few nodes, RS485 makes more sense than CAN.

If one wants to play with CAN, that is one thing, but low cost, simple and robust makes 485 a good choice.

paul

[Jamesthresher]

Thanks for all the great suggestions everyone, it's been extremely helpful.

On balance i think that i will go down the CAN route. Multimaster would be a huge advantage for this project, especially when combined with interface IC's that are suitably priced for the project and use SPI which makes my life quite a lot easier on the micro side of things.

Crusader66, while i'm sure that there are many off the shelf relay solutions, unfortunately they don't fit for this requirement.

The project provides a physical push button controller, each button (or combination of buttons) will switch in one or more relays, which ones can be programmed via a usb interface which can also be used to either control the switching via PC and/or provide feedback to the computer when a user selects a button. At the same time many devices can be connected together so that they can notify the other devices about which relays are switched in and potentially lockout those button selections on the other devices. At the same time it must have a high level of RF immunity.

I have a single device prototyped and working in isolation but was struggling to find a suitable solution for the interconnections between separate devices.

Given these requirements CAN seems to make a lot of sense.

Thanks again.

[RayJones]

You will be happy with the final outcome using CAN.

Yes there is a learning curve involved, but it will be worth it in the end.

If you go simple, you may end up cursing it in the end especially if you do want nodes to chat to each other peer to peer not client server.

Best thing to do is devise a set of ID codes you wish to employ and work from there.

I've done a bit with the PIC18F2580 which has the CAN controller built in, and only needs a bus transceiver.

Just make sure you terminate the bus!