Ingredients

Let’s see if I can remember what I used:

• 20 rashers of bacon (Smoked)
• 1 onion, finely chopped
• About half a bulb of garlic, minced
• A good heaped tablespoon of brown sugar (some might call this 2 spoons)
• Some Chilula chipotle hot sauce (smokey tasty)
• 1/2 a cup of maple syrup (maybe a little more, maybe more like a 1/2 mug)
• 1 cup of coffee
• 1/4 of a cup of cider vinegar

Method

It’s pretty easy:

• Fry all the bacon
• Put the fried bacon into a pot with the onion and garlic on a medium heat, give it about 10 minutes until the onion is nice and soft
• Add everything else to the pot and bring to a simmer
• Leave the pot open and keep it at a low simmer for around 2 hours (You may have to add a little water if it starts to look too dry)
• You should end up with a sticky mess, put it in a food processor and whizz to your desired consistency
• Eat on toast, with eggs, anywhere where you might use a chutney

So the setup I used was:

• A Core i7 based server
• Debian 6.0.1 AMD64 (Squeeze)
• Xen 4.0.1 (Debian packaged version)
• Windows 2008r2 Standard Edition
• GPLPV 0.11.0.238 paravirtualized drivers for Vista/Win7/2008

I’m going to start at the beginning since that’s what I did.

Hardware

Before you begin you’ll need to check that your processor supports virtualization extensions, and that these are enabled in your motherboards BIOS. If you have Linux on the machine (or can boot a Linux live cd) you can check for virtualization extensions in the following way:

cat /proc/cpuinfo

You are looking for vmx (for Intel processors) or svm (for AMD processors). One caveat is that if you;ve installed the Xen hypervisor already you may not see vmx or svm listed in /proc/cpuinfo. In this case you can run:

xm dmesg

Check for a line that looks something like

(XEN) HVM: VMX enabled

Okay, so assuming you’ve got virtualization extension support on your processor the rest of the hardware is pretty much up to you (and what the kernel will support).

Debian and Xen

This is fairly straightforward if you’ve installed any Linux distribution before. I had to do it the hard way, doing a bootstrap from Centos (as the server is in a datacentre somewhere and came with Centos as the only OS choice). The install should be as minimal as possible, you don’t really want much running on the host (dom0) system. The only notable thing about my setup was the partitioning:

/boot 256MB
/ 10GB
swap 8GB
LVM Volumegroup ManyGB

LVM makes managing guest disks quite straightforward and flexible.

Note: Debian 6 uses GRUB2 as its boot manager, the easiest way to ensure the OS you want to run is booted by default is to modify /etc/default/grub and modify the GRUB_DEFAULT line to the name (with quotes) of whatever entry you want to boot by default, then to run grub-update. You can check the names of the current GRUB entries in the file /boot/grub/grub.cfg

So once you’ve done your base Debian install, you’ll want to install Xen. The following should install most of what you need:

apt-get install xen-linux-system-2.6-xen-amd64 lvm2 bridge-utils genisoimage

GRUB2 installed with Debian 6 knows about Xen and when you do the apt-get above your /boot/grub/grub.cfg should get updated automatically with new entries for your Xen hypervisor and appropriate kernel, if you want to make sure the update has happened just do a grub-update.

Okay so now you should be able to reboot and boot into your “Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN 4.0-amd64″ or similar.

Once booted you should be able to do and see the following:

root@vmhost:~# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  6928     8     r-----    697.8

In my configuration I have a number of public IPs assigned to the machine which I can assign to the virtual machines. To enable this we need to tell Xen to use bridged networking. To do this you need to edit the file /etc/xen/xend-config.sxp and make sure to uncomment the line:

(network-script network-bridge)

Once you’ve done this you’ll need to restart xend (service xend restart) or restart the machine to bring the bridge up.

Windows VM, disks and DVDs

First you need some installation “media”. I wanted to install Windows 2008 from an MSDN dvd iso image. The first problem, how do I get the dvd image from the MSDN site with only text based browsers that don’t support Javascript? I started by logging into MSDN and going to the downloads section in my desktop browser (I used Chrome but you should be able to use any browser that allows you to see what requests are being made to the server). Open the Chrome developer pane (the easiest way to do this is just right mouse anywhere on the site and do “Inspect element”) and then go to the Network tab. Click the download link and you should see requests to a couple of URLs on the MSDN servers. The first is to a “default.aspx” click on this and you should see more information about the request. Copy the URL parameter, you should be able to use this with wget on your Xen host to fetch the dvd iso image.

Okay, so now we have the DVD image, we need a “disk” to install to. I partitioned my disk so that most of the disk was free for LVM. If you haven’t used LVM before it’s worth having a read about it now, the simplest set of commands to get LVM up and running are below (replace /dev/sdx4 with whatever device(s) you want to use for storing the virtual machine images on):

pvcreate /dev/sdx4
vgcreate vm-volgroup /dev/sdx4

Assuming you use the lines above you have an LVM volume group called vm-volgroup on which you can create logical volumes with a command something like:

lvcreate -L 60G -n windowstest-disk vm-volgroup

So the above will create a new 60GB logical volume called windowstest-disk on the vm-volgroup. A block device will be created for this volume and symbolic links made so you can easily access it. For example using the commands above you will end up with a link at /dev/vm-volgroup/windowstest-disk, which you can use in your configuration files to refer to the disk.

We also need one more block device, this is going to be a CD to install the PV drivers from. Grab the PV drivers installer from http://www.meadowcourt.org/downloads/ I used gplpv_Vista2008x64_0.11.0.238.msi

To create a cd image with the file on it, stick that file in folder on its own, then do the following:

genisoimage -o /opt/isos/win2k8drivers.iso drivers/

Xen VM Configuration

So we’ve now got all the block devices sorted out we need a configuration file for the machine. Here’s what I used:

name = 'windowstest'
kernel = '/usr/lib/xen-4.0/boot/hvmloader'
builder = 'hvm'
device_model = '/usr/lib/xen-4.0/bin/qemu-dm'
memory = 2048
shadow_memory = 8
vcpus=1
acpi=1
apic=1

# Choose a better mac address
vif = [ 'bridge=eth0, mac=00:11:22:33:44:55' ]

## The VM has the following block devices
#  - A boot disk with a single partition for the OS, swap, and programs
#  - The installation DVD
#  - The PV drivers CD
disk = [ 'phy:/dev/vm-vol/wintest-disk,hda,w',
'file:/opt/isos/en_windows_server_2008_r2_standard_x64_dvd.iso,hdc:cdrom,r',
'file:/opt/isos/win2k8drivers.iso,hdd:cdrom,r']

# Boot from the DVD first
boot='dc'

usbdevice='tablet'

## Use VNC for the console.
vnc=1
vncunused=0
vnclisten = '127.0.0.1'
vncdisplay=2
vncconsole=1
vncpasswd='agoodpassword'

vncviewer=0
sdl=0

stdvga=0
serial='pty'
ne2000 = "0"

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

Note: Do not use a maxmem definition in the configuration file. THIS WILL CAUSE YOUR DOM0 TO CRASH.

Okay, we should now be good to go.

Connecting to your Windows VM

So you’ll see in the configuration file above, the VNC server that is displaying the windowstest VM’s screen is bound to 127.0.0.1. You can specify the Xen host’s external IP, however if it’s world viewable on the internet that may not be a good idea. Running it on localhost means that you have to use ssh to forward a port on your desktop machine to the local port on the Xen host. You can use putty to do this:

Port 5902 as we are using VNC screen 2

Putty Tunnel Added to the configuration for this ssh host

Connect and log into to the host, and the tunnel should be established.

Connecting to the ssh forwarded VNC port

Windows Installation and Paravirtualized Drivers

Once you are connected via VNC you can go through the Windows install as normal. Once this is done we want to install the GPLPV drivers. The drivers are test signed, this means that Windows will not boot with them unless we explicitly tell it to boot without signed drivers (which requires setting on every boot) or by enabling test mode. Test signing mode can be enabled permanently by opening a command line on the windows machine and typing the following:

bcdedit.exe /set TESTSIGNING ON

You will need to reboot the VM to enable test mode.

When the VM has rebooted and you’ve reconnected with VNC you can install the GPLPV drivers from the CD. The default install options should be fine. Rebooting the VM again after the drivers are installed should enable the PV drivers. Congratulations you’re done!

UPDATE: Signed PV drivers are now available take a look here: http://wiki.univention.de/index.php?title=Installing-signed-GPLPV-drivers

Taking apart one of the games I was presented with this:

PCB from Super Bomberman 2 cartridge, non-working

As you can see there’s quite a lot of dirt/corrosion on the contacts of the PCB. I tried removing the dirt with some cotton buds + IPA but it was fairly stubborn so I ended up giving the contacts (just the contacts leave the rest of the PCB alone) a very light sanding with some 1000 grit sandpaper (probably wet and dry, I just found a small piece of it in the top of my toolbox). I wouldn’t recommend using anything coarser as you may damage the tracks.

As an aside, grit is the measurement of “roughness” of sandpaper and polishing compounds. It refers to the maximum number of holes per inch in a mesh that will still allow the compound/grit through. So the larger the number, the finer the grit.

So after a little sanding I got this:

Shiny Bomberman 2 PCB

Putting it back into its case and putting it into the SNES, success! Super Bomberman 2 lives again! Opening the cartridges isn’t really necessary but I thought I’d do it to get some better pictures of the board.

Sympathetic Dreamcast

As a show of support for its black screening older friend, my Dreamcast decided to start rebooting itself a few seconds after starting up, or whilst loading games. This, again, was down to corrosion of contacts. The power supply in the Dreamcast is internal and uses a pin header plus sprung contacts to transfer the power to the console’s main board.

Removing the power supply and again lightly sanding the pins fixed the problem. Hooray! Although that does mean I now have to finish the Nomad Soul…

Note, before you start cutting wires in your car: the internals of the headlight auto levelling system are unknown to me I’m treating it as a “black box” (how convenient that it is actually a black box) and just looking at the inputs and outputs and making assumptions about how it works. I accept no responsibility if you cause damage to your car, yourself or others from doing things detailed in this post.

Background on HID lights

All 231BHP versions of the RX8 (in the UK at least) have high intensity discharge headlights (HIDs).

One of the requirements for using HIDs in a car is that the car must have some sort of auto-levelling system to ensure that when the car is loaded unevenly front to rear that the difference in height front to back does not cause the lights to point too far up, potentially dazzling other motorists.

The RX8 does this by having actuators in the headlight unit to angle the beam up and down. To sense the suspension load at the front and rear it has 2 sensors, one on the left front suspension, another on the rear left suspension assembly.

So what’s the problem?

So you may be thinking why do you want to manually adjust the lights then? Surely this is a safety feature?

The sensors are, essentially, potentiometers (variable resistors) attached via a linkage to the suspension. They have a wiper that moves along a carbon track the ends of which are connected to power and ground.

It costs £400to make this? Really?

By reading the voltage from the wiper connection on the front and rear sensors the auto-levelling control unit can work out if one end of the car is higher than the other and adjust the headlight angle accordingly.

The problem is that the sensors that are used, corrode and wear out. This wouldn’t be so much of a problem but Mazda want around £400 per sensor! For a variable resistor?!

So there we have it:

1. Give £800 to Mazda for some new sensors
2. Attempt to repair the sensors (if you’re lucky you may be able to dismantle the sensors, give them a good clean, replace contact springs and they might start working again)
3. Go manual

How to do it

Fortunately Mazda have made this quite simple to do as the headlight auto levelling control unit is in the cabin and not, for example say, part of the ECU, or in some inaccessible location.

The control unit lives just to the left of the glove box, to get best access to it, remove the glove box, this involves gently bending in the side of the glove box when it’s open to allow the end stops out, once that’s done you should just be able to lift the glove box out (there is also a soft opening mechanism, but mine died quite some time ago, as far as I know you can just unclip it from the glove box.

[AUTO LEVELLING CONTROL UNIT PICTURE Coming Soon!!!]

The auto levelling control unit is the black box that says “Auto Leveling Unit” on it. It has one connector with 24 pins, the details of which you can see below:

This is as seen from the cable side of the connector

From the RX8 wiring diagrams the cables we care about are :

• P – Black with a Green Stripe – Ground for sensors
• C – Black with an Orange Stripe – Power for sensors
• I – White with an Orange Stripe – Rear Sensor wiper output
• K – Black with a Blue Stripe – Front Sensor wiper output

So what we want to do is tell the auto levelling unit that the front suspension is at its neutral position all the time and we want to be able to adjust the “rear position” to make the unit think the boot is either lightly or heavily loaded to make it adjust the headlight level accordingly.

So here’s a simple little circuit to do just that, you will need:

• 2 x 4.7k Resistors
• 2 x 1k Resistors
• 1 x 10k Linear Potentiometer

What you need to build

R3 and R4 are there to change the range output by the potentiometer, as the auto levelling control unit most likely flags a fault if the voltage is zero or maximum (implying a short or open circuit somewhere).

So simply build it up in whatever fashion you desire (do make sure to insulate the parts from each other) and put it on a long enough wire to locate the potentiometer somewhere you can get at it, I think the ashtray would make a fine home.

Before starting the install, disconnect the negative battery lead. Installing it is a matter of cutting back a bit of the massive amount of insulation tape on the cable to the auto levelling unit connector then cutting the 4 wires detailed above (check twice, cut once). Strip a short length on each of the 4 cables from the connector (insulate the other ends, they are not used, they’re just connected to your broken sensors) and then either solder, or use terminal blocks to connect your contraption.

Anyway, the engine requires oil in the combustion chamber(s) to lubricate the rotors. Petrol dissolves the oil and which can lead to the rotors failing and you being left with a large bill. But what does this have to do with ignition coils?

The Problem

Due to the way rotary engines operate the coils are worked very hard. At 9000rpm the coils and spark plugs are sparking 150 times a second. This leads to them running rather hot which causes the insulation on the coil to break down which means a shorter path for the electricity to arc to where it’s not supposed to (somewhere other than the spark gap of the plug). Eventually the coil will fail and stop providing enough voltage to the spark plug, which means the spark plug is going to stop sparking.

• Less sparks = Less petrol being burned.
• Less petrol being burned = More petrol on the rotor
• More petrol on the rotor = Less oil on the rotor
• Less oil on the rotor = More engine wear
• More engine wear = Less happy owner

Solution

Change your coils regularly, at the same frequency as your spark plugs (about every 3 years). My car had 28,000 miles on the clock and was just over 5 years old when I changed mine. They are fairly easy to change yourself, the main pain is removing the airbox and bellows to get at them, once that’s out of the way it’s just the matter of getting them connected up to the right leads.

They are very expensive from Mazda UK. Happily, however, you can buy a set of 4 of them from Rotary FX for the same price as Mazda UK will charge you for a single coil.

What mine looked like

All 4 looked like the picture below, 2 of them had failed completely when tested with a multimeter(both trailing plug coils). Since the replacement there’s not a lot of difference at low revs but higher up the rev range the difference is a lot more noticeable.

Yuck, white spot on the coil where it has overheated

They essentially allow you to turn 3 output pins into 8. So let’s have a look at a fairly normal shift register chip the ON MC74HC595A:

Logical layout from the datasheet

Inputs

The inputs we’re interested in if we want to use this to expand the output of our microcontroller are:

• The Serial Data line
• The Shift Clock
• The Latch Clock

Now you may be thinking what about the Reset line, what about Output Enable? Well we don’t really need to use these.

• Reset: Each time we shift data into the shift register we’ll be doing 8-bits at a time “overwriting” the previous values so reset isn’t really very valuable to us (we’d much rather that extra I/O pin on our uC). You’ll notice that the Reset line is an inverted input (see the little circle at the end of the line?) so we want our chip to always be not in the reset state so we just tie that pin high (to 5V in the case of this chip).
• Output Enable: We want the chip to always have its outputs enabled. I’m guessing you’d rather have an extra uC I/O line than worry about the tiny amount of time at start up when the shift register has not been fed any values and so all its output are on. The line is again an inverted input so it’s really not Enable so we tie it to ground to have our outputs always on.

How do you work this thing?

Well it’s pretty simple, whenever the chip detects a rising edge (i.e. from ground to +5V) on its shift clock input it shifts the bits current stored in the shift register along one (so the highest bit drops off the end to be lost forever) and the lowest bit of the shift register becomes whatever the serial data input line is currently set at. So we fill up our shift register one bit at a time until we have all 8 bits, once all of our new 8-bits are into the shift register we want to send a rising edge to the latch input, this will transfer the bits in the shift register onto our output pins (QA-QH) on the chip.

So in in pseudo code:

ShiftRegisterPort = 8bit value we want on the output of our shift register
for(bit=0;bit<8;bit++){
  uC Shift Clock Pin = 0;
  uC Serial Data Pin = RegisterPort Bit (7-bit);
  uC Shift Clock Pin = 1;
}
uC Shift Clock Pin = 0;
uC Latch Clock Pin = 1;
uC Latch Clock Pin = 0;

The timing diagram looks a bit like this:

Rough timing for writing to the chip

That’s it

And that’s pretty much it. If you are not too fussy about the state of your outputs you can even run this from 2 pins by tying the shift and latch clock lines together, this does give you a ripple effect as the bits are output as they are shifted into the shift register. If you do this you also have to clock 9 times (with the last data bit being ignored) as otherwise the 8th data bit is not latched from the shift register. For slowly changing outputs,  this could work quite well, however if you want to do PWM, for example, then you don’t really want your outputs rippling all the time as values are shifted along.