Removing a Stuck Shower Plate from the Gaggia Classic

Shower Plate Removal

My shower plate had become badly clogged, with two of the holes pretty much completely blocked. When I tried to remove it, I found it was really badly stuck… I tried soaking in descaling solution, tapping it with a soft faced hammer, levering it from the side with wood (mindful of damaging the shower plate)…. but it wouldn’t budge.

Then I stumbled on a tip in a forum: simply insert a longer screw in the central hole, and tighten this until it pulls the shower plate free! So, I used an M5x20mm socket head cap screw (pictured above) and, with a few turns of an allen key, the plate popped straight off.

I tried cleaning and descaling the shower plate, but it was pretty badly stained. Having neglected my machine so badly, I felt slightly ashamed and decided it deserved an upgrade with a shiny new brass shower plate…

Brass Gaggia Shower Plate

Much better!

More Windows 10 Weirdness

Since upgrading to Windows 10, I’m still having some weird issues… one thing that particularly annoyed me was the long delays when creating and renaming folders. After renaming a folder, Explorer would sometimes take about 10 seconds to respond. The fix for this issue was:

  1. In Windows Explorer, select the View menu.
  2. Click the Options button on the right hand side (not the drop down).
  3. On the General tab, under Privacy, untick both of the “Show recently…” and “Show frequently…” Quick access options as pictured below.

This fixed the slow renaming issue. The weird thing is, I’m pretty sure that I disabled these options before and they seem to have enabled themselves again?!

I’ve also got another really strange problem I can’t understand. Occasionally, I’ll boot into Windows and some of the apps won’t start – they just freeze up or hang on the splash screen. For example: Chrome, Calc, Outlook and nslookup (on the console) freeze and have to be force closed but, weirdly, others like Notepad and Excel just start fine, and ping and tracert both work. Multiple restarts don’t cure it.

Purely by chance, I found a way to fix this by rebooting the PC into Ubuntu Linux (it’s dual boot), shutting Linux down and rebooting into Windows 10. Simply restarting Windows isn’t enough, I have to actually shut down, log into Linux, then restart into Windows 10. I cannot understand how/why this fixes it…

UPDATE: I eventually discovered that holding SHIFT when shutting down Windows 10 makes it do a full shutdown, and a clean restart then cures the problem. This still happens to me occasionally… irritating.

TB6560 Stepper Motor Driver versus GRBL

For a while now I’ve had an old TB6560 Stepper Motor Driver board kicking around, which never really saw much use. I used to drive it from a PC parallel port (remember those?) with a very big, ugly old desktop PC running LinuxCNC. Because of the size, this was pretty inconvenient. Recently, I decided to resurrect it and try to drive it from an Arduino Uno with GRBL. It took some time to find the pinout online, particularly since there are several variants of this board with completely different pinouts, so I decided to make notes here…

This manual appears to correspond to my 3 axis board: (TB6560 3 Axis Manual) and here’s the pinout that I’m currently using successfully:

LPT1 PinLPT1 FunctionArduino PinGRBL Function
1X Step2Step Pulse X-Axis
2Y Enable8Stepper Enable
3Y Direction6Direction Y-Axis
4Z Direction7Direction Z-Axis
5Z Step4Step Pulse Z-Axis
6Z Enable8Stepper Enable
7X Direction5Direction X-Axis
8Y Step3Step Pulse Y-Axis
9Spindle Motor12Spindle Enable
14X Enable8Stepper Enable

This works but these blue TB6560 boards are absolute junk and have numerous well documented design flaws (e.g. skipping steps) which require DIY modifications to fix, so if you are considering buying one… don’t. There are plenty of better options available!

First experiences of Windows 10

I finally conceded to upgrade from Windows 7 to Windows 10 (Dell Precision M4700 Laptop) and… it’s not terrible, but I’ve had a few issues:

  • CDRW drive vanished. Fortunately restored by downloading drivers from Dell.
  • SD card reader vanished, required new Dell drivers and manually enabling some devices in device manager. I’ve still not got to the bottom of this one: every time I need to use my SD card, I have to open Device Manager and manually enable “Intel(R) 7 Series/C216 Chipset Family PCI Express Root Port 8 – 1E1E”. Still a major annoyance!
  • Takes an inexplicably long time to shut down, with a black screen. However, this seems to have to improved since a recent Windows update.
  • PDF files are associated with Edge by default. Which is odd, given that Edge seems incapable of opening PDF files. Fortunately, it is easy to change the file associations to fix this. Why on earth does it do this?
  • OpenGL quad-buffer frame sequential stereo no longer works properly (NVIDIA Quadro K2000M / 368.86 drivers). Either it displays the left stereo channel only, or works but with terrible performance (1 fps). Workaround: using the “Virtalis applications” profile seems to fix this (but restricts the 3D settings available). Solution: this one finally seems to have been resolved by Windows updates, and currently working OK on 369.09 drivers.
  • OpenGL stereo also causes issues with double images on the lock screen (below), and remnants of the lock screen are visible when returning to the desktop.quad_buffer_lockscreenThere is a temporary workaround: starting a stereo application and exiting it again temporarily fixes the desktop flicker, until the PC is locked again, at which point the problem returns. The only way to fix it otherwise is a reboot. Solution: this now seems resolved on 369.09 drivers.
  • When OpenGL stereo is enabled (on NVIDIA card/driver above), the display brightness increases to maximum, and it is not restored when the stereo application exits. Afterwards, the brightness controls in Windows no longer seem to work. Workaround: using the “Virtalis applications” profile seems to fix this. Solution: this one was eventually resolved by Windows Updates and/or 369.09 drivers.
  • The sound sometimes randomly stops working. Uninstalling and reinstalling audio drivers and fiddling with settings doesn’t seem to fix it. Then mysteriously, just after I’ve given up, it starts working again all by itself… spooky.
  • Windows Explorer often seems to respond really slowly and displays a blank page for a few seconds when initially browsing the local hard drives (which are both SSDs!) Solution: I disabled “Quick access” under: Quick access.. Options… General… Open File Explorer to: “This PC” (instead of “Quick access”). This eliminated the problem.
  • Recently (after an automatic update) every time I log into windows, I can briefly see a progress bar showing two files relating to the touch pad drivers being deleted (!) Still haven’t got to bottom of this issue.

In the interests of balance, some positive things…

  • The “Movies & TV” video player is much smoother at seeking in video.
  • The notification sounds remind me of Zelda / Wind Waker… which is cool.

Fire-o-matic: the home made Fire Machine

This project is firmly in the category of things you should not try making at home, but is great fun nevertheless… it’s a home made “Fire Machine” which launches jets of flames and fireballs when you switch it on:

This is obviously quite dangerous, so I seriously wouldn’t recommend making one of these. You can buy them ready made on eBay (although they are pretty expensive).

Anyway, rather than write up all the details of this project, I’ve taken some photos and videos of the main components instead. This video shows the solenoid valve components and how it was assembled (mostly out of scrap parts):

Here’s another video showing the electrical parts. It’s actually fairly simple, so there’s no real need for a circuit diagram/schematic:

This is where I originally got the inspiration from (Chinese made DMX fire machine):

Gaggia Classic Boiler: step response, lag and temperature drop rate

Partly for my own notes, here are the results of some simple experiments with the Gaggia Classic boiler, to better understand its behaviour. Prior to these tests, the machine started out at ambient temperature of around 21°C. The temperature sensor is the TSIC 306 mounted in the same position as the original brew thermostat. There was no portafilter fitted. The tests were carried out on 240V AC mains in the UK, and this is the original Gaggia Classic with an Aluminium boiler.

This first graph shows the temperature (blue line) in °C versus time in seconds for a step input of heat at full power for 4s. The red line shows the timing of the heat pulse. Note the lag of about 4s before any measurable change in temperature after the element is switched on. In this example, the starting temperature was 21.7°C, the peak temperature was 29.8°C and the temperature rise was 8.1°C.


This second graph shows a step input of heat at full power for 8s. Again, there is a lag of about 3s before the temperature changes. Here the starting temperature was 23.2°C, the peak temperature 39.1°C and the temperature rise was 15.9°C. The original data can be downloaded as a CSV file.


Here’s a longer sequence, showing the first 35 seconds of the boiler heating up from “cold” after the heating elements are first switched on. The heating elements were on for the full duration of the graph below. Again, it takes 4 seconds before the first change in measured temperature. After 12 seconds, the temperature rise becomes almost linear, with a rate of increase of about 1.83°C/s (straight line fit to a linear subset of the data in Excel). The original data can be downloaded as a CSV file.


For the final test, the machine started at about 26.9°C and was driven up to 93°C under PID control then allowed to naturally cool down, to see how fast the temperature drops. Again, the data can be downloaded as a CSV file.


The initial temperature drop from 92.9°C to 90°C takes 29.25s, which is about 1°C every 10 seconds (0.099°C/s), within the small region between 90°C and 93°C where our temperature controller operates.

Measuring Ulka EP5 Pump Inductance

Having previously tried to estimate the pump inductance of the Ulka EP5 Pump, and without really being certain of the accuracy, I decided to try and actually measure it. Unfortunately, this is made difficult by the series diode built into the EP5 pump. Although I had a spare pump, I didn’t want to completely destroy it by opening it up, so I decided to try and reach the terminal by performing “minimally invasive surgery” on the pump…

To start with, shining a torch through the plastic pump body reveals the location of the metal tab terminal on the solenoid, and the series diode:2016-05-04_ulka_exam1

Having done this, a Sharpie pen was used to mark a point above the metal tab, which was approximately where the “U” is in the ULKA logo as shown by the small black dot below:


Then a pin vice was used to carefully and slowly drill a 1mm hole until it reached the surface of the metal tab, while taking care not to drill too far:


Having done this, we can now directly access both terminals of the solenoid and completely exclude the diode from our measurements. Using a low cost LCR component tester (fish8840 Taobao) it is possible to measure the inductance and series resistance as shown below. Successive readings showed 847.8mH, 856mH and 859.3mH with an average of about 854mH. The series resistance was about 165Ω as measured previously.2016-05-04_ulka_coil_LR

As both sides of the diode are now accessible, we can also check the diode forward voltage as shown below. This shows Vf=706mV and C=40pF:

2016-05-04_ulka_diode_VFCWhen finished, the hole will be filled with epoxy to seal it back up again and make it safe.


The inductance was measured as 854mH and the series resistance was 165Ω. The diode forward voltage is 706mV. These tests are carried out at a low voltage, and without any hydraulic load on the pump. It is possible that the solenoid plunger position may also affect the measurements. Note that the measured inductance is significantly different to the previous estimate.

Heisenbugs; the Dark Side of Debugging

Some of the most difficult software bugs to track down are those that disappear when you try to study them… Heisenbugs! For example, when an issue is reproducible in a Release build, but disappears when you run the software in the Debugger.

There are many possible explanations for this which include differences in memory initialisation, timing, code optimisation, code and memory layout between Debug and Release builds. I won’t elaborate on the details here, as they are already very well covered on stack overflow.

The reason for this post is that we recently encountered an issue in some code which has the following behaviour:

  1. Has a reproducible bug in release mode (not an outright crash or exception, but fails to behave as expected).
  2. Runs perfectly well when started in the debugger, with no issues.
  3. When started without debugging, and the debugger is attached later, several first chance exceptions are seen.

My theory was that the exceptions weren’t being triggered when started from the Debugger because the memory initialisation (or other Debug/Release differences) were preventing the exceptions from occurring. However, there was some debate on this point, with someone else suggesting that attaching the Debugger later was causing spurious exceptions. Their suggestion was that if these exceptions were genuine, they would also occur when started in the Debugger.

I’ve seen this debate crop up frequently enough, that I thought it would be useful to create a very simple example to demonstrate an exception that reproduces in Release, but works fine in Debug. Also, to confirm whether the same exception would reproduce when the Debugger is attached to a running process.

Here is a first attempt at creating a very small Heisenbug demonstrator in C++, which has a deliberate access violation:

#include <iostream>

void main() {
    int *x = new int[3];
    if (x[1] != x[2]) delete [] x;
    delete [] x;

When a Release build is run in Visual Studio 2013, it demonstrates the following behaviour:

  1. When started without the Debugger and a key is pressed, it causes an exception.
  2. When started under the Debugger and a key is pressed, it exits cleanly and works fine.
  3. When started without the Debugger, and the Debugger is later attached and a key is pressed, it causes an exception.

If you run this a few times, you might find that Windows enables the “Fault Tolerant Heap” for the executable, and then you won’t be able to reproduce the exceptions. The solution is to disable the Fault Tolerant Heap for your executable, by going to these keys:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\heisenbug.exe

HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\heisenbug.exe

Then delete the Fault­Tolerant­Heap entry on both of these keys. In my case, only the HKLM version was needed.

Returning to the code to explain how this works, here’s a commented version, explaining each line:

// create an array of 3 integers, without initialisation
int *x = new int[3];

// compare elements 1 and 2 (which are not initialised)
// if they are different, delete the array and leave
// the invalid pointer in x
if (x[1] != x[2]) delete [] x;

// wait for a key press

// delete the array (potential access violation)
delete [] x;

There are two intentional bugs in this particular line of code:

if (x[1] != x[2]) delete [] x;

The first bug is that we are accessing uninitialised memory, because the array x has not beeen initialised. When we compare x[1] and x[2] the result is unpredictable. In a Release build there’s a good chance (but not absolute certainty) that these values will be different, and it will delete the array. Second, after deleting the array, the variable x still contains the (now invalid) pointer address. Later on, when this final line of code executes, it will access an invalid pointer, usually causing an access violation exception:

delete [] x;

However, when running in the Debugger, it’s very likely that the memory will have been initialised by the Debugger, and x[1] and x[2] will usually contain the same value. This prevents the pointer from being deleted, and avoids the access violation. The code runs without issue when being debugged.

This serves as a very simple example of a bug which only appears in Release, and disappears in the Debugger, due to accessing uninitialised memory (as mentioned above, this is only one of many possible causes of such an issue).

Abarth 500 Fuse Box / K1S Dashcam Wiring

I recently fitted a K1S Dashcam (Koonlung K1S) to an Abarth 500, and wanted to have a tidy install with no wires showing if possible. To avoid having it plugged into the 12V lighter socket, I needed to find a suitable place to wire it into the dashboard fuse box. Although the fuse box is described in the manual, it doesn’t indicate which fuses are permanently live, and which are switched live. This information is not readily available on the interwebs either, so I figured it out with a meter and made some partial notes in the table below.

F127.5Right dipped headlamp power supply
F137.5Left dipped headlight and headlight alignment control unit power supply
F327.5ConstantFront, rear and luggage compartment roof lights
F3610Diagnosis socket, radio, climate control, EOBD
F375Brake light switch, instrument panel node
F3820Door central locking
F4315Windscreen/rear window washer pump
F4720ConstantDriver's side electric windows
F4820ConstantPassenger side electric window
F495SwitchedParking sensor, control backlighting, electric mirrors
F507.5Airbag node
F517.5SwitchedRadio switch, Blue&Me, climate control, brake lights, clutch
F535Instrument panel node

Obviously, there are a lot of fuses there which are “safety critical” such as the Airbag, Brake Lights etc. which are best avoided. Also, the fuse layout is probably the same on the standard Fiat 500, but you know… they might not be, so use this information at your own risk!

The picture of the fuse box in the manual is upside down (for right hand drive models) so here’s a rotated version with the fuse ratings added in blue. The Switched (S) and Constant (C) supply fuses are (partially) labelled in red:

Abarth Fuse Box

To avoid cutting any wiring, I used one of these mini “add-a-circuit” widgets, which allow you make another connection to an existing fuse:


They need to be used with some care, because you could fit the original and new fuses in the wrong places, and fit it in the wrong orientation. As there were no instructions with it, I used the resistance range on my meter to double-check the wiring before fitting the fuses.

In the picture above/below, the left blade is the input side, which needs to go to the live supply in the fuse box. The right hand pin nearest the wire is the output, after the fuse. The original fuse goes in the lower two holes. The new fuse for your added circuit goes in the top two holes, and the output of that fuse is the red wire. Pretty self explanatory really:


When installed in one orientation (12V input to left blade as described above), the input goes through F1 to item A and the input goes through F2 to item B. If either fuse blows, the other item should still have power. However, when installed in the reverse orientation, note that the input will go through F1 to item A but will go through both F1 and F2 in series to item B. So you need to consider the orientation when installing it.

The wire projecting from the side of the “add-a-circuit”, and the fuses projecting sideways can make it impossible to fit in some positions and orientations (e.g. if they interfere with the side of the fuse box). This can limit your choices on which fuses it can be connected to.

Here’s a shot of it fitted in situ on the fuse box. In this case, it’s inserted into F49 (Parking Sensor, control backlighting, electric mirrors). Using a meter, I found that the left terminal in F49 was live with the fuse removed, hence the output wire faces right when installed:


Caution: whereas the left terminal of F49 was live, I found that it was the right terminal of F47 and F48 that was live, so it isn’t the same for every fuse.

For the ground connection, I used an eyelet crimp terminal under one of the two bolts which secures the bonnet release handle to the chassis. This is a very short distance from the fuse box, so easy to run a wire.