Christmas with Elmo

I wasn't expecting to get much done on Elmo over the Christmas period because we had family visiting. Having mentioned my IR transmitter problems to Dad, an ex-BBC electronic engineer, he came up with a lot of good advice and we spent a happy morning fiddling with the Elmo breadboard and troubleshooting his ideas for a signal amplifier.

During the process, I discovered that, unlike most mobile phone cameras, my iPhone 5 doesn't pick up IR very well. We were using the camera to see when the IR transmitter was working and were getting rather baffled as to why nothing seemed to be coming out of the transmitter. Switching to Mum's old Nokia phone and the IR transmitter lit up like a Christmas tree and we knew we had the right approach.

Some more fiddling and highly technical walking backwards and forwards holding a Sky box to test the range and we'd fine tuned the components to give a good range of IR transmission - certainly plenty for now. What a great result.

There is a Mark 2 circuit to come, but for now, here's the schematic we've ended up with:

All credit goes to Dad for the IR transmitter. Now I'm set to continue development.

LIRCing

Finally had some time to spend on Elmo and after a fair bit of fiddling have got LIRC working. There seems to be something a bit odd about the GPIO pin configuration for the receiver and transmitter, but I eventually managed to find a combination that would work and I can now successfully, and consistently, read codes from an IR remote control

Transmitting has proved a little more problematic. I can get my normal LEDs to work straight from the GPIO pins, but the IR transmitters won't work (you can't see the IR they give out with the naked eye, but you can use a phone camera to see the pulses). I believe the devices need too high a current.

This is something I foresaw and so got some transistors, however I didn't get the correct resistors and I don't want to risk overloading the Pi, so I'll hold off until I've had chance to get some more resistors

In the meantime, I've also set up a technical blog - mostly for my own use because otherwise I tend to lose the scraps of paper I jot things on.

Open Source Joy

Having spent days trawling all manner of RPi forums, blogs, help sites and such, I have finally managed to get lirc operational on the Raspberry Pi.

Almost all of the sites missed at least one step needed, which led me to become incredibly frustrated - especially when I'm running the 'preferred' RPi distro - Raspbian - which has recently had the LIRC support built into it. My problem turned out to be the firmware. Installing the firmware update tool and running that eventually got me where I needed to be - and the mode2 lirc test program now happily outputs lots of lovely, raw, IR data when I fire my remote into the receiver.

Unfortunately, that's eaten all my available time for this weekend, so it'll be another week before I have a chance to do any more ... at least it's progress, though.

Reborn

Has it really been (more than) a year? Frankly, the FitPC/Iguana driver issues just got the better of me, and I lost all momentum on this project. Earlier in the year I was given a Raspberry Pi, and I've recently been thinking this might be a good device to try for this very purpose. So I've spent a bit of time thinking and writing some code to get the basic things working. It was fairly easy to hook up an IR transmitter and receiver to the GPIO ports on the Pi. I'd initally thought I could just poll the port in order to learn the IR codes, but it's proven to be problematic - the resolution just isn't high enough. So, I've resorted to using LIRC again to try to do this. Today I've downloaded the new Raspbian image for the Pi and am in the process of getting the LIRC drivers compiled for the Kernel. This is somewhat time consuming and probably won't be finished today, but hopefully I'll be able to soon get LIRC up and running and see if I can get any success with receiving and transmitting IR using this new bit of hardware. This could be a very short rebirth if the drivers don't work.

One step forward, two steps back

It's been a while since the last update, mainly because things haven't progressed a great deal.
I reinstalled the previous version of Ubuntu and it did allow the system to run, however, I started encountering problems with the IR driver locking up. There was nothing obviously wrong (and nothing on the manufacturer website) so I decided to start again, Reinstall version 9.10 of Ubuntu again but not apply any updates.

Busy weekends and long working weeks conspired to delay this but I managed to do this last Friday and it appeared to work.

I then spent the weekend implementing (most of) the configuration file system to optimise startup times (in the end I didn't use Boost, but went for a simpler solution - a shame since that was what started all these problems). I also took the opportunity to rework the channel picker control so you now have to press a button to activate the selection. Everything seemed to be working well, but when I disconnected all the development kit and reinstalled the server in the lounge, the IR crash problems started to appear again.
I've managed to do some investigations and found that the daemon appears to lock and refuse to send any IR signals - the only solution is to restart the daemon. More testing revealed this happens quite quickly under some circumstances, but doesn't seem to happen at all at other times. My conculsion is that the way in which I'm interfacing to the driver must be problematic, so I need to revisit that.

So, I need to look at the way I'm driving the IR device through the driver - possibly write some test code to try different techniques of making it work and see which ones are the most reliable. I also need to finish the configuration file mechanism and also do some more optimisations for speed of network connection. Finally, I want to enhance the control layout mechanism so I can test drive some better layouts for controlling devices.

Error. Redo from start

To help develop the file transfer system I decided was needed for Elmo, I decided to install the C++ Boost library on the server (Boost is particularly useful for cross-platform development).
Since my Ubuntu package manager had been complaining that my version was very old, I decided to upgrade to the new version 10 - Lardy Lumpfish, or whatever it's called.

BIG Mistake.

There are no graphics drivers for my hardware in this version. Having searched all over the place I still can't find a decent solution and the way things are at the moment means I can't boot into the system without getting an error and having to select to rebuild the display config (even when no display is connected). This is pretty hopeless for a system that isn't supposed to have a display.

After much deliberation, I've decided to reinstall from scratch the previous version - Karmic Koala - and reapply all the patches. This does give me the opportunity to document the process, which is probably no bad thing.

Obviously, I can't make any other progress until this is resolved

Process of continual improvement

So, Elmo has been installed and running for about three weeks now. This has allowed time to see how it really behaves when used in anger. Technically it has been generally working well, with just a couple of glitches to do with booting Ubuntu, however there are a number of "issues" - not really problems - that diminish its usefulness.

The biggest problem is latency. I've noticed that reconnecting to the server after you've initially powered up is actually taking quite a tangible amount of time. This is probably because the iPhone has to get back onto the WiFi network and then reconnect to the server. The upshot is that when you've been watching TV for a few minutes and decide to change channel, its not as good and experience as I'd hoped, there is a noticable delay. I have a few ideas about how to improve this, mainly around trying to predict when the user is about to press a button - I'm thinking of when the phone is unlocked as one trigger - although that probably won't give me enough time - or possibly using the accelerometer to detect when the phone is picked up.

An associated problem is that when you want to change between different items of equipment the phone has to download the new screen layout from the server. This again takes time and makes the process clunky. The simple solution is to store all of the screen layouts on the phone - only refreshing them at startup. This should be reasonably straightforward.

The screen layouts definitely need attention because the main screen is far too busy and the channel change lists aren't really useable. Because the iOS picker control basically selects an item when you stop scrolling, it means that the channel picker always comes up with a number of different channels before you get to the one you want. As each channel takes around a second to be selected by the server (3 digits transmitted over IR), this ends up being a bit tedious.

The IR transmitter is also very sensitive to positioning. I've found that changing the TV angle by about 10 degrees so the face of the TV is more closely aligned with the server helps greatly in the reliability of the signal transmission. On the whole the IR is pretty reliable now, but it still seems to go through patches where it struggles. Probably some more work is needed on the low-level IR capture. There are a small number of codes that have stopped working altogether as well.

Although there are a number of issues here, none of them are major. I intend to try to work to correct these over the next few weeks and see how sweetly I can get Elmo to sing. First step is to cache the screen layouts (because it should be simple) and then look into the connection latency issues.