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?
