Autumn Almanac

It's been a short week what with the Bank Holiday Monday, and my new employer's policy of closing the firm at lunchtime on Fridays. With us rapidly moving into the Autumnal month of September, here's a round-up of some of the things I have been inspired with this week.

New Toys.

I've been tinkering with a new Texas Instruments DSP dev-board at work, which will become part of a dc motor control system. I first used TI DSPs back in the late 1980s with the TMS320 series, and wow have they come on in performance since then.

The dev-board is based around their "Delfino" DSP which is a 32bit floating point DSP capable of 150MHz clock speeds. It has 512K of program space, 68K of RAM and 64 general purpose I/O pins - 18 of which can be PWM for driving power stages. It also has 16, 12 bit ADC inputs, which can be run in two banks of 8, for making simultaneous measurements - such as voltage and current, for calculating instantaneous power.

The Delfino is mounted on a small strip of PCB known as a "control card", which brings out 100 pins in a common footprint. This makes it easy to swap control cards for any of the DSPs in the TI range, and ensure functional pin compatability - a neat idea. It removes the user from the difficulties of handling 176 pin ball grid arrays (BGAs), and it means that you can develop your application on one of the larger parts and then move down to a smaller, more cost effective part, later, when the code is finalised.

Putting the processing elements onto a common footprint is a great way of taming what would otherwise be a difficult technology. The raw technology is grouped into a series of manageable ports or interfaces, and the user is presented with a simplified programming model.

On a simpler level, - this is exactly what the Arduino does. It simplifies the microcontroller's interfaces into a series of easily understood pin functions, and presents an extra programming layer into the code which divorces the new user from the complexities of manipulating I/O at a register level. This makes the technology much more accessible to the new user, but at the expense of a speed reduction in I/O operations - compared to direct I/O register manipulation.

When the User becomes more experienced in programming, then the "stabilisers" can be removed. Learning to programme an Arduino in C will hopefully produce a whole new generation of embedded programmers - who have the confidence to get "down and dirty" to the hardware level. This is something that has perhaps been lacking in recent years, as coders generally develop applications in high level languages on sophisticated platforms such as laptops and mobile phones.

Networked Arduinos

A week after the Snowdonia Mega-Hack session, the dust is starting to settle on the networked Arduino project. Trystan has been developing firmware so that he can use the networked slave as part of his solar photovoltaic monitoring system. This was chosen as an example application as something that would illustrate the capabilities of the network slave as a means of monitoring pV panel volts, amps and watts and controlling a battery charging system.

The low cost serially connected slave would make an ideal candidate for a battery monitoring system (BMS). Using optically isolated serial comms, one slave could be applied to each 12V battery, in a larger battery bank or an electric vehicle battery. The low power requirements of each slave would allow it to be powered from the battery it was monitoring - with its I/O referenced to the 0V terminal of each battery.

Data Logging.

Another neat application which has come to light is the OpenLog Data Logger This is an ATmega328 interfaced to a 2Gbyte SD card. It has a simple serial interface, and it just sits an logs all the serial data it sees on its RxI pin. The source code and schematics are all open source, allowing this application to be easily incorporated into some home-made hardware.

One idea would be to use it to record "both sides" of the data on the Arduino serial network. The slaves could be interrogated at regular intervals for stored data, which they transmit to the network, and the OpenLog stores this data away to flash in a large text file. OpenLog comes with a small but neat collection of commands allowing data to be retrieved, files to be appended and erased. This seems like an easy method to get data from the slaves into permanent storage, from where it can be accessed by laptop, sent via ethernet to the web, or whatever.

2Gbytes is a huge amount of storage. Even sending continuous data at 9600baud, it would take more than 25 days to fill the SD card.

Central Storage and Real Time

The Arduino slaves are lacking in vast amounts of local storage. There is 2K of RAM on the ATmega328 microcontroller, and if just over half of that was available for data storage, it could hold about 600, 16 bit readings. Using a store and feed-forward method, the slave could hold say an hour's worth of instantaneous power readings, taken at 6 second intervals and then send the whole file up to the central storage. At 9600baud, this data transfer would take about 4 seconds - easy enough to do once every hour between taking sensor readings.

The problems of limited storage have been with us for much of the last 60 years of computing. Certainly until the late 1980s, memory was an expensive resource, and computer engineers found ways of connecting many users to the one central mainframe and sharing its memory resources between several users.

This is exactly the same situation we have with our network of distributed Arduino slaves - albeit on a very much smaller scale. We have to find a clever way of sharing central resources, such as file storage, realtime clock and ethernet connection between the slaves. By storing the slave data in RAM and then forwarding it to the central SDcard at regular intervals would provide a sensible compromise to storing data, without over-complicating the slaves with their own additional storage. The feed forward model could also be applied to the Master device - collecting data from the slaves storing in SD card and then forwarding this data to a laptop, or web connected server. This would give the Arduino network a degree of autonomy and not reliant on having a PC permanently switched on to service the data.

The NuElectronics Sensor Shield comes with RTC and SDcard for data storage. With a bit of juggling it should be possible to implement the OpenLog firmware onto this shield. The RTC timestamp could be distributed as a CSV packet across the wired network at regular intervals - so that slaves could synchronise their local time to the realtime.


CurrentCost Channels and Pachube Feeds.

One idea, starting to "bubble to the surface" is the concept of having a number of data channels which can be monitored. This is something which the CurrentCost energy monitors have implemented, where originally they had a separate channel for the energy monitored on each of the three phases of an electricity supply. The LCD display would allow basic channel information to be viewed.

The concept was extended to allow data from Individual Applance Monitors (IAMs), to present the energy used by an appliance such as washing machine or fridge to be given their own channel. The CC128 display unit was given a capacity of 10 channels, with the user being able to step between them using a button on the front panel. This approach allows other sensors to be added later to enhance a sensing network - and with the Current Cost DevBoard, enthusiasts can add their own sensors, linking back to the CC128 via their proprietry wireless link. Thanks to @jtonline and @yellowpark for letting me know about the CurrentCost Technical Blog. -in which Chris Dalby, a developer at CurrentCost introduces some of their technology to the Homecamp/Hacker community.

Incidently - for those interested in wireless networks, JeeLabs has introduced a kit for a wireless JeeNode. Its based on the ubiquitous ATmega328 and a wireless transceiver module. It presents 4 identical "ports" to which various sensors or devices can be attached. It's all open source and based on Arduino technology. At 17.50 Euros it seems good value for money, and the wireless module used is the same one which CurrentCost use, which to the experienced coder should open up some possibilites for integrating the two systems.

So if we consider any source of data, such as electricity instantaneous power, or room temperature, or solar panel output could be expressed as a data channel. The CurrentCost display allows basic monitoring of channels using its restricted LCD, but this could be extended to an application running on an O2 Joggler display or a laptop etc. With an application running on a laptop, iPhone or via the web, would give enhanced monitoring options such as historical graphing, comparing channels or using them for further processing or other applications such as Pachube - where several physical channels are combined together as a Pachube feed.