JokamajoInstituut

At Jokamajo we're currently alpha testing a social metering application called Flukso. Flukso lets you compare your total electricity consumption to that of other households. These can be family, friends, colleagues, you name it. With Flukso, we're trying to turn those abstract watts and kWh's into something more tangible. You can display time-series charts covering the most recent hour, day, month or year. You can also dynamically add or remove other Fluksonians' (yeah, by signing up to the trial you're also getting a new passport) data onto the chart. If you're interested, you can check it out here. Note: Due to privacy reasons, we're only showing my personal chart.

fonduinoIn order to get this working, we needed to be able to transfer the pulses sent out by the energy meter to our Flukso server. We spent quite some time searching for a set of suitable off-the-shelf building blocks. We tackled this problem from two angles. Solving the networking problem first led us fairly quickly to a wireless residential router running a Linux kernel. OpenWRT is a good candidate as it lets us add all the software packages we need for our metering, like NTP support for timekeeping. As a fair amount of people are now using wifi to connect to the Internet from any room in their home, using a wifi capable router makes sense. Trying to detect the pulses sent out by the energy meter meant that we then had to look for at least one free GPIO on the router board and getting the linux kernel to pass these triggers to our software residing on the board. We solved this by using the hotplugging deamon. The major drawback of this solution is that we haven't got a long-term solution to store the meter value on the router. Since storage is all flash-based, you can only write to it about 100.000 times. Households having an average electricity consumption of 70kWh per week and the energy meter sending out a pulse for every Wh you've consumed, means that you're burning through the flash in less than two weeks time. That's a bit short, even for an alpha trial...

We then looked at it from the other side. Detecting the pulses is now the easy part. Just use a microcontroller. We really like the AVR ATmega168-based Arduino project. Such a controller gives us the opportunity to play with all kinds of IO. We solved the storage problem by using the analog comparator on the AVR to compare the supply voltage to the chip to an internal reference voltage. Now we can keep the meter value in RAM. When the comparator detects a power drop, it triggers an interrupt routine which can still write the value to the AVR's EEPROM before brown-out. Our major stumbling block in this case consisted in the networking part. How could we get this Arduino to communicate with a web server? There are a couple of Arduino shields out there that try to solve the networking problem. You can see examples here and here. But they only give us an ethernet connection, no wifi. DHCP is barely supported and we can forget about some more 'exotic' protocols like NTP.

Come to think of it, the fact that we ran into these problems actually makes sense. 8-bit microcontrollers are great for connecting to the physical world. You can measure almost anything you like, as long as it can be converted to volts and amps. Driving leds and motors is a breeze. Wireless routers on the other hand are perfect for networking and fairly demanding computational tasks. They're running, or can be converted into running, Linux. So basically all the power of a UNIX operating system is at your fingertips. Pursuing a hybrid solution, in true Prius style, therefore makes sense. And that's exactly what we've done for our Flukso prototypes. When googling for this type of solution we bumped into an experiment marrying an Arduino to a Fonera in this post. Since our trial means installing the solution in people's homes, we were in need of a more polished solution.

Sparkfun released a minimalistic Arduino-compatible board called the Wee that contains just the bare essentials for getting the AVR up and running. Comparing this board to a Diecimila makes the latter look rather bloated. And we got lucky. The Wee is so-to-speak pin compatible with the Fonera 2200. If you align both boards correctly, you can solder GND to GND, Rx to Tx, Tx to Rx and 3.3V to ... 3.3V! This means that we could let the Fonera and Wee have a two-way UART conversation. Additionally, you can power the Wee directly from 3.3V out pin on the Fonera's serial header. We later switched to a different way of powering the Wee through the Fonera, but that's another story.

Now we needed to have some sort of connector to terminate the wires coming from the energy meter. We noticed that the spacing of the perforations in the Fonera's grey plastic shell are actually 0.1" apart. So we could just insert and glue an 8-pin female header into the Fonera's perforations. We could also slide the pins of the header into a small prototyping board. So there you have it. A fully functional and configurable Fonera-Arduino hybrid, a Fonduino. Or should we call it an Ardonera instead?