Saturday 25 February 2012

Now we're talking

I soldered up the second jeenode today (the USB node came ready assembled), good fun, haven't done that for a while. I then compiled the RF demo from jeelabs (make sure to get the jeelib library from https://github.com/jcw/jeelib#readme, and not the RF12 and Port libraries), loaded both nodes up, et voilá, I can send packages from one to the other.

They don't work too well when close together, but I took one downstairs and the communication was very good. I will need to carefully design my protocol though, to ensure that while packets are lost, no data is lost.

Friday 24 February 2012

The first 'gotcha'

The tablet arrived, and so have the parts from jeenode!

The tablet is nice, especially after I did some updates on it  - more about that some other time.

I got the arduino development tools to work, too. If you're using a jeenode USB, the instructions given on JeeNode Tips are a bit out-of-date: if you get arduino programmer is not responding errors, you need to change the device type to Uno (I think the bootloader has been updated). Then you can just take one of the example sketches, go to 'upload' - and see it working (with small changes - the 'blink' sketch assumes an LED on pin 13 - it's on pin 9 on the jeenode).

In eclipse, I went with this Arduino plugin - a fork from the official WinAVR plugin. It appears to work, though Eclipse is throwing java.lang.UnsatisfiedLinkError: no spawner in java.library.path in the path configuration - so I had to configure all the paths by hand. By default, the executables are all in /usr/bin, the header files in /usr/lib/avr/include, the IDE path is /usr/share/arduino, and I have no idea where the Atmel part description files are (or what they are, for that matter). I wonder if the problem is cause by setting the java library path in eclipse.ini for subclipse (see yesterdays post), but removing that entry doesn't seem to help.

That wasn't the 'gotcha', unfortunately. The gotcha is that the tablet only has one USB OTG mini-b socket, and no external power connection. In the OTG standard, the host device (the tablet in my setup) provides the power. When the battery is empty, I have to unplug it and charge - but that won't do if the tablet is the user interface for the whole system.

Fortunately, it looks as if there is a provision for exactly this in the USB OTG standard (thank you Wikipedia for linking to it). The USB Accessory Charger Adapter is a three-way connection between host, client, and charger. Has anyone ever come across a device actually implementing this? (don't confuse this with the USB splitter cable that's plugged into two ports on the host, to double the current). From reading the spec, since I am only interested in a single use case, it looks like a resistor in the plug at the tablet might be enough to tell it that, while it's the host, it is allowed to draw charge.

Of course, that depends on if the tablet actually implements OTG, including that part of the spec. It's not clear, as some other tablets come with a dongle that adds a second port and ethernet adapter - that would suggest it's connecting to a hub, which OTG can't do (I think?). Maybe there is another way of switching from client to host role without following the OTG standard.

I don't actually have a cable yet that goes from USB mini male to USB A female, so I can't try what happens if you plug in a hub.

Thursday 23 February 2012

Eclipse with Android and Subversion

In preparation for the coding, I spent some time updating eclipse for Android and Subversion.

To get the Android eclipse development environment to work, I ended up re-installing eclipse from scratch - it told me it had conflicting requirements between ADT and java-EE, and refused to budge. I had to install the 'proper' sun jvm too, no luck with the openjdk version. After that, installing adt as described in google's page worked fine. I still had an old SDK installation, it was happy to update that to the current state (btw: there are no 'close' buttons on the eclipse android configuration pages: use 'escape' to close).

Subversion was a bit more tricky. Debian installs svnserve with the basic svn package, but no startup scripts. This page describes how to set up the '/etc/init.d/svnserve' script that starts up svn - just change the path to the location of the repository. The repository needs to be created with 'svnadmin create path/to/rep' (it creates a few files and directories at that location), and I needed to set up permissions. See Tony's helpful page for how to.

I didn't import an existing directory (as Tony does), instead I installed RapidSVN - an SVN Gui - and used that to create a new directory within the repository (modify -> make directory). This directory will be the root for all parts of this project - android and arduino based. The URN for the svnserve server, if installed on your local machine with default settings, should be svn://localhost:3690 (svnserve doesn't support http based browsing).

The subclipse plugin caused another eclipse problem. On a windows machine recently it was straighforward.  On linux you have to install JavaHL individually - and while it's available as libsvn-java, neither debian nor ubuntu currently have version 1.7 of this library which is required for the 1.8 subclipse plugin. However, as this post notes, debian and other packages for javaHL 1.7 can be found at this repository. I just added
deb http://opensource.wandisco.com/debian squeeze svn17
into my /etc/apt/sources.list, added the signature to my key ring, and updated libsvn-java.

I am a bit jealous of the tortoiseSVN windows client, which is very nice, mainly for browsing and organizing the repository. I am now trying RabbitVCS, maybe that's similar (Debian is 2 versions behind though, as it is not using Nautilus 3 yet).

Update while debian's libsvn-java puts the javaHL libraries into /usr/lib/i386-linux-gnu/jni, the version from wandisco is stored at /usr/lib/jni. The correct path needs to be added to the eclipse.ini file (' -Djava.library.path=/usr/lib/jni')

Wednesday 22 February 2012

The other kitchen node: arduino takes the tablet

The kitchen node I described in the previous post has a USB port. Why?

Because the kitchen will also house the user interface. As I mentioned before, I initially looked at the Raspberry Pi. But I wanted a nice touch screen to go with it, and they aren't cheap. And then I realized that by the time I add wifi, sound (for alarms, if nothing else), and power, I might as well get one of those cheap Chinese Android tablets. I'll save all the hassle of connecting the display and touch screen, and have a powerful environment to program the UI.

So, somewhere mounted on the kitchen cupboards, we will have a nice 7in tablet, talking to the Jeenode using USB. The one I've ordered (Ainol Paladin) is not the cheapest available, but it's the cheapest running Android 4.0 (so I can play with the newest Android version), has a capacitive screen, and it's not one of the (reportedly) underpowered VIA 8650 based systems.  Apparently, the VIA chip is on its way out, to be replaced by something faster. I would have liked an Allwinner 10 based device, but they are more expensive.

There remains the question how to connect the tablet to the jeenode. One option I found is a low-level debug mode based connection as used in the IoIo. That's supposed to work on most devices, but the ioio is a bit more expensive, and since it's not actually an arduino-type node (more of a dumb direct io extension of the android device), driving an rfm12b wireless node off it is not straightforward.

The other option is based on Android's new Open Accessory Development Kit. Not all devices support this mode, and because the USB host in this case is the arduino, it needs a more powerful (and expensive) mega based node.

But don't tablets support USB host mode? After all, most of them come with external dongles with ethernet and additional USB ports? That wouldn't make sense if they only could work as USB clients.

Indeed they do, and as this great post describes, it is possible to connect Arduinos as simple serial clients. Perfect.

At least, that's the theory. The tablet will come tomorrow (and there's always a worry about quality with cheap Chinese devices), and the jeenode parts have shipped from Holland as well. We'll find out.


Tuesday 21 February 2012

The Kitchen Node

In the kitchen, we currently have an ageing X10 based system to switch three light circuits. When we moved in, all three lights were on the same circuit, so the kitchen was either dark or blazing. I couldn't reach all the wires to put in a new threeway switch, so I had to fit a remote system. It's not terribly robust, there is a noticeable delay between pressing the button and the light switching, and the switch itself is not very intuitive (I keep pressing the wrong buttons). 

The first task for the new system will therefore be to replace the X10 relays. The controller will be a USB jeenode. After looking at many different arduino based systems, my conclusion is that jeenodes offer the best design for my home system - they are very cheap, have radio built in, convenient connectors, and offer a small form factor.

I initially planned to use two Relay plugs for the three lights, but in the end decided to go for three relay nodes from a different supplier (Ciseco). My budget is very tight, and this option is a bit cheaper - they'll be wired straight to the jeenode's pins (using up two of the four connectors). I've also dropped the jeenode's carrier board and box - I'm sure I can find two plastic boxes, one for the node, and one for the relays to keep the high voltage bits separate.

On one of the remaining connectors, I'll connect a temperature sensor. The room board would be nice, but had to go for now;I can add that later when there's a bit more money.


Monday 20 February 2012

The Background Picture

Snowdrops in the orchard of Cotteridge Park, taken 29/01/2012.

Home Energy Controller

And this is my big new project: building a system that makes it easy to control and monitor the energy we use at home.

I have a strong interest in environmental conservation, and in energy use. I took part in Nesta/UKERC's Carbon Crucible program, and I had EPSRC funding for a feasibility study in analysis of energy monitoring data. The UK is trailing behind many other EU nations when it comes to real, implemented CO reductions (they just keep announcing things and then not realizing them). Taking action locally seems the only way to achieve at least some level of improvement.

The other reason for this project is that I want to build up some experience in embedded devices, play a bit more with Android, and after a long break get back to tinkering with electronics.

It all started with the Raspberry Pi excitement - $25 for a small but powerful Linux based computer - so many things one can do with it. Initially I was thinking about connecting to the systems in our car (I am currently working with an automotive engineering company),  but then I found the Open Energy Monitor page - offering open hardware and software for home energy monitoring. That seemed a much more useful project - and one where I could justify (to myself and the rest of the family) spending the time and money.

The current plan calls for three nodes: one in the kitchen, providing the user interface and replacing the ageing X10 based light control; one in the laundry controlling and metering the boiler, and one in the lobby metering gas, electricity, and quite a few temperatures indoors and outside. The overall bill of parts should hopefully stay bellow £250.



Sunday 19 February 2012

Why I started this blog

A while ago, I had to dismantle the front hub on my bicycle. It's a generator hub, powering the lights on the bike, so there are delicate electrical contacts to take care of. Luckily, some kind person had put a set of photos online, describing exactly how to disassemble (and, more importantly, reassemble) the hub.

It's not such a common hub, and I doubt that more than a dozen or two people would have benefited, but for me it was exactly the information I needed.

Since then, I've had a number of occasions where, after spending hours working out how to solve a particular problem, I thought it would be good if I could just document it somewhere where other people could find it. It doesn't matter if no one actually reads the blog - as long as google indexes it.

The other reason is that I am embarking on a DIY project that I want to document. More about that in my next post.