The Contiki build system depends on some GNU utilities that are not installed. Using the following steps I was able to compile for the “native” (i.a. Mac OS) target:

1. Install GNU binutils using MacPorts.
2. Edit “cpu/native/Makefile.native” and adjust the “Compiler Definitions” section like this:
   
### Compiler definitions
CC = gcc
LD = gcc
AS = as
NM = nm
# Use GNU ar instead of /usr/bin/ar
AR = gar
OBJCOPY = objcopy
STRIP = strip
ifdef WERROR
CFLAGSWERROR=-Werror -pedantic -std=c99 -Werror
endif
CFLAGSNO = -Wall -g -I/usr/local/include $(CFLAGSWERROR)
CFLAGS += $(CFLAGSNO) -D_XOPEN_SOURCE=500 -O
# Simplify ld arguments
#LDFLAGS = -Wl,-Map=contiki-$(TARGET).map,-export-dynamic
LDFLAGS = -Wl


Another issue is the ELF binaries for the AVR Raven boards. These files contain all components of the programs: flash and eeprom
images as well as fuse settings. Unfortunately, avrdude cannot read the ELF format. So you have to extract the flash manually:


$ avr-objcopy -R .eeprom -R .fuse -R .signature -O ihex $NAME.elf $NAME.hex


It works similar for the EEPROM section (where the IP data is stored):

$ avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex webserver6.elf webserver6.eep


You can also check which fuse settings are used:

$ avr-objdump -d -S -j .fuse webserver6.elf
webserver6.elf: file format elf32-avr
Disassembly of section .fuse:
00820000 <__fuse>:
820000: e2 99 ff


The directory structure of Contiki is somewhat overwhelming. I am currently working in these directories:

1. contiki-2.4/platform/avr-ravenlcd: This is where the code for the ATMega3290p lives. Run make here and upload.
2. contiki-2.4/platform/avr-raven: The ATMega1284p code lives here, this is where most patches are. Don’t run make here!
3. contiki-2.4/examples/webserver-ipv6-raven: Run make here for the ATMega1284p code. This builds the webserver code and includes the platform/avr-raven dir.

In addition, I have a serial terminal for debugging output:
screen -U /dev/cu.SLAB_USBtoUART 57600

It took me a while to figure this out, so here are my notes:

1. Install Scratchbox as described here. This greatly simplifies cross-compiling things. It also provides you a way to run the compiled ruby interpreter on a bigger host machine using QEMU. This is essential because I rely on rubygems, and the Chumby is too small to execute the gem install commands. Besides, at least for the sqlite3-ruby and mongrel gems, I need to compile native code.
2. Install dependencies. I found the following libraries necessary:
   • OpenSSL 0.9.8n – avoid the 1.0.0 version, it causes problems with the Ruby interpreter.
   • Zlib 1.5.3 – same as installed on the Chumby.
   • Readline 6.1
   • A recent version of sqlite, since I need it for my gems later on.

   Compile the libraries and install them into /mnt/storage (use –prefix where necessary).

3. Adjust the environment to use the new libraries:
   BASEDIR=/mnt/storage/usr
export PATH=$PATH:$BASEDIR/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$BASEDIR/lib
4. Install Ruby and rubygems. I was not able to compile Ruby 1.8.7, but Ruby 1.8.6-p399 works nice. To configure everything, I use the following commands:
   export ac_cv_func_getpgrp_void=yes
export ac_cv_func_setpgrp_void=yes
./configure --target=arm-linux --host=arm-linux --disable-pthread --enable-wide-getaddrinfo --enable-zlib --with-zlib-dir=/mnt/storage/usr --enable-readline --with-readline-dir=/mnt/storage/usr --prefix=/mnt/storage/usr --with-openssl-dir=/mnt/storage/usr && make && make install

5. Install rubygems:
   
/mnt/storage/usr/bin/ruby setup.rb --prefix=/mnt/storage/usr
mkdir -p /mnt/storage/usr/lib/ruby/gems/1.8

6. Afterwards, the necessary gems can be installed using the gem command. It might be necessary to provide additonal path information to the gems that compile native extensions, for example
   gem install sqlite3-ruby -- --with-sqlite3-dir=/mnt/storage/usr

The result is an image with Ruby installed, and all necessary gems for my project. The tarball can be downloaded here. To install, scp it to the Chumby and log in:

scp *tarball* root@*chumby-ip*:/mnt/storage
ssh -l root *chumby-ip*
cd /mnt/storage
tar xvzf *tarball*


Now you have a directory /mnt/storage/usr with all tools permanently installed on your Chumby. In order to use it, please adjust your PATH and LD_LIBRARY_PATH appropriately:

export BASEDIR=/mnt/storage/usr
export PATH=$PATH:$BASEDIR/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$BASEDIR/lib


/me mumbles more automation needed. But not today.

I have been presenting the mySmartGrid project at C-RaDar, the monthly chaos show in Darmstadt. Someone recorded the show (don’t know who, but thank you!). You can download the MP3 here (german language):

C-RaDar March 2010: mySmartGrid and other stuff

This was a fun experience, kudos go to the C-RaDar people! The picture above: CC-BY-SA-NC by georgia.g, thanks!

All the electric power generated from renewable energy is good – no additional CO2 is produced. Saving energy in general is also a good idea – what you don’t consume, you don’t need to produce. But energy savings require you to understand your own energy consumption – you can’t improve what you can’t measure. A simple energy cost monitor is available for 10 Euro, but it requires you to plug it into different appliances in order to figure out what a specific device consumes. And only the more expensive ones log the power consumption over time, which is pretty interesting.

An alternative to the simple energy meters are smart meters. In Germany, utility providers need to offer their customers the replacement of old (typically black) meters with shiny new digital “smart” meters. Actually, there is nothing smart about them – they just transmit the energy consumption of the household via powerline or other technologies to the utility provider. The utility provider does not need to visit the household in order to get the reading. And, in some cases, customers can have a look at the realtime energy consumption of their household.

The benefit of the realtime data is that you can assess the impact of your actual energy use very quickly. Google.org is offering the PowerMeter, which works for example with the smart meters offered by Yello Strom. An interesting open-source alternative is the Flukso.

The Flukso is a little WLAN router with some additional circuits to measure your power consumption. You install it in your breaker box. Depending on the configuration of your breaker box you need one or three current clamps. These clamps just go around the cables that supply your household – it is not necessary to re-cable the breaker box. I have a three-phase supply, so my installation consists of three current clamps and the Flukso itself. David Rowe has a nice writeup on the installation.

The Flukso then measures the power and transmits the data over the WLAN to the Flukso website. Once you’re logged in you can see your own energy consumption as a realtime graph. It is quite fascinating to find out how your energy consumption is composed. Here is one of my charts:

The graph shows time on the X-axis and my energy consumption in Watts on the Y-axis. The peak (1) shows that I was getting up in the middle of the night, preparing some tea and switchin on my computer. I had a pretty decent jet lag that night. In the morning I got up again around 8:00 (2). Apparently I used my coffee machine and switched on some lights, but I left shortly afterwards. The regular power consumption (3) originates from my fridge which draws power in regular intervals. Around 18:00, I got home again, switched on lights, prepared tea etc (4).

The graph is very interesting and really helps to improve your energy usage. But it also scares me – as I demonstrated above, a lot of information is stored in such a graph. Honestly, I don’t want my utility provider to know this. And I definitely do not want Google to know that much about my life. Or would you like to see advertisements for sleeping pills after a night of jet lag?

The picture at the top is CC-BY BK59 on flickr, thanks!

Green energy is good. Finally, people around the world begin to realize that the climate change is a serious problem for mankind. Driving with a car harms the environment – more efficient cars (or electric vehicles) are the new SUVs. On the other hand, a lot of energy is consumed in private households. In Germany, energy-efficient remodeling is rewarded with cheap credits. Often, solar power is used to heat water and generate electricity. More and more wind parks are built which also draw their energy from the sun, indirectly.

Unfortunately, renewable energy source create problems for the conventional power grids. In a power grid, demand and supply of electricity must match at all times. If a consumer draws power from it, the exact amount of power needs to be fed back into the power grid as fast as possible. There is almost no reservoir for electrical power (except for pump storage hydro power plants, but the capacity is limited). Since renewable energy sources such as solar and wind power cannot be planned additional power capacities need to be in place in order to compensate for the lack of power.

In the German research project “mySmartGrid” I am working on another technique to alleviate the erratic nature of these power sources. Instead of adding more production capacity or storage capacity we want to control the demand for power. In addition to the not-enough-power-available problem we currently have another problem: the too-much-power problem. When wind blows over Germany, significant power is generated – whether it is needed or not. Often, wind parks need to be shut down when too much power is generated. This is clearly not desirable from an ecological point of view.

To put it simply: We have either too much energy available, or not enough. It is rare that we have exactly the right amount of energy at our hands. This situation is shown here:

We can influence this only to a certain degree. BUT: We can change the way we consume the energy. For example, think of your fridge: It doesn’t matter whether it draws power now or five minutes later. The temperature change is inert. Thus, it is easy to move the demand – not save any power, but shift the demand for electricity by some time. In other words: switch the fridge of when the supply is short. Then, when the supply exceeds the demand, switch the fridge on again – it will draw more power since the internal temperature was raised. This is what we do:

Of course, this is only the simplified version of what we are doing. In reality, we must ensure that food doesn’t go bad. In addition, controlling a single fridge has almost no impact. But if you aggregate lots of households, the impact can be significant. Heat pumps consume a lot more energy and can be controlled in a similar way. If you can combine lots of households with heat pumps, fridges and freezers, the impact on the demand side is serious.

In the mySmartGrid project we combine up to 1000 households. We intend to control the energy consumption of household appliances as described above. The following picture shows a high-level overview of the architecture:

We combine the predicted power supply information for a period with statistical models of the power consumption of our households. This gives us an understanding when too much energy is available. We create schedules that contain information when a household should maximize its energy consumption. The schedules are then distributed to the households. The so-called “Kundenhub” is currently an iPod which offers a user interface. Household members can always override the schedule we propose.

The iPod uses various mathematical models to determine how to switch appliances on or off. It executes the strategies locally: there is no direct remote control over household appliances. The commands are sent to connectors close to the appliance which then can control the appliance.

This research project contains a lot of challenges – but I save this for another post.