Install software

We’re using the Rygel UPnP package, specifically its MPRIS interface to enable UPnP rendering to desktop media players. In addition, we install GUPnP to provide a UPnP Control Point, and finally banshee. I had a crack at using Totem as a renderer, as of April 2013 the version in Ubuntu registered as a MediaRenderer but quietly refused to play any content I asked it to. The upnp-inspector package is nice for checking everything works.
sudo aptitude install rygel rygel-preferences gupnp-tools banshee upnp-inspector

Configure rygel

Open Rygel’s configuration file:
nano ~/.config/rygel.conf
And enable the MPRIS interface by adding the following at end of the file:
[MPRIS]
enabled=true

Rygel is designed as a UPnP media server, and by default will start offering up local video, music and picture shares as media servers. If you don’t want this, it can be disabled by running the Rygel Preferences GUI tool, or by adding this to the [general] section of your rygel.conf:
interface=
upnp-enabled=false

Autostart Rygel at login

cp /usr/share/applications/rygel.desktop ~/.config/autostart
Log out and back in to start the Rygel service.

Configure Banshee

Finally, the MPRIS interface needs to be enabled in Banshee. Start it up, navigate to Edit -> Preferences. Click the Extensions tab, scroll down to the utilities section, and ensure the MPRIS D-Bus Interface is enabled.

Playing things

Inspector window showing my XBMC server, the local Rygel share, banshee, and BubbleUPnP on my android phone.

Start UPnP Inspector. It should list any available MediaServers on your network and, if you didn’t disable them, local shares from Rygel. Start banshee, and it should also appear as a MediaRenderer in the inspector window.

Any UPnP control point on the network will be able to send content to banshee (I’m fond of BubbleUPnP on Android). Or start the UPnP AV Remote control program. I’ve only been playing with it for an hour or two, but get best results from external control point software. The GUPnP remote occasionally stalls trying to play things.

The system comes with a controller that allows you to set a colour manually, as well as pre-set colour change and fade functions. Rather than build my own circuit I wanted to save time by reusing this controller. Opening it up revealed a PIC microcontroller, and three MOSFETs for the red, green and blue channels.

First thing to do is disable the microcontroller by cutting through the power track. Cutting through the big pad I’ve marked on the diagram means it’s easy to then wire a switch across it if you want to be able to use the controller as normal.

Three output pins from the microcontroller drive the MOSFETs, but only two of them have big friendly solder pads, so I soldered wires on to the three resistors just below the MOSFETs (R5, R6 AND R7). Then soldered the other ends of these wires to a short strip of header pins. These are then plugged straight in to pins 9, 10 and 11 on my Arduino. I’ve labelled the picture with which MOSFET drives which LED channel, but they match what’s printed on the PCB where the input cable is connected.

Finally, we need a ground wire. Easiest way to connect it is to solder a wire on to the –ve wire on the input cable. The other end of that is again soldered on to a header pin, which is connected to the ground pin of the Arduino.

And that’s it. I hooked these up to my LeoStick the Freetronics guys gave away as swag for LCA 2012 and loaded up some demo code I had sitting around from the last time I played with an RGB LED.

Right now I’m using this setup as a light controller for boblight on my XBMC media centre. Setting up the controller, writing my own single-channel boblight sketch, installing software and configuring the XBMC addon was all done in a single evening. It was a lot of fun, and even with a single channel the results are pretty awesome.

My rope light has three wires — two strings of LEDs and a common ground. It also has a little control box with a rectifier and an MCU with a handful of pre-programmed modes. I cut the cable between the controller and the rope, and was incredibly surprised to discover that the LEDs were being fed with 240V DC. At a very low current, but still dangerous enough to make me throw away initial plans and approach it again with a lot more care. Also beefier relays.

The rest, though, was very straightforward. The Arduino Playground has plenty of information about interfacing with relays. I’ve got 12V relays, so I’m using a 12V wall wart to power my Arduino board, and then run Vin from the Arduino out to power the relays via a simple driver circuit. I’m not too pleased about running separate power supplies for the rope lights and the lower-powered control electronics, but I’m definitely not capable of doing anything about combining them yet, so that’s the way it will stay for now.

My first revision of this project used four of these drivers (I thought I’d find a use for the others… eventually) on a piece of prototype board, with header pins attached so I could attach it to the Arduino as a shield. It was my first non-trivial Arduino project, and first time I’d done any serious soldering for a while, so it looked rough as guts. But it worked, and gave me much more interesting ways to control my lighting. The first test of the full system, with a two-channel variant of the Blink demo sketch, looked like this (direct youtube link).

Completed shield

I ran this board for a while, but wanted to control the outside lights from the same system as the power controller I built recently, so build new drivers for my relays on the side of that shield. The end result was a very, very full short shield, but the entire thing looks much nicer, and very deserving of the translucent case I mounted it in. I still want to do a little more work with the hardware. First to add a hardware (illuminated) button for separate control of the outside lights, and then maybe look in to using an external voltage regulator to supply the 12V and 5V I’m using for the control board instead of feeding 12V in to the Arduino. But I’m very happy with the project so far.

I haven’t yet uploaded the software I wrote to run all of this. It needs tidying, and there’s a weird bug in the timers still, and sooner or later I’m going to have to change the hardcoded password in my branch. However, I love showing off the webpage, so check this out:

Remote control website running on my phone

I bought it with the intention of controlling it with an Arduino. However, interfacing with it proved to be a little more difficult than most other systems around, and nobody else seems to have done it yet. So here’s how I managed it.

About the remote

The remote handles four separate channels. On the outside, rather than buttons that toggle each channel on or off, the remote has separate on and off buttons for each channel, as well as a 9th button to turn all channels off. On the inside there’s two main parts that we care about.

• A Holtek 7130A-1 power regulator. This takes the 12V from the battery and outputs 3V (at up to 30mA) to power the rest of the circuit. After accidentally hooking this up to my bench supply with the polarity reversed, I can confirm that these operate using really foul-smelling smoke. Luckily we won’t be requiring it any more.
• A Holtek HT46R01T3. This chip combines a small MCU with a 433MHz transmitter. The data sheet specifies an operating voltage of 2V-3.6V, so it’s trivial to power from the 3.3V rail on an Arduino.

Six of the GPIOs from the HT46R01T3 are used. Each button shorts a pair of these GPIOs together to tell the MCU to transmit a command. So to talk to an arduino we break out six GPIO pins, plus two more wires to power the remote.

Parts

As well as an Arduino, we use:

• A shift register. I used a Freetronics EXPAND shift register module.
• 8x NPN transistors. BC549s worked for me. A BC547 or any other equivalent should be fine.
• 8x 150kΩ resistors.
• Some 8-strand ribbon cable, in addition to a handful of other hookup wire.

Hardware hacking

Each command is triggered by shorting two GPIO pins together. The pins used, and the resulting command, look like:

Pins	16	2	13
14	Outlet 1 On	Outlet 2 Off	All Outlets Off
15	Outlet 1 Off	Outlet 3 On	Outlet 4 On
3	Outlet 2 On	Outlet 4 Off	Outlet 4 Off

To start with, we take a length of 8-strand ribbon cable, and solder it on to the remote PCB. For power, use the negative battery terminal, and the far right (from the back) pin of the power regulator. For the GPIO pins, I used a continuity meter to trace them to a convenient solder pad on one of the push buttons.

For my remote, these are how the different wires wound up being connected:

Red	+3.3V
Brown	GND
Grey	Pin 2
Purple	Pin 3
Blue	Pin 13
Green	Pin 14
Yellow	Pin 15
Orange	Pin 16

Using output 7 on the shift register to issue a command through the remote.

We use a separate transistor to activate each command, omitting the “all outputs off” command. Each output from the shift register is connected to a 150kΩ resistor, which is then connected to the base of an NPN transistor. Two GPIO pins are then connected to the collector and emitter pins of the transistor. To issue the “Outlet 1 On” command, connect GPIO pins 14 and 16. It doesn’t seem to matter which way around these are connected to the transistor — I tested both orientations and they seemed to work.

We need eight of these switches. I tested each command on a breadboard, and then individually after assembling them on a prototype board. Once they’re assembled they’re connected to the outputs from the shift register. My code uses “Outlet 1 On” hooked to output H, “Outlet 1 Off” to output G, “Outlet 2 On” to output F and so on. Because I assembled it upside down. :-(

Connect the +ve wire from the remote to the 3.3V power pin on the Arduino, and the ground wire from the remote to one of the ground pins on the Arduino.

Finally, the shift register is connected to the Arduino. For the EXPAND module:

• Connect Vcc and Reset pins to the 5V supply on the Arduino.
• Connect GND and Output Enable pins to the GND pin on the Arduino.
• Connect Clock to digital pin 5 on the Arduino.
• Connect Latch to digital pin 6 on the Arduino.
• Connect Serial In to digital pin 7 on the Arduino.

It gets a little bit cramped, but I was able to fit the EXPAND module and all other components on to a Freetronics ProtoShield Short, with enough room left over on the right hand side for a couple more relay drivers that I am avoiding discussing in this post.

Software hacking

To transmit a command we have to simulate a button press:

• Send a value to the shift register turning on the appropriate register output.
• Delay briefly. 500ms works well to just issue a command. If you want to use the arduino to program outlets then closer to 2000ms would be needed.
• Send a 0 to the shift register to turn off all register outputs.

The below sample sketch listens for keystrokes entered on the serial console, and sends the associated command. Train a couple of outlets to the remote, load the sketch, open a serial console (make sure the “no line ending” option is set), and then if you’re anything like me spend half an hour typing on the keyboard and giggling at the little LEDs turning on and off.

/* RemoteDemo
   Demo sketch for Jackson remote power control.

   Hardware:
   A shift register connected to pins 5, 6, and 7.
   Outputs are wired as:
     A: 4off
     B: 4on
     C: 3off
     D: 3on
     E: 2off
     F: 2on
     G: 1off
     H: 1on

   Run the sketch, and open the Serial Monitor in the Arduino IDE.
   Typing a letter between a-h will send the associated command.
*/
// IO pins
const int dataPin = 7;
const int latchPin = 6;
const int clockPin = 5;

boolean cmdEnabled = false; // true if we're sending a command
long cmdTimer = 0;          // track how long we're sending command
int inByte = 0;             // incoming serial byte

void sendCmdOn(int cmd) {
  digitalWrite(latchPin, LOW);
  shiftOut(dataPin, clockPin, MSBFIRST, cmd);
  digitalWrite(latchPin, HIGH);
  cmdEnabled = true;
  cmdTimer = millis() + 500;
}

void sendCmdOff() {
  digitalWrite(latchPin, LOW);
  shiftOut(dataPin, clockPin, MSBFIRST, 0);
  digitalWrite(latchPin, HIGH);
  cmdEnabled = false;
}

void setup() {
  pinMode(dataPin, OUTPUT);
  pinMode(latchPin, OUTPUT);
  pinMode(clockPin, OUTPUT);

  // Flush the expand module
  sendCmdOff();

  Serial.begin(9600);
}

void loop() {
  // If there's a serial character waiting, parse it
  // and send the appropriate command.
  if (Serial.available() > 0) {
    inByte = char(Serial.read());
    switch (inByte) {
    case 'h':
      Serial.println("Turning on Outlet 1");
      sendCmdOn(128);
      break;
    case 'g':
      Serial.println("Turning off Outlet 1");
      sendCmdOn(64);
      break;
    case 'f':
      Serial.println("Turning on Outlet 2");
      sendCmdOn(32);
      break;
    case 'e':
      Serial.println("Turning off Outlet 2");
      sendCmdOn(16);
      break;
    case 'd':
      Serial.println("Turning on Outlet 3");
      sendCmdOn(8);
      break;
    case 'c':
      Serial.println("Turning off Outlet 3");
      sendCmdOn(4);
      break;
    case 'b':
      Serial.println("Turning on Outlet 4");
      sendCmdOn(2);
      break;
    case 'a':
      Serial.println("Turning off Outlet 4");
      sendCmdOn(1);
      break;
    default:
      Serial.println("Invalid command received");
    }
  }

  // If we've exceeded the timer, stop sending a command.
  if (cmdEnabled && cmdTimer < millis()) {
    Serial.println("Releasing button");
    sendCmdOff();
  }
}

I bought a HTC Dream on an Optus plan the day they released it in Australia. Out of the box it was awesome, pretty much everything I wanted out of a smartphone. But as time passed, the Cupcake android release became widespread, and Optus lollygagged about pushing the update out to their users. One by one my favourite applications released updates that made them incompatible with my phone, until eventually I gave up and found a good guide on rooting G1s.

With an up-to-date firmware and Market Enabler to get around Optus’ other major problem of not making paid applications available, I was in smartphone heaven. That was until I heard wind of ROMs based on the Android 2.1 release (as seen on the new Nexus One handset) running on the G1. It looked like it might be fun to try, so off I went.

One of the steps involved in initially rooting a handset involves loading a new SPL to bypass region checking and enable booting unsigned ROMs, so I’d done it a couple of times before and was fairly comfortable with it. Unfortunately, newer builds need the Haykuro SPL, which is supposed to be more aggressive with how it deals with the internal storage space (leading to more size for bigger images), but also kind of dangerous. I double– and triple-checked everything, but still seem to have screwed something up flashing the SPL, and now I have a phone that is basically dead. The 1st bootloader screen comes up, but I can’t get in to the fastboot menu or the recovery image. My poor little momo (my computers are named after Samurai Champloo characters) was no more.

Luckily my birthday was yesterday, so I don’t feel too bad about treating myself to a new phone. After a morning of reading reviews, I think I’ve decided on a Motorola Milestone. I’m a little wary of Motorola — my last Moto handset was an absolute disaster, and working for a mobile communications company means I’ve had a chance to tinker with newer Motorola handsets that were similarly disappointing. But the Milestone seems to be a very impressive and solidly-built phone. The jury is still out on whether the Milestone or the new Nexus One would win for Best Android Phone right now, but I for one am swayed by a good hardware keyboard.

So, momo is dead, long live… uh… momo?

I flew out of Sydney on Tuesday evening. On Tuesday morning I realised I should probably think of something to do with my hire car and my three blissful days of nothing before I had to be at Rickaby, so spent some time with google maps. Eventually picked Coober Pedy because:

• I’d never really been to central Australia before. Seen some bits of desert while tooling around in WA, but not true outback.
• My vague recollection was that it was a pretty interesting place.
• I like saying Coober Pedy.
• It was about as far away from anywhere I’ve been before, that I could reasonably get to in the time I had.

I tried explaining this to a bloke I met in the pub in Coober Pedy. He was absolutely amazed, and couldn’t quite comprehend that somebody would just, on the spur of the moment, get in a car and spend ten hours driving to Coober Pedy, just because.

Last year I went to Cowra because on a Friday morning I thought “hrmn, I want to go somewhere this weekend, where should I go?”, and picking Cowra because I hadn’t traveled West of Sydney much, and Cowra seemed about as far as I could reasonably drive on a Friday night. I got there and had a conversation with a bloke in a pub that went something like:
“So if you’re from Sydney, what are you doing out here? Work?“
”*shrug* Just having a look around. Wanted to get out of town for a weekend, and wound up here.“
”…bullshit.“
Incidentally, the Japanese garden at Cowra is the largest in the southern hemisphere, and absolutely amazing.

By the time I’d gotten to Taralga six months ago, I’d given up and just told people that I was on my way to Yass but had to go via Bathurst because *mumble*mumble*. That seemed like a much more realistic explanation than wanting to see more of inland NSW (and telling them I’d taken a two-door hatch along Wombeyan Caves Road would have probably been pretty damn embarrassing).

What’s the big deal? Do people not just travel for the hell of it any more? Maybe they think it only counts if you’re going overseas? Have we forgotten how much of the new and exciting is sitting right at our doorstep (and if not there, definitely a two hour flight and ten hour drive from it)? Maybe small town inhabitants just don’t believe their particular small town is worth visiting (I know I still think this about Yass).

When was the last time you threw the figurative dart at a map?

Can I fit the words “Coober Pedy” in to this post one more time?

Edit /etc/config/dhcp, and in the config dnsmasq section add a line like this. The format is as per the dnsmasq man page:

    option dhcp_boot	pxelinux.0,tftp_server_hostname,tftp_server_ipaddr

The init script does all the parsing of the dhcp config file, converting things in there to cmdline arguments to dnsmasq. So you need to edit /etc/init.d/dnsmasq, and in the dnsmasq() function add this line:

	append_parm "$cfg" "dhcp_boot" "--dhcp-boot"

The function already has a bunch of append_parm lines. Just search for those and add your new line immediately under them.

Restart dnsmasq and you’re good to go.

(apparently I don’t have a picture of her doing anything particularly nerdy)

I first met Alice[1] not too long after she was hired by Google, as the sole female engineer in their Sydney office. Happily, that doesn’t seem to be the case any more, but she continues to do a lot of great work as an IT evangelist. Along with Pia Waugh, Alice works with school-age girls encouraging them to get involved with computing, most recently at the Go Go Girl for IT event. She’s also been involved with local Aussiechix events, helping run the micro-confs in Sydney and Melbourne last year, as well as being involved in Linuxchix miniconfs at recent LCAs.

I’m always impressed by her encyclopedic knowledge of the issues women face, both in the professional IT sphere and elsewhere, and the passion and clarity she brings to defending her rights and the rights of other women. I listened in on Alice’s group during the Evangelising IT workshop at the Linuxchix miniconf this year, which came up with some excellent strategies for trying to keep girls (and boys as well!) interested in computing. It was one of the highlights of LCA for me this year.

On a completely unrelated note, Alice is a very talented photographer who shares my love for old-school picture making. Having a chance to learn from her both behind the camera and in the darkroom is just another reason for me to feel inspired by her work.

[1] For the record, I believe this happened shortly after my then-housemate, Jamie also started work at Google. I arrived home one afternoon to find half the Google office in our pool.

peter@fuu:~$ date +%s
1234567890

Apparently the next big event is 0x50000000 seconds since epoch, due to happen shortly after 9pm on the 13th of July, 2012.

We went with a 100mm (3.9″) flat white matte, surrounded by a 70mm (2.8″) plain black frame. Apart from a slight bevel on the inside edge, the frame is plain and square. All told, this thing is 1070mmx870mm (42.1“x34.3″), easily the biggest and most impressive print I own.

I couldn’t be happier with the way it’s come out, and I’m incredibly proud to have such a beautiful and prestigious print gracing my lounge room.