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.