adq

The next part of my TV control project was to cover the TV's IR sensor. I have an IR transmitter stuck to it, but the TV gets confused by signals from other remotes. I needed some sort of nodule to cover it, which also had a cavity in it to hold the transmitter. Additionally, it was important it should look unobtrusive when stuck to the TV.

I immediately thought of FIMO as the solution; I've actually been wanting to play with it for a while, so this was a good excuse. I headed to the artist's supply shop on the bridges at lunchtime and got a wee block of black. As it was much cheaper than I'd expected, I got some red and purple to play with later (hmm: black, red, and purple: who could have guessed I'd go for those colours initially eh? :)

Later, at home, I opened the packet. I thought it looked similar to plasticine, but it doesn't feel or work (or smell :) the same. I had to cut a piece off with a stanley blade as it seemed quite stiff. I started moulding it into the slug-like shape I needed with my fingers, and it quickly became a lot easier to work: must have been the heat from my hands. I finished off the slug, made the transmitter cavity, and then bunged it on a piece of alumiunium foil in the oven for 30 minutes (at 110C).

After the time was up, I retrieved and let it cool for a while. It didn't look very different. However, it was now hard to the touch, but still slightly rubbery at the same time. I tried putting the IR transmitter in the cavity, but it no longer fitted: there must be a small amount of shrinkage  during the cooking process. Therefore, I got out my dremel drill with the carving head and started to hollow it out. It was really easy to do so: FIMO seems to retain a degree of flexbility even after cooking, so I didn't feel it was going to shatter (as long as I was careful).

Here's a pic of the underside with the hollowed cavity:


Apologies for the crap on the table from the dremelling! The cavity itself is fairly rough: I didn't need fine work as it won't be visible.

Oh yes, after cooking, it still looks matt and slightly rough. I see you can get a variety of coatings to put on FIMO objects before cooking them so that they'll look glossy etc,

I attached it to the TV with a piece of double sided sticky tape: I'll see in the morning if its still attached, but the end result is quite light. The slug is just visible next to the green LED near the corner of this picture:



As it turns out there are two types of FIMO: Classic and Soft. I had bought soft, which is apparently er.. softer and easier to manipulate, but is also less strong. Classic is supposedly better for fine detail work, but I've yet to try it out myself.

So, this wasn't the most artistic of creations, but it performs its function perfectly, and was great as a quick test of the cooking process and gaining some confidence with the properties of the material. I now want to do something more artistic with the rest of the FIMO.

I'd been looking for a way for my media PC to control the power of the other devices in that system (sub, amp, tv). I'd thought about X.10, but I felt that was expensive overkill.

After some investigation on maplin's website, I found these.



These are RF remote controlled 4bars. Quite nifty, although I'm not that interested in the remote control bit as I need something the computer can control and know what state it is in (see earlier post about discrete IR codes). So I bought a couple of them as they were £13 each.

I got them home and opened one up:



Looks like a fairly standard digital board controlling a relay. Which, indeed, it was (I built a similar system to control my old water cooling system). The relay is switched on simply by supplying 5v. I removed the digital board and replaced it with a cable the computer could control:



And it works beautifully!

However, lets take a closer look at the digital board I removed:



The chip on the left is a PT4301-X, typically used for remote control systems such as car ignition, garage doors etc. The chip on the right is the interesting one from my point of view. Its a Microchip PIC16F630 (which is flash and therefore reprogrammable)! The port on the top right is the programming port for the PIC, and the port on the bottom is the 4 outputs from the PIC. There are two buttons on there as well. Effectively I have two rather nifty wee embedded programmable remote control development boards.

The remote control itself has an MDT2010 in it - again this is a reprogrammable microcontroller with 35 instructions and 1k of EPROM.  (apparently it is based around the well known "COMS" technology *cough* *cough* :)

So: now I need to think of a project idea for an embedded remote control system. The box claims a range of about 30 metres in open air....

Here we go!

First of all, my lirc configuration for the toshiba TV power button, manually adjusted to the proper NEC timings:
( Here )

Next up my "tvon" script, which uses the "i2cget" program from i2c-utils:
( here )

And finally my "tvoff" script, which uses the "i2cget" program from i2c-utils:
( here )

I've been experimenting with the IR blasting TV control option. With IR blasting you don't (normally) get any status back from the TV, so you need what is called a "discrete code" - an IR signal that either turns the TV on, or turns the TV off. An on/off toggle signal (which is what the power button on remotes usually does) is useless as the controlling PC doesn't know what state the TV is in.

Some research and IR recording with my serial irman device later, it turns out the TV is using a modified version of the NEC protocol (they've swapped the signals for zero and one over).

Now I knew the protocol, I played IR roulette: transmit all possible codes and see what happens. Unfortunately, it was pretty useless - I didn't find any discrete codes. I did have a scary moment sending the value 0x28 when the TV lit up with "SETTING CONTINENTAL SHIPMENT", but it didn't really seem to affect it. I later found a code for "UK SHIPMENT" (0xa8) so I've undone whatever it is it did :)

I've just spotted a working solution: when the TV is in standby, I don't see any i2c devices over the HDMI cable, when its ON, they're present. So I now that actually can tell the TV's state, I have no need for a discrete code.

Still, I really must make sure to get a non-shit TV next time; I can't even turn overscan off on this one (I'd prefer one of the linux based TVs :)

In which I investigate tv control and accidentally stumble over the HDCP protocol.

I've been investigating controlling my tv from my media box recently. There are three four main possibilites:

1. IR blaster
2. The service port on the TV
3. DDC/CI
4. CEC

1 - will work, but I'd like a finer degree of control
2 - I have the TV service manual, but it doesn't really give the pinout of the service port
3 - Is the standard DDC/CI monitor protocol.
4 - CEC is docced in the HDMI specs, but I don't think it works over my HDMI->DVI cable (but my new video card has an HDMI output so maybe it would be accessible over that). Confirmed - CEC is not done over i2c for some irritating reason - there's a seperate 1 wire bus for it which is not exposed over DVI. Also, I don't think the card drivers expose an API for controlling it. You can get extra hardware that intercepts it, but that doesn't mean the TV supports it.

So I've been investigating 3 first of all. The TV DOES support EDID reading, but DDC/CI is seperate protocol for the PC to control the settings on the TV (e.g. change input, power it up etc). This tool, ddccontrol implements the protocol, but says my TV doesn't support the DDC/CI protocol. Bum.

Using i2cdetect however, shows there are mysterious i2c devices on address 0x3a and 0x51 (0x50 is the EEPROM with the EDID information):

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- 3a -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

So I did some googling. Apparently the device on 0x3a is how the HDCP protocol is tunneled over the connector. This doc documents the various HDCP registers for one chip's implementation. Nothing very useful from my point of view in there though.

I wonder what the one at 0x51 is? -- probably just part of the EDID eeprom I'd guess

Interesting, see this link on the reg

Ofcom are asking people if the BBC should be allowed to apply their proposed  programme listing DRM. Whether responding will do any good, I don't know, but it can't do any harm...

Note that as they're not proposing DRMing the *content*, just the programme guide (by restricting knowledge of the decompression tables) . It won't affect me or my recording system whatsoever, in fact, I'd give it about a week till someone figures out the missing information and releases it :)

It could be viewed as the start of a slippery slope though.

Wheee, at about 12am last night I decided that I really just had to port tigervnc to the latest 1.7.x xserver. It hadn't been done previously because there were some fairly massive cleanups in the keyboard code from 1.6.x->1.7.x which changed a lot of things.

A couple of hours later, and I had a working version submitted to the developer's list. However I did feel a bit tired at work today as a result.

Actually, since it was hacking about in the guts of X, I reckon this is more like a good deed of the month :)

Photos from our trip to the Lake District . I can see why people fall in love with the place: the colours, man, the colours!

This evening I finished off my rsync script. It now uses the "--link-dir" feature to support proper incremental backups using hard links.

The system works pretty well; wander into the flat, wifi auto-connects and phone backs itself up automatically. No user intervention required whatsoever.

Here's the finished rsynchero script:
( Read more... )

So, at the end of my previous post, I had rsync compiled and runnable on the phones via ssh.

Some playing about and chatting later, my friend Colin suggested adding the backup into one of the dhcpcd hooks. The idea being that whenever the phone connects to my flat wifi and successfully gets an IP address, it will automatically kick off a backup at the same time.

This is easily achieved by adding the following script into /etc/dhcpcd/dhcpcd-hooks/96-backup on the phone:

case "${reason}" in
BOUND|INFORM|REBIND|REBOOT|RENEW|TIMEOUT)
   if [ x"${new_dhcp_server_identifier}" = x"DHCPSERVERIP" ]; then
      wget -q -O - http://WEBSERVERIP/SOMETHING/backup.cgi?machine=hero-adq
   fi
   ;;
esac

So, when it connects to an access point whose IP is DHCPSERVERIP, it'll automatically make an HTTP request to a CGI script on WEBSERVERIP. This script uses sudo to kick off the backup. I decided the server should control the backup process rather than the phone as it makes it much easier to maintain. Also, the backup has to run as root on the server so it can maintain the userid/groupid and access rights on the files as this is important for android to function correctly if I were to restore something.

The script, 'rsynchero', which runs on the server and actually does the backups is as follows:

#!/bin/bash

SRCDIR=$1
DESTDIR=$2

/usr/bin/rsync -a \
        --force \
        --ignore-errors \
        --delete-excluded \
        --delete \
        --exclude '**/dalvik-cache/**' \
        --exclude '**/cache/**' \
        --exclude '/proc/**' \
        --exclude '/sys/**' \
        --exclude '/cache/**' \
        --exclude '/dev/**' \
        --exclude '/sdcard/newsrob/**' \
        --exclude '/sdcard/mp3/**' \
        --exclude '/sdcard/acv/**' \
        -e '/usr/bin/ssh -p 2222' \
        $SRCDIR $DESTDIR

I've added the server's ssh public key to /data/dropbear/authorized_keys on the phone so it can login securely without needing to supply a password.

So, this is it done. The backup has already proved itself useful when a file was accidentally removed from nicola's phone yesterday (something went wrong with the 'Secrets' app).

The only other thing that would be nice is a multi-day rotating backup in case a file is removed and only noticed some time later.

I've been looking for a way to automatically backup my HTC Hero android phone. All the solutions on the market seem a bit lacking - either unable to backup everything, or only backing up to the SD card and so on.

My total flat backup system is fully automated and based around rsync and rdiff-backup over ssh. I really just wanted this running on the phone as well; the modaco ROM I'm running already has an ssh server built in.

I had a look at porting rsync to the android build system, but it seemed more trouble than it was worth. So I built a normal ARM GLIBC toolchain under gentoo with:

crossdev -t arm-softfloat-linux-gnueabi

Next, I downloaded the rsync 3.0.6 source, configured it with:

CC=arm-softfloat-linux-gnueabi-gcc ./configure --host=arm-softfloat-linux-gnueabi

After typing 'make', I ended up with a shared binary. I manually relinked it statically to avoid having to have a chroot environment on the phone. This precompiled binary is available here.

I'm still figuring out precisely how to trigger the backup, but I can certainly do complete system backups with zero fuss now.

Well, finally here are my photos from Beltane 2009. Some good shots I hope!

I'm uncertain whether I'll be going to this particular event in future; yet again, I had to delete many photos ruined by the rubbish people had simply left lying about. That just depresses me: as much as I'd like to enjoy the event, its just too swamped with fools :(

Some shots of my brass domino mask. It consists of half-etched brass sheet on leather. Cotton tape secures the mask to the head.

I'll try and do a similar shoot for my submariner mask soon too!

This is just absolutely insane.

I finally glued and bent the mask into shape this evening. Here's the first test shot of me wearing it. I still need to add the extra cogs and do some cleanup, but the basic thing is done!