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!

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.

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….

Upgrading a SIP Migmate 130 Turbo welder – Part 2, The 6m Dollar Welder

So after it had been left abandoned in a cupboard for a couple years I was recently contacted by the guy who actually owns the old SIP Migmate welder saying he had a couple projects to do that would be good for a MIG but aware we’d previously done it serious damage to the torch he’d found a wire feed unit with a euro torch connector on ebay and could we make it fit. Well of course we could, what could possibly go wrong! Before I knew it he’d ordered it to ship to me so I guess we were modding the welder again. We can rebuild it better than it was before!

Upgraded Wire Feed

Wire feeder
The new wire feed motor

So this is what turned up – clearly a different beast entirely to the original plastic rubbish. Don’t be mistaken, it’s a top quality Chinese unit but it is significantly better built than the original – one being mostly metal it doesn’t deflect under load. Add to that the motor is rated at 40W which is probably four times more than the original one it should be able to drive wire through longer torch leads with no problem.

Wire feed drive comparison

You can clearly see the significant difference in the units in this picture. But that isn’t going to stop us!

First off we need to remove the existing feed unit. These are held on with four pop rivets which are quickest removed with a power drill. To extract the drive unit the torch must also be unbolted from it with the one retaining nut.

Migmate 130 of feed removal

So at this point you should be left with this :

At this stage you’re probably wondering how this will work, and if (however unlikely) you’re attached to this welder you probably want to stop reading, this will not be pretty!

If you’re you’re not attached to the welder I suggest finding an angle grinder and getting busy!

The key thing to note here is because the new drive is for a euro torch it is energised by the main supply so no conductive part of the feed drive can be in contact with the casing. Add to this the new unit has an adjustment on the top which needs clearance under the case the feed motor cut out needs to continue much lower down.

Due to the feed mechanism being physically wider the connector for the euro torch connector will sit further out than the original torch outlet. In an ideal world I’d have relocated the the wire feed to the bottom of the welder but the outlet inductor is behind the panel and I didn’t want to go trying to move that enough for that idea to be viable.

First cut for wire feed

The first cut doesn’t look too serious, then hack the front out :

Front first cut

Hmm, yes I’ll work out how to cover that up later!

Next up we make a plate to hold the euro connector. This is to prevent any movement on the euro connector causing it to hit the case which could end very badly. I found a random bit of polycarbonate I had lying about drilled a clearance hole in it then worked out where it needed to sit. The horizontal position here is less critical as we can adjust it on the mounting later. The plate needs mounting holes to fix it to the front plate so drill and bolt this. A trial fit then also identified that when the new feeder was fully forward in position more clearance was required in the internal plate so this needed a little more butchery.

New mounting for replacement wire feeder

The blue wire dangled through the divider in the picture is actually the trigger wire for the welder something we’ll need to sort out later to actually make it work.

Wire feeder trial fit

So here’s the trial fit, nothing touching the case where it shouldn’t and all seeming to fit well. around this time I wanted to get a matching torch for the upgraded welder so I went to my favourite welding shop (Noz-Alls in Cheltenham) to pick one up and while there I explained what I was up to with the welder and he helped me out with some more bits he had. Specifically I wanted to upgrade the welder from using 0.7kg wire spools to 5kg spools so I needed a new mount for the reel and not only did he have something he also mentioned that I’d suitable gas valve (the welder originally had a mechanical one in the torch but I hadn’t even thought about the fact euro torches don’t have this. Again he had just the thing available for a few pounds so I got that as well.

New feed roller

Now that looks more like a proper setup, this new mount just bolts through the divider plate. Next up we need to mount the drive motor itself, it is critical to remember the black plate under the drive must remain to insulate it from the mounting bracket. I originally intended to mount it with a section of angle but in the end I came up with another alternative. I had a short offcut of 40x40mm aluminium profile with a couple angle fixings which by luck was perfectly sized so I decided to use that up.

Mounted new wire feeder

Something I should probably note here is using either durloc or nyloc nuts on everything I can and make sure everything is good and tight. The owner of this welder can be hard on equipment and I want to be sure that when I hand it back it won’t just fall apart!

Fully fitted wire feed and reel holder

That’s the wire feed and 5 kg reel setup all installed. So now back to the problem I mentioned earlier with the gas valve. The black hose coming off the back of the euro connector is the gas line, I need to connect this to a valve. I decided to mount the valve on the electrical side of the welder because my plan was to drill out the original hole the gas hose entered through to take a more standard 3/8″ BSP threaded fitting.

Gas Valve

New gas valve

The valve I bought is a direct fit to the 5mm ID hose off the euro connector. The valve inlet is an 8mm barb so I bought an 8mm to 3/8″ BSP female hose barb and screwed it into the back of an 3/8″ BSP bulkhead fitting. The bit of hose is a section of 8mm fuel hose I had lying about. The valve actually has a nut on one side to allow it to be mounted to a panel, in this case I mounted it to a section of aluminium angle. These valve are available in a range of voltages; usually 6/12/24VDC in welders but others are available. Since the feed motor is 24 VDC and we need this to open when the feed is on it makes sense to use the same then we only need one trigger switched supply for both.

Earth lead

So with the addition of a detachable torch I thought a detachable earth lead might be a good idea. I bought a 10-25 dinse connector off ebay, this comes as a plug and socket pair where the socket fits through a hole in the panel and the plug is bolted onto the end of the cable. To mount the socket I undid the clamp inside the welder where the cable was fixed to the supply transformer. The cable is held in by a plastic clamp so just undo that and pull the cable clear and remove the clamp from the panel. As it turns out the panel hole was fitted with a dinse connector in a different model and so they actually fit the panel perfectly with the anti-rotation key even fitting. Again for the power connection to the socket I used a 10mm re-usable cable lug but had to fold the solid core from the transformer back on itself so the clamp would tighten onto it solidly.

Dinse connector
Make sure it’s all tight; you don’t want this coming loose!

Wire Feed Controller

I decided in the end rather than bothering to improve the existing speed controller which is well documented to have issues I’d simply replace it with a modern PWM DC motor controller. PWM controllers generally allow a very wide range of adjustment and because they apply full voltage the motor retains excellent torque even at low speeds. So I bought another quality Chinese board off ebay and after a couple weeks I had one of these:

These go for about £2.50 and from my initial tests with a 19 VDC laptop supply and the new 40W motor it worked perfectly and it gave very smooth control up through the full range. The only thing that might need adjustment later is that full speed seems excessively fast for a welder but this is something to assess when the motor is loaded. With the smoothness of the range this wouldn’t be a problem but if we don’t need it later it would be better to add a resistor to make the controller only go up say 75% full speed when the dial is at maximum. But we’ll worry about that later.

The next problem is the nut on the potentiometer which would normally hold it in place fits right through the original hole in the panel. So I found a large penny washer which it would tighten up on and drilled two holes in it. This washer was then pop riveted to the front panel. With the knob back on you cant even see the rivets.

New motor controller
Rear view of the new controller
And the front view – you can see the other additions as well

Now, you may notice I’ve taken out the original PCB. This is partly because we needed the spot for the new speed controller but also because that makes about half the PCB redundant. The only other things on the PCB are a small 12V PSU (to drive the main supply relay), a couple line filter capacitors and a 16A relay which switches the main supply. My plan is to replace the relay with a 24V coil one and run all the control off the separate 24 VDC supply.

More to follow in the next update!

Upgrading a SIP Migmate 130 Turbo welder

The story of this upgrade starts with a friend of mine acquiring it about 15 years ago (at which point it was already quite old) and after some use real life got in the way and it was abandoned in a barn for about a decade. At this point I needed a welder for a project and asked to borrow it. Now when I got my hands on it and started trying to use it it became immediately obvious these welders were amazingly basic and poorly constructed and so immediately I started modifying it to make it work a little better.

Factory Wire Feed

First off the standard wire feed is terrible, it’s made of plastic and if you put enough pressure on to push the wire the mounting for the drive (being plastic) actually bends away and just won’t consistently grip. This situation can be improved by changing the plastic torch liner out for a steel one to reduce friction but it’s still dodgy. Bracing the wire feed on the outside helps as well.

Migmate 130 Feed Mod

Here you can see the feed modification. It is simply a bit of scrap metal with a slight bend in it and two holes. The two screws are already in the feed system and hold the parts from the factory so it just picks up on them. This simple mod helps the two feed rollers from deflecting away from each other.

The next issue with the wire feed is the motor is driven off the main transformer output with half wave rectified DC which causes a one main problem, the supply to it isn’t consistent. When the arc is struck the voltage at the motor will drop due to the load change on the transformer which tends to make the motor constantly pulse in operation rather than give a consistent feed so it’ll join metal but not in a particularly convincing way.

To get round this I added a small regulated 24VDC supply for the motor with the help of information I found on the internet such as the wiring diagram for the welder. The was this works is the control board gets its 24V supply from the black wire on the 4 pin connector. If we disconnect this and instead feed it our own 24VDC the supply shouldn’t fluctuate any more. I used the existing supply (the black wire we just intercepted) via a relay (24VAC coil) to turn on the wire feed when the output energises. You should end up with something like this

I’ve not checked the rating on the factory feed motor but I would guess 10W at most. I used a 24VDC 15W PSU module (specifically a Tracopower 15124C that I found on ebay) and it worked well. I managed to fit it behind the main transformer bolted to the outer casing.

Added power supply location

Further to this the motor speed circuit is actually very poorly designed and after a little use can get twitchy and change during use. I didn’t get as far as modifying this but further information can be found here :

Wire speed mod

Or if that should ever go offline also in this PDF :

Earth Lead

Another key usability thing is that these welders have very short leads and the clamp was poor from new and appeared to be a similar thickness to tinfoil and added to that was badly damaged and even rusty and since poor contact causes many issues with consistent welding so I decided to upgrade the cable and clamp to help the situation. For a welder this size you need to be looking at a minimum of 10mm2 cable but this will not allow you to operate at full power consistently (not that this welder is actually capable of that anyway!) 16mm2 would give you plenty of spare capacity.

The clamp itself was just bought off ebay again, they’re about £4 each so difficult to go far wrong. You could go for a different style to the normal clamp if you prefer such as a magnetic one. To connect the cable to the stud on the clamp I used a reusable cable lug which uses two small bolts to tighten to the cable, you could buy crimp lugs but crimping them without the correct tools can be hit and miss. I’ve heard a cold chisel will work but your mileage may vary. I actually used a second reusable cable lug to clamp the new cable onto the transformer outlet inside the welder – not the neatest solution but it worked.

Gas Supply

The standard shielding gas supply on these welders is via a small plastic tube which is intended to be connected to a mini-bottle which sits in two brackets on the back. The brackets aren’t actually fixed to the welder so can be easily knocked off. The standard regulator is rubbish and the one I got with the welder was totally seized shut. I bought a like for like replacement initially and this highlighted the limitation here. The bottle is so small and the regulators so poor that the gas flow actually changes during use and rapidly empties entirely. They have no gauge and so the first you know of having no gas is when your welds go horrible. I looked into it and found a good solution – you can buy regulators that adapt a normal gas bottle to this type of hard line.

I looked into getting gas and found that the time of massive rents on bottles is over. In the UK there are a couple networks of suppliers who will give you weld gas with only a bottle deposit (currently £65 for mine) and no ongoing rental charge. Once the bottle is empty you take the bottle back and get a full one and just pay the gas fill cost (about £30 for the bottle I have) I found a supplier of Hobbyweld gas (Noz-Alls Cheltenham – www.weldingdirect.co.uk) and got their 10L bottle, these are pressurised to 137 Bar giving a total of 1370L of gas. This lasts drastically longer. The shop I went to also sold a standard regulator but with a crimped hose and a push fit to suit this welder off the shelf making this very easy for about £20.

Roll Drag

One other problem I had was the tension spring which is supposed to hold the roll under a little tension to prevent overrunning was actually sharp and biting into the reel. I added a large flat washer under the spring to stop this then added a small washer as a shim to prevent it being over-tightened. This provides friction over a large area to avoid this problem and it seems to work well.

So once I’d done all of this it worked significantly better and we used it for a few projects to good effect right up until we tried to repair and refit the load bed of a pickup truck which involved welding plates onto chassis rails and various other extensive welding work. After burning through multiple contact tips and a couple shrouds we got to the point where the torch died entirely with the wire welding into the inner workings of it and came to the conclusion it was done for. The torch on these being hard wired into the unit finding a replacement wasn’t as simple as a standard euro torch and at this point I wasn’t sure it was worth replacing until we actually needed it again. Some time later I bought a new compact R-Tech MIG which by comparison is a revelation and so the old Migmate got thrown into a cupboard for storage with the expectation it would eventually probably be scrapped.

Though that’s not exactly how the story ends…

Solving the DL180 G6 Fan Controller Problem

Some time ago I acquired a DL180-G6 rack mount server for very little money as these go for next to nothing on eBay in most configurations and one version has 12×3.5″ drive bays. Unfortunately there seems to be a bit of a problem with these systems where if you change any of the hardware (such as an unsupported raid card) or a whole variety of other things the on board fan controller defaults to high speed and it will sound like a jet engine. The fans are high flow high speed fans and so while they do work well they really scream at high speeds. Disconnecting the fans won’t help because if you do that the system will refuse to boot entirely.

The Fans

I decided that I needed to come up with a solution to this problem because well…how hard can it be?! Fundamentally these are standard 4 pin PWM type fans which have the following connections:

1 – GND
2 – +12V
3 – Tach
4 – PWM

Unfortunately the ones in the DL180G6 are a special case in that they have 6 pin connectors which follow a slightly different layout:

1 – +12V
2 – GND
3 – Blank
4 – Tach
5 – PWM
6 – Blank

The blank pins on the fan connector may seem a bit pointless at first but they’re like that because the motherboard support redundant pairs of fans in some configurations (I saw this on a Storageworks x1600g2 which shares the same main components). Due to this the motherboard needs a second tach (RPM) signal to monitor the second fan in the redundant pair and presumably due to the high power consumption of these fans a second +12V supply. This means you can either connect a single fan direct to the motherboard or a pair via the splitter which comes in the storage works (HP p/n  534358-001). The motherboard header looks like this:

1 – +12V-1
2 – GND
3 – +12V-2
4 – Tach – 1 (Inlet)
5 – PWM
6 – Tach – 2 (Outlet)

The good news is this means you only need one PWM per pair of fans in this configuration.

Arduino 25kHz PWM

At this point I decided I needed to build something I could fully control and so I decided to try to control it with an Arduino using the on board hardware PWM. This isn’t as easy as it sounds because PWM fans operate on a PWM control frequency of 25kHz which isn’t a standard configurable frequency on an Arduino IDE because it isn’t a direct division of the system clock. Thankfully there is a way round this. Timer 1 on the Arduino nano is a 16 bit timer and by directly manipulating the timer registers we can make the timer reset after a number of cycles so we can basically create a timer of any frequency we need. In this case  rather than being limited to prescalers (divide by 1,8,64,256,1024) from the main clock (16MHz) and 0-255 (0% – 100% duty) by using the 16 bit timer we can set a clock reset every 320 cycles which gives 25kHz at this clock frequency. I found some code which nicely did this on stack exchange and so just went with it.


The clever bits are shown here:

    // Configure Timer 1 for PWM @ 25 kHz.
    TCCR1A = 0;           // undo the configuration done by...
    TCCR1B = 0;           // ...the Arduino core library
    TCNT1  = 0;           // reset timer
    TCCR1A = _BV(COM1A1)  // non-inverted PWM on ch. A
           | _BV(COM1B1)  // same on ch; B
           | _BV(WGM11);  // mode 10: ph. correct PWM, TOP = ICR1
    TCCR1B = _BV(WGM13)   // ditto
           | _BV(CS10);   // prescaler = 1
    ICR1   = 320;         // TOP = 320
void analogWrite25k(int pin, int value)
    switch (pin) {
        case 9:
            OCR1A = value;
        case 10:
            OCR1B = value;
            // no other pin will work

The first bit sets up the timers to run at 25kHz as we need. The second bit is a special analogue write function to make sure we set the time right. We will use this function to update the timer value. We now have two PWM channels on pins 9 and 10 of our Arduino Nano.

Temperature Control

Next up I decided to add temperature control to these fans using a couple old DS18B20 temperature sensors I had lying about. These are good because multiple sensors can be daisy chained to a single data pin and the value doesn’t need scaling or anything unlike an analogue input pin and a thermistor. They cost a little more but for convenience they’re hard to argue with. They usually use +5V, Gnd and one signal pin. The signal pin needs a pullup resistor to work – this is normally specified as 4.7k. Technically these are a “1wire” device which can be run on parasitic power so the +5V isn’t actually required at the device end but if used in parasitic power mode you short it’s Vdd pin to ground. More information can be found here:


There are specific Arduino libraries for using these devices so they’re really easy to use but they have one issue in this application. To do what I intended and have two separate fan zones we need to know which sensor is which. Thankfully included with the Onewire library is an example function called “DS18x20_Temperature” which will scan for devices on a specified pin. In the example this is called “ds” and it pin 10 by default but for my purposes this won’t work because we specifically need pin 9 and pin 10 for the two PWM outputs so this needs to be relocated somewhere else.

#include <OneWire.h>

// OneWire DS18S20, DS18B20, DS1822 Temperature Example
// http://www.pjrc.com/teensy/td_libs_OneWire.html
// The DallasTemperature library can do all this work for you!
// http://milesburton.com/Dallas_Temperature_Control_Library

OneWire ds(10); // on pin 10 (a 4.7K resistor is necessary)

void setup(void) {

The code above isn’t the complete code for this example just an excerpt so you can see yours is the right one – use the one from the library.

Changing the pin to whatever you choose and running the example with serial monitor open you’ll get an output of the devices it finds. If you do this with one device connected at a time you can note down the device address for each. I marked them as #1 and #2 before hand to keep track of these later.

The Circuit

The next bit is bringing it all together electronically. We already looked at the Onewire sensors so these are really easy to connect up, I used two normal 3 pin PC fan connectors to allow these to be disconnectable for easy installation. The next bit is the fans. The PWM on fans are controlled using a pulse signal as described earlier but this isn’t a direct voltage control input. The fans need the PWM pin pulled to ground to control the signal but the output pins on the Arduino aren’t capable of absorbing the current required for direct connection so we need to add a transistor to do this for us. I went for a 2N7000 Mofset for each PWM channel because..well basically I had a bag full of them to hand and they’ll work at the output voltage of the Arduino. These will connect the fan PWM connection to ground when the Arduino output is driven high which unfortunately will reverse our PWM direction but that doesn’t matter because we can flip it back the right way in code. To correctly drive a a mosfet from an arduino you will need a gate drive resistor (to limit inrush to the Mosfet gate capacitance as this could damage the Arduino) and a gate pulldown resistor to make sure the mosfet fully turns off when the Arduino is no driving it. People will suggest all sorts of value for this but I went for a 220Ω for the gate drive and a 10kΩ for the pull down. The capacity of this Mosfet means we can use a single one for a large number of fans.

For simplicity I decided to use another of the eBay 6 pin fan connectors to connect up the cables for the fans. I intend to pass the power and tach signals directly to the motherboard so I’ll come up with a breakout cable to just isolate the PWM signal from the motherboard and allow us to feed in our own. Due to doing this we only actually need 4 pins (+12V, GND, PWM1 and PWM2) running up to the Arduino to control the fan but since I had them anyway why not!

Arduino Nano PWM Fan Breadboard

So this is the result the two connections for the DS18B20’s are on the right and the 6 pins for the fan/motherboard loom in the middle.

The Complete Code

This is where we start to bring everything together:

#include <DallasTemperature.h>
#include <OneWire.h>

// PWM output @ 25 kHz, only on pins 9 and 10.
// Output value should be between 0 and 320, inclusive.

int fanspeed1 = 25;
int fanspeed2 = 25;

float temp1;
float temp2;

#define onewirepin 3
OneWire oneWire(onewirepin);
DallasTemperature sensors(&oneWire);

DeviceAddress TempAdd1 = {0x28, 0x83, 0xC8, 0xE6, 0x3, 0x0, 0x0, 0x15};
DeviceAddress TempAdd2 = {0x28, 0x4A, 0xDE, 0xE6, 0x3, 0x0, 0x0, 0xFC};

void analogWrite25k(int pin, int value)
    switch (pin) {
        case 9:
            OCR1A = value;
        case 10:
            OCR1B = value;
            // no other pin will work

void setup()

    Serial.begin(9600);    //Start diagnostic serial port
    // Configure Timer 1 for PWM @ 25 kHz.
    TCCR1A = 0;           // undo the configuration done by...
    TCCR1B = 0;           // ...the Arduino core library
    TCNT1  = 0;           // reset timer
    TCCR1A = _BV(COM1A1)  // non-inverted PWM on ch. A
           | _BV(COM1B1)  // same on ch; B
           | _BV(WGM11);  // mode 10: ph. correct PWM, TOP = ICR1
    TCCR1B = _BV(WGM13)   // ditto
           | _BV(CS10);   // prescaler = 1
    ICR1   = 320;         // TOP = 320

    // Set the PWM pins as output.
    pinMode( 9, OUTPUT);
    pinMode(10, OUTPUT);

    sensors.begin (); // Initialize the sensor and set resolution level
    sensors.setResolution(TempAdd1, 10);
    sensors.setResolution(TempAdd2, 10);

void loop()

    sensors.requestTemperatures(); // Command all devices on bus to read temperature
    temp1 = sensors.getTempC(TempAdd1);             //Read Temp probe 1
    fanspeed1 = constrain(map((int)temp1,20,60,15,100),15,100);   
//Map fan speed for channel 1 to 25% at 30C to 100% at 60C and constrain the values to 25-100% range 
//(prevents fan from either going below 25% or trying to be set to above 100%)
    Serial.print ("Temp 1 is : ");
    Serial.print (temp1);
    Serial.print ("  Speed 1 is : ");
    Serial.println (fanspeed1);
    temp2 = sensors.getTempC(TempAdd2);            //Read Temp probe 2
    fanspeed2 = constrain(map((int)temp2,20,75,15,100),10,100);   
//Map fan speed to 25% at 30C to 100% at 75C and constrain the values to 25-100% range
    //(prevents fan from either going below 25% or trying to be set to above 100%)
    Serial.print ("Temp 2 is : ");
    Serial.print (temp2);
    Serial.print ("  Speed 2 is : ");
    Serial.println (fanspeed2);
    // Update Fan Speeds:
    analogWrite25k( 9, map(fanspeed1,0,100,320,0));         // Scale % fan speed from sensor one to actual PWM value for 25kHz output      
    analogWrite25k(10, map(fanspeed2,0,100,320,0));         // Scale % fan speed from sensor two to actual PWM value for 25kHz output   

Ok, it may not be perfect but it works.  The main bits to note are as follows:

1. The two “DeviceAddress” fields, these are the ID’s for our two DS18B20’s that we identified earlier.

2.  This line – fanspeed1 = constrain(map((int)temp1,20,60,15,100),15,100); which maps a temperature (converted to a float) between 20°C and 60°C to a fan speed of between 15% and 100% which is then constrained to this range so a temperature of 10°C doesn’t cause the fan to be given a 0% demand. You may want to change these constraints to minimise fan noise but I was being cautious and wanted to be sure the fans didn’t even slow down too far that anything overheated or triggered a BIOS warning. You can also tweak the temp vs speed mapping to optimise for a specific volume or temperature.

Map and ConstrainThere is another line like this for fanspeed2 so we can set different scaling ranges for the two sets of fans. You might only need a lower fan speed to maintain a temperature through the raid card area for example.

3. This line : analogWrite25k( 9, map(fanspeed1,0,100,320,0));
It maps our 0-100% fan speed to a value between 320-0 respectively so that we correct the signal inversion caused by using the N channel Mosfet.

The Wiring Loom

This bit is actually really simple but takes ages, buy or borrow a proper crimp tool for fan connectors a soldering iron and a good selection of heat shrink to cover everything up.

With this loom you can actually wire it up to a standard PWM fan controller off eBay or whatever if you just want a quick solution without all the soldering for the breadboard bit since it gives you power, ground and the PWM signals. Just be aware ONLY PWM fan controllers (the 4 pin ones). By doubling up the tach lines you could also take out several fans if that’s what you want so run the tach line from one fan to multiple motherboard headers if thats what you want. Here’s just how to intercept the right signal from the fan headers the way I did it:

DL180G6 Fan Wiring

Here’s what we end up with:

DL180g6 Fan Breakout

The Result

Finished Arduino DL180G6 Fan Controller
As mentioned earlier this will also work with the redundant fan systems because it passes through the tach signal of the second fan in the pair and a single PWM controls both. If doing this be careful, different servers seem to have different fan inputs configured depending on exactly what they are and you need to make sure you connect up to the right ones or the server will error on fan failure. This will probably work OK with other similar servers but can’t guarantee anything so  your mileage may vary. The other good news is that if PWM fans don’t get a PWM signal they default to 100%.

With the settings I have the fans will spin up to 100% briefly as the Arduino powers up but then spin down a few seconds later- this is normal behaviour for these fans. When the system is idling the fans seem to sit at the 15% most of the time occasionally going a little faster and now the power supply is by far the loudest part of the server so I probably wouldn’t bother setting a speed below 15% but the system is drastically quieter overall. You probably still won’t want it in your bedroom but you won’t be able to hear it everywhere in your building any more!

Other developments

When I get a bit more time I’m hoping to wire the Arduino USB connection up to an internal USB header so I can monitor the temperatures and even reprogram it when the server is running to fine tune the settings in operation. Technically its also possible to write a program to monitor CPU load and ramp the fan accordingly but this might just be too much effort.

Hopefully this will help those of you out there who have been having problems with these servers. Good luck

RX8 Project – Part 13, Canbus #3, Labview!

If you just want the CANbus ID for the RX8 PS light and not all the background work just skip to the end!

So it’s been quite a long time since I had chance to have another go at getting the CANbus on the cluster working and while previously I manged to get everything apart from the power steering warning light working I decided I really should find out why not. This is a simple lesson in why getting sufficient sleep is really important!

I was contacted a while ago buy a guy doing a similar conversion to mine who happened to have a second complete RX8 and a variety of diagnostic equipment that can talk CANbus who had send me a block of CANbus log data that I’ve done nothing like enough work on since I’ve had it! Anyway the key here is I knew that the car some of the logs had come from had the factory PCM (ECU) working as intended and as such the power steering light doesn’t illuminate. This meant that somewhere in that log file was the data that turned off the light, I just had to work out where it was!

Now first off I took the approach of taking the two sets of data logs I had, one from a car with a functioning PCM and one from a car that doesn’t. Then list out all the ID’s that occurred in each set of data. I’m going to assume for my purposes that any that occur in both sets are not required. The logic being that the data that turns off the light must be present in one set and not the other. I admit that this might not be the case if there’s something more complex going on like if with the PCM removed the power steering computer doesn’t get the required data and sends a different value on the same ID. But for now it’s a starting point!

The ID’s that remain are as follows:

201, 203, 215, 231, 240, 250, 420, 620, 630, 650

A couple of these we’ve already seen elsewhere, specifically 201, which is the RPM and speed to the dash, and 420 which control the cluster warning lights. So after setting up the arduino and canbus data to strobe all these remaining address and nothing happening I gave up!

Many weeks went by and I it was nagging at me why I couldn’t find the right code. Eventually I decided to try a different tack so I ordered a USBtin which is a really neat little USB to CAN adapter which appears as a virtual COM device in windows and can be controlled using a series of commands known as the LAWCIEL protocol (details of which can be found here). The kit version is really quite cheap and would probably be a good option for the budget conscious but on this occasion I just decided to be lazy and buy the prebuilt one.

Clearly I’ve decided to PC control it at this point! Next up I needed a way to stop it when the warning light went off. I ordered a very cheap optical detector off ebay which can be wired into an Arduino or something similar. These are the ones that vary around £1-2  so difficult to argue with. They offer a potentiometer to adjust the switching brightness so I can tune it to what I need and a digital output so I don’t need to mess about doing analog reads or calibrating things on a microcontroller. Yes i know it’s not the neatest or most efficient way of doing it but for my purposes it’s so cheap and easy it really doesn’t matter! So I need to make that talk to a PC in a way I can use and that’s where this whole thing starts to get more interesting.

I’d pondered ways of interfacing a microcontroller to a PC easily and while it’s not terribly hard to make it shout over serial when an input goes high I came across something much more interesting. There’s a company called National Instruments who make lots of very expensive software and equipment for recording data from experiments but fairly recently they started supporting hobbyists by producing the Labview Makerhub, and more specifically a package called LINX. LINX includes a series of drivers and firmwares to allow things like Arduinos, Beaglebones and even Raspberry Pi’s to be used as IO devices (the Raspberry Pi can actually have programs loaded to them as a full remote node). This is quite a major step because it suddenly allows hobbyists to use really good professional software without having the problem of only being able to use NI’s extremely expensive hardware! This gave me and idea – use labview as the core software then I can use the supplied LINX firmware to set up an arduino as IO. To make this deal even sweeter you can also download Labview for free from NI for home use. Take a look here

So after a quick bit of following the instructions we have a basic labview program that will read the arduino IO via serial:

Labview Lynx1

Basically what this does  is it starts by opening a serial connection via the LINX toolkit, this returns a device name to an on screen string display and passes a reference which identifies the connection to the read stage. The next bit the larger grey rectangle is how Labview handles a while loop so it’ll keep performing the enclosed functions constantly from left to right until the conditional term in the bottom right goes high – in this case it’s a stop button. So basically the loop just calls a LINX channel read of channel 2 where I connected the light sensor to the Arduino. The inner rectangle only executes when the read value is false (i.e. when the light goes off) and while there’s a lot of information recorded here from elsewhere in the program basically if it sees the light go off it records the current ID being tested, the time that has elapsed since the test started. This means we know when it’s right!

Labview is designed to capture data from lab instruments and so there’s a really handy thing called the VISA toolkit that allows blocks of data read and write via the serial port and basically you can just open a port with specified settings then make read and write requests and do things like crop the incoming data at a predefined character. In this case that character needed to be CR (Carriage Return) this is ASCIIcharacter 13 because LAWCIEL terminates everything with one.

Labview Lynx2

For the USBtin we open the correct COM port at 115200,8 Data bits, No parity, 1 stop bit and no flow control. The other thing to note is at the top right, this sets the termination character to the numeric value of CR, the benefit here is you can perform a read of any length and it will automatically break up the data in the buffer so a single read can vary in length but the start will always synchronise  with the read call. Opening the connection in a terminal program for the first time and you’ll see nothing actually happens as such, an OK is signified by a CR so all you see is the cursor move. At this stage we are only connected to the USBtin, not the CANbus. So next, configure the CAN connection, send a value of “S6\r” . The code is S6, this will set the USBtin to 500kbit correct for the dash, the \r is how you indicate a CR in a Labview string. Next I chose to send “v\r” which requests the version from the USBtin, we don’t need this but it gives a solid confirmation it’s talking to us. Next up Z1\r tells the USBtin to timestamp the incoming data, I thought this might be useful but never actually implemented it.

Labview Lynx3

With the setup complete we can start reading data by opening the CAN connection by sending O\r. On a terminal program (assuming you have the CANbus wired up) doing this would result in packets of can data from the cluster appearing. The initial read of length 1 byte reads just the confirmation from the USBtin that it has received the open request. Next is the main read, it’s worth noting the read length is set at 50 bytes but this will be cut short by the termination character set earlier so we can accept varying length CAN data. C\r closes the CAN connection and again another read 1 byte clears the acknowledge. Tacked on the end is a section to read the controller status looking for error states etc. The keen eyed amongst you will notice the majority of this code is conditional, this is because the code needs to insert send requests among the stream of reads. This is because if the data is not read from the USBtin constantly a buffer somewhere fills (I imagine on the USBtin itself but can’t confirm this) and the port crashes. I spent a lot of time finding this out the hard way!

Labview Lynx4This is the write data code, again very similar but it just opens the port, writes whatever string is in the buffer and closes the connection. Once the connection is confirmed closed it resets the Boolean that causes the ‘write’ condition so on the next loop it goes back to reading again to keep the buffer clear. The read loop runs at the maximum possible speed but it is slowed down because it waits for either a termination character or 50 characters to be received before it completes and loops again.

Beyond that the only other bits of code just generate the data for the write buffer using an increment counter for the ID field and toggling between either 8 bytes of FFFF or 0000 every 100ms for 20 cycles and setting the write flag high to send the data..

So after letting this run for a fair while it started spitting out values, specifically the ID 300 for the power steering light. Wait a minute that wasn’t in the list earlier. Yes I know that, that’s where getting enough sleep comes in. Originally I split the data based on whether or not the PCM was fitted and ignored the ones that occurred in both sets, the obvious mistake here is that of course the power steering light isn’t controlled by the PCM, quite logically it’s controlled by the power steering controller!

So there we go, ID 300, the first byte (leading) controls the light, values below 80 turn the light off. Unplugging the PCM causes the controller to send 80 on loop hence the the warning light.

Get data from ID: 4B1
0	0	0	0	0	0	0	0	
Get data from ID: 81
43	6F	1	4B	
Get data from ID: 300
Get data from ID: 231
F	0	FF	FF	0	
Get data from ID: 430
95	5F	83	0	0	0	60	
Get data from ID: 81
25	6F	1	4B	
Get data from ID: 81
16	6F	1	4B	
Get data from ID: 630
8	0	0	0	0	0	6A	6A

Looking at the log data again we see that ID 300 is getting a value of 80 – this is during the self test before the engine is started. I previously tried sending this data on the original Arduino CAN setup and go no result so what did I do wrong. Again this is based on another assumption, I though the logger was ignoring high order bytes with zero value (ie this value if could be 00-00-00-00-00-00-00-80) well it turns out that was totally wrong, it actually ignores trailing zeros, the value of the can data here should be 80-00-00-00-00-00-00-00.

So while all these hours of work told me one thing I should have already known it’s actually worked out Ok because it highlighted this other problem (read ‘incorrect assumption’ !). This means The odds of me working out all the other data from the logs (that I’d previously written off as not usable) is actually much higher!



Subwoofer Project – Part 1, My First DIY Amplifier

This write up is largely just to set the scene for my later forays into audio projects which I will progress onto in later sections but it does ramble a bit!

Some time ago back when I was still a student I realised that most reasonably priced speaker systems consisted almost exclusively of a series of tiny satellite speakers and a main sub which was often comparatively overpowered in order to mask the inadequacies in the satellite speakers mid range. Now there are systems about which actually use pretty well performing satellites with a decent frequency range but these are usually quite expensive making them well beyond my reach as a student and still a bit lacking and so I started working out what I could do.

My first project was based around some amplifier kits I found at a local electronics store on offer so being student with little money I decided they would be a good place to start so I bought a pair of them to provide both left and right channels with the heady heights of 7W per channel! Shortly afterwards I went on eBay to find a cheap and reliable way to power them from the mains to make a self contained unit with minimal risk of death! I ended up buying a job lot of 5 transformers each rated at 12VAC at about 5A, or about four times what both amplifiers would use at peak output! But they were cheap and well insulated (much safer than cutting up a wall adapter and fitting it in the case). Some may ask why I didn’t just use a normal 12VDC wall adapter and just have the amplifier modules in a case – basically I hate the things but it was also because I wanted to be totally sure the power supply wasn’t the limiting factor!

Note : Since writing this post the company I bought the kits from (Maplin) has ceased trading and so the link above no longer works. The kit in question is Velleman K4001 7W Mono Amplifier details can be found here.

Going off on a tangent….

Now all this was going well except one thing, at the time I had virtually nothing in the way of tools I needed to build this apart from the soldering iron – an item my dad happened to see in a skip when a local college was upgrading their equipment back in probably the late 90’s and an item that has been used for every electronics project I’ve done ever since! If anyone is curious it’s actually one of these Xytronic XY9-60A  but it’s been branded as a Rapid Electronics unit and is orange rather than the blue shown.

These were about £100 new and my advice is if you know anyone who is starting to show an interest in soldering buy them something like this! There are plenty of even cheaper, decent soldering stations around now due to the greater number of people doing hobby electronics projects at home and it makes these projects considerably less frustrating!

One key thing for me was the temperature control which being an analog control on mine isn’t terribly precise but it’s still a huge improvement over very basic soldering irons and good enough for the vast majority of hobby projects. The second thing is the soldering tip is small and also interchangeable. A soldering iron that looks like a screwdriver isn’t terribly helpful in most cases because it makes even easy joints much harder to get access too. Back during the early 2000’s when the old Nokia phones were popular there was a brief craze of changing the tiny keypad and screen backlight LED’s out for different colours and I actually did several of these with a soldering tip I filed narrower for the purpose!

Now back to the point…

Having no tools I decided to buy something that would cover as many tasks for as little money as possible, so I bought a £20 fake Dremel and an aluminium enclosure and got to it! Some might describe what happened to that case as butchery but at the time I was using what I had. So the case looked a bit scruffy but it did the job! In the process of using the fake Dremel with an abrasive disk the disk shattered and one of the bits flew of and made a mark in my then virtually new monitor but by luck missed my face. Wear safety goggles – they really are worth it!

Taken from Reddit:

View post on imgur.com

I soldered up the kits as per the instructions and then soldered a diode rectifier and a capacitor onto the transformer output to produce DC (like this) and connected this to the two amplifier modules. I used a dual logarithmic potentiometer (variable resistor) for the volume control (one potentiometer wired to each amplifier). This is wired between the audio source and the amplifier input.

Potentiometer Wiring

A single pot usually has three legs, in the diagram the box represents the pot. The audio in+ and audio in- go to the two outer legs (doesn’t matter which way) with the audio to amp+ being taken from the middle leg. Audio in- and Audio to Amp- are both connected to the same leg.

It’s probably best to point out here while it doesn’t electrically matter which way round you wire the In+ and In- just make sure when doing a dual pot make both channels the same otherwise when you turn the pot one side will get louder as the other gets quieter and you have accidentally made a balance control!

Power came through a panel mounted IEC connector. If you can’t cut panel holes perfectly accurate then I recommend buying these as bolt in types, they normally need M3 countersunk bolts and then a matching nut on back but they offer a much greater tolerance than push fit ones and you wont pull them out! As a bonus they can also be fitted to any thickness of material with either long bolts or if you’re trying to mount into a decent thickness of wood even small screws in a sensible length can be used.

The finished product looked like this:

Basic Amp

It’s moved house with me maybe six times and has suffered a bit but it still works ten years on!

As a final note on this, this amplifier is as basic as it gets. The Velleman kits use a TDA2003 amplifier chip for all their functionality and the boards are basically just filtering capacitors for it. These are ok but the main limitation I found is at very low volume they seem to either limit the output power or the frequency response is terrible and all the bass on the audio drops away. As you turn it up the bass comes back which is a bit odd but in some ways actually ok when I was a student as it meant the low frequencies which tend to disturb people at night weren’t so prevalent! I never saw this as a major problem though.

Another point it’s worth considering because very few people actually appreciate it is that 7W per channel doesn’t sound much but it’s quite surprising what it can do – the volume control has lived at 25-30% for most of its life and with the source on maximum you will almost certainly go well above what most would consider a comfortable listening volume. Speakers are rated for sensitivity which is the sound level they generate per Watt of supplier power at 1m distance. The very cheapest speaker drivers should achieve 82db for 1W at 1m so for just 1W of input power we’re talking a sound level similar to a food blender! The issue is that the sound level vs power is not linear, doubling the sound level (+3db) actually requires four times as much power but we have 7W watts and that only takes us up to 4W but clearly another 3dB is beyond the limits of the amplifier but at 85dB we’re at the point where in the UK companies have to supply workers hearing protection. Better speakers can achieve sensitivities  of 90dB with 1W at 1m which puts at noise levels comparable to petrol lawnmowers using 4W of power! Higher power outputs amplifiers have their uses but the next time you hear about someones 1kW+ amplifier it’s worth being *very* dubious!

If you want to understand what this is all about I recommend reading http://sound.whsites.net/articles/pwr-vs-eff.htm  where Rod Elliot describes the concept of power vs sound level in much greater detail. It gets quite involved but will explain the limitations and realities!

Also for a bit of a laugh have a look at http://sound.whsites.net/project117.htm   where he describes what a 1.5kW amplifier would actually look like and involve. Rod is amazingly knowledgable and I have built some of his projects using his PCB’s and used them in my subwoofer project so these will appear in later sections.