I am intending to build some Atmega based home monitoring chips. I want to monitor temperature, humidity, and current levels. Current level monitoring would be done with an inductive pickup on AC lines. Additionally I want to have some pins on each monitor that can be used as remotely commanded GPIO.
My plan is to use Attiny84 chips to implement this. Each board would be fed with +15 VDC and +7 VDC. I can regulate this with 780x series regulators to +5 VDC and +12 VDC for powering the chips and any other sensors or relays I may wish.
Power delivery would use two pairs in Cat5e cable. Devices are to be daisy chained together. This leaves two pairs in the cable remaining. From what I have read, RS-485 seems like an attractive solution for data and control. The last device needs a termination resistor connected to it, but that should be easy.
If I understand correctly, adding a chip to my circuit like a MAX485 only adds the physical capability for RS-485 signaling. I still need a software implementation to communicate and furthermore and actual protocol for multiple devices to exchange data. I would have up to 12 devices daisy chained together with a single master. In a half-duplex RS-485 system, the bus basically acts like a party line.
The master device would perform the following functions in order during each communication round.
-
Sending a sync signal. This would be a known byte pattern, followed by an identifier and a checksum. The identifier would be a unique identifier for this communication "round". Additionally this data sequence would include the identifier of a slave device which is permitted in this round to send data.
-
Waiting for a grace period. This grace period is used to allow any unknown device to come transmit to the master a request to join the network.
-
Receiving data from the slave device designated in the sync data sent in step 1.
-
Sending control commands to any number of slave devices. This includes GPIO commands and join network acknowledgements. All control commands must be acknowledged later by the slave in a transmission back to the master.
The slave devices would be in one of two states
-
Unacknowledged by the master. It synchronizes on the sync signal and transmits in the grace period. In an ideal situation, the master transmits back an acknowledgement during step 4 of the next communication round. If the device does not receive this it waits a random number of rounds before trying again. This permits collisions in the grace period caused by multiple devices attempting to transmit to eventually be resolved.
-
Acknowledged by the master. The device transmits sensor data when indicated by the sync signal sent by the master. The device sends acknowledgements of control commands back as well during this time period. It ignores communications to and from other slaves with the master.
The idea behind this is that the RS-485 implementation in the Atmega controller is going to be software only. The device obviously cannot transmit and receive data all the time or it would not be useful as a sensor device. The length of a round in real-world needs to be large enough that error in the chips built in oscillator is insignificant. In this way, synchronization based off the signal from the master can be kept for several rounds without actually needing to receive or transmit data.
During the joining phase, this allows synchronization allows the slave to correctly identify the time period to transmit a join request.
Once the slave is on the network, it allows the device to know when to listen for permission to transmit and to receive data. It also means the device has an option to "skip" a round or rounds of communications to go perform sensor measurements, command GPIO, or whatever I need. The theory being that if the device was just permitted to send sensor data it will not be requested permitted to again immediately, nor does it actually have any new data.
The issue with this is that since a slave effectively drops out of the communications layer for at least one round, all commands to slaves must be acknowledged with a message back to the master. This permits the master to simply retransmit commands until acknowledged. This also means commands should be descriptions of state, not state changes. There is a very real chance a slave will execute a command more than once. I don't know exactly how acknowledgements will work, but it will probably just be a message consisting of an identifying number and a checksum.
Whatever checksum I use in this system needs to be cheap to compute because I'll be doing it on chips that only have 8 Mhz or so clock speed and are 8-bit computers.
The biggest drawback to this system I can see is that if the slaves are all power cycled for some reason they will all collide when trying to join the network in the grace period. This means it may take a very long time until they all rejoin the network.
Am I missing anything significant with this? Are there any big decisions I need to make that I have completely ignored? Is my understanding of RS-485 as as big party line accurate?
Best Answer
If you have a limited number of potential addresses (say 256) the master can always poll a currently unconnected slave address to see if it has sprung into action. So if you have 20 actives slaves, then the master polls a 23 rd slave each "round" and numerically increments the unconnected_slave_address for the next "round". It will only take a few seconds to do enough rounds to find a new slave and then the job is done.
No need to have a grace period; just one more slave slot will do the trick and when a new slave (or errant slave) is found it gets listed as "active".
And yes, RS485 is a suitable physical layer for this.
I would use low drop-out regulators and I would give the drop-out voltage a little more headroom - there will be maybe a volt induction from your local home AC wiring and this means the regulators need a bit more space to regulate properly.
I would also consider using Manchester encoding so that you can high pass filter the data received without fear of corruption. 100 kohm biasing after the capacitor should be OK no matter how many slaves you have in place i.e. it won't destroy the impedance matching from end to end of the cable. I don't know what data rate you intend to run at but working at or above 9600 Baud seems sensible to help the high pass filter block any AC pertubations. Yes I know RS485 is a current loop but if you can inject a little bit more hardware security at the design stage it will pay dividends.
Designing for Manchester encoding also gives you a better chance to implement RF links should there be a need for any in the future.
Just a few thoughts on doing this if writing your own protocol.