RX8 Project – Part 20, Canbus #5, RX8 Odometer

So again for this post I’m going to concentrate on one specific aspect of the RX8 CANbus system which a few people have asked me about and that’s making the ODOmeter on the cluster tick up correctly without the factory PCM (ECU) being fitted to the car. This also allows the trip A and B meters to work correctly as they are all linked to the same register.

I’ve mentioned in previously to people that the odo requires a state change to update and I think this is why people haven’t been able to identify what controls it – simply writing a value doesn’t do anything. It is controlled via byte 1 of what I defined as statusMIL, this is CAN ID 0x420 which is the same ID which also controls things like the temperature and oil pressure displays on the dash.

I originally identified how this was controlled during some of my early reverse engineering work on the cluster when I was just sending blocks of values (initially cycling between 00 and FF for all bytes in the array) to CAN ID’s to see if I could make anything happen and I noticed at some stage the trip had increased. Clearly this meant one of the ID’s was doing something and because the same ID also controls various warning lights they also flashed on and off at the same time as the odo incremented which made the identification of the ID rather simple.

Next up I edited the program to count each byte in the CAN data up in order, so for example start with an array with only 00 in each byte then starting at byte 0 increment the value by 1, send the whole array, wait briefly and increment again and so on. When the top value of FF is reached set it back to 00 step on to byte 1 and so on. This allowed me to isolate the specific byte that was controlling the odo changes. Anyway the story goes on and after a lot of trial and error with values and timings I got to this bit of fairly horrible test code:

#include <mcp_can.h>
//#include <mcp_can_dfs.h>      //Declaration for Standard Can
#include "mcp2515_can.h"        //Declaration for Seeedstudio Can Library

#define CANint 7  // Normally 2
#define LED2 23   // Normally 8
#define LED3 0    // Normally 7

#define NOP __asm__ ("nop\n\t")
const int SPI_CS_PIN = 17;
mcp2515_can CAN0(SPI_CS_PIN);   // Declaration for Seeedstudio library
//MCP_CAN CAN0(SPI_CS_PIN);     // Set CS to pin 10 - Older Library version

void setup() {

    delay(1000);    //delay to allow for monitor
    Serial.println("Setup pins");
    pinMode(LED2, OUTPUT);
    pinMode(SS, OUTPUT);
    pinMode(LED3, OUTPUT);
    pinMode(CANint, INPUT);

    Serial.println("CAN init:");
    if (CAN0.begin(CAN_500KBPS) == CAN_OK) 
        Serial.println("fail :-(");
        while (1) 
            Serial.println("Zzz… ");

Serial.println("Good to go!");

unsigned char statusPCM[8]  = {125,0,0,0,156,0,0,0};                            // Write to 201
unsigned char statusMIL[8]  = {140,0,0,0,1,0,0,0};                              // Write to 420

void loop() 
    unsigned int i=0;
    unsigned int j=0;
    unsigned int k=0;
    float mile=0;
    unsigned char num;
    //Warning Lights - 0=Error, 1=OK

          statusPCM[0] = 50;           //RPM  Value*67 gives 8500 RPM Reading Redline is 127
          statusPCM[1] = 0;           
          statusPCM[2] = 0;
          statusPCM[3] = 0;
          statusPCM[4] = 93;           //Speed  Value=0.63*(Speed)+38.5
          statusPCM[5] = 0;
          statusPCM[6] = 0;
          statusPCM[7] = 0;

          statusMIL[0] = 145;         // Temp 91-0%; 96-10%; 107-25%; 152=50%; 158-75%; 164=100%    
          statusMIL[1] = i;           // Odo / Trip     
          statusMIL[2] = 0;
          statusMIL[3] = 0;
          statusMIL[4] = 1;           // Oil Pressure (0=Off, >=1 is OK)         
          statusMIL[5] = 0;           // Check Engine Light
          statusMIL[6] = 0;           // Battery Charge Light
          statusMIL[7] = 0;
            CAN0.sendMsgBuf(0x420, 0, 8, statusMIL);
            CAN0.sendMsgBuf(0x201, 0, 8, statusPCM);
        Serial.println("Miles : ");

Basically much of it is the includes and setup which is common on all CAN code but the more interesting bit is the main loop. In essence it just uses two nested loops to count up to a certain value and transmit the new value each time. All the other CAN is just static values to turn off warning lights on the cluster – the the ID 201 isn’t actually required here but it stops extra things blinking at you! Additionally ignore the comments on the statusPCM, while these sort of work I realised later that the speed and RPM use 2 byte blocks rather than a single byte to display all values.

So in the code there are 2 loops, the first is counter “i” which in this counts up to 206 (which is 207 steps including 0) and the second outer loop “k” which counts up to 200 and for each increment of “i” the new byte value is sent over CAN. Now through experimenting with various values for counters in earlier versions of this code I’d come up with the values you see here which seem to be consistently accurate for me. Basically 207 changes of the byte sent to the dash = 0.05 Miles counted so the extra loop “k” multiplies this up to a useful mileage change we can measure on the cluster. every time “k” increments it also sends and update to the serial monitor so we can keep track of it. We can see that 200 loops of 0.05 miles should result in a count of 10 miles and that’s exactly what we get on the trip meter.

The very last line is one you don’t see in many Arduino programs, “while(1){};” makes the program hang at this step. Basically what it’s doing is a normal while loop except using a static 1 as the condition makes it always true but there’s no code in the curly brackets so it will just sit there endlessly doing nothing rather than starting the main loop again as it would normally. This was simply so I could leave the code running to completion (at this stage I was sending CAN data with much wider time delays than needed to make sure none got missed) without it looping back round without me noticing.

So now we can count it up which is interesting but not especially useful as it is but since my car didn’t move I left it here for a long time with the plan to sort it out later. Anyway following my recent posts resurrecting this project there’s been some interest in how to sort it out so I started working on it within my already butchered about derivative of Dave Blackhursts code, which in itself was a further development of much of my earlier work. I’m aiming to post a version of my finalised code for the complete system once I’m happy I’ve got all the features I want but this should give you enough info to understand how this bit works.

Updates by Timer1 Interrupt

First off lets just say this didn’t work quite right for this task so I moved away from timer interrupts but it does include some interesting bits of timer manipulation so I’m including it anyway.

The best idea I had initially was to use the data from the ABS system which gave an accurate speed for all the wheels individually but the problem was I would need to vary the frequency at which the ODO byte was changed such that the ODO rate matched the speed. My first idea here was to use a hardware timer on the Arduino and use a hardware interrupt to increment and send the CAN packet. This would require the timer count value to be calculated on the fly from the ABS data. First I built and Excel spreadsheet which firstly calculated the frequency we need to update and send CAN data at to give the right ODO reading for a given wheel speed.

excel mph to freq conversion

So all this does is some basic calculation,

Pulses per mile * mph = pulses per hour

pulses per hour / 3600 = Hz (updates per second)

1000 / Hz = Millisecond interval per update (used to cross reference from the CAN logger)

From this we can fiddle about with values to see what gives enough range on timer1 (because it’s 16 bit which gives us a much wider range of intervals, timer 0 is only 8 bit and usually used elsewhere in the Arduino IDE) to make this work, or for that matter if it even is possible without dynamically changing the pre-scaler value.

Timer 1 is controlled primarily by register OCR1A which is the value it counts to before the timer resets so we need to work out the correct value for the register to do what we want. Rearranging the standard equation gives us this:

OCR1A = (( Clock_Freq / Required_Freq ) / Prescale ) – 1

Now because the count is a 16 bit integer there will be some error created by rounding on the count value so I added another section which updates to show the error vs the required value.

Excel OCR1A count value calculation

The top two lines are just the standard calculation the middle two lines are where the clock and prescaler values are entered and the OCR1A value is calculated. The 230 and 1.15 come from the previous step automatically. The bottom two lines then return the degree of error resulting.

It looks like we can cover the range we want with a prescaler of 1024 however as the speed goes down below 1mph the period between CAN sends becomes excessively long and beyond the range of the timer (max value of OCR1A is 65535), the limit is approximately 0.21 mph which seems reasonable. This means only 1 update over CAN every 4.1s which it turns out is about the limit anyway because if you make the updates longer than about 4.5s for this ID all the warning lights turn on again between updates but we can handle this case seperately.

Now to get the timer working we need to set up a few other things

TCCR1B options

We want to use CTC mode resets the count value at the top of the count to make it loop round constantly so WGM12(CTC1) in register TCCR1B should be set to 1.

TCCR1B options

Next to get the prescaler value of 1024 we need we set CS12 and CS10 to 1. Lastly OCIE1A in TIMSK1 needs to be set to 1 to trigger the interrupt every time the count reaches the count value set bring it all together and we get something like this :

void setupTimer1() {
  // Clear registers
  TCCR1A = 0;
  TCCR1B = 0;
  TCNT1 = 0;

  // Freq (Hz) (Clock (Hz) /((OCR1A + 1) * Prescaler))
  OCR1A = 64700;
  // Set CTC mode - trigger interrupt on TOP
  TCCR1B |= (1 << WGM12);
  // Prescaler 1024
  TCCR1B |= (1 << CS12) | (1 << CS10);
  // Output Compare Match A Interrupt Enable
  TIMSK1 |= (1 << OCIE1A);
  // Enable Interrupts

// Send update to cluster on interrupt
    // Increment ODO byte each time function is called
  // this makes ODO update based on ISR frequency call.
  // Check speed is > 0.21 mph ( (left+right/2) * 0.337962 * 100
  if ( (frontLeft + frontRight) >= 68){
  CAN0.sendMsgBuf(0x420, 0, 7, send420);

Next up to convert from a speed to a timer count value we need to do the same thing on the Arduino that we did in Excel earlier so here’s a quick function which just calculates count.

int calcTimer1Count(float speedKMH){
  float freq;
  int count;
  float speedMPH;
  //Serial.print("speed = ");
  speedMPH = speedKMH / 160.934;
  // Required frequency for timer 1 ISR
  //  1.15 is 4140 (Pulse per Mile) / 3600 (1hr in seconds)
  //  0.7146 is 2572.5 (pulse per KM) / 3600
  freq = speedMPH * 1.15; 
  //Serial.print("freq = ");
  // Required OCR1A value based on 16Mhz clock, works best with 1024x prescaler giving minimum 0.21mph
  count = ((16000000 / freq) / 1024) - 1;
  //Serial.print("count = ");
  return count;

The input here is km/h because that’s what the ABS values are given in so we might as well convert that here as well.

Now in the main loop we’re scanning for incoming data on CAN and checking what the ID is already for the bits to manage the immobiliser exchange and handily in this Dave Blackhurst has already added code to read the ABS data which we know is coming in on ID 4B0 in two byte blocks so we can just update OCR1A with a function call to our new calculation function with the average of the front wheel speeds whenever new ABS data is received.

    if(ID == 0x4B0) {
      frontLeft = (buf[0] * 256) + buf[1] - 10000;
      frontRight = (buf[2] * 256) + buf[3] - 10000;
      rearLeft = (buf[4] * 256) + buf[5] - 10000;
      rearRight = (buf[6] * 256) + buf[7] - 10000;
      //Going to check front wheel speeds for any issues, ignoring the rears due to problems created by wheelspin
      if (frontLeft - frontRight > 500 || frontLeft - frontRight < -500) { //more than 5kph difference in wheel speed
        checkEngineMIL = 1; //light up engine warning light and set speed to zero
        vehicleSpeed = 0;
      } else {
        vehicleSpeed = (((frontLeft + frontRight) / 2) / 100); //Get average of front two wheels.
      //Update timer count value with live speed for ODO
      OCR1A = calcTimer1Count((frontLeft + frontRight) / 2);
      // Dump speed to serial for debug - this is just a cropped int.

Now when I ran the whole program I hit a minor issue, it worked initially and the timer speed changed correctly but after a small number of can packets the Arduino stopped sending any other CAN data. I don’t know what caused it – best guess is when the interrupt was called it was blocking something and causing a buffer overrun somewhere else making the Arduino crash but either way I felt a different approach would probably be quicker than solving that so I moved on.

Updates by Delay

So the alternate approach relies on the main loop running quite quickly and simply counts how much time has elapsed since a function was last called and if over the set value calls the function. This basically allows functions to be called in the loop without needing to slow the loop itself down. The down side here vs interrupts is the accuracy of this is entirely based on the speed of the main loop so if the loop slows down the events will move about in time. Also obviously if the loop is only doing something like 10ms per iteration you will never get something to go faster than that!

void loop() {
  //Send information on the CanBus every 100ms to avoid spamming the system.
  if(millis() - lastRefreshTime >= 100) {
    lastRefreshTime += 100;

So this is the initial version Dave used in his code to keep the scanning at a decent pace for the CAN reads. The function millis() just returns a counter value in milliseconds since startup. Unfortunately scanning at millisecond rates isn’t going to cut it for the ODO because at say 200mph the update period is 4.35ms so if we work in ms the best we could do assuming the loop ran fast enough is 5ms which means the ODO would be going 15% slower than the vehicle speed. Luckily Arduino also has a similar built in function ‘micros()’ which does the same thing but counts in microseconds. Some of you familiar with binary might be thinking an integer counting up in microseconds will hit its limit very quickly and then it is likely to cause a problem with the calculation however we get round this because the returned value is of type ‘unsigned long’ which gives us a range of up to about 70 minutes before the count resets. Interestingly because of the way data types wrap round like this the variable “lastRefreshTime” can actually be either signed or unsigned and it works the same.

long calcMicrosecODO(float speedKMH){
  long uS;
  float freq;
  float speedMPH;
  Serial.print("Speed = ");
  Serial.println(" km/h");
  speedMPH = speedKMH / 160.934;
  // Required frequency for timer 1 ISR
  //  1.15 is 4140 (Pulse per Mile) / 3600 (1hr in seconds)
  //  0.7146 is 2572.5 (pulse per KM) / 3600
  freq = speedMPH * 1.15; 
  Serial.print("Freq = ");
  Serial.println(" Hz");
  uS = 1000000/freq;
  if(uS < 4500000 && uS > 0){
    return (uS);}
  else {
    return (4500000);

Similarly to the previous interrupt version we have a function which calculates the correct delay required to keep the ODO at the right frequency, there are some minor differences to work in microseconds and if the speed is too slow cap the output at 4500000us (4.5s). Otherwise it’s much the same.

    if(ID == 0x4B0) {
      frontLeft = (buf[0] * 256) + buf[1] - 10000;
      frontRight = (buf[2] * 256) + buf[3] - 10000;
      rearLeft = (buf[4] * 256) + buf[5] - 10000;
      rearRight = (buf[6] * 256) + buf[7] - 10000;
      //Going to check front wheel speeds for any issues, ignoring the rears due to problems created by wheelspin
      if (frontLeft - frontRight > 500 || frontLeft - frontRight < -500) { //more than 5kph difference in wheel speed
        checkEngineMIL = 1; //light up engine warning light and set speed to zero
        vehicleSpeed = 0;
      } else {
        vehicleSpeed = (((frontLeft + frontRight) / 2) / 100); //Get average of front two wheels.
      //Update timer count value with live speed for ODO
      ODOus = calcMicrosecODO((frontLeft + frontRight) / 2);
      Serial.print("ODO Step : ");
      // Dump speed to serial for debug - this is just a cropped int.

Above we see the call for ‘calcMicrosecODO’ which is basically the same as the interrupt version but gives an actual time delay in microseconds rather than a timer count. It is called in this way with a calculation in the parameter field because if it is stored in a variable in between the number gets cropped off at the decimal point even if the variable is a float – I believe this is due to the way Arduino processes floats.

void loop() {
  //Send information on the CanBus every 100ms to avoid spamming the system.
  if(micros() - lastRefreshTime >= 100000) {
    lastRefreshTime += 100000;
  // Call function to updateMIL on variable timebase
   if(micros() - ODORefreshTime >= ODOus) {
   ODORefreshTime += ODOus;

So our extra call for the variable timed refresh is above, it varies a bit from the first one because we have a varying time delay depending on the frequency required which here is a long we are calling ‘ODOus’ which we calculated previously. Obviously because we are using two comparisons we need another refresh time variable to keep them distinct, this is also a long. Also the second one calls a specific function for the variable time refreshes ‘sendOnClock()’

void sendOnClock(){
  // Do not increment ODO byte when step is = 4.5s
  // slower than this updateMIL must still be called so 
  // warning lights don't turn on but speed may be zero!
  if ( ODOus < 4500000){
  CAN0.sendMsgBuf(0x420, 0, 7, send420);

This function is pretty basic, all it’s doing is checking the resulting ODOus value isn’t 4.5s because if it is this value is means the calculation is at it’s upper limit and the car isn’t moving (specifically the speed is below 0.21 mph). In this state it still updates the warning light registers and sends the CAN packet to keep the warning lights from blinking on but it doesn’t increment the ODO byte value so the ODO doesn’t continue to tick on.

// Time delay for Odo
long ODOus = 4500000;      

// Set to max 4,500,000 to keep dash 
// MIL warning lights awake at 0 speed

The declaration for ODOus is set as 4,500,000 at start up so it correctly. The only downside to this is it takes a few seconds for the dash lights to go out initially and the oil pressure gauge goes to normal in two steps. This could be dramatically improved either by setting a higher minimum speed at which the ODO ticks because even increasing to 0.5 mph would improve the maximum duration to 1.7 seconds. Another option to avoid this is just to send an update to 0x420 in between the ODO calls. If we keep the one to the other loop ‘sendOnTenth’ without incrementing the ODO value it will just display any changes to the warning lights almost instantly while keeping the ODO working correctly.

void sendOnTenth() {
  //  PCM Status's to mimic the PCM being there, these may be different for different cars, 
  //  and not all are always required, better safe and include them all.
  CAN0.sendMsgBuf(0x203, 0, 7, send203);
  CAN0.sendMsgBuf(0x215, 0, 8, send215);
  CAN0.sendMsgBuf(0x231, 0, 8, send231);
  CAN0.sendMsgBuf(0x240, 0, 8, send240);
  CAN0.sendMsgBuf(0x620, 0, 7, send620);
  CAN0.sendMsgBuf(0x630, 0, 8, send630);
  CAN0.sendMsgBuf(0x650, 0, 1, send650);
  CAN0.sendMsgBuf(0x420, 0, 7, send420);    // Duplicated in sendOnClock to update ODO

  CAN0.sendMsgBuf(0x201, 0, 8, send201);

So that’s it but I should probably mention that I’ve not tested this on a live car however I have a program which works out the correct CAN byte values and then builds a correctly formatted string which can be pasted into USBtinViewer and sent to simulate an update from the ABS and the Arduino and cluster all seem to respond correctly:

Labview speed to CAN bytes converter  front panel
Labview speed to CAN bytes converter  front panel code

In this code you will see a scaling factor of 100 which should be correct but on my cluster I seem to get a speedometer reading 1 mph higher than intended from a calculated 5-185mph I actually see 6-186 mph on the cluster. I’m not sure why this is but it may be on purpose due to the common requirement for speedometers to never read lower than true speed. Indicated speed is required to be within -0% / +10% + 4km/h of actual speed in the EU. Technically we could correct this by doing two vehicle speed calculations on the Arduino, one for the odometer calculation using the proper scaling factors to keep it accurate and one for the displayed vehicle speed using a scaling factor which corrects this error. I do not intend to do this but I have found a scaling factor of 99 rather than 100 makes the speedometer match up if required.

As ever your mileage may vary, but hopefully it’ll closer than it was before! As I said earlier this is part of another major overhaul of the code and I’m intending to publish the final version as a complete code when I’m happy I’ve got everything working but that might take some time.

RX8 Project – Part 19, Canbus #4, The Comeback!

Lets be clear before we start – This will not allow you to start a car with a factory ECU with the wrong key or by bypassing the immobiliser. This is to do with making things like engine swaps work fully in the car without the factory ECU connected.

I’m going to apologise right now, there’s quite a lot of background about how I investigated the process of the ECU talking to the immobiliser in this one, if you don’t care and just want the CAN info scroll down a bit. I’ll write a complete update of all the codes when this phase of work is all done.

As some of you are probably aware my RX8 engine swap has been going on some time for a variety of reasons but specifically due to not having cover and so not easily being able to hook the car CANbus up to my computer to do live diagnostics I had hit something of a problem. I couldn’t generate data fast enough to fake all the devices on the bus reliably to test things on my desk away from the car but had no-where undercover to work with it connected to a PC so largely I’d planned to concentrate on organising a garage – something that should have happened more than a year ago now but due to the pandemic and related 2020 problems that not gone as well as hoped!

Anyway a few months ago on trying to find a CAN diagram for the car to aid answering a comment someone posted on here (yes I do try to answer them but I know sometimes it takes a while – I’m hoping to keep a better eye on it this year!) I came across a video from a guy called Dave Blackhurst (this one) which was rather interesting as he apparently had my two main issues from my previous code sorted, specifically the immobiliser system (the thing I want to look at here) and the power steering.

So to see how he was doing it I went to the linked Github and downloaded his Arduino code and on opening it I was largely very familiar code, specifically a whole set of variable declarations for the various dash instruments and a large section of code related to using a boolean variable to set the correct bit in the corresponding CAN packet so individual warning lights can be turned on or off and the speed/RPM etc to all be set easily on the cluster. So this was basically a development of my previous work

Now just to be clear this isn’t a complaint. This is just the first time I’d see my work go full circle and someone else actually develop it further which was quite exciting. If I hadn’t wanted it used and developed I wouldn’t have posted it online! Even better was it gave me a kick to have another go at it and at the very least try this new and improved code which said it fixed all the issues because if true Dave might have just solved my remaining problems!

So back to the immobiliser. I’d never managed to get the immobiliser light to go out despite trying all sorts of combinations of data from the logs I had but after seeing what Dave had done I realised I’d been missing a critical bit of information. The CAN logs I’d previously worked from were predominantly provided but someone else who contacted me via the blog and so were from two other cars and not my own. Additionally you can see in the early blog posts I actually built my own CANbus board several years ago which worked but had some speed issues with all the work it was doing. This was because when I started this project several years ago there was little else available for sensible money so it was the only real option. Long story short the immobiliser relies on a very short data exchange which occurs when the ignition key is first turned on and is never repeated and basically it had just been missed by the loggers that I had data from previously so I may never have figured it out!

Excited at the prospect of this just being a load the code and go I wondered if in the intervening years better hardware was available for this job than my old Arduino Nano based DIY job and there are now various Arduino expansion shields for CAN but to me these were all rather clunky solutions so I started looking at the “Feather” range which has a couple options but again these were a board and a piggback interface which isn’t what I wanted and there’s a new one which is the Adafruid Feather M4 CAN which looked pretty good but doesn’t seem to have ever actually been in stock anywhere so moving on.

Adafruit Feather M4 CAN

Following this I had a realisation – if if was going on the car it really didn’t need an integrated battery. Previously I’d started using Leonardo based modules for projects and these proved very quick for most tasks and have integrated USB meaning data throughput can be faster so I tried to find a Leonardo based CAN module. Eventually I found a company who I’ve used before for various neat modules do basically exactly what I was after for a reasonable price, enter Hobbytronics and their L-CANBUS board.

Leonardo CAN BUS board
Hobbytronics Leonardo Canbus

Looks just the job and even comes with the headers and 9 way connector unsoldered. and the board itself has pads for screw terminals to be soldered in place of the 9 way connector for bare wire connections. This time round I decided I wasn’t going to mess about with screw terminals while testing so I splashed out and bought a £10 OBD2 – 9 Way D-Sub CAN cable off eBay to go with it (unfortunately Hobbytronics were out of stock of the cable). This also had the advantage of including 12V and ground connections which are routed to the board regulator so the module is powered directly off the OBD2 port on the car making testing really easy.

I also decided being powered off the car that rather than risk shorting the module/car it needed a case and since I recently was given what I believe is still the cheapest 3d printer on eBay by a friend who got so annoyed with it he bought one that was actually good, so I designed a 3d printable one :

It’s pretty basic, the holes should be undersize for an M2.5 laptop screw so they basically thread cut it when you first put them in. Not ideal but it’s what I had. M2.5 sized plastic screws with a coarser thread would be better but either way it held fine. This case also leaves the USB accessible.

Anyway, back to the point we now have some nice neat hardware so I tweaked the code to run on this module (different CAN pins to the normal Adafruit CAN shields) and flashed it. After plugging it into the car…nothing happened. Once I’d reflashed the Leonardo with CLK_OUT enabled as per the instructions following a conversation with Hobbytronics who were very helpful (in their defence it says to do it right on the product page but I’d not read that bit!) I loaded it again and when hooked up to the car what I got was the basic warning lights went off, but the immobiliser and power steering that I’d hoped to resolve were still there. Time to delve a bit deeper!

So looking at Dave’s code here’s the bit to resolve the immobiliser:

 if(CAN_MSGAVAIL == CAN0.checkReceive()) { 
  // Check to see whether data is read
    CAN0.readMsgBufID(&ID, &len, buf);    // Read data

    //Keyless Control Module and Immobiliser want to have a chat with the PCM, this deals with the conversation
    if(ID == 0x47) { //71 Dec is 47 Hex - Keyless Chat
      //***** Fixed Coding for Dave Blackhurst's Car *******
      if(buf[1] == 127 && buf[2] == 2) {      
        // Look for 0x 06 7F 02 00 00 00 00 00
        CAN0.sendMsgBuf(0x041, 0, 8, send41a);// 0x041 = 65
        // send41a = 0x 07 0C 30 F2 17 00 00 00
      if(buf[1] == 92 && buf[2] == 244) {     
        // Look for 0x 08 5C F4 65 22 01 00 00
        CAN0.sendMsgBuf(0x041, 0, 8, send41b);
        // send41b = 0x 81 7F 00 00 00 00 00 00

I’ve added in the codes being looked for or sent in each case which Dave identified from scanning the bus on his RX8 just to make it easier to see what’s going on. Breaking this down ID 0x47 is the immobiliser module sending data out which generally seems to just keep repeating 0x06 01 FF 00 00 00 00 00 when in normal use with the car running as factory I have that from my previous logs. So this first code starting 0x 06 7F 02 is something from the immobiliser which triggers the exchange. The code basically just reads any incoming data then checks the ID is 0x47 (i.e. it’s coming from the immobiliser) and that two bytes match the what he knows the CAN data should be (simpler than checking the whole code) , specifically byte 1 being 127 (7F) and byte 2 being 2. He then sends the recorded response to this (send41a – 0x 07 0C 30…) back to the immobiliser which would normally be done by the PCM (ECU) in the car when present. Then we look for the response from the immobiliser matches what we expect (0x 08 5C F4….) and sends a second reply to the immobiliser (send41b – 0x 81 7F 00….). I started thinking the module wasn’t talking to the CANbus right but after some fault finding and adding a diagnostic LED blink at critical points I found it was on the bus but just wasn’t seeing the right data coming from the immobiliser to respond to. Now I knew this exchange worked on Dave’s car but not on mine so clearly the codes we have aren’t universal in some way but I needed to work out what was going on but at least I knew what to look for.

Back when I was trying to find the code to disable the power steering light from Labview I bought a device called the USBtin which is a neat little PCB which is basically just a USB to CAN adapter but it has a built in protocol to control it so you can read the data via software like Putty or relative easily develop custom applications to connect to it. Now facing this problem I decided to give it a go and see if it was actually fast enough to catch this exchange in the first few fractions of a second of the ignition being on. I blew the dust of the original ECU for the car and hooked it back up to the bus (there’s no engine but I hoped that wouldn’t matter for this bit) loaded the basic USBtinViewer onto a tabled and hooked it up.

Ok it’s a photo of a tablet screen but anyway, the point is the USBtin is clearly fast enough to catch all the data because the monitor mode shows it’s caught the exchange because it’s logged packets to ID 0x41 and 0x47 and the last message to 0x41 matches the last one from Dave’s car (send41b – 0x 81 7F…). So it’s got the data, unfortunately to see what was sent both ways I had to trawl through the trace mode which just lists every CAN packet on the bus but after a bit of searching I found this:

So going through it first and ignoring all the extra data (there will be more to follow on this) there’s the default message from the immobiliser sending 06 01 FF… highlighted in yellow, then shortly afterward we see what looks very similar to Dave’s first message of the exchange but where his was 0x 06 7F 02, mine critically is 0x 06 7F 01. Looking back to Dave’s code for this we find that he was specifically looking for byte 2 = 2 and mine is 1, which is probably why it never triggered on my car. Now because that first packet we need to match starts 0x 06 7F … on both cars I can just change the check to look for that combination instead but at this point I also realised the outgoing data from the ECU (0x 07…) and return from the immobiliser (0x 08…) are totally different for my car so rather than mess about I just swapped out both to match what I’d logged for my car (assuming the codes may be car specific to stop PCM’s (ECU’s) being swapped between vehicles they’re not coded to or something) and tried it again, but this time…

Yes this time it cleared the security light! Definitely progress!

But for me making it work isn’t really enough and I like to understand why something works and hopefully make it better!

First off I tried again but this time with the matching done using the updated positions for the consistent bits of the code common to both cars. Specifically getting rid of the check for the byte 2 being any value because this appeared to change from car to car. What we can reasonably assume is fixed from this data is byte 0 because they always seem to indicate the step in the exchange with the exception of the initialisation state and first request state which both start “06” however byte 1 gives us if the immobiliser is still starting (0x 06 01…) and making a request to the PCM (0x 06 7F) and these match on both cars. We then send back one of the first response packets (0x 07….) and wait for the next request which byte comparing the data both cars start with byte 0 = 08 and based on the rest it’s reasonable to assume again this is the sequence step and so universal. Then Dave looks for a value of byte 2 which differs between our cars, however I have noticed that byte 5 for both cars is always 01 so this would work for both. So we end up with this :

      byte send41a[8] = {7,120,192,226,94,0,0,0};                      
      // Reply to 47 first  : 0x 07 78 C0 E2 5E 00 00 00 
      // Bytes 0 is the same, bytes 3 & 4 dont seem to matter, 
      // 5,6,7 are zero
      byte send41b[8] = {129,127,0,0,0,0,0,0};                         
      // Reply to 47 second : 0x 81 7F
      //***** Fixed Coding for Jon's Car *******
      // Some experimentation showed that on the initial request
      // for my car byte 2 was a 01 not a 02
      // however all codes so far begin 06 7F 
      // for either car so this was used.
      // Similarly in the second message from the 
      // immobiliser bytes 1-4 change but byte 5 
      // is always 01 on either vehicle

      if(buf[0] == 0x6 && buf[1] == 0x7F ) {                      
        // 0x 06 7F 01 00 00 00 00 32
        // printhex(buf,8);                                        
        // Transmit out received request on debug serial port 
        // - breaks timings on vehicle.
        CAN0.sendMsgBuf(0x041, 0, 8, send41a);                    
        // 0x 07 78 C0 E2 5E 00 00 00 
      if(buf[0] == 0x8 && buf[5] == 0x1 ) {                        
        // 0x 08 94 29 BC 91 01 00 32
        CAN0.sendMsgBuf(0x041, 0, 8, send41b);                     
        // 0x 81 7F 00 00 00 00 00 00  

I’ve included the notes I made at the time – the printhex is a function I wrote to dump these arrays out to the serial port easily as two digit hex pairs for monitoring what’s going on at different times. As noted here it breaks the timings of the exchange between the ECU and immobiliser but if we want to check something we just add it in and at least we can see what the data was. I’ll do a separate post for that as it might be useful to others. Not unexpectedly matching in this way worked fine but more interestingly I tried my car with Dave’s codes matching in this new way and interestingly it actually worked with no security light…

Well that raises even more questions because in theory I’d just swapped my ECU for his (in terms of the code exchange at least) and it authenticated!

So I went back to my car, reconnected the original ECU, powered it up with the USB logger again and noticed that each time I turned my ignition on the code exchange was different so clearly the idea of the code being fixed for a pair of ECU and immobiliser was wrong. After a number of goes and recording all the results a few things started to become apparent.

Firstly the initial request from the immobiliser had some variations on bytes 7 and 8 which always matched the byte 7 and 8 in the second request but the bytes we look for (byte 0 and 1 shown in green) are always 06 7F in every try.

Second, the first response given by the ECU indeed always starts 07 (light blue), but the next 4 bytes change each time the ignition is turned on (bright blue).

Third, bytes 0 and 5 in the second request are always 08 and 01 respectively (orange) however the 4 bytes between change each time the ignition is turned on (yellow).

Fourth, the second response is always the same (pink).

So what I think is going on here is actually something slightly different. If we assume for a moment the ECU knows the code or processing going on in the immobiliser we get a proper challenge/response interaction. I think the first message sent by the immobiliser is basically a “ready” message telling the ECU to send a block of data. The ECU then responds with a 4 byte block of data which is randomised each start. The immobiliser then performs some function we don’t know and sends the result back to the ECU where it checks the result against what it should be and gives a pass or fail back to the immobiliser so it updates the dash light. The last packet is always the same because we’re using everything from one car so its a pass so we don’t know what a mismatch fail looks like yet but I’m going to look into this at some point.

Now the interesting result of this outcome is with our Arduino we’re not checking if the code response actually matches and if my theory is right the outbound 4 bytes can be absolutely anything as it’s basically just a seed value, then the immobiliser will will reply with a coded version which we just ignore and so long as we reply with a pass message at that point (0x 81 7F 00 00 00 00 00 00)the immobiliser turns the dash light off.

To prove this out I set up the Arduino to send different random numbers in each of bytes 1-4 to the immobiliser in the initial response and indeed while the response from the immobiliser bytes 1-4 change as in response the immobiliser light went out on the dash every time.

My final theory is that the immobiliser module is reading the data from the chip in the key, and using that to transform the initial data from the ECU to create the response and since the ECU knows the key code and whatever this transformation is it knows if it’s the right key or not.

Now hopefully that problems solved for all RX8’s, I’m aware I haven’t posted a full, complete code like I have done previously but that’s because it has all sorts of other features going in this currently and I’ve not finished and tidied the rest of it yet. I’ve also considered the situation where there might be an RX8 out there that doesn’t match the code pattern found in my current sample of two vehicles so I’ve actually added a feature where if you jumper a wire onto a digital input and connect the Arduino to a car with the original ECU in place it will read out the entire code exchange and store all the codes for that car in EEPROM on the Arduino. If you then take the jumper off and pull out the ECU, when you turn the ignition on again the Arduino will use the codes it just stored instead of the defaults. Again I’ll write this up properly when it’s all finished.

Finally thanks to Dave Blackhurst for your work on this. While your solution didn’t work for my immobiliser it gave me the drive to have another go and enough information to go in the right direction and hopefully we’re a step closer to a universal engine/motor swap solution for everyone.

More to follow!

Living with a Scirocco 1.4 TSI 160 (118kW) – Part 3, Supercharger Bypass Valve (P10A4 Fault)

Sometime last year I was having problems finding a spot in a carpark so ended up sat in the car with it idling for several minutes and when I went to pull away the engine warning light flashed on almost immediately – not something anyone wants to see!

For the rest of the drive the car would mostly work ok at low engine RPM but the engine all but refused to go above approximately 3000rpm which is around the RPM the turbo takes over from the supercharger on this engine and the supercharger is disengaged by its electronic clutch. The curious bit was that at hitting the cut off there was a sudden loss of power at that RPM rather than it staying consistent and just holding an RPM limit suggesting it wasn’t a limp mode as such. My initial suspicion was that the turbo wasn’t spooling up so whether the wastegate was stuck open or something I didn’t know.

Luckily I bought VCDS which is an excellent tool for diagnosing and performing adjustments and if you do a lot of work on VW’s well worth the investment so I hooked that up to see what fault the check engine light was actually reporting and saw the following :

A quick Google of the code P10A4 identifies specific air regulating flap in question but this could also be found by a brief search of the engine bay – there aren’t many flaps in the intake! VW refers to this part as J808.

Image of the TSI160 engine with intake flap highlighted

What this flap actually does is when the supercharger disengages the flap opens providing an unrestricted flow to the intake of the turbo. Obviously if this doesn’t open when the supercharger disengages suddenly the air supply to the engine is closed and you get a massive power loss. You can see what’s going on in the image below which is taken from VW’s manual for this engine – SSP-359. This isn’t a workshop manual but does explain the design and behaviour of this engine in a good level of detail.

There are quite a few guides on how to replace this part such as using the one at workshop-manuals.com . This is an excellent resource but I do recommend using an ad blocker before going there as there are so many ads it’s very annoying otherwise!

My approach to get at the flap was to start at the airbox end and disconnect all the lines going into the intake tract (there are many in all directions so carefully work along it). Eventually once everything is detached you can undo the three long screws which hold the intake pipes on either side tight against the flap and so hold it in place. In my case I ended up detaching the section of pipe after the flap as well so I could lift the whole intake pipe up to get access to the bottom screw nearest the engine as its very awkward to get at otherwise.

Anyway as usual I didn’t want to replace the part if I could avoid it and luckily I found some comments somewhere saying the problem was caused by oil weeping from the intake into the flap unit clogging up the motor so I wondered if it could be cleaned because fundamentally there’s very little that can go wrong inside as they are basically just a motor. Luckily at this point knowing this was likely the problem I figured I couldn’t make it any worse than dead so started trying to work out what was going on.

So looking at the casing of the valve I came to the conclusion there was a simple gearing mechanism inside but based on the space between the clear position of the motor under the curved housing the likelihood was that the gear on the motor itself was small and so I could not explain why there was a significant large area in the housing below it which would likely be a handy cavity with no obvious purpose. The problem being caused by oil makes sense – the motor sits in the bottom of the housing which is underneath the intake pipework so any oil leaking into the housing would pool around the motor. I think the leak is through the spindle bearing for the flap.

So I came up with a plan which may be apparent already because I neglected to take any “before” pictures. I didn’t want to cut the unit open because even though the two halves appeared to be screwed together it looked like the seam had been sealed in some way (presumably part of why oil gets trapped inside) and while nothing appeared to be spring return I really didn’t want to risk it. So I decided to drill a small hole into the extra casing I identified earlier by using the casing as a guide as to where the gear and so end of the motor was. I then carefully drilled a small hole approximate 4mm in the casing and indeed there’s clear space behind this area.

My plan was basically to just flush the inside out with brake cleaner to remove all the oil residue so the hole was just a little large than the straw on the spray can. Sure enough on blasting some into it immediately the predictable brown runoff started pouring out. Another interesting thing happened as well – some residue started to run out of the seam inside the intake passage suggesting this isn’t sealed from the internal workings and in fact the seal on the unit is only on the very outer edge if the housing which may well explain the leaking issue! anyway several passes with brake clean and sloshing it about inside to rinse out as much as possible (I recommend just keep replacing the brake clean until it runs out clear) and it should be ok again hopefully. At this stage you might want to spray a small amount of lithium grease through the hole onto the gears for longevity but if you do just keep it small so you don’t just end up fouling everything with that instead!

Next, make sure the thing is totally clear of brake clean! I held mine under a hot air hand drier for about 10 minute to make it hot enough to drive off all the vapour then left it out in the sun for about half and hour. The last thing you want is a it catching fire!

The final thing I wanted to do is cover up the hole, particularly now knowing the intake wasn’t sealed from the innards. To solve this I tapped the new hole out to M5 and carefully checking the clearance I had behind the cover I put a short button head in place that wouldn’t foul the motor drive gear. Hopefully this also means If I ever have this problem again cleaning it should be easier. You can see the new M5 button head below.

After putting it back into the car I used VCDS to clear the fault code and so reset the engine warning light and took it on a test drive to confirm everything was fine. I think in total this took me about three hours but I was figuring it out as I went so you could probably do it in less.

While this was done during 2020 and so I have been using the car less due to travel limitations and working from home I can confirm that now five months later the car still works well and I have had no further issues following this repair.

Living with a Scirocco 1.4 TSI 160 (118kW) – Part 2, Turbo Replacement

It’s been a little over a year since I posted the introduction blog article on this car and more specifically on the unusual twin charged engine it has. Unsurprisingly over the last year or so I’ve found a few things that need a little work but generally the car has been excellent, needing minimal thought but certainly has some aspects to be aware of for prospective owners to keep the the engine working correctly.

When I bought the car it was a bit lacking power compared to what I was expecting and when accelerated hard in one gear (which due to a seemingly large gap between the supercharger and turbo rev ranges required revving it high) and changed up it would randomly have no power at all. I managed to trace this to a couple problems both related to the turbo wastegate. Firstly the requirement to rev it high was caused by serious wear on the wastegate pivot meaning the wastegate didn’t fully close so the turbo wouldn’t spin up properly. A temporary bodge to get round this is to tighten up the actuator rod to take up the slack but while this sort of helps it actually wears the housing even faster but it can get you by while you wait for a replacement. The second problem of lacking power after a high RPM change was that the wastegate actuator rod was actually bent and touching the turbo housing so it was actually getting temporarily stuck when fully extended so going into the next gear the turbo was basically just dumping the exhaust out the wastegate rather than doing anything useful. So this definitely needed looking at!

First off let me just say I initially looked at the position of the turbo nicely sat at the top front of the engine and thought a couple hours and it’d be done. I was wrong, very wrong! It looks lovely and easily accessible but it just isn’t as easy as it looks for many reasons mostly relating to it not being a turbo mounted to a manifold. the entire exhaust side manifold and turbo are a single unit so you need sufficient clearance to pull the whole unit out.

There it is under the heat shield – looks simple right?

I used various guides to do this swap and generally was in a rush (that didn’t work out so well) so I have very few photos of this but the information is fairly widely available anyway (try searching for guides to the mk6 Golf with the same engine) this is to highlight a few points people may find useful. I suggest referring to workshop manuals for a handy guide with diagrams of each section you need but strongly recommend an ad blocker before you do.

  1. The hard plastic boost pipe which runs from the supercharger to the turbo inlet is retained at the turbo end by a single M6 torx bolt with the threads tapped into the aluminium casting. On the rebuilt unit I bought this thread turned out to be ruined to the point it was impossible to tighten. I suspect this is because undoing the captive fastener during disassembly tries to push a metal sleeve out of the plastic. This is fine in itself but I think it wears the aluminium, similarly tightening it back in will also be hard on it. The reality is the pipe should be pulled back a little at a time as the screw is undone to prevent the load on the threads but this is a bit awkward to achieve as the pipe has very little ‘give’ in it. I strongly recommend checking this before you start – I had to call in a favour because having spent a lot of time swapping the turbo it was rapidly approaching closing time for all the shops to get anything to repair this and without it the car shouldn’t be run. If you’re in any doubt just buy an M6 helicoil kit and put a shiny new insert in place in the aluminium casting because there is only the one screw and if it fails your car will not be happy! Helicoils in softer materials are actually stronger than directly tapping the material the right size because the insert is a stronger material than what it’s going into and because they’re fitted by screwing into a larger thread in the parent material than the desired final thread they have a larger contact surface area in that material.

2. To fully undo all the bolts of the manifold flange you have to undo the alternator mounting bolts and twist it out the way. To do this you have to take off the alternator belt by releasing the tensioner then remove the top mounting bolt for the alternator entirely and slacken the other. This requires removing the engine bay undertrays as well but if you’re doing this job save some time and just pull them all off now. The alternator can then be rotated down and away from the block to get at the bolt. Someone out there might have some creative way of getting at that bolt but I had nothing that would get at it from any angle and couldn’t see any other way if could be done because it’s in a recess with manifold one side, oil filter casting the other and alternator in front of it.

3. Remove the radiator fans. In the picture above you can see how tight this is relative to the turbo and so you need to do this to have enough clearance both to get tools in to undo the manifold nuts and also to remove the the turbo itself from the exhaust studs. Removing these is done from the underside and also involves removal of the pipe between the turbo outlet and intercooler to give sufficient space. You need this removed to change the turbo anyway so it’s no inconvenience.

You’re looking to remove pipe sections 15, 16 and 17 for clearance. Item 11 are two bolts holding the charge pipe to the engine. The radiator sits between the charge cooler and this charge pipe.

The fan module can be removed as a single unit downwards with both fans in place by simply removing the four bolts holding it to the radiator and unplugging it at its electrical connector (item 13 on the bottom edge in the image above).

4. Buy a fitting kit off eBay or somewhere – there are load available but this is the simplest way of making sure you have all the replacement seals and gaskets you might need. Get the most comprehensive one you can find if you can’t easily go to get more parts once this car is apart!

5. The oil drain hose from the turbo is an absolute pig to get at.

The part I’m referring to here is number 12 above and consists of a section of solid pipe at the turbo end with a very short section of hose crimped on. I used a socket on a series of extension bars to get the bolt out of the turbo end but the block end is very awkward to get at because you can’t see it from any angle and the access is tight because the bolt sits virtually under the downpipe. Good luck! When you’re struggling to put it back on after changing the turbo don’t forget the gasket. Also this pipe is apparently common for leaking because the bolt doesn’t get put in sufficiently tightly or the gasket gets damaged during reassembly. I’ve highlighted this below in red.

6. The coolant hard line on top of the turbo needs to be removed which leaves an open rubber hose end. An M8 bolt fits perfectly to block this and stop coolant pouring out over everything so have one to hand before you take it off.

7. Carefully check the boost control hoses – apparently these commonly crack and certainly in my case they were quite degraded around the turbo. You can buy the proper replacement VW part if you wish but it may be cheaper to just order some 5mm vacuum hose and put a run in. In my case I didn’t notice the damage until I started taking it apart and managed to get a random bit from a friend. His wasn’t the common stuff it was thin walled and reinforced so the standard clamps didn’t fit but luckily with some persuasion I managed to fit the thin hose into an offcut of the original one. When combined with a suitable hose clip it’s working fine and has been for ages – that said I do not recommend this option!

Damaged section of hose in red above. The image below shows the hose I replaced marked in red going from the turbo housing back to the boost control solenoid and then the second similar line from the solenoid to the wastegate actuator marked in green.

Unfortunately as I mentioned earlier I didn’t take extensive photos of this replacement but I hope these few points help someone out there!

Good luck!

Repairing A Failed P400 Raid Cache Battery

This was done on my HP P400 but the same method should work on a range of other cards with a similar setup such as the P212, P410 and probably many others from this era. As ever your mileage may vary!

Recently I was trying to copy one particularly large file across my network and realised the write speed on my server was dramatically reduced from what I would expect and the reported queue length in resource manager was regularly getting to 10 which seemed excessive. I was also seeing peak throughput to the 12 disk array of about 30 MB/s total.

I was copying the file off my desktop and this is where the weirdness started. I was sending from the desktop at 50MB/s which was slow but on investigation it checked out that that was correct for the drive it was coming from (though it did highlight I was still using one drive that was about 13 years old I should probably replace!). It would start fine and after a while I’d see the following:

Error 0x8007003B: An unexpected network error occurred

Error 0x8007003B: An unexpected network error occurred

I’m still not entirely sure what process is going on in the background here but what I saw was increasing ram usage (presumably at the 20MB/s difference between the sending and writing processes but I didn’t work it out). I assume at some point this buffer hits a limit and it fails. Whatever the exact process this is just a symptom of the fault elsewhere as indicated by having such an awful write speed on the array.

I started investigating the array by actually installing the HP array configuration utility (I probably should have done this ages ago but I actually configured the array through the BIOS utility originally) and on selecting the controller sure enough :

P400 Failed battery warning

Well that’s fairly definitive. So I decided to open it up and have a look at the damage. for the P400 the battery pack is on a long cable and is usually mounted to a bracket on the chassis next to the card. On the DL180 I have it installed into you have to remove three mounting screws and lift out the entire mounting frame and riser card section in one piece.

P400 card installed

Here you can see the HP P400 card (made by LSI but as far as I’m aware with no LSI branded equivalent). Piggybacked on the card is the 512MB cache card and coming out of the right end of it is the multi-coloured cable to the battery. This can be gently pulled out so the battery can be removed.

P400 position in DL180G6

The battery module as it was installed in my server, apparently someone had previously put it back in 180 degrees wrong but nevermind. Right away you can just about see the distortion in the casing caused by the battery failure.

P400 Cache Battery

A closer look at the battery pack shows how badly distorted the casing actually is indicating a total failure of the cells inside – not terribly surprising for a 13 year old battery! If you were doing this properly you’d just buy another one of this whole battery unit and replace it but I decided that for a raid card this old most second hand ones would likely be well used because I doubt they have produced new ones for a while so it’d be hit and miss anyway. Add to that the battery unit just uses four standard 1.2V NiMH cells (albeit uncommon shaped ones) I decided I could probably fix it with basic parts. The issue here was that I found this issue late on December 23rd so the challenge was to fix this with parts I could find locally before the Xmas break. Standby for the hackery…

I started trying to get into the pack on the basis it was ruined anyway. First off flip the pack over and unplug the cable from the battery pack. Technically this isn’t required nor is the board removal below but it makes it easier and takes the risk out when you’re working on the rest of it.

P400 Battery Cable connector
P400 Battery Cable connector removal

Removing the cable shows us the management board that handles charging status and health reporting to the card so we need to keep this. This is retained by a single clip in the recessed section on the left hand edge. Push the clip to the left and lift it, you may need to press it with a tool of some sort as it’s quite small and firm.

P400 Battery management PCB

Once unclipped as above the board can just be lifted out because the battery contacts are just sprung against the underside.

P400 Battery management PCB removed

Next up we need to try to get at the cells themselves. It’s a little hard to see but it turns out the underside is the ‘removable’ section of the case (as in the rest of it is a single moulded part) but mine was thin and brittle enough it just broke up as I tried to take it out but being the underside it’s not visible when reinstalled anyway.

P400 Battery enclosure cover removal

I used one of these iPod cover pry tools I had handy but since the cover broke up anyway a fine screwdriver would also do. Gently work round the cover prying it up but the cover is silicone-ed to the centre of the cells as well so just work on it – it comes of relatively easily.

P400 Battery cells exposed

Now we can see the cells for the first time. You can probably see the how the battery contacts for the PCB form part of the pack. Gently work round the pack cutting/levering the silicone apart then lift the cells out from the curved (non PCB) end of the housing to prevent damage to the contacts. Hopefully If should look like this:

P400 Battery cells removed

For anyone who wants to rebuilt their pack with the correct new cells they’re four Varta V500HT 1.2V/500mAh cells wired in series but you would have to find a good way to replace the cell links because they’re welded on. Also I could only find the cells on eBay where they were £7.50 each

So this is where my plan goes a bit more creative. I decided to just replace the the pack with some basic off the shelf NiMH cells so initially I tried to find a prebuilt pack of the right voltage. These are commonly available on eBay and several other places with a pair of wires coming out however as mentioned earlier this was now Xmas eve and so anything I ordered wouldn’t arrive for ages due to the break. I realised I had some AA NiMH cells which were also 1.2V so four of these would also be correct but I had no way of mounting them. After a brief search I found a local model shop who had suitable 4xAA holders in stock and I was the owner of this.

4xAA Battery  Case

Well worth a couple quid. Next we have to try to make this connect to the management PCB. Now if we were going totally hacky I’d have just soldered the two wires off the battery pack directly onto the contact pads on the back of the PCB and put a big bit of heat shrink over the board but that seemed a step too dodgy…however tempting it was! What I actually did was cut the board contact pads from the pack with a section of the metal from the cell side to allow a wire to be soldered on. The contact pad can them be slotted back into the original housing.

P400 Battery cell contacts reinstalled

In the picture above I slotted the PCB back in to check it made contact and to help hold the pads in place during soldering. Next I drilled a small hole into the rear of the housing to run the wires through from the other pack then soldered the wires on. The + and – are clearly marked on the housing and on the PCB so check this before soldering.

P400 Battery new pack connected

And I stuck a bit of hot glue on the contact points to stop them moving and a blob on the wire to keep it from straining the joints.

P400 Battery 3xAA complete

Now just put the AA’s in the case. If you have a battery case like this one, remember to flick the switch to ON!

Now you just plug the cable back into the PCB and install back into your computer. If you have the proper mount for it in your chassis it will just clip back in and not even be obvious the back has been removed. If you used a longer bit of black 2 core cable between the new pack and the old one you could make it even neater. Alternatively if you cut out the top of the housing you could probably fit a 2×2 AA housing sticking out through with the aid of some silicone but it’d still mount onto the standard bracket even if it would be pretty ugly. Take your pick!

P400 Battery with new 4xAA pack in the server

All done, now put the server back together and fire it up…

P400 Battery charging warning

Now on checking the HP Array configuration tool the message has changed to the above. I left it do its own devices and after a while this warning cleared. Once caching was enabled again the speed increase was dramatic. The write speed on the array for large files (>1Gb so larger than the cache) measured at 234 MB/s on the server Vs the 30 MB/s it was before. Smaller file writes which store to the cache are dramatically faster. On reattempting the large copy that kicked all this off it worked flawlessly first time. Monitoring resource manager on the server I could see that rather than a continuous write at 30 MB/s and high queue depths the write speed was periodically jumping much higher and waiting for more data in between, the queue depth was constantly at less than 1. I also didn’t see the increasing RAM usage I’d seen previously. It is also evident looking at the drive lights are mostly solid now with the occasional blink where they were constantly blinking.

Repairing a Hotpoint WT640 With The Flashing Display Fault

Note : This involved opening up mains powered equipment. This is dangerous and if you don’t understand and feel confident in what you’re doing don’t do it!

Due to the amount of sharing of components this may well apply to other Hotpoint models or even other brands (such as Whirlpool or Indesit) as they are all part of Whirlpool Group but this is the machine I had and did the repair on and beyond that don’t know. Anyway, back to the point…

So one day I went to my washing machine expecting it to have finished and it’d stopped mid way through a cycle and the LED display which shows the remaining time was flickering badly. I turned it off and on again and it worked and the screen came on as normal so initially I wrote it off as just a blip and carried on my day. Unfortunately a few days later I turned it on and the problem had come back and this time I couldn’t get the machine to run a cycle and powering off didn’t help.

Knowing there’s not much going on inside a washing machine from a technical point of view and also knowing that flicking/buzzing on equipment is often caused by a capacitor failing I decided I’d have a quick look and see if I could find any of the tell-tale signs of capacitor failure anywhere.

Before you do anything unplug the machine!

The main PCB for this machine is located to the rear of the machine behind a hatch and once you can get at the back of the machine is really easy to remove.

WT640 rear access hatch

First off remove the white hatch on the rear of the unit as shown in the photo, this will require a crosshead screwdriver.

WT640 Main PCB location

Looking through the uncovered hatch you will now see the PCB to the left hand side with a number of connectors installed in it and the wiring held in place by clips. Gently release the wire from the clips so it is free to move. I suggest taking photos of how it is all laid out so it’s easy to put it back later. Next remove the screws in the rear panel that retain the PCB housing (highlighted in red below). You may also still have a cover over the diagnostic port (location marked in green) and if you pop this off as well.

WT640 PCB housing mounting screws

At this point you should be able to lift the PCB out of the hatch. The wiring is still connected currently but should have enough slack to allow this.

WT640 Wiring positions

Now gently pull off all the the connectors and you can remove the whole board from the unit. This is the bit where many maintenance/service places will just plug a new board in and call it a day but that costs quite a bit of money and not the sort of thing I do given half a chance!

WT640 Main PCB removed from machine

Next there are a series of clips around the plastic housing that we need to undo separate the housing and look inside. You should be able to release these by just squeezing the lower section of the housing but if not slip a fine bladed screwdriver between the sections of the housing and pop them apart. The position of the clips it pretty obvious because there are matching cutouts in the plastic. The image shows one side but they continue round the casing.

WT640 PCB cover clips

With any luck you should be looking at something like this:

WT640 Main PCB Open

Now there’s not a lot of parts on here but a very brief search leads us to the small group of capacitors in the centre. Specifically the parts marked on the PCB as C17 and C20.

Capacitor failure signs on C17 and C20

Looking at these capacitors it’s pretty easy to see both the 680uF (C17) and 470uF (C20) have swelled out end caps which is indicative of failure so that’s a strong indication this is a problem and while there’s no guarantee it’s the cause of the specific problem we are having it’s a pretty strong possibility! For the sake of a couple capacitors it’s well worth replacing them regardless and seeing what happens – so that’s what I did.

The pads to desolder for C17 and C20

I’m the image above I’ve marked the pads that need de-soldering to remove these capacitors just to make life a bit easier. You can probably see that I’ve put red sharpie on them in the image as well – this is something I often do to make sure I don’t try to desolder the wrong part.

C17 and C20 Capacitors removed from the PCB

So now the dodgy capacitors are gone, check the markings on yours and order some replacements. Mine were both 10V rated electrolytic parts rated at 680uF for C17 and 470uF for C20. When ordering capacitors the voltage isn’t critical as long as you’re buying ones with a voltage either equal to or above the required voltage so in this case you could use 16V or even 25V parts if they’re easier to get. I recommend buying a higher temperature type (generally 105°C parts are widely available and will make the component last longer) additionally low-ESR parts have less of an internal heating effect and so if you can get these do so and they should last even longer, particularly in warm environments. You could just do like for like replacement but I’m a fan of doing a bit more to only do a job once and not have to fix it again later. Particularly when the parts are so cheap! Make particular note of the polarity of the new capacitors when you install them, the polarity marks should be the same way round as the old ones.

New C17 and C20 capacitors installed

The new capacitors are installed. Now in classic Haynes manual style “reassembly is the reverse of disassembly”. Once I’d stuck everything back together I put the power on and the blinking was gone.

Good luck, as ever your mileage may vary!

Update : Two years later it’s still working perfectly.

RX8 Project – Part 18, Resurfacing Cylinder Heads the Cheap Way!

As ever do this at your own risk. For most people you’re better off just getting heads machined by a specialist but if you’re reading this blog you’re probably already aware that’s not always the way I do it!

So this idea came from me wondering how I could easily clean up the cylinder heads on the V6 without additional machining. The heads were generally in good condition so I just wanted a fresh surface for the new head gaskets to seal well on rather than trying to remove any surface damage or warping. If you have this sort of damage this method is not for you.

When I came up against this problem I decided to do some research and found quite a few people online saying you could just do it with suitable abrasive paper and a sanding block. Now I get the idea but the engineer in me sees a good possibility of some part getting ground back more than another actually increasing the issues with the head that we’re trying to remove in the first place. Around this time I spoke with a few different people who have experience with engines and they all said much the same thing – machine skimming is safest and easiest but with enough care it should be possible to do a perfectly good job by hand, the problem is getting the whole thing completely flat which is very difficult by hand. Most people who had done this seemed to have done it on engines with small cylinder heads such as single cylinder machine engines which being small are easier to get flat by hand.

The problem was absolutely one of getting something suitably flat that would cover the whole head to get the whole thing even so I started looking into what might work. I was already aware of engineers surface tables which are used for checking flatness but these are large, heavy and very expensive as they’re often made of stone or tool steel. I then looked at getting some surface ground steel plate (where a thick steel place is ground to a precision flatness) but again this seemed to be expensive and awkward. After a bit of thought I had an idea…

£4 eBay coffee table

Ok, so at first glance this seems like a daft idea but stick with me! The cheapest and most rigid precisely flat surface I could find was a piece of toughened float glass. Specifically toughened because it is created in such as way as to pre-stress the surface which makes it both stronger and stiffer but also much more brittle – this is the glass that breaks down into granules when broken rather than shards. Initially my plan was to just order a decent sized bit but that seemed rather wasteful so I thought about it and realised second hand furniture included quite sizeable bits of the glass. I began searching eBay and Facebook marketplace to see if I could find something suitable as cheaply as possible and after a week or so found this coffee table. It was nearby and listed as local collection only with some damage to the wood veneer and scratches on top surface of the glass (so the price was unlikely to go high) and 99p no reserve starting. Couple days later I was the proud owner of a £4 coffee table!

Now you may be wondering why we aren’t bothered about the surface scratches on the glass which is likely to be a problem with any similar furniture. The reason is twofold, firstly due to this being toughened glass any scratches are likely to only be very minor and secondly the glass has a whole other side which is unlikely to have any scratches anyway so we’re going to use the underside.

I took the table apart carefully removing the top and to give additional support I placed it flat on a 19mm (3/4″) thick bit of chip board carefully screwing an section of baton at each end to stop the glass sliding about while we’re working. This assembly when then placed on my carpet which is just very hard office carpet tiles on concrete so shouldn’t allow any appreciable movement so hopefully with that stack of support the glass should be perfectly flat even with a cylinder head on it! The abrasive I will be using is wet and dry paper in a range of coarseness, get a pack of each grade you plan to use, it will take a lot of it! I made sure the wet and dry would stay in place by spraying the back of it with spray mount adhesive and putting it in place. Spray mount should also peel off relatively easily when we need to change the paper. I used 3 sheets to create an area larger than the head face in both length and width.

Glass coffee table refinishing rig

So now we have our setup we need to prepare the cylinder head for this. When it came off the engine it was quite grimy as you might expect so this needed addressing.

Head with worst of gasket scraped off

So here you can see how it was when it was (almost) fresh off the engine but with the residual head gasket material scraped off. You can see the amount of grime isn’t too bad, I have already wiped some off the top half but the bottom is a bit more representative. You can also clearly see the outline marks from the head gasket that we’re looking to remove later. This step basically involved soaking the mating face in a de-greaser then wiping it all off carefully.

Head during degreasing
Head after degreasing but before refinishing

It’s not perfect but it’s a huge improvement on where we started. The combustion chambers are considerably better. There’s some residual on the face but its more staining than anything else and will be removed by the refacing. So now we’re ready to go.

First cover the wet and dry with your chosen lubricant – water should work but I found WD40 seemed to work better as it helped the head ‘glide’ more. A light oil like 3in1 would probably be even better as it’s a little thicker again and WD40 tends to dissolve the spray adhesive as you work making the wet&dry come loose. Take the head and place it on the wet and dry (I started at 120 grit) holding both sides lightly start to slide it across the surface. There are different approaches to this where you can angle the head first one way then the other to give a crosshatch pattern. In my case I generally moved it in a long oval and this seemed to give a nice even finish but as ever your mileage may vary!

Cylinder head sat on DIY refinishing setup

You will find that as you work the oil and metal shavings will spread so I suggest doing it somewhere you don’t mind the mess!

This will take some time and effort. If the wet and dry wears down replace it. when you’re happy with the initial surface being clean of all the minor marks and debris you can go up to increasingly fine levels of grit for a better finish.

On the subject of finishes when I was doing this work I found the following information which relates the abrasive rating with the achieved resulting surface roughness – if anyone knows where this is from please let me know as I can’t seem to find out.

US GritUK Grit Ra µmRa µinch
80 1.6570
180 0.6225
240 0.4518
320 0.2510
Comparison of grits vs achieved surface finish

So in the context of this I’m working in UK grit. Unfortunately the only information I could find on the required surface finishes for head gaskets came from the US so is in Ra µinch (Ra being the roughness average of the surface) but luckily this table equates everything. Generally normal gaskets seem to need a surface finish of about 50-60 Ra µinch, modern multi layer steel head gaskets require 30 Ra µinch or smoother so we need to finish at a minimum of P320. I actually went up to P400 to be safe.

Comparison between not touched and work in progress cylinder head

This is the comparison of the untouched head and the one with the first couple of grits done and so not quite finished but you can see the massive improvement made here.

Head surface reflection

I know judging by eye isn’t accurate but it’s clearly doing something good!

Keep going until you do all the grits you need and when you’re done then you need to check the flatness. I did this with an engineers straight edge (as opposed to a builders straight edge which is a big ruler) which cost £25 off ebay. This is a bit of steel that has been precision ground to be completely straight in one plane so is often only a couple mm thick but 70mm wide or more. You check the flatness by putting the straight edge perpendicular to the head (so it sticks up) and trying to slide a feeler gauge under the mid point (or as close as possible) of the area you’re checking. You need to check the width, length and both diagonals but also check across all the bores. The head should have no more than 0.075 mm off flat over the longest span on an iron head, or 0.05 mm off flat on an aluminium head on a V6. In my case the smallest feeler I have is 0.04mm so that proved it was good enough but to check it further I got some thin foil, checked the thickness with a digital micrometer which came out as 0.01mm and placed the foil on one of the central bridges of the head and put the straight edge on and it rocked on the foil. I then redid the test with the foil at the ends and the same again in other directions. Each time the straight edge was clearly resting on the foil first so the head must be flat to <0.01mm across the whole head. Unfortunately I neglected to take any photos of this stage but there’s plenty of information online.

That’s about as good as it gets so our £4 coffee table looks like a success. Plus I still own a coffee table – albeit with a few new scratches!

RX8 Project – Part 17, Changing to a concentric clutch slave.

To preface this I’ve not actually run the car with this setup yet so please make your own decision if you give it a go. This was done on the gearbox from a 2006 year RX8 5 speed box so may not be applicable to others. It looks like it should work but that’s only my opinion – your mileage may vary!

So this is a bit of an odd problem which depending on the engine you’re swapping in may not be and issue but in my case I decided a V6 was a good idea and unfortunately the standard clutch slave on the RX8 gearbox is on the top offset to one side which lines up perfectly with one of the cylinder heads on my V6. Add to this if you made the better decision mentioned earlier and made the adapter thicker you may be able to avoid this as well. But since I’m largely making this up as I go along here we are!

Now I did look into whether anyone offered a concentric slave conversion for this car but it seems that was never a thing anyone did so I set to work building my own. Luckily there was one thing I knew which would help this process quite a bit – the input shaft on the gearbox is the same diameter/spline as most Ford patterns and so a Ford part should be exactly the right clearance. Add to that I’m actually using a Ford clutch if I get the depth right everything should just match up ok.

So that’s the good news, the bad news is the RX8 gearbox was never intended to be used in this way so mounting a cylinder could be an issue. Now on the RX8 there’s a flanged sleeve mounted which the original release bearing slides on the outside of. This is held on by four bolts into the back of the bellhousing and so this appeared to be essentially the only option. The tube itself can’t stay because the new concentric slave is the same ID and so clashes with it but I thought why don’t I just unbolt the tube at the flange and bolt a suitable adapter there and we’re good to go? Well it’s never that easy is it. Under that flange is a location lip which not only keeps it concentric to the gearbox input shaft but it turns out it also the height of the shoulder accurately holds the input bearing in place behind it so if I just remove that whole part the bearing will move out of position and that will very likely result in it not having enough support and rapidly removing itself from the gearbox in small pieces.

3D model of the RX8 gearbox input bearing retainer
Unfortunately I can’t find a photo of it but the part looked like this!

Ok so I can’t just remove the flanged tube and stick an adapter plate on but how about cutting the tube down to the flange to leave a flat face above the bearing retainer and just using some longer bolts to keep it all in place. After some very careful trimming I was left with this:

Modified RX8 bearing retainer

Next was picking a suitable concentric slave from the Ford range. After a bit of poking about and trying to find something I could make fit I found the Teckmarx TMCS00047 which is a 3rd party part number for a 2001-2007 Mk3 Mondeo/Cougar among others which as you might have read earlier was also available with this same V6 engine I am using and this model has a few advantages firstly that both in and out hydraulics are in one direction so if I make that line up with the original position of the clutch fork I should have easy access and also that they’re threaded the standard M10x1 brake fitting thread so I can direct connect hoses or hardline as I need to make it work. another major advantage is they’re used on loads of versions of the car so they’re widely available and very cheap at under £25 delivered. It also seems that the RX8 also has almost same clutch master cylinder bore as the Mondeo (18mm vs 19mm) which should mean pedal travel is still sensible.

Mondeo mk3 concentric clutch slave

3D model of Mk3 Mondeo Clutch slave

Now with the clutch slave accurately 3D modelled I could measure the 4 bolt flange from the gearbox bearing retainer and by overlaying the two bolt patterns aligned on the centre of the input shaft I could design an adapter which I could index the relative rotational angle of the bolt patterns in the software until the fluid connections where in the right place for the hole in the bellhousing. The resulting first version was this :

3D design of first adapter design

Initially I transferred this to a bit of scrap plastic to make sure I hadn’t made any stupid mistakes before spending much more time cutting a proper steel adapter plate.

Plastic prototype RX8 clutch slave adapter

So with all that checked out and nothing apparently an issue I moved onto the steel one. I did make a mistake here if you can spot it…

To make the adapter I did the same as I had done with the plastic where I printed out the design at 100% scale, stuck it to the steel and then used a centre punch to mark the centre of all the drill positions. I admit this isn’t the most accurate method but it seems to work quite well!

Clutch slave adapter Mk1 in steel

This is the initial adapter, the four larger holes are M8 clearance holes. on the original RX8 flanged retainer they’re 9.4mm but I think I did them 8.5mm as that’s the drill I had available and tightening up the tolerance was probably a good thing. This actually turned out to be less of a problem in the end but that’s another story. The centre hole is larger than the original design to allow for the location feature I’d overlooked on the new slave (which is 42mm OD) to sit within it.

Clutch slave adapter trial fitted to the gearbox

So it fits, I called this good progress but it should come as absolute no surprise that it wasn’t quite that simple…

Clutch slave unit fitted to adapter plate

As soon as I tried to add the clutch slave all the issues become apparent as it just clashed with everything. This told me that I’d need to change the adapter to countersunk bolts so the slave didn’t foul them. I could have changed the rotation but I wanted to avoid having lengths of pipe in the bell housing if I could. Plus I’d already made this steel adapter and didn’t want to do it again!

The other thing I noticed is that the cast webs off the original pivot point actually clashed with the adapter plate preventing it from quite sitting flat so I decided to remove some of the plate to correct this minor issue.

Now the adapter sits flat and at the same time I countersunk all the adapter bolt holes and replaced the bolts.

It all fits more or less where I wanted it but when I tried to bolt up the gearbox I saw another problem. With the bearing retainer plate, a sensible thickness for an adapter plate and the height of the concentric slave itself the slave was already almost fully pressed down so that which it may have worked initially as the clutch wore the slave would prevent the clutch from fully re-engaging. Clearly not ideal so we need to get more radical. First off the back of the clutch slave had a lip similar to the one on the RX8 flanged plate which initially I was just going to leave on and sit on top of the bearing retainer plate as it was slightly thicker than the adapter plate but that just wasn’t an option any more. Below you can the way the slave is totally compressed. Also note how close the hydraulic connection point is to the original pivot point casting.

Stack height issues in the new clutch assembly

This lip was adding a couple mm of stack height we needed to remove so I proceeded to carefully file the lip off down on the slave such that it would sit full within the adapter plate and ideally totally flush to the back of the plate.

On trying to refit this in its new position I realised I’d created another problem that I glossed over earlier – that I’d need to remove some of the original gearbox casting to make the new slave sit flat in the orientation I needed as the original clutch fork pivot point clashed with the location where I wanted the hydraulic connections on the new slave. The best method I found was a drill bit larger than the feature and just drill the top of it away until it clears the new slave.

Around this time I realised really I needed to remove the original flanged bearing retainer plate as it alone added about 4mm to the stack height so I engaged in the type of butchery that makes engineers wince. I took the flanged retainer and trimmed the flange off it. Yes I specifically mean that – if you cut through the bearing retainer ring it will reduce the height such that the bearing is no longer held tightly so you need to carefully trim off just the flange plate leaving a ring the right height fill the gap between the bearing and where the retaining plate face would be. because the new slave retaining face was now flush with the adapter plate this ring will now be held in place by that. Removing this plate now meant I had to drill yet more out of the pivot casting to prevent it clashing but that’s easy.

Final fitment of the concentric slave conversion from the original fork position

Now everything is in place and the hydraulics are accessible through the original clutch fork hole.

RX8 gearbox refitted to the car

And all back in the car…

For anyone who may want it here’s the PDF drawing for the adapter :

Getting John the Ripper working in OpenCL mode in Windows

I recently needed to recover passwords from a Linux system where I had the drive which I could connect to a Windows PC but this presented several issues starting with finding the right file then what tools to use and most importantly how to mate it correctly in OpenCL mode to get the benefit of graphics card processing power!

Firstly the drive was formatted as EXT3 which Windows doesn’t natively support. After a bit of research I found a free program called Ext Volume Manager and gave it a go. It worked perfectly and after giving a list of available drives you can double click and mount the drive as a drive letter in Windows then just browse to it like any other drive. It was simple and worked really well.

Now that problem out the way we needed to find the password file. In Linux passwords were historically stored in a hashed form in root/etc/ in a file named passwd so this is the first place to look. Open it in notepad or similar and it is highly likely you will see a series of lines line this:


The X is where the hash would have been found historically but when the security was updated this method was changed and so the X just shows that there is a password configured but it’s stored elsewhere.

That elsewhere is a file in the same location called ‘shadow’. The structure of this file is very similar to ‘passwd’ but in Linux has different permissions. Luckily in windows this doesn’t make much difference so we can just open it.


The data should look more like this (I have cropped out some of the line to avoid it filling the screen. The $6$ in this case identifies the password hash as being sha512crypt format but yours may differ, the options are:

  • $1 = MD5 hashing algorithm.
  •  $2 =Blowfish Algorithm is in use.
  •  $2a=eksblowfish Algorithm
  •  $5 =SHA-256 Algorithm
  •  $6 =SHA-512 Algorithm

The next bit ‘ THMmaDC5 ‘ is the ‘salt’ value which is random data used to encode the password as the hash making it more difficult to guess.

The remainder up to the colon is the hashed password which is what needs to be guessed so now we have the right file.

Next go ahead and download Cygwin ( https://www.cygwin.com/ ) this is basically a miniature Linux platform on Windows which lets you compile Linux programs to run under Windows if they are compiled for it.

When installing Cygwin generally you can just use defaults and whatever local mirror you fancy however when the list of tools is shown search for OpenCL and add this to the installation.

OpenCL Version

Add the highlighted component to the install and continue and you should find you will soon have a Linux installation in a folder on your PC (default location is C:\cygwin64\ ).

Next download the zip of latest version of John the Ripper ( https://www.openwall.com/john/ ) – this is a widely recognised tool for this purpose and seems to work best. I also tried a program called HashCat but this didn’t seem to be able to find the hashes in the file. The version I used was 1.9.0-jumbo-1-64 Bit.

Hopefully the zip will look like this. Copy the all the folders and paste them into the Cygwin folder – there will already be a folders with those names so merge them. This operation adds the descriptors to allow Cygwin to recognise your OpenCL device however on my PC (and from what I’ve been reading online several others the path was incorrect so we’ll fix that.

Browse to the following path C:\cygwin64\etc\OpenCL\vendors\ and open the amd.icd file in notepad.

Next go the the system32 folder as shown and search for ‘amdocl64.dll’ . In my case this wasn’t present in the system32 folder directly but I found a match in System32\DriverStore\FileRepository\ . If that is what you find just copy the file and paste it into system32 itself and this should correct the mismatch.

Next copy your ‘shadow’ file into ‘C:\cygwin64\run’ – technically this isn’t required but it makes life easier. In my case I edited it to have a .txt extension to make testing easier. Now to test it!

Open a command prompt Window and browse to ‘C:\cygwin64\run’ then enter the following command:

john shadow.txt –format=sha512crypt-opencl

Interchanging the format for whatever is relevant to your hash type. If you run john without specifying a hash format it will recognise it correctly but will default to CPU only mode rather than the OpenCL version which comes with a performance hit for most people.

All going well you should see something like this :

That tells us its working fine and has successfully found the graphics card as a processing device. Now take a break and leave it to churn through its options for as long as it takes. It won’t be fast!

Start of 2020 Update

Apologies to anyone who’s been waiting for an update on any of the projects I’ve put on here – I’ve had a lot going on over the last year and writing up all of this information takes me a lot of time so has taken a bit of a back seat. None of that information has been lost and I hope to start catching up on all of this over the next few months.

Where we are right now :

V6 Mazda RX8

The V6 engine has been fully rebuilt and has been sat in my living room next to an engine crane for about 8 months now, Partly this is due to me not currently having a garage to work in and it being winter and partly due to being very busy last summer. But yes, the project is still ongoing and hopefully will make good progress this year.

Six million dollar welder

Is still on my workbench awaiting the last couple of bits. I’ve had to swap out 24V PSU’s a couple times as they couldn’t deal with the current of the new feed motor. It now works but needs the relays mounted to the panel so I need to remember to find 4″ of DIN rail.

DL180 Server

Is still working beautifully after the Arduino fan controller mod. It’s been hosting this blog ever since so something like 12 months now without a problem. It also provides the storage for my CCTV system.

Hikvision CCTV

I’ve got a couple of updates to write about expanding the system beyond the original one camera setup I wrote up last year. Using multiple cameras with network storage seems to be poorly documented and have a few interesting quirks but after some work I got it working fine. The biggest problem I’ve had since is when the local police asked for my footage following a nearby break-in I had to supply them on a 1 Tb hard drive! High resolution digital video takes up a lot of space!

Other Projects

I’ve had various other projects going on as well. I’ve started looking into using NodeMCU WiFi microcontrollers as sensor nodes with their own web servers around my house with NodeRed requesting the page and parsing the HTML to return the information I want. I can read the temperature sensor connected to the nodes and control the LED on the MCU from NodeRed. Currently the data is not stored because I ran out of time trying to get MySQL setup. I’ll write this all up at some point

Raspberry Pi’s – I seem to have collected a selection of Raspberry Pi’s somewhere along the way. I have a Zero, a ZeroW, 1B (which in a different life I turned into a PoE CCTV camera), 2B and 3B plus I think somewhere there’s another 2B. I really should do something cool with them!

Wooden storage box – I started restoring a large wooden box some time ago. The box used to be in my granddad’s workshop as a toolbox for many years and before that I gather it belonged to his uncle so it’s been around for a long time and has suffered a bit with use and age with some areas with woodworm damage and the rope handles badly degraded. It has also been painted brown at some stage so I’ll need to get that cleaned up as well. I intend to restore it to a ‘usable’ condition so rather than trying to make it as new just tidy it up, repair the damage and make it solid enough not to degrade further but still look like the well used item it is.

Subwoofer project – Has been in constant use for ages despite never being technically finished. I really need to actually finish it and write this up!

There will be more but I think that’s enough update for now – rest assured I’ve not stopped! Especially since this morning another turbo arrived in the post, the fourth I now have here….