Over the course of the Bank Holiday Weekend, we took off to the remote hills of Snowdonia with the purpose of developing a simple serial communications network for the Arduino based hardware using the ATMega328.
The emphasis was on simple. It had to be something that any Arduino enthusiast could wire up on a breadboard and get working, and it had to be low cost. I accept that there are better network drivers such as RS485, and a whole host of protocols, but as this was to be partly an educational exercise, as well as a bit of fun, the methods used had to be clear and easy to learn.
In the previous post I introduced the design. Now I share some of the more specific detail of the implementation. A later post will cover the programming and command specification.
Background - the need for a low cost sensor network.
The openenergy project is all about finding cost effective ways to monitor and control renewable and domestic energy systems, such as solar water heating, photovoltaics, electricity and gas monitoring.
We had realised that with very low cost microcontroller hardware, we could afford to use a micro at each sensor node, to make a network of distributed smart sensors. The Arduino project has given a great opportunity to make low cost hardware for as little as £5 per device. The next logical step was to find a cost effective means of connecting such devices together in a network, co-ordinated by a Master unit. Sensors could be interrogated by the Master, and then with a web-enabled Master, the sensor data could be accessed remotely via the internet - using a service such as Pachube.
The system was intended to be cheap, and easy to build for the sort of people who tinker with Arduinos. We could have used a more elaborate system based on RS485, but in order to introduce beginners to networking devices, a very simple signalling method was devised. It uses a single 74AHC125 quad tristate buffer as a line driver, and 5.08mm pitch screw terminals for connecting the network cable - so no fancy connectors or crimping tools are needed to make a connection. It is designed in a way to be compatible with stripboard or built on a low cost protoshield. Indeed, on stripboard, a slave Arduino can be built for under £5 including the ATmega328. The first prototypes were built on breadboards, so that they could be readily modified as new ideas were tried out.
The weekend consisted of building experimental hardware, debugging it and writing firmware to get it running. It was in many ways a learning exercise, as each step of the design we had to work out from scratch. During the course of the weekend, we learned a lot about networking microcontrollers and devising simple control structures in firmware to get it to work as a system.
Day 4 Monday 30th August 2010.
We started with the basic stripped down Arduino consisting of ATmega328 and 16MHz crystal and added a 74AHC125 quad tristate line driver chip. The line driver allows the Arduino to communicate over several tens of metres of 4 core telephone or CAT5 network cable, and also allows an addressing scheme such that only one slave has access to the network at a time - to avoid conflicts.
We devised a simple serial protocol, which can be typed in at a terminal emulator, and using a FTDI cable, access any slave on the network and set up a one to one communications session. We also devised a sketch to run on a standard Arduino, such that it could act as a master and control several slaves. For the purpose of demonstrating the system we built up 3 slaves and connected them at 30m, 35m and 40m respectively away from the master.
The network consists of 4 wires: TX, Rx, +V and 0Vand we used some CAT5 UTP network cable we had available. It could equally work on standard 4 core telephone cable (CW1308 - about £12 for 100m). This wire has a resistance of about 97 ohms per km, and this dictates the voltage drop seen at the power terminals of the remote slaves. A 100m length will drop about a volt if the slave draws 100mA.
We standardised on the following colour scheme, which is loosely based on the ethernet standard but just using the solid colours - rather than the colour/white striped pair - which would be used if we were working with RS485 differential signals:
Brown +5V supply from regulated psu to power all slaves. We used a 2A 5V supply.
Blue 0V system and signal ground return line.
Orange Tx Transmit signal from Master to Slaves
Green Rx Receive signal from Slaves to Master
The use of orange and green for Tx and Rx is the same as ethernet colour coding
The aide-a-memoire for the colour scheme is that Orange is the Outward transmission from the Master.
Our DC power was put on the brown and blue wires. We chose brown for +5V, purely because in the UK we associate brown with live and blue with neutral. This might be in conflict with some of the Power over Ethernet recommendations - but it seemed logical to us at the time.
Above. An Arduino connected to the network using a quad buffer chip and driving a serial LCD.
The 74AHC125 can be thought of as our network access chip. It uses it's tristate buffers to either isolate or connect the Rx and Tx lines of the Slave chip to the network. In order to control the network, and programming operations, we provisionally reserved 3 digital output lines:
Digital 5 /Tx Tristate Enable Setting this low connects the Slave Tx to the network
Digital 6 /Rx Tristate Enable Setting this low connects the Slave Rx to the network
Digital 7 /Autoreset Setting this low causes the Slave to reset itself and allow over network re-programming.
For the simplest network implementation only digital output 5 is needed.
Below: The network chip and the 4 way screw terminal block assembled on a small breadboard to add the network to an Arduino. These parts could be assembled on a protoshield or just a bit of 0.1" stripboard. The basic network uses Rx, Tx and digital output 5 to control the Tx tristate buffer.
We found that connecting digital 5 to an LED connected through a resistor to +5V made a good indicator - lighting up when each Slave had been selected and was communicating with the bus.
If the anode of the LED is connected to the Tx pin rather than +5V, the LED will come on when selected and flicker whe the slave is sending data to the network. A similar LED on the Rx line shows when there is commands or traffic from the master on the Rx bus.
Connecting the 74AHC125
Pin 1 Tx Enable Connect to Digital 5
Pin 2 Tx Connect to Digital 1 (Tx)
Pin 3 Output Connect to green network wire
Pin 4 Rx Enable Connect to Digital 6 (or 0V on simple system)
Pin 5 Input Connect to orange network wire
Pin 6 Rx Connect to Digital 0 (Rx)
Pin 7 Ov Connect to oV ground (blue wire)
Pin 14 +5V Connect to +5V (brown wire)
Pins 8 - 13 of the 74AHC125 remain unconnected, but could be used for other buffering tasks.
If the 74AHC125 is mounted on a small piece of stripboard or protoshield, a 4 way 5.08mm pitch screw terminal block can be used as the connection to the network. It can be inserted next to the 74AHC125 such that it connects directly to pins 3, 5 and 7 leaving only +5V to be connected to the remaining pin.
In the afternoon we decided to prove the distance over which we could send data. We had a drum of 250 metres of CAT5 UTP (unshielded twisted pair) network cable, which we quickly added to our experimental network and hastened together another display slave.
After a quick reprogram of the Master we now had a master and 4 slaves on the network and a total cable distance approaching 300 metres. The Master could successfully transmit and receive data from all of the slaves and display data on a remote LCD connected to the slave that was 300m away from the master.
It would be a relatively simple matter to enhance the network to use differential signalling - such as is used in RS-485. Instead of the 74AHC125 driver chip - a couple of MAX485 (or similar) differential line drivers could be used. Taking this approach would allow the Arduino to be used as a DMX (lighting) controller. However, we chose to remain with simple TTL level serial - as this is the native signalling format used by the Arduino, adequate for our purposes - and it is easy to look at and debug with an FTDI cable to monitor the TX and Rx lines.
The first application for the networked devices was to control a photovoltaic monitoring system. This unit measures the voltage and current produced by a pair of 75W solar pV panels and monitors the charge into a 12V deep cycle lead acid battery. If the battery reaches a full state of charge, a dump load consisting of up to 5, relay selected halogen 12V bulbs could be turned on. Trystan wrote some firmware to obtain voltas and amps readings from the solar controller and send them to the Master device, and a programme running on the Master determined when the dump load relays should be activated.
All in all, a very successful and useful addition to the openenergy.org project.
The Snowdonia Mega Hack Group are (left to right)
Suneil Tagore, Trystan Lea, Ken Boak and Glyn Hudson.
3 comments:
Thanks for sharing such a nice post.
Very interesting! - looking forward for schematics and code :-)
Thanks for sharing!
Ian
A little curious why none of the standard serial protocols were used, nor were the physical interference-rejection properties of twisted-pair cabling? Seems a bit like reinventing the wheel, or at least casting aside a lot of good work already done by experts to solve these very problems.
Post a Comment