Snowdonia Weekend Hack Session

Friday 27th August - The Mission Begins.

Your Mission (should you choose to accept it) - to develop from scratch, a network of serial slaves controlled from a Master Arduino and to use it to monitor a photovoltaic renewable energy system.

Time Allowed 3 days.

Personnel:

Trystan Lea - Chief Coder and host
Suneil Tagore - Renewables Consultant
Ken Boak - Hardware builder and tea maker

Resources:

10 Arduinos of various types - official, Freeduinos and DIY breadboarded units
2 NuElectronics Ethernet shields
1 Etherduino - a DIY ethernet compatible clone built on breadboard.
Box of useful electronic component bits
2 x 75W solar pV panels
Hall effect sensors for current sensing
110Ah Deep cycle battery
200W 120V Inverter
500W UPS found in skip - cruddy modified sine wave
250m drum of ethernet cable
Lots of tea and firewood

Location: Secret Snowdonian Bothy - outside the Trawsfynydd Nuclear Plant Fall Out Zone

Over the course of the August Bank Holiday I was invited up to North Wales to join Trystan Lea and Suneil Tagore, of openenergymonitor.org for an extended weekend build session with the aim of further developing the openenergy project. Trystan had developed a number of Arduino based control systems and was looking for a way to connect them together as a network.




I had first met Trystan and Suneil back at the April 2009 Homecamp Un-conference, and was impressed with their open source energy monitor based on the Arduino. We had kept in close touch over the last year and the plan was to pull our collective ideas together over the course of the weekend and develop some of the concepts into a working system.

I had recently been working on "Etherduino" a web-enable compatible Arduino built on breadboard, and I had a few ideas on how we could put together a network consisting of a Master and several Slaves - all connected with a 9600 baud serial wired network.

The openenergy devices are a series of Arduino based units that can be applied to electricity monitoring, controlling solar water heating, gas meter monitoring and other purposes related to energy conservation and renewables. Trystan had already developed the electricity monitor and the solar water heating pump controller, but wanted to tie them together with a simple remote display so that various paramenters could be viewed from a central display - for convenience located in the kitchen.

I had donated a couple of solar panels to the project, and we decided a good use of the network was to use it to extend the openenergy system to monitor a small pV system and control an inverter and battery system.

So with all these individual elements working in isolation a plan was devised to develop a low cost, simple means of connecting them together in a network so that they could be monitored and controlled from one central point by a master device.

The Concept Emerges.

The Arduino, and many other microcontroller based devices,generally communicate via a serial interface, running at TTL levels and modest baudrates. On the Arduino, the standard is 9600 baud, and this makes communication with a laptop easy using a FTDI serial to USB cable.

We had decided that because the cost of adding a microcontroller slave to a system was in the order of £5 per node, then it was cheap and easy to compose a system of a series of distributed nodes all communicating through a network.

We agreed that the system of simple slave boards connected by a wired network would be easiest and cheapest to implement, and as the Arduino is fundamentally a device with serial input and output and a serial programming interface we thought that we would stick to a simple text based serial interface running at 9600 baud 8,n,1.

In oder to make the network easy to build, test and modify, it was decided to keep the logic levels as those of the Arduino, and not introduce any further complication such as differential signalling (eg RS485). In essence, one Arduino can communicate with another just by cross-connecting their Rx and Tx pins with a cable and providing a common signal ground between the 0V GND pins.

We realised that for the network to be practical it should allow several devices to be connected to the one network, and there should be some method to prevent them all trying to access the network at the same time - which would lead to very corrupted data and a breakdown in communications.

We also wanted to distribute dc power down a spare wire of the network, so that this could be used to power the microcontroller and sensors at the far end. As the Arduino is fundamentally a 5V part, we wanted to restrict the voltage on the bus to +5V so that any accidents in wiring would not result in damaged ICs.

Finally we needed a method to prevent more than one device accessing the the Tx line at the same time. Thus a 4-wire network was selected with the signals being Tx,Rx 0V and +5V. This made the use of cheap telephone cable or CAT 5 network cable quite practical.

The next question was how far could we reliably send 9600 baud down a telephone extension cable and get uncorrupted data at the far end? After a few beers on Friday night we did some simple tests using a 30m length of 4 core cable connected to and Arduino and found that 9600 baud was quite happy over that distance. With this proven we were ready to specify, design and build the full network.

Day Two - Saturday 28th August

On the Saturday morning I built up a couple of slave Arduinos on breadboards - and because they were fitted with displays, we decided to call them Disciples. The plan was build up identical hardware and document it, so that I could take a unit back to London and one could be kept in Wales - so that both Trystan and I were working with the same platform.

The Disciple consisted of the ATmega328, a 16MHz clock circuit and a header to allow an FTDI cable to be plugged in for programming. In addition, a 74AHC125 quad tristate buffer was fitted which allowed us to drive a cable network, with only one slave transmitting to the bus at a time. It was later decided that we would also use another '125 buffer on the Rx line of the slave, to improve the signal from the network and to allow the slave Rx pin to be isolated from the network for local programming operations.

By early evening on the Saturday we had managed to connect two Disciple slaves to the network and Trystan had written a sketch which accessed them individually form the Master and sent a command to flash an LED. Very soon we had both slaves "ping-ponging" their LEDs on and off under the complete control of the Master Arduino.

Day 3 - Sunday August 29th.

Not such an early start because we were tired from the previous mega-hack session. The aim for the day was to incorporate the slave code into a photovoltaic solar panel and battery monitoring system.

Much of the morning was spent wiring up the pV monitor panel with two Hall-effect sensors - one for pV current and the other for load current. A bank of 5 relays controlled by the Arduino allowed 5, 12V lamps to be selectively turned on, thus putting a variable load on the system. this was a first step to developing a full maximum peak power point tracking system, which Suneil is working on.

By lunchtime the sun was out and we were starting to get a peak of about 10A at 14V, which was about all my 75W panels were capable of.

Trystan then started to merge the slave control sketch with the pV monitoring sketch - so we could get remote pV data - volts, amps and watts from the pV controller and send this data up to the master unit. The 74AHC125 tristate line driver was temporarily added to the pV controller on a separate breadboard, to be tidied up later once we had the system working.

Towards the end of the afternoon we had 3 slaves working on the network, one of which was the pV monitor. Fortunately this co-incided with a sunny spell and the pV panels were in full sunshine and being remotely monitored.



We then set about writing some code to send text to the Disciples (display slaves) such that the command packets send on the network would be displayed on the second line of the LCD, and any response from the Disciple would be echoed to line 4. Below is the display slave displaying a typical net packet. @,28 selects slave 28, and this is confirmed when the green "slave active" LED coming on - bottom right.




Shortly after that we went down the village pub for a well deserved pint (or three) and an evening meal. The weekend had been a great success and we had achieve all of our objectives - and there was still Monday left to tidy up a few loose ends.