7
\$\begingroup\$

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.

  1. 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.

  2. 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.

  3. Receiving data from the slave device designated in the sync data sent in step 1.

  4. 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

  1. 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.

  2. 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?

\$\endgroup\$
  • \$\begingroup\$ That seems awfully complicated. How do slaves know their identifier (address)? \$\endgroup\$ – kkrambo Jul 16 '17 at 13:44
  • 1
    \$\begingroup\$ @kkrambo slaves initially have no address on first power up. They receive one from the master and then write the address and a checksum into an address into the internal of the EEPROM. Alternatively I can do this on my workbench if I need a specific device to have some specific address. \$\endgroup\$ – Eric Urban Jul 16 '17 at 15:57
  • \$\begingroup\$ I recently built a Weather monitoring system with many of the same sensors distributed throughout my property. I opted for CANbus rather than Modbus, because the chips were plentiful and cheap on eBay and allowed for vast distances (500m-1km) between nodes! \$\endgroup\$ – Tom O'Connor Jul 16 '17 at 20:21
4
\$\begingroup\$

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.

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.

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.

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.

\$\endgroup\$
  • \$\begingroup\$ Thank you for your reply. Can you provide an example circuit of high pass filtering the data with a 9600 baud data rate? \$\endgroup\$ – Eric Urban Jul 16 '17 at 15:55
  • 2
    \$\begingroup\$ Well you use capacitors to connect each slave to the common line and you have biasing resistors at the A and B terminals of the 485 interface slave side of those capacitors. If Manchester encoded at 9600 bps, the lowest frequency is 9.6 kHz so if using 100 k pull ups and pull downs on each A and B line you need to choose a capacitor value that produces a high pass 3 dB point at about 1 kHz. Sounds like a 3n3 is suitable for AC coupling - it forms an RC cut-off of 964 Hz and will block 60 Hz quite well. \$\endgroup\$ – Andy aka Jul 16 '17 at 16:10
3
\$\begingroup\$

On the wire level RS-485 is a "party line". RS-485 is easy to implement when there is a single master. If your devices don't require "P2P" connectivity (eg. the current sensor does not care what the humidity is) then Modbus is a proven and simple solution. Don't reinvent the wheel.

I've used FreeMODBUS with many AVRs to implement slaves (it is quite bloated, but memory is cheap). You can buy a USB<->RS485 adapter and run software like qModMaster to test your sensor or use libmodbus to write your own programs.

If you need "multi master" then RS-485 is a very bad choice and your medium access control will be complex (been there, done that). In that case CAN would be the usual choice.

When connecting many devices to a single bus make sure to not exceed the maximum unit load of your transceivers.

\$\endgroup\$
  • \$\begingroup\$ I will run a single master. I will look at FreeMODBUS. My concern with modbus is it seems to be designed to do everything even though my use case is limited. \$\endgroup\$ – Eric Urban Jul 16 '17 at 15:54
  • 1
    \$\begingroup\$ You don't have to implement everything. You basically need "read registers" and "write register" function codes. \$\endgroup\$ – filo Jul 16 '17 at 16:12
  • 2
    \$\begingroup\$ I've used Modbus over both RS485 and Ethernet. The protocol itself is very standardized and works as long as you get the wiring straight (for RS485 - Ethernet it is painless) and have a single master. What the registers actually mean varies a LOT and there is no standard there. I have found every possible combination of byte orientation, floating point format, etc. Some implementations "extend" Modbus by using a value in one register to change the use of another register or do other wacky things. You can make your own "standard" and it will be as standard as anyone else's Modbus. \$\endgroup\$ – manassehkatz Jul 16 '17 at 16:37
1
\$\begingroup\$
  1. I would reconsider the hardware platform. Use something cheap and modern like stm32f0 or f1 chips. You will have all nessesary hardware (including can)
  2. Do not overcomplicate simple tasks. Your idea is a perfect example of "how do not make the communication".
  3. Use something existing and standard like modbus. You will be able to connect another devices as well.
  4. Multimaster system is too complicated for the home automation system.
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.