It may not be much, but I stuck together a small article about how to remotely automate the startup of HP servers. We did this ages, and only now have I gotten around to tidying up the notes!

Over here

Last night I thought I would try out “Remote Media” by Mark Martinsson on my HTC Desire as an alternative to Twonky Media Server. I started it up, and then left it indexing my files. However, due to me being extremely tired I then left it and went to bed instead. I briefly checked on it in the middle of the night to plug it in and charge, and spotted the “Low storage space” warning. I thought nothing of it, as I’ve encountered that many times before and decided I would deal with it the next morning.

So, 7 hours later I looked at the phone and spotted the HTC logo endlessly looping. This Is Bad(tm). The phone had died in the middle of the night, and was now failing to boot. Great.

I booted up the Recovery image with the volume down & power button combo, and had a look around. Every time I tried a command I got the following error.

E:Error in DATA:data/recovery/log
(No space left on device)

Great. Google have made an OS that fails to boot when it’s out of space. How clever. I subsequently decided against just formatting all and starting from scratch for two reasons. Firstly, my backup was more than a few days old, and secondly I didn’t want to be beaten by a stupid design failure. Onto the recovery images and remote access.

Now, I’ve used ClockWorkMod before in order to install other ROMs, but for some reason my phone had defaulted back to the normal Recovery image. This image doesn’t have ADBD, and also doesn’t offer any Backup to SD options. After spending I good hour or two hunting down an independent recovery image for the Desire, I discovered the ClockworkMod Recovery image sitting on my SD card! Back into Recovery Mode, select Apply update.zip, and relax as ClockWorkMod Recovery appeared.

In this ROM it would be trivial to backup and then reinstall, but doing all that just due to lack of space seems silly. Download the Android Developer Kit, connect up the phone with the USB cable, and run ./adb device from the tools directory to check that the phone is discovered.

Once discovered, connect to the built in ADBD instance with ./adb shell.

root@kyleg-laptop:/home/kyleg/Applications/android-sdk-linux_86/tools# ./adb devices
List of devices attached
HT067PL05406 recovery

root@kyleg-laptop:/home/kyleg/Applications/android-sdk-linux_86/tools# ./adb shell
~ #

A quick df -h displays the obvious

~ # df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 199.2M 0 199.2M 0% /dev
/dev/block/mtdblock4 40.0M 1.2M 38.8M 3% /cache
/dev/block/mtdblock5 147.6M 147.6M 0 100% /data
/dev/block/mmcblk0p1 6.7G 4.3G 2.5G 63% /sdcard
~ #

Now we’re in business. We have access to the phone and the filesystem. We can then do some hunting around to find what’s taking up the space. A few minutes later, du -h /data | grep M shows up the following…

58.5M ./data/com.noname.remotemedia/databases
58.5M ./data/com.noname.remotemedia

Culprit found. Thanks guys.

/data/data/com.noname.remotemedia/databases # rm remotemedia.db
/data/data/com.noname.remotemedia/databases # df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 199.2M 0 199.2M 0% /dev
/dev/block/mtdblock4 40.0M 1.2M 38.8M 3% /cache
/dev/block/mtdblock5 147.6M 89.2M 58.5M 60% /data
/dev/block/mmcblk0p1 6.7G 4.3G 2.5G 63% /sdcard
/data/data/com.noname.remotemedia/databases #

And off we go. A quick sync and exit, and the phone can safely be rebooted and used. I highly recommend uninstalling Remote Media though..

Post moved. I felt it was more suited as a page within the site rather than a mere blog entry.

See here

Recently we were in the unfortunate position of running out of IP address in our DHCP pool. The Novell DNS/DHCP Management Console will give you a handy utilization % for your subnet, but will not tell you how much of your allocatable pool is in use. As a result, machines were timing out whilst waiting for an IP.

To diagnose this, we loaded dhcpsrvr.nlm with the -d3 option, and checked sys:/etc/dhcp/dhcpsrvr.log. The tell-tale sign is copied below.

67  : Get type:2, IPAddr:10.240.64.119, LeaseTime:0, MacIndx:774, pIP:B23F2540
AMAGet() exit err:0, subnet:10.240.64.0, addr:10.240.64.119
2010/05/21 10:15:56  <DHCPINFORM> packet received from client <0:13:72:9D:1C:E6>, IP Address <10.240.64.119>.
2010/05/21 10:15:56  Sending BOOTP/DHCP reply <DHCPACK> to <0:13:72:9D:1C:E6> as <10.240.64.119>.
Get type:4, IPAddr:10.240.64.106, LeaseTime:0, MacIndx:1042, pIP:0
Fill pool returned error 1
Error 5 adding new ip
AMAGet() exit err:5, subnet:0.0.0.0, addr:10.240.64.106

Ultimately, we needed more addresses in the pool. It would appear that in order to change your pool range in OES, you export the pool, edit it, and reimport the pool.

This seemed like far too much of a faff for me, so it was time for some rummaging. Normally the eDirectory enabled DHCP server stores lease data in eDirectory. First port of call was the WM_Subnet container that we use for those objects. In there, there’s an object called WM_Range. This contains details of the IP range available for DHCP use.

First off, unload the dhcpsrvr.nlm module, and then open the object up in ConsoleOne, and click on the “Other” tab. The attributes “DNIP:Start Address Number” and “DNIP:End Address Number” are decimal representations of the start and end IPs respectively, and can be expanded out to edit each attribute individually. Simply overwrite the current entry with the new decimal address that you want to use, click ok, and load dhcpsrvr.nlm back up.

Figuring out a decimal address is fairly easy, and is described in this Technet article. You can also convert a quad octet (IP address) to decimal notation with an online calculator.

This, and the subsequent videos, are a prime example of hybrid car building. One day, just one day, I hope to do something similarly daft/stupid/brilliant/expensive/etc

Fantastic footage of the last ever night time landing of a Space Shuttle. STS-130 safely makes it to the ground, and the night time situation allows for great footage of the jets of flame coming out the APU exhausts at the tail root. The flames happen all the time, but are usually invisible during the day. Similar footage of STS-9 can be found over here.

If you run SpamAssassin, you may be pleased to encounter this bug about now – https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269

Because nobody ever thought the year 2010 would happen :-/

There’s some more details on the rule, and more importantly how to disable it, over here http://wiki.apache.org/spamassassin/Rules/FH_DATE_PAST_20XX

As has been noted earlier, the AC has had its fair share of fuel flow problems. Ranging from the large (a rotten fuel tank) to the tiny (a flake of corrosion in the accelerator pump). Here’s a few things that were done to try and cure it.

Firstly, replace the filters that sit on top of the fuel tank drain plugs. They may not seem like much, but internally the fuel intakes come down inside the tank, and slip inside the filters that are on top of the plugs. This fine mesh is the first line of defence against rubbish in the fuel tank. We thought we could get away with old ones that had a slight tear in them. After a few weekends of running, further inspection showed a pile of gunk sitting inside the filter! This would lead directly to the fuel pump…

The second thing to do was to insert an inline filter between the fuel solenoid (since the AC has two fuel intakes), and the fuel pump. This is just a bog standard plastic inline fuel filter after the solenoid, and is there to save the pump from any rubbish that somehow gets past the gauze filters on the drain plugs. We also took the chance to replace all the fuel hoses between the solenoid and the carburettor. The existing hoses were coming up on 30 years old, so we though it wise to avoid any rubber degradation issues and replace the whole lot in one go.

Roughly at the mid-point now, we opted to change the fuel pump. It had been noted that the fuel was flowing back down the line after the car had been left to sit for a day or two. This made starting it particularly difficult, and was probably the precursor to a failed pump. Add to that all the rubbish that had been coming through the fuel system in those weeks of diagnosis, the pump filter had been cleaned out more often then we had had hot meals. A new pump was fitted, and the fuel draining problem immediately vanished.

Annoyingly though, we were still experiencing problems with fuel flow. Between Gordon and I, we must have stripped the about 20 times. Every time it would work great for 20, maybe 50, miles before reverting to its normal way of not letting any fuel flow when under load.

Convinced it was a problem of more rubbish in the fuel system, we decided to fit another filter after the pump and before the carburettor. Initially we went for the cheap plastic inline filters that are readily available, but we didn’t leave it in that configuration for very long for another reason – we fitted a Filter King instead.

The Filter King not only acts as a filter, but it also has a sedimentation bowl which doubles as a small fuel reserve. Any rubbish floating in the fuel can fall to the bottom of the bowl whilst the fuel in the bowl can continue to be drawn upon by the carburettor. We initially tried the Filter King before the fuel pump, but it’s clearly designed to have fuel pushed through it. The pump couldn’t draw air hard enough to draw fuel into the Filter King, and nothing worked. Now, the AC 3000ME range historically has a problem of fuel starvation during a long corner. This is most likely due to the shape of the fuel tank, but appears to be mostly mitigated by the Filter King now.

Sadly, after all this work, the fuel was still not flowing as planned. At higher revs after 30 minutes of running it would start to cut out. Something was clearly wrong, and all things started to point to the carburettor… no matter how many times we stripped it down and rebuilt it!

When you blip the throttle on the AC, it activates the accelerator pump. This pumps a higher than normal amount of fuel into the carburettor in order to rapidly increase the revs of the engine. It also ensures the engine stays running and doesn’t cough and splutter to a halt. Sound familiar? After much poking and prodding, I discovered that the one of the two accelerator pump outlets was partially blocked! These outlets start at about 4mm across, and narrow to about 0.5mm. That’s why it had passed our cursory blowing through the thing to see if it was clear. Using a small length of wire from the fuel hosing braiding, the passageway was cleared, and tiny flake of white aluminium corrosion fell out…

So that was it, all those problems were caused by a tiny bit of corrosion that had worked itself up to the narrowest gap it could wedge itself into. Although it seems like we were on a wild goose chase for a lot of it, I believe that a lot of worthwhile work was still completed. Replacing the drain plug filters was definitely required, the pump was on the way out, and the Filter King cures some edge case starvation problems, as well as providing a handy visual indicator for the state of fuel flow in the system.

I have a minor issue that I’d like to get resolved. I have a cheap but very good USB GPS receiver. However, it uses a weird USB connector and the cable for said connector has developed a fault (at the strain relief point, amusingly). Can anyone advise on the type of connector it uses?

In the two lower photos the cable at the top left is the one I need a replacement of. The device at the bottom is the GPS receiver, and the cable at the top right is a normal mini-USB plug. The photo on the far right is a micro-USB connector, and it isn’t that either

Recently I’ve been looking at getting a computing device into the Land Rover. Short of buying a full sized 7″ touch screen, I opted to go for a slightly cheaper £20 4×20 LCD display. This was more to be proof of concept, and give me a starter to work on, before I decide whether or not to put a full sized screen in.

Ultimately, I purchased a SmartieLCD module from Ebay. It arrived, I plugged it into my laptop running Windows at work, and it worked first time. Now it was time to get it working with LCDProc!

Earlier on I had spotted that SmartieLCD in Windows used the Matrix Orbital DLL file. Sadly, when using LCDProc in Linux, Matrix didn’t work at all. It was time to go looking

Enthused by http://lists.omnipotent.net/pipermail/lcdproc/2009-July/013021.html, and manufacturers documentation, I decided to check out the CVS copy of LCDProc. The last ‘release’ was back in 2007, so if I was to get anything recent it would have to be from CVS

cvs -d:pserver:anonymous@lcdproc.cvs.sourceforge.net:/cvsroot/lcdproc login
cvs -z3 -d:pserver:anonymous@lcdproc.cvs.sourceforge.net:/cvsroot/lcdproc co -P lcdproc

Having a look around the source files indicate that Sure Electronics displays were supported, but not enabled by default. A simple ./configure flag would enable them, so it was time to get compiling. Firstly some support files have to be installed first.

sudo apt-get install libusb-dev autogen automake

After that, kick off the build process, and enable Sure Electronics support at configure time.

sh ./autogen.sh
./configure –enable-drivers=SureElec
make
sudo make install

Now that the software is installed, LCDd needs configured in order to send data to the LCD display.

sudo vim /usr/local/etc/LCDd.conf

In here, a few parts need changed -

driver=SureElec
DriverPath=/usr/local/lib/lcdproc/
Edition=3
Contrast=200
Brightness=480

And that’s it! Execute /usr/local/sbin/LCDd, and you should get a Clients: 0 and Screens: 0 on the LCD display.

All is good!