Navitrino goes MEGA

For some time I have been developing a central heating controller as the first application under the Navitrino banner.

Whilst it's never going to be the smartest or neatest heating controller, the knowledge gained in doing this relatively straight forward project will boost my experience of programming embedded hardware in C, and give me a whole set of new devices to play with, such as an SD card interfaced using the SPI bus, real time clocks, one-wire devices, ethernet controller interfacing and writing to modern displays such as those found in mobile phones. Navitrino is essentiallly a navigation exercise through the world of modern consumer electronic devices.

One of the problems I have found, is that it it is difficult to develop new code, whilst your one and only Arduino is busy runing a central heating controller. Obviously the solution was to get another Arduino - but it would be a shame not to take the opportunity to go for a massive hardware upgrade - which meant buying an Arduino Mega.

The Mega has been widely copied in China, and a look on TaoBao.com - the Chinese equivalent of Ebay, turned up loads of examples, including bare boards and other interesting shields. Whilst you can buy a Mega for as little as £17 from Hong Kong, I decided that I couldn't wait 3 weeks, so in a rash move, splashed some cash to CoolComponents and bought a brand new Mega 2560.

The Mega 2560 is the latest offering from the Arduino stable - and it is an Italian born throroughbred. It uses the Atmel ATmega2560 processor which is a 100 pin quad flatpack - bristling with I/O. No more would I be restricted to the 19 I/Os on the standard Arduino - now I would have 3 extra comm-ports, 10 more analogue inputs, 32 additional digital I/O lines plus the I2C port brought out to its own connector.

In terms of memory, the ATmega2560 has 256K of flash, 8K of RAM and 4K of E2. That should be more than enough for the largest of projects. The Mega 2560 is still quite costly - in fact you could buy two Chinese import Mega 1280's for the same price. Once the Navitrino application code is stable - I expect that it will fit into 128K - so the cheaper Mega 1280 will be the preferred option as the starting platform.

I've also bought the Nokia 3310 LCD shield from NuElectronics, which at £10 is good value for money. It can be set up as a 5 line x 16 character display, but can also display bitmaps and larger font texts. Andrew Lindsay has written an improved library to give better graphic functions and fonts compared to that supplied by NuElectronics. The Nokia shield also has a 5 axis miniature joystick with a tact switch action. This is connected to a resistor divider chain such that it produces an analogue value for each of the 5 axes.

I have modified the shield so that the reset switch can be used as a "hot water boost" button. This was done simply by removing the reset pin from the shield, clipping off the remaining plastic header which held the reset pin, and connecting a resistor from the exposed "reset" pad to the adjacent via which connects to the end of R14. I used a couple of 0603 resistors (8K2, 3K9 in series) but a 12K 1206 would fit. Pressing the reset button then generates an analogue value - just like the other switches on the joystick. For my choice of resistors it gave an analogue value of 916.


I also modified the board so that the power LED can be driven from digital output 2. In this way the LED on the shield can be driven independently from code to signal when the water is hot - flashing when the water is heating and staying on full time when the water has exceeded the 45C comfort temperature. These two new features allow the Nokia 3310 shield to form the basis of a simple user interface for the central heating controller.


The plan is to use the mega initiallly to develop a user/programming interface based on the Nokia 3310 shield and then the mega will eventually become the master or hub device with the ethernet connection which talks to a number of slaves. I'm also interested in seeing how the Mega can be adapted to present a series of identical ports - just like JeeNodes so that any device can be plugged into any port.

I've also bought some DS18B20 temperature sensors which I'm going to use to extend my temperature sensing network to allow four more rooms of the house to be monitored. It's an important addition to the basic controller - and there is a lot of interest in using one-wire sensors which use considerably less I/O pins than the equivalent thermistors.

Navitrino Heating Controller - Update

As an update to the status of my Navitrino heating controller project.

A flurry of hardware bodging and C coding activity this weekend has now got the 4 channel relay board fully operational. The relays control the central heating, hot water and the various pumps and valves in the system.

The relay board will be housed in a plastic cased "wiring centre" - either Honeywell or Danfoss - available for about £10 and located in the airing cupboard next to the existing controller where it is close to the pumps, valves and tankstats.

The HW and CH relays will be wired in parallel with the existing controller. This allow the existing controller to continue to be used whilst development progresses - so that hot water boost can be used.

The relay board just needs a 3 wire serial link back to the main controller so that it can receive the various relay-on commands. Ultimately this link could be wireless and would appear to be an ideal use for a pair of JeeNodes - a good way of getting to learn about the JeeNode project.

The main controller will remain in my work room until development has finished, but a display slave can be situated in the living room, so that anyone can access the "normal" thermostat controls from downstairs and without a degree in computing science/electronic engineering.

The aim is to progress to the point where the heating controller can standalone without the laptop running. There's nothing more frustrating to find that Windows automatic updates has shut down your application at 3:18am, whilst you were in the middle of a long datalogging run. This embarrassment will shortly be fixed with the Navitrino logging directly to SDcard, with no more need for a permanent connection to the laptop.

The code is progressing well, I can now handle heating decisions made on time of day and day of week. For example, at weekends the controller automatically sets the room temperature a little higher during the day, and doesn't start heating till 7:30am, rather than 5am on a workday. Virtually any set of rules and exceptions can be programmed in - it's just a case of deciding which ones are actually useful.

Testing has now ceased for the evening - as a result of an uncontrolled heatsource being ignited in the living room.

Time to sit by the woodstove and watch TV.

Jeepers!

JeeLabs and JeeNodes

The Arduino community spawns some interesting derivatives. One such device is the humble JeeNode from JeeLabs. JeeLabs is the company founded by seemingly tireless innovator Jean-Claude Wippler.

http://jeelabs.org/intro/

The JeeNode is a long thin pcb with an ATmega328 down the middle and a Hope RF RF12 transceiver at one end. It is loosely inspired by the RBBB (really bare bones board). The originals were made entirely from conventional components for easy DIY assembly.

I have known about these little ATmega328 and wireless tranceiver boards for some time now. However, I hadn't realised how much stuff this guy had done in the last 2 years.

His main innovation was to fit the low cost transceiver (£5) to every board - so wireless comms is central to the design. Secondly he arranges the I/O in four identical "ports" which carry one analogue I/O, one digital I/O, common interrupt, power and ground. As all ports are identical, any of his peripherals can plug into any port. To me, this seems a really neat way of arranging hardware, making it modular and expandable.

Just browsing through his hardware blog, he writes about something new almost every day, producing dozens of innovative little devices. I presume he has a software blog too !

http://jeelabs.org/category/hardware/

Lots of good stuff, well thought out and implemented - and almost all of it compatible with Arduino.

Whilst for compactness, he uses the 6 pin 2.54mm SIL header on his boards, he also expands these out to a 6 pin RJ11 connector, so that he can connect things up easily with very low cost telephone extension cables - about £1 for a 5m double ended cable.

Mindstorms

I was recently reminded of this connection method when I saw the Lego Mindstorms kit at an exhibition in London earlier this week. Mindstorms now consits of a vast number of sensors and motor devices, all of which are easy plug-compatible with the NXT controller. The NXT "brick" controller is quite a sophisticated device with an ARM 7 as the main processor and an ATmega as the I/O controller. It has 4 identicalI/O ports A-D and 3 motor ports which provide PWM power control of motors and tacho position and speed feedback. Wow! hasn't Lego grown up in the last few years - the height of sophistication in my early days was an electric Lego trainset.

So, the JeeNode identical port design is a great way to get a standard interface to hardware devices, and the wireless comms is a well considered addition. The RF12 module can run at any of the sub-1GHz standard ISM bands, and has a range and data bandwidth ideally suited to this application.

JeeMax?

So what if you built one of these around an Arduino Mega? (ATmega1280 or 2560) 16 identical ports with some I/O left over. As RJ11 sockets are only about 13mm wide, with 8 down each side, the board need only be about the size of an existing Mega. (108 x 54mm).

With each connector carrying AIO, DIO, power, ground, INT and unregulated power (eg 12V) a whole variety of different sensors or devices could be plugged in. Devices could be simple - such as a thermistor or PT100, or smart - such as microcontrollers or memory devices. Devices could be fitted with a very low cost 8 pin ATtiny, which gives them a unique identity, and allows the hub to identify their function - a bit like USB ennumeration, but simpler.

Using a larger pin-count micro on the device, would allow multiple channel sensors to be plugged into a single port - for example Trystan Lea's 12 channel pulse counter, or an 8 channel temperature sensor, or a 4 channel relay board. This would easily allow you to expand up to a large amount of I/O on a system.

Once the hub device has identified what devices are plugged in, it should be a much simpler task to build up a custom application around those devices.

Of course the JeeNode design brings wireless communications for remote nodes, but you still have to get power to these nodes. Wireless can struggle in older buidings with very thick walls or a lot of internal metalwork. Sometimes wired systems have advantages too.

Bodgineering!

Here's a really useful relay board fitted with four 10A mains relays. I bought cheaply a few years ago thinking that it might be useful. The only problem was that it used a PIC16F886 and a weird serial protocol to control the relays and the rest of the I/O.

How about transforming it into a Arduino Relay Slave - just what the Navitrino central heating controller needs?

A quick check of the PIC16F886 data sheet confirmed that the reset, power and clock oscillator pins of the PIC were nearly all in the same position as on the ATmega328 - as used in the Arduino. Those that weren't, could readily be bodged.

The only changes needed were that pin 19 on this board is grounded - no problem if I make D13 an input, and pin 22 - an output to an unused darlington driver, would have to be made OV to keep the ATmega happy.

The board has a 12V dc input, a 5V regulator and a MAX232 serial chip. In addition to the four relays, there are four further outputs driven by the same ULN2803 octal darlington driver IC, plus four opto-isolated inputs. All inputs and outputs have LED indicators fitted to show their status.

The first job was to trace all the connections and work out what I/O was connected to the relevant pins on the Arduino

Pin 1 Reset
Pin 2 RXD I1.0
Pin 3 TXD I1.1
Pin 4 Digital 2 Relay 0
Pin 5 Digital 3 Input I1.2
Pin 6 Digital 4 Opto-Input I0.3
Pin 7 +5V Input I1.3
Pin 8 0V 0V
Pin 9 OSC1 Osc1
Pin 10 OSC2 Osc2
Pin 11 Digital 5 Relay 3
Pin 12 Digital 6 Opto Input 0.2
Pin 13 Digital 7 OP 1.3
Pin 14 Digital 8 to connector J5
Pin 15 Digital 9 to connector J5
Pin 16 Digital 10 to connector J5
Pin 17 Digital 11 Serial Output (MAX232)
Pin 18 Digital 12 Serial Input (MAX232)
Pin 19 Digital 13 0V
Pin 20 AVcc +5V
Pin 21 Aref
Pin 22 0V OP 1.2
Pin 23 AN0/ Dig 14 OP 1.1
Pin 24 AN1/ Dig 15 Relay 1
Pin 25 AN2/ Dig 16 OP1.0
Pin 26 AN3/ Dig 17 Relay 2
Pin 27 AN4/ Dig 18 Opto-Input 0.0
Pin 28 AN5/ Dig 19 Opto-Input 0.1

Once I was sure that the wiring was OK, I replaced the resonator with a 16MHz crystal and fitted one wire link to correctly feed 5V to pin 7. I then made up a 4 wire cable with a header that would fit my FTDI programming cable. With this all done, I powered up the board without the ATmega fitted and confirmed that my power and ground arrangements were good.

I wrote a short test sketch to set up the I/O with the correct pin functions and to produce a slow sequence of turning the reays on and off. I programmed this into an ATmega on another known working board and then swapped the IC into my relay board - remarkably it all works fine! I have subsequently reprogrammed the ATmega in-situ with the FTDI cable and all is well.

That's the underlying beauty of Arduino, you take a bootloaded ATmega328, add a crystal and connect power and ground and very quickly you have a common I/O platform for rapid prototyping of your latest hardware project.

For a couple of hours work - I now have a working relay slave board, onto which I can develop some code. The board will be used to drive the central heating, hot water and pump functions which require mains relays to operate. A simple seria slave link as developed for my "serial command interpreter" back in August will allow this board to be driven from the main Navitrino master - or possibly remotely via the internet using the Etherduino.

Who said bodging was all bad?

Coding up the Controller

A brief catch-up.....

Since late June I have been developing a series of applications for domestic energy monitoring and control based on the popular Arduino open source platform. These applications come under the general banner of "Navitrino" which is an open source project to develop low cost hardware for performing energy control and monitoring tasks within the home.

Navitrino has so far been limited to Arduinos and its clones, because they are cheap, available and easily programmed, but with the portability of C code and the introduction of interesting new ARM based hardware like the mbed, there is no reason why Navitrino can't ultimately be ported to different platforms. For the moment the Arduino is perfectly adequate to develop applicatons and the various sensing and communication techniques which make up the Navitrino project.

To recap, what's been developed and discussed in earlier posts, Navitrino is a low cost, real time monitoring and control application currently running on Arduino hardware. The project has been aimed at DIY domestic energy monitoring and applications such as solar water heating control, central heating control, electricity and gas monitoring and solar pV monitoring.

Whilst I am focussing on gas central heating control - because of my particular circumstances, Trystan, Suneil and Glyn at openernergymonitor.org have been developing electricity monitoring, solar heating and pV monitoring and other temperature monitoring applications. To allow synergy between our work, we have chosen a common platform to work with, and regularly communicate to work on new ideas together. Other partners from Europe have joined up with openenergymonitor to contribute some of their own open source energy related developments.

Progress on Navitrino Central Heating Controller Application.

Meanwhile, I have been slowly improving my Navitrino central heating controller code - once I managed to get a functioning real time clock running last weekend. Now that the basics of the controller are working under the RTOS task scheduling framework, adding new rules and exceptions and making various control decisions is relatively easy.

From a control perspective, I split the day into 3 parts: day, evening and night. This allows specific temperature regimes based on the occupancy of the house. For example, during the weekday day period, we are generally at work so I have the controller keep the house at 17C, so that it doesn't get too cool and then take ages to warm up. At weekends the house is more likely to be occupied, and the comfortable temperature is required at around 7:30am rather than 5:30am.

For the evening period, the controller reads the setting from a potentiometer - which allows you to set the evening temperature at whatever you feel comfortable - I set it for about 19C. The evening period starts at 5pm, so the house is fairly warm for when I get home from work.

If we choose to light the woodstove in the evening, the living room heats up and the thermostat function of the controller makes sure that the boiler is kept off.

At night - after about 12 midnight, the controller allows the house to cool back to 17C, and then it holds it within +/- 0.2C of 17C - so that it only uses a little gas on the coldest nights.

There are already a couple of exceptions programmed into this scheme. As Elaine works from home on Thursdays and Fridays, I use the "day of the week" variable from the RTC to detect if we are Thurs, Fri, Sat or Sun and increase the day period temperature to 18C - which is a more comfortable daytime temperature for when the house is occupied.

Additionally I have introduced some hysteresis into the temperature decision making, so that when we reach 17C for example, the boiler doesn't keep switching on and off as we hover each side of 17.00C. I allow a band of 0.2C either side of the set temp before the boiler switches, so it will come on at 16.8C and off at 17.2C. This gives a longer burn time for the boiler and allows the pipes to heat up properly. It's overall less wasteful on gas than having the boiler constantly stop-starting.

I've also got the water temperature sensing working - so it advises you on the LCD to "Wait" if the water has not yet reached the minimum temperature for a comfortable bath/shower. Once up to temperature - it advises you that the water is hot.

This weekend I hope to wire in the two relays that correctly select either hot water and/or central heating so that it correctly controls the valves and will allow me to schedule hot water only for my 6:00am weekday showers, and get the hot water "boost" button to work correctly. If the heating is going to come on regularly during the night it may well be worthwhile selecting the Hot Water option to come on whilst the boiler is running, to top up the temperature of the hot water tank, rather than turning the boiler on specially to re-heat the water.

Additionally I want to see whether sensing the outside temperature at 4am can help improve the decision making in order to get the house up to temperature on time on the colder mornings. On Thursday it was below freezing until 4am, and suddenly with a depression coming over, the outside temperature shot up to 8C by 6am. These sorts of overnight sudden changes in temperature are not easy to predict - especially when the room temerature sensor is effectively isolated from outside changes by the lag of the thermal mass of the building.

The next job will be to have a look at the 1-wire code so that I can extend the sensor network to include more temperature sensors and pulse counters. Additionally I hope to get the code debugged to allow the SDcard for datalogging this weekend.

Keeping Track of Time

The Navitrino controller has been running the heating system for over two weeks now and logging the internal and external temperatures. However, with it doing a full-time logging job, there has been little opportunity to take it off line and develop the firmware further.

I have a simple milliseconds timer to update the hours minutes and seconds, and unfortunately this has been running a bit fast. I really need to incorporate the real time clock code and make use of the DS1302 real time clock chip fitted to the NuElectonics shield.

Earlier this week I came across a simple task scheduler to run on the ATmega/Arduino - developed by Daniel Bradberry, and documented in his blog

Yesterday, using a spare DIY Arduino clone, I had a go implementing his simple task scheduler .

It was simply a matter of installing his "Timer" library and adapting his example sketch to suit.
In his header file Timer.h you need to change this line of code to get the required task-tick time

#define INTERRUPT_INTERVAL 200

(this interval is then used in one place in the file Timer.cpp)

At the moment his second tick lasts something like 1.63 seconds, so I reduced the 200 above to 122 to make it much closer to 1 second. Unfortunately with the Timer 2 inside the ATmega, clocked at 16MHz, its not easy to get a very accurate second with the divide ratios available - closest you can get is 999.4mS which gains about 2 seconds per hour - but for most task timing it's fine.

His library allows you to set up a series of "once only" or repetetive tasks - with up to 10 independent timers scheduling them.

I set up tasks t_sec, t_15 and t_60 which kick off every second, 15 seconds and minute.

I have now re-jigged my central heating control/datalogger program so that it is controlled by the task scheduler.

The code looks a bit like this:

t_sec() {

// these are tasks you want to do every second eg update the time hh:mm:ss registers


task_1();

task_2();

etc


}


t_60() {

// these are tasks you want to do every minute

task_3();

task_4();

etc


}

If this partial re-write is successful, the next thing will be to add in the code for the SDcard datalogging, 1-wire and the RTC. However, these tasks will be much easier to implement now that I have the task-scheduler working.

More Navitrino Progress

My "Navitrino" heating controller has worked well over the last week or so, taking room temperature and outside temperature readings every minute and logging them to a terminal program running on my spare laptop.

Fortunately the weather has been fairly mild, and the heating system didn't have to come on at all - apart for heating the hot water tank for 20 minutes each day. My wife, Elaine survived with just the wood stove in the evenings, although the controller was set to switch on the boiler, should the temperature drop below 17C at any time.

I'm now going to try to draw up a specification for the Navitrino hardware, based on my experiences over the last few weeks. This is not an exhaustive list - just a few points on the "wish list" which can later be compiled into a more detailed specification.

1. Navitrino requires as a bare minimum, the configuration of ATmega328, SDcard and Dallas DS1302 RTC - as supplied on the NuElectronics SD/Sensor Shield. There may be a requirement for a link between Digital 5 and Digital 10 to standardise the SDcard with the SD library code. For more I/O intensive applications, the Nuelectronics sensor shield could be fitted to a cheap Arduino Mega. Megas are now available from Hong Kong for £17 - plus £7 postage!

2. Navitrino should run primarily as a RTC driven datalogger, with data logged to SDcard and echoed to the main serial port - for logging/graphing with KST.

3. The RTC is used as a task scheduler, with tasks scheduled for time of day, day of week etc. I have found some information on Daniel Bradberry's blog for an improved RTOS task scheduler library. This will be useful for setting up tasks such as heating on and off periods.

4. Sensors and I/O should have a means to be defined in terms of device type and channel. The physical I/O should be mapped into registers in RAM (ints and long variables in C) , with a regular task used to update the state of the I/O from the registers (for outputs) and vice-versa for inputs. There will need to be I/O handler routines - for example to read all the ADCs several times, and average each of them into a 16 bit unsigned int register. Similarly for 1 wire devices, these are read and the data passed into suitable registers for temperatures, ADCs and pulse counters. If a bank of relays or LEDs were driven from a serial shift register, there should be an equivalent register in RAM which holds the state of all the relay/LED lines.

5. There should be an easy way to set up new tasks and new I/O devices/channels. Perhaps some sort of configuraton editing program which runs on a laptop and downloads the updated configuration to the internal 1024 bytes of EEPROM on the ATmega. Alternatively it might be possible to read the configuration from a file on the SDcard. 1024 bytes might not sound a lot - but if a byte can represent a high level task or an I/O device, and timed schedules (start time, duration) can be fitted into 7 or 8 bytes then quite complex programs should be possible.

6. There should be provision to have a second serial channel, using simple serial, to drive a remote LCD display (like the one I used on the Disciple slave) and to receive button presses from a simple keypad - although the buttons could be read with a 1 wire device or even a spare ADC channel.

7. Perhaps "Navitrino" should be defined as more of a software process running on Arduino hardware, to act as a framework which allows sensors and tasks to be easily implemented.

I thought that the combination of Arduino plus NuElectronics sensor shield as being the minimum hardware configuration on which to host the Navitrino system. For anyone wanting to follow this project - this is a cheap and easy combination to purchase and put together. It is also the minimum hardware which will do standalone realtime datalogging - without the need for external PC support.

There would be applications where RTC and SDcard would not be needed - because realtime is provided by internet and data storage would be external/online.

So the problem then becomes how do you accommodate vastly different hardware configurations within the same basic system. How do you make it easy to add extra hardware, where it's needed, such as ethernet connectivity - yet keeping a common programming model for the unit?

So I think Navitrino should focus more on how to specify tasks and sensors within the software, and develop it as a common software framework which is easy to upgrade - adding more tasks or sensors as and when they are required.