Characterizing fuel injectors for use on MS3X engine management systems.

It’s been a while since I’ve made a post on the subject of engine management calibration. I don’t do “tuning” for a living anymore and the subject of cars in my life thankfully has gone back to just a hobby. That said, I once again enjoy learning something new when it comes to calibrating engine management systems. I’ve been spending a lot of time in the last few weeks with my 2JZGTE Powered Mustang studying the effects of injector characterization on the vehicle. Before getting too ahead of myself, however, I should introduce what this blog post is all about.

Injector characterization has become a popular topic in the amateur tuning communities lately and for good reason. The stability of an engine’s fuel calibration, from a control standpoint, weighs heavily on the injector flow rate and offset being correct. The goal of this blog post is to shed some light on how to collect data from your own injectors to develop operating characteristics for your application. This blog is aimed primarily towards MS3X users, however, a lot of the information in this blog is universal. Due to the differences in electrical injector drivers used between different manufacturer’s ECU’s, the operating characteristics developed in this blog may vastly differ if using an engine controller other than MS3X.

Before explaining how to collect data to determine the operating characteristics of a fuel injector we must know how the ECU uses this information to meter fuel to the engine. If you’re reading this blog it’s likely you’re already familiar with how fuel injectors are sized. Most commonly we’ll define the flow rate of an injector by how much fuel it delivers over a period of time, in cubic centimeters per minute or pounds per hour. In this blog we’ll use CC/min as our preferred measurement. Knowing how much the injector flows over time is what allows us to precisely meter fuel into the engine. The longer the fuel injector is energized, the more fuel it delivers. We expect this flow rate to be linear, so if we know a fuel injector flows 440cc/min it should flow 220cc in 30 seconds, 110cc in 15 seconds and so on. Since we’re dealing with pulse-widths only in the millisecond range our delivered quantity is actually much smaller, but we still expect the flow to be linear as we increase or decrease the injector pulse-width.  MegaSquirt defines injector flow rate with a global modifier called Required Fuel. The definition of Required Fuel is the effective pulse -width required to create a stoichiometric mixture at 100% volumetric efficiency. There is a handy calculator provided in software that will calculate the Required Fuel pulse-width based on engine displacement, fuel injector flow, number of injectors, and the stoichiometric air/fuel ratio of the fuel being used. The more accurate the information entered into the calculator, the more accurate you can define the flow rate of the injector to the ECU. Once the ECU knows how much fuel the injector flows at 100% VE, for any higher or lower VE value the ECU will just correct the pulse-width based on the difference in VE percentage and whatever other modifiers are applied to the fueling equation.  We should be good to go, right? Not so fast.

If you paid attention to the definition of Required Fuel in the last paragraph, you’ll notice it’s the effective pulse-width required to create a stoichiometric mixture at 100% volumetric efficiency. Since Required Fuel defines the flow rate of the injector, all fueling calculations made by the ecu are calculated as effective pulse-widths. The effective pulse-width is a theoretical value that assumes the injector flows from exactly the time it’s commanded to open to the time it’s commanded to close. In reality it doesn’t work this way. There is a delay from the time we energize the fuel injector to the time it delivers fuel. There is also a delay from the time the injector is de-energized to the time it stops delivering fuel. These two delays combined are called the injector offset, or in MegaSquirt terms Injector dead-time. In this blog, however, we’ll use the term offset as it more accurately defines the operating characteristic. As an example, if we have a Required Fuel pulse-width of 7.5ms and did not apply any injector offset, we’d likely have a leaner than stoichiometric mixture at 100% VE because we haven’t accounted for the the time it takes for the injector to begin and end flow. In that 7.5ms the injector was energized it may have only been delivering fuel for 6.5ms. In this case, there is an offset of 1ms that needs to be accounted for. By telling the ECU the injector has a 1ms offset, the ecu will then add the offset to the effective pulse-width, in this case the Required Fuel pulse-width of 7.5ms and the offset of 1ms for a commanded pulse-width of 8.5ms. The fuel injector is energized for 8.5ms, delivering fuel for 7.5ms of that time, and we now have a stoichiometric mixture. The offset of an injector is not a single, constant number. Injector offset is influenced mainly by the voltage delivered to the fuel injector. Generally speaking, injector offset increases as voltage decreases and the change in offset is exponential as voltage increases or decreases.

As important as injector offset is to maintaining a consistent calibration, it’s one of those values that are seldom calibrated for the application. Until recently, injector offset data wasn’t offered by injector manufacturers and determining accurately the offset of a specific injector seemed like black magic. Injector offset changes with fuel pressure, the electronics driving the injector, and manifold pressure. Because all of these variables have some amount of effect on the offset of the injector, most manufacturers left it up to the end user to determine the operating characteristics for their exact application. And it’s still like this today. Recently I made a post on Turbobricks.com  demonstrating that an OEM fuel injector with operating characteristics taken directly from the OEM ECU varied by a considerable degree when that same injector was placed on a different ECU and engine. Because of this, even with supplied injector data, I encourage the end user to determine the operating characteristics for their exact application.

So how do we determine the operating characteristics of a fuel injector? It’s quite simple. We measure the volume of fuel delivered by the injector over the linear operating range. Wait. Linear operating range? When plotting fuel injector flow, there is a point at very low pulse-width values were the injector flow will become non linear. The point this happens on a high quality fuel injector is very low, usually below 2ms. Because the injector flow becomes non linear, it’s very hard to control the injector and we usually want to avoid operating the injector below the linear operating range. By graphing the injector flow across its linear operating range, not only can we determine exactly what the fuel injector flow rate is, but we can also determine the offset by where the linear regression intersects the X axis.

Since I want to determine the operating characteristics of the injectors used on my 2JZ, I set up a test bench on the car to collect all of the data required. Using a high current variable power supply, I isolated the car’s electrical system from the battery so the ECU and injectors were run directly off the power supply. This allowed me to operate the injectors from 10.5v to 14.2v and get an understanding of how voltage affected offset. The battery was still wired to the fuel pump with a high current battery charger to keep the battery topped off. By running the fuel pump off the battery I avoided such a large current draw on the power supply running the ecu and injectors, keeping a very stable voltage to the injectors. I removed the fuel rail from the intake manifold and set one of the injectors in a graduated cylinder to measure volume of fuel delivered. Using the MS3X ECU in test mode, I was able to control the fuel pump and how the injectors delivered fuel to the graduated cylinder.

To collect data on the operating characteristics of the injector I was testing, I first determined the operating voltages I wanted to collect data. Since my power supply went as low as 10.5v and as high as 14.2v, I decided to collect enough data to determine offset at 10.5v, 12v, 13v, and 14.2v. I started by collecting data at 10.5v. Next, I need to determine the operating range I want to collect data for. The injectors in this application run as low as 1.5ms and as high as 20ms, so I’ll collect data from 1ms to 20ms in 1ms increments. Then I needed to determine how many times I’m going to fire the injector at each increment to collect data on volume delivered. To decide this, I fire the injector at 20ms and adjust the number of injections until the test approaches the limit of the reading of the graduated cylinder. This will provide a better average for the injector flow rate. In the case of the factory injectors, 1200 injections per sample was sufficient. I also need to set fuel pressure to my operating pressure, in this case 43 psi. I haven’t determined if interval has a huge effect on data collection, I set mine to 30ms which is equivalent to about 4000rpm when operating.

IMG_1975

The injector test bench set up on the car, about as sloppy as you can get.

It goes without saying that doing it this way is very dangerous, because you’re dealing with gasoline. Just don’t do it, you’ll burn yourself to death.

I started the test by sampling the volume delivered at 1ms commanded pulse-width, 1200 injections at 10.5v. No fuel was delivered so I moved on to 2ms commanded pulsewidth. 9cc of fuel delivered from 1200 pulses at 2ms commanded pulsewidth. I kept doing this in 1ms increments at 10.5v until I had volume delivered from 1ms all the way to 20ms. Then the test was performed all over again from 1ms to 20ms at 12v, 13v, and 14,2v. If you plan on doing this, plan on taking quite a few hours to collect all of your data.

To show an example of the entire operating range, here are the results from the data collected at 14.2v:

14.2v flow 2JZ440cc blog

2JZGTE 440cc operating characteristics: 43psi fuel pressure 14.2v

There are some slight discrepancies as to how linear the flow is at higher pusle-widths. I’ve found in my testing high mileage injectors lose their ability to flow in a precisely linear fashion. These injectors have a bit over 200k miles on them. Aside from that, you can note below 2ms on the graph where the injector no longer operates in the linear range with the rest of the injector. To plot a linear regression, it’s wise to reject this data from the graph since it’s not in the operating range of the injector. Looking over the data, it appears the injector operates linearly from 2ms to 20ms, so we’ll graph just that data and apply a linear regression with formula:

14.2v flow 2JZ440cc linear blog

2JZGTE 440cc fuel injector linear operating range with linear regression and formula to determine x intercept.

Rounded down, the function of the linear operating range of this injector is defined by the following equation: f(x)=9.3316x-3.7526. You can either determine the X-intercept directly from that formula, or enter the formula into a graphing calculator and verify the data in both graphs match. The X-intercept of the line is 0.402ms, and this is the offset of a stock 2JZGTE 440cc fuel injector at 14.2v and 43psi. This data was collected at 10.5v, 12v, and 13v to arrive at the following offsets for this injector:

10.5v – 0.892ms
12v- 0.692ms
13v – 0.516ms
14v – 0.402ms

Dynamic flow rate can also be calculated from that data collected in these graphs. Referring to the graph above, the dynamic flow rate at 20ms can be determined by doing the following:

  • Determine the effective pulse-width by subtracting offset from the commanded pulse-width: 20ms-.402ms=19.598ms.
  • Determine how much fuel was delivered in one single pulse. Since we measured the volume of 1200 pulses we divide the volume by the pulses: 184cc/1200=0.1533cc per pulse.
  • There are 1000ms in one second, how many times does our effective pulse-width occur in one second? 1000/19.598=51.026 times.
  • How much volume of fuel is delivered if we add all of the effective pulses into one second? 51.026*0.1533cc=7.822cc per second.
  • Multiply by 60 to get CC/min 7.822*60=469.32cc/min dynamic flow at 43 psi.

After a few hours of collecting data I now know the injector offset values at 10.5v, 12v, 13v, and 14.2v. I also now know the dynamic flow rate at my operating pressure as a more accurate figure to apply to the Required Fuel calculator. BUT! MegaSquirt speaks in terms of percentage for defining injector offset. How do we do this?

MS3X wants an offset number that represents 100%. 13v is a nice place to put this number so we’ll call 0.516ms 100%. Now it’s as simple as calculating percentage difference for every other offset value:

10.5v – 0.892ms – 173%
12v- 0.692ms –  134%
13v – 0.516ms – 100%
14v – 0.402ms – 78%

Since the engine doesn’t operate outside of these ranges unless something is wrong, it should be OK to interpolate the shape of the curve to higher and lower voltage values.

Once I get done upgrading the secondary injectors I can apply this data to the ECU and start collecting data on the effects it has with the calibration. Stay tuned.

Posted in Cars | Comments Off

Arduino based AW30-40 / AW4 transmission control. Part 1: Figuring it all out.

It’s been a few months since I’ve had a good Arduino project to play with. Some of you may be wondering about my last writings on the Spa controller and wonder why I haven’t completed that project and have moved on to this one. Well, that project is complete and working quite well. I tend to focus on completing projects without documenting the results towards the end of the project. Suppose I can document the conclusion of that project at a later time.

The idea of this project came about recently when thinking of ways to address the limitations of the transmission control in my 1994 Jeep Cherokee. In the past I’ve used the Megasquirt GPIO board using MShift firmware control my projects involving electronically controlled transmissions. Given the simplicity of the Aisin Warner AW30-40 transmissions (called the AW4 on the Jeep) I figured it would be a good project for an Arduino.

The purpose of this project is much like the spa controller. Exercise my ability to design a control system from the ground up. This includes coming up with the circuits to interface the various I/O to the Arduino itself, write the code for a functional control system, lay out a PCB that will drop into the factory control case, and document what I’ve found in an attempt to help others. There are certain aspects about the factory controls I’d like to change to suit my application. One of these is leaving the converter locked under more driving conditions than just freeway driving. Another change I’d like to make is the ability to manually select what gear the transmission is in. In my model Jeep there is no way to manually select between first and second gear. You may only command the transmission the highest gear it can go, but gear selection is still up to the controller.

First, we need to understand how the factory control system works. Given my past experience with aftermarket control systems on these exact transmissions, I have a pretty firm grasp on how they work. However, each manufacturer has little differences on how they control the transmission, and what is controlled, so it’s best to understand first how Jeep does it on their vehicle. The subject of study in this case is my 1994 Jeep Cherokee XJ with an AW4 transmission.

The best way to understand how the factory control system works is by looking over the factory service manual at the wiring diagrams and connector pin outs to understand what is being used to control the transmission, and what can be controlled:

xjtranscont1

Transmission Controls showing inputs and outputs.

xjtranscont2

Transmission Controls showing inputs and outputs

xjtranscont3

1994 Jeep Cherokee XJ AW4 transmission control pinout

The transmission controller connector pinout basically summarizes what’s all involved in the control system in this application. There are two pins on this controller that are not relevant to a DIY control system: Pin C4 (data link connector) was used for proprietary mopar diagnostic tools and is not needed for a DIY controller. We’ll make our own diagnostics in the new controller. Pin C11 (trans switch power mode) according to the factory service manual (not pictured) this wire does not connect to anything on a XJ Cherokee. I’ll look into this specific function a bit later.

We’re left with the I/O involved in controlling this transmission:

  • Pin C3 – Trans output speed sensor. This input tells the controller how fast the transmission output shaft is turning. In addition to detecting engine load, the controller decides when to shift into a higher or lower gear based on the output shaft speed. This input is pulled up to 5V by the controller and the speed sensor grounds the input to produce a 0-5v square wave. Frequency of the square wave increases with output shaft speed.
  • Pin C8 – 1-2 gear input. 12v applied to this input indicates to the controller that the gear selector is in the 1-2 position.
  • Pin C9 – Drive gear input. 12v applied to this input indicates to the controller that the gear selector is in the D positon.
  • Pin C10 – Stop lamp switch sense. 12v applied to this input indicates to the controller that the brake pedal is depressed. This is usually used to unlock the torque converter when the vehicle is being slowed down.
  • Pin C14 – Solenoid S3 control. This output controls the torque converter lockup solenoid. The controller applies 12v at this output to lock the torque converter clutch.
  • Pin C15 – Solenoid S2 control. This output controls the number two shift solenoid. The controller applies 12V at this output to energize the #2 shift solenoid.
  • Pin C16 – Solenoid S1 control. This output controls the number one shift solenoid. The controller applies 12V at this output to energize the #1 shift solenoid.
  • Pin D2 – Throttle position sensor signal. This input receives the 0-5v TPS signal from the engine control harness. This is used for load sensing.
  • Pin D3 – Sensor ground. This is an isolated ground for the sensors. This is shared with the engine control sensor ground.
  • Pin D7 – Ground. This is a chassis ground.
  • Pin D14 – Battery positive. This input isn’t necessary in this project. It may be omitted.
  • Pin D16 – Ignition switched positive.

In addition to the factory controls, I’d like to add the following I/O to my project:

  • Transmission temperature input
  • Up/down shift paddle inputs
  • Manual/auto mode
  • Serial comms for a status display
  • Tachometer input for WOT shifting (shifts at a set RPM point per gear rather than output shaft speed)

Looking at the connector pinout above, there are quite a few unused pins on the trans controller connector. Since the controller I’m designing is meant to be a drop-in replacement for the factory controller, it would be sensible to obtain some pins to populate the unused pins on the controller connector for the added I/O. Not all unused pins on the connector are available, however. Taking a closer look at the factory controller PCB reveals some pins are common with pins currently in use. We’ll visit this later when we get to the PCB design phase.

 

IMG_0820

Top view of factory controller PCB

IMG_0821

Bottom view of factory controller PCB showing some pins being common with others.

Now that we have a fairly good idea what’s involved in making the factory control system function we need to make sure a standard arduino board can handle the I/O.

There are nine digital inputs:

  1. Brake pedal switch
  2. VSS
  3. Drive gear input
  4. 1-2 gear input
  5. Paddle shift up
  6. Paddle shift down
  7. Manual / Auto switch
  8. Engine RPM
  9. Serial Rx

There are Four digital outputs:

  1. Shift solenoid 1
  2. Shift solenoid 2
  3. Torque converter control solenoid
  4. Serial Tx

There are two analog inputs:

  1. TPS signal
  2. Trans temp

That gives us a total of 13 digital I/O pins, and two Analog input pins. My Arduino board of choice, the Arduino Pro Mini has 14 digital I/O pins and 8 analog input pins. Plenty for this project.

Next up: Circuit design and component selection for all of the I/O

Posted in Arduino Based Transmission Controller, Projects | Comments Off

Arduino Based Spa Controller part 4: Working temperature control

A lot has happened since the last post. First and foremost I’m happy to report that the Arduino has been controlling the temperature on my hot tub for the last few weeks. I decided it was time to clean the tub, fill it up, and start prototyping. The temperature control at first was incredibly basic, using only the few lines of code in the example I posted in part 3. This was done under strict supervision during the initial tests. There were no safeties in either hardware or software which meant that any minor failure could result in the heater running away and causing a meltdown. Once I knew the SSR worked well with the tub heater and thermal control worked as it should, it was time to develop the hardware and firmware. But, lets start where we left off.

The first big change is the display screen. I switched from SparkFun’s basic serial LCD to an OSEPP parallel LCD with an integrated keypad. The new LCD shield not only tidied up the prototyping platform, but it also gave me the ability to develop the user interface end of the controls as well with the keypad. While this shield took up a bit of my available digital I/O and one of the ADC inputs, it still left me with enough I/O for tub functions without having to make any sacrifices. With the new display shield I had to purchase another proto shield with stackable headers to accommodate the control circuits. SparkFun’s proto shield did just the trick in this case.

 

The new OSEPP LCD display shield with integrated keypad.

 

Before soldering a bunch of hardware onto the proto shield I sat down and thought about the hardware end of the controls. Heater runaway is a serious issue to both people and property so I felt it was essential to have both hardware and firmware redundancy when it came to safety. In addition to the two temperature sensors the tub also has a pressure switch in the heater pipe that detects the flow of water through the heater. Later on down the road when I start developing the motor control end of the project I can also use this sensor to detect pump failure. In order for the Arduino to turn the heater on, the following conditions must be met in the firmware:

  • Tub temperature is under target temperature
  • Heater temperature does not exceed the maximum threshold of 106 degrees
  • The pressure switch is closed, indicating water flow through the heater.

In the event of a processor failure where the heater control line is left closed, I had integrated similar logic into the hardware. One of the changes I made to the new prototype is buffered thermistor inputs. By using OP amps to buffer the sensor input, I provide a layer of stability to the sensor reading by making the input impedance constant. This allows me to also drive more than one circuit with the thermistor without experiencing any sort of differential reading. The buffered tub temperature reports directly to the Arduino and is only used in the temp control loop. The heater temperature sensor is used in all saftey shutdowns. In addition to the firmware safeties, A three circuit AND gate provides a hardware layer of protection in the event of a failure. The AND gate drive the SSR for the heater. In order for the gate’s output to be true and high, the following inputs must be high:

  • Heater control pin on the Arduino
  • Overtemp comparator (goes low if heater temp >= 106 degrees)
  • Pressure switch is closed, indicating water flow through heater.

Any one of those inputs that goes low as a result of command or failure will open the SSR and shutoff the heater, independently of the processor.

 

Assembled prototype board woth op amps and logic gates

 

Current working stack of shields. Arduino, proto shield, LCD shield.

 

Posted below is the schematic of the current temp control prototype with integrated hardware safety. The comparator is a basic op amp circuit. The inverting input is a basic voltage divider with precision tolerance resistors that simulate the thermistor circuit at 106 degrees. The circuit currently does not have any hardware hysteresis and exists primarily as a last line of defense in the event of a heater over temp. All of the inputs on the AND gate are pulled low. CMOS gates act much like MOSFET’s in that input capacitance will cause the gate to remained charged if the input floats. This could potentially lead to a false output at the gate and allow the SSR to remain energized. This is a BAD scenario, so all inputs are pulled low with 10k resistors to prevent inadvertent gate charging. In addition to overtemp shutdown, the firmware and hardware will shut the heater off if the pressure switch opens as a result of loss of flow through the heater. The controller considers this an emergency situation and will shut the entire control system down and display the error on the screen.

 

Basic thermistor / pump pressure input schematics with safety hardware.

 

Water flow error screen

 

Normal working controls.

On the next revision of the hardware I plan to integrate a little bit of noise filtering on all of the sensor inputs. I may also plan to integrate a bit of hysteresis into the over temp comparator, however, in testing I haven’t found that necessary.

On the firmware side of things there were quite a few changes made to the display code since the new display is driven in parallel instead of a serial display like the last prototype. The keypad on the new display shield takes up only one analog input and uses different values of resistance to identify to the processor which button is being pushed. The up and down buttons on the keypad were written to change the target temperature of the tub. In the future the other buttons will handle the lights and jets.

After a quick bench test of the new heater control circuits and corresponding firmware, the prototype is back on the tub to make sure everything works in practice before moving on to pump and light control.

Here is the current code with integrated safeties. Firmware safeties should not be used without hardware safeties in the event of a processor hang up or failure. Little bits and pieces of light control and pump control code are floating around in there as well.

//NSFabrication.com SPA controller Beta 2, temperature control
//Designed as a generic replacement for Balboa based controllers
//Provides hysteresis thermostatic control of pool heater with heater overtemp and no water flow shutdown
//OSEPP LCD Keypad control
//Use AND gate control board for hardware redundancy 

#include <math.h> //Library to calculate Steinhart-Hart equation 
#include <LiquidCrystal.h>
LiquidCrystal lcd(8, 9, 4, 5, 6, 7);

int temp1 = 0; //Sets temp1 to zero
int temp2 = 0; //Sets temp2 to zero
int temp2raw = 0; //Sets raw temp2 to zero
const int heaterpin = 11; //Heater SSR on pin 11
//int heaterstatus = LOW; //Initial heater status. LOW = OFF
int tgttemp = 100; //Target pool temperature 
int jetflag = 0; //Jet status flag
//int jetstatus = LOW; //Jet output state
int jetpin = 12; // Pump high speed output on pin 12
int pumpflag = 0; // Pump status flag
//int pumpstatus = LOW; // Pump output state
int pumppin = 13; // Pump relay output pin
const int pressuresw = A3; //Pressure switch on Analog 3
int psw = 0; //Pressure switch digital flag
int lightpin = 2; // Light control on pin 2
int lightflag = 1; // Light status flag

// define some values used by the panel and buttons
int lcd_key     = 0;
int adc_key_in  = 0;
#define btnRIGHT  0
#define btnUP     1
#define btnDOWN   2
#define btnLEFT   3
#define btnSELECT 4
#define btnNONE   5

// read the buttons
int read_LCD_buttons()
{
 adc_key_in = analogRead(0);      // read the value from the sensor
 // my buttons when read are centered at these valies: 0, 144, 329, 504, 741
 // we add approx 50 to those values and check to see if we are close
 if (adc_key_in > 1000) return btnNONE; // We make this the 1st option for speed reasons since it will be the most likely result
 if (adc_key_in < 50)   return btnRIGHT; 
 if (adc_key_in < 195)  return btnUP;
 if (adc_key_in < 380)  return btnDOWN;
 if (adc_key_in < 555)  return btnLEFT;
 if (adc_key_in < 790)  return btnSELECT;  
 return btnNONE;  // when all others fail, return this...
}

const int numReadings1 = 100; //Averaging for temp1
int readings1[numReadings1];
int index1 = 0;
int total1 = 0;
int average1 = 0;

double Thermistor1(int A1) { //Steinhart-Hart equation for temp1
  double Temp1;
  Temp1 = log(10000.0 / (1024.0 / A1 - 1));
  Temp1 = 1 / (0.000904790 + (0.00022575 + (0.00000011138 * Temp1 * Temp1 )) * Temp1 );
  Temp1 = Temp1 - 273.15;
  Temp1 = (Temp1 * 9.0) / 5.0 + 32.0;
  return Temp1;
} 

const int numReadings2 = 100; //Averaging for temp2
int readings2[numReadings2];
int index2 = 0;
int total2 = 0;
int average2 = 0;

double Thermistor2(int A2) { //Steinhart-Hart equaition for temp2
  double Temp2;
  Temp2 = log(10000.0 / (1024.0 / A2 - 1));
  Temp2 = 1 / (0.000904790 + (0.00022575 + (0.00000011138 * Temp2 * Temp2 )) * Temp2 );
  Temp2 = Temp2 - 273.15;
  Temp2 = (Temp2 * 9.0) / 5.0 + 32.0;
  return Temp2;
}


void setup()
{
  //Serial.begin(9600);
  
  pinMode(heaterpin, OUTPUT); //Defines heaterpin as an output on the Arduino
  pinMode(pressuresw, INPUT);
  
  digitalWrite (heaterpin, LOW); //Ensures heater is off until commanded on
  
  for (int thisReading1 = 0; thisReading1 < numReadings1; thisReading1++)
    readings1[thisReading1] = 0; //Averaging equation for temp1

  for (int thisReading2 = 0; thisReading2 < numReadings2; thisReading2++)
    readings2[thisReading2] = 0; //Averaging equation for temp2

lcd.begin(16, 2);              //Splash screen on boot
lcd.setCursor(0,0);
lcd.print("NSFabrication"); 
lcd.setCursor(0,1);
lcd.print("SPA Control B2");
delay(2000);
lcd.clear();
}

void loop()
{
  total1 = total1 - readings1[index1]; //Averaging equation for temp1. This filters and smooths the input. 
  readings1[index1] = int(Thermistor1(analogRead(A1)));
  total1 = total1 + readings1[index1];
  index1 = index1 + 1;
  if (index1 >= numReadings1)
    index1 = 0;
  average1 = total1 / numReadings1;

  total2 = total2 - readings2[index2]; //Averaging equation for temp2. This filters and smooths the input
  readings2[index2] = int(Thermistor2(analogRead(A2)));
  total2 = total2 + readings2[index2];
  index2 = index2 + 1;
  if (index2 >= numReadings2)
    index2 = 0;
  average2 = total2 / numReadings2;

temp2raw = analogRead (A2); 
//Serial.print (temp2raw);
while (temp2raw > 880) // Low water temp or no heater sensor shutdown BROKEN
 {  
    digitalWrite (heaterpin, LOW);
    lcd.clear();
    lcd.setCursor(0,0);
    lcd.print ("ERROR!!!");
    lcd.setCursor(0,1);
    lcd.print ("Water Temp LOW");
    if (analogRead (A2) < 880)
    {
      break;
    }
    delay (1000);
  }    

psw = digitalRead(pressuresw); //No water flow shutdown 
while (psw == LOW)
  {
    digitalWrite (heaterpin, LOW);
    lcd.clear();
    lcd.setCursor(0,0);
    lcd.print ("ERROR!!!");
    lcd.setCursor(0,1);
    lcd.print ("No water flow");
    psw = digitalRead(pressuresw);
    delay (500);
    lcd.clear();
  }
  
lcd.setCursor(0,0);
lcd.print("Temp:");
lcd.setCursor(5,0);
lcd.print(average1); //Display temp1
if (average1 < 100)
{
lcd.setCursor(7,0);
lcd.print(" ");
}

lcd.setCursor(0,1);
lcd.print("Htr:");
lcd.setCursor(4,1);
lcd.print(average2); //Display heater temp
if (average2 < 100)
{
lcd.setCursor(6,1);
lcd.print(" ");
}

lcd.setCursor(9,0);
lcd.print("SET:");
lcd.setCursor(13,0);
lcd.print(tgttemp); //Display target temperature
if (tgttemp < 100)
{
lcd.setCursor(15,0);
lcd.print(" ");
} 
  
 while (average2 > 106) //Heater overtemp shutdown and error display
  {
    digitalWrite (heaterpin, LOW);
    lcd.clear();
    lcd.setCursor(0,0);
    lcd.print ("ERROR!!!");
    lcd.setCursor(0,1);
    lcd.print ("HEATER OVERTEMP");
    delay(1000);
  }
    
  if (tgttemp > average1) //Simple hysteresis control loop. If temp is below target temp, turn heater on. Otherwise, off. 
  { 
  digitalWrite (heaterpin, HIGH) ;
  lcd.setCursor (15,1);
  lcd.write ("H");
  }
  else
  { 
  digitalWrite (heaterpin, LOW);
  lcd.setCursor (15,1);
  lcd.write (" ");
  }
  
  
  if (jetflag == 1)
  {
    digitalWrite (jetpin, HIGH);
  }
  if (jetflag == 0)
  {
    digitalWrite (jetpin, LOW);
  }
  
lcd_key = read_LCD_buttons();

switch (lcd_key)               // depending on which button was pushed, we perform an action
 {
   case btnRIGHT:
     {
     if (jetflag == 1)
     {
       jetflag = 0;
       lcd.setCursor (9,1);
       lcd.print ("    ");
       delay(1000);
     }
     else
     {
       jetflag = 1;
       lcd.setCursor (9,1);
       lcd.print ("Jets");
       delay (1000);
     }
     break;
     }
   case btnLEFT:
     {
     //reserved for light on/off 
     break;
     }
   case btnUP:
     {
       if (tgttemp < 104)
     {
       ++tgttemp;
       delay(1000);
     }
     break;
     }
   case btnDOWN:
     {
     if (tgttemp > 90)
     {
       --tgttemp;
       delay(1000);
     }
     break;
     }
   case btnSELECT:
     {
     lcd.print("SELECT");
     break;
     }
     case btnNONE:
     {
     // do nothing
     break;
     }
 }

}

Posted in Arduino Based Spa Controller | Comments Off

Arduino Based Spa Controller part 3: Barebones tempurature control

I always preface blog posts when my electronics speak to the world for the first time:

  

Now that I have an understanding of the previous Spa controllers functions it’s time to start prototyping hardware and firmware on my controller. The first part of the control system I’m going to work on is the tub temperature control. For now it’s just hardware development. Once the hardware is in place I can work on the code later to suit the controllers functions.

I’ve gone back and fourth on what kind of control loop I wanted to use for thermal control. A vast majority of factory spa controllers use a simple hysteresis loop, much like a thermostat, and it works just fine. With the proper hardware I could implement a more complex PWM control that precisely maintains tub temp. For the time being, however, I think a bare bones hysteresis loop will work fine for proving the hardware.

First I have to make the thermistors work with the Arduino. Since there isn’t any input on the Arduino that measures resistance I must come up with a circuit that allows the Arduino to read the temperature sensors. A simple voltage divder will work. Grounding one leg of the thermistor and pulling the other leg up to +5v will allow the Arduino to measure voltage change as resistance to ground (thermistor) changes. In the event of a sensor failure this will also pull the input up to +5v. Since that range of the sensor is invalid, I could write a little bit of code that will shut down the controller in the presence of a sensor fault. I’ll save the sensor fault code for another time, however.

Now comes the fun part. The resistance curve as temperature changes across the thermistor is non-linear. It’s not as simple as calculating a slope-intercept to obtain the temperature of the sensor. Math was never my strong suit so I wasn’t looking forward to going back to my math books to figure out the formula of an exponential curve. Then I remembered a while back, in one of the MegaSquirt documents (long before MS was mainstream) there was mention of a formula that essentially defined (almost) all thermistor curves: the Steinhart-Hart equation. A quick Google search revealed numerous coefficient calculators for Steinhart-Hart equations. I used this one here to find the coefficients based on the information I obtained in part 2 of this blog on the temperature Vs. resistance curve. Once I found the coefficients I was able to write a Steinhart-Hart equation into the Arduino and verify they’re proper.

Instead of posting bits of the code all over the control system as an example, I’ll just post the entire code where I’m at currently at the end of this blog.

Instead of writing the code for the Steinhart-Hart equation from scratch I decided to take a look over at the Arduino forums to see if anyone posted any examples. There were a few examples I found that ranged from simple to complex. I chose to use the simples code I could find. I entered the coefficients found using the calculator previously mentioned, and the pull-up resistor value (10k), wrote a bit of code for my 16×2 LCD display and checked the values against a thermometer. Much to my amazement, the measured and displayed values were dead on. I was now reading temperature from both the tub temp sensor and heater temp sensor through the Arduino!

Temperature being displayed after writing Steinhart-Hart formula.

Temperature being displayed after writing Steinhart-Hart formula.

For the time being Temp1 is the tub temp sensor and Temp2 is the heater temp sensor. Just displaying the raw values calculated directly from the formula I found the display to wander between one degree quite quickly. This makes for a messy display and could cause trouble in a hysteresis loop. In a previous Arduino project making a closed loop boost controller I had found a simple equation in the Arduino forums for filtering and smoothing an analog input. I decided to use that in this project as well. Hardware filtering can be used as well, but I prefer to have the luxury of doing it in software.

Now that the temperature input is working properly it’s time to make the output. I’m more concerned about hardware at this point than software so I figured I’d make the worlds easiest hysteresis loop. If the temp is below 104 heater is on, else the heater is off. Simple as that.

I picked up a solid state relay from a local electronics supplier today to expedite the development of this project. I’ll be using contactors for the motor control, but the heater control I decided to use a solid state relay. Initially I was under the assumption that all solid state relays were capable of pulse width modulation. However, upon further research I found that most of the cheap ones such as the ones used for controlling heaters in home brewing don’t play so well with PWM. The lower end solid state relays use triacs to switch AC current. When a triac is latched it remains latched until the cycle it’s switching passes zero, then unlatches. This means you’d effectively have to implement a zero crossing detector to know when to turn the relay on and off. More expensive solid state relays that are rated for “random switching” are capable of being switched anywhere in the cycle and are more appropriate for PWM control of AC devices. Hey, as long as a simple hysteresis loop gets the job done I’m happy.

The cluster f*%^ on the kitchen table that is the temperature control prototype.

What you see above is the working prototype for the temp control. The heater temp sensor for now is just an ambient temperature sensor. The pool temp sensor is placed in a crock pot full of water. The crock pot, set on high is controlled by the Arduino through the solid state relay. With a target temp of 104 degrees the Arduino energizes the solid state relay to heat the crock pot. When the water in the crock pot comes to temp at 104 degrees the heater is turned off an remains off until the temperature goes below 104 degrees where it will again energize the relay and heater. Basic functionality at its finest. The most complex part of the project was interfacing the thermistors with the Arduino in a fashion that read accurately.

Perhaps one of these free weekends I have in the near future I can tidy up the protoboard and somehow implement the heater control into the spa for a trial run, to dial in the control strategy.

For now, here’s the code I’ve come up with. No safety features, just bare bones temperature control.

//NSFabrication.com SPA controller Beta 1, temperature control
//Designed as a generic replacement for Balboa based controllers
//Provides hysteresis thermostatic control of pool heater with no saftey shutdown

#include <math.h> //Library to calculate Steinhart-Hart equation 

int temp1 = 0; //Sets temp1 to zero
int temp2 = 0; //Sets temp2 to zero
const int heaterpin = 10; //Heater SSR on pin 10
int heaterstatus = LOW; //Initial heater status. LOW = OFF
int tgttemp = 104; //Target pool temperature 

const int numReadings1 = 100; //Averaging for temp1
int readings1[numReadings1];
int index1 = 0;
int total1 = 0;
int average1 = 0;

double Thermistor1(int A0) { //Steinhart-Hart equation for temp1
  double Temp1;
  Temp1 = log(10000.0 / (1024.0 / A0 - 1));
  Temp1 = 1 / (0.000904790 + (0.00022575 + (0.00000011138 * Temp1 * Temp1 )) * Temp1 );
  Temp1 = Temp1 - 273.15;
  Temp1 = (Temp1 * 9.0) / 5.0 + 32.0;
  return Temp1;
} 

const int numReadings2 = 100; //Averaging for temp2
int readings2[numReadings2];
int index2 = 0;
int total2 = 0;
int average2 = 0;

double Thermistor2(int A1) { //Steinhart-Hart equaition for temp2
  double Temp2;
  Temp2 = log(10000.0 / (1024.0 / A1 - 1));
  Temp2 = 1 / (0.000904790 + (0.00022575 + (0.00000011138 * Temp2 * Temp2 )) * Temp2 );
  Temp2 = Temp2 - 273.15;
  Temp2 = (Temp2 * 9.0) / 5.0 + 32.0;
  return Temp2;
}


void setup()
{
  pinMode(heaterpin, OUTPUT); //Defines heaterpin as an output on the Arduino
  digitalWrite (heaterpin, LOW); //Ensures heater is off until commanded on
  
  for (int thisReading1 = 0; thisReading1 < numReadings1; thisReading1++)
    readings1[thisReading1] = 0; //Averaging equation for temp1

  for (int thisReading2 = 0; thisReading2 < numReadings2; thisReading2++)
    readings2[thisReading2] = 0; //Averaging equation for temp2

  Serial.begin(9600); //Beginning of serial stream. There may be a cleaner way to write all of this code. 
  Serial.write(254);
  Serial.write(01); // Clear display
  Serial.write(254);
  Serial.write(128);
  Serial.print("NSFab'd");
  Serial.write(254);
  Serial.write(194);
  Serial.print("SPA Controller");
  delay (2000); //Delay splah screen. No delay in firmware, diagnostics will be performed during splash screen
  Serial.write(254);
  Serial.write(01);
  Serial.write(254);
  Serial.write(01);
  Serial.write(254);
  Serial.write(128);
  Serial.print("Temp1:");
  Serial.write(254);
  Serial.write(192);
  Serial.print("Temp2:");
}

void loop()
{
  total1 = total1 - readings1[index1]; //Averaging equation for temp1. This filters and smooths the input. 
  readings1[index1] = int(Thermistor1(analogRead(A0)));
  total1 = total1 + readings1[index1];
  index1 = index1 + 1;
  if (index1 >= numReadings1)
    index1 = 0;
  average1 = total1 / numReadings1;

  total2 = total2 - readings2[index2]; //Averaging equation for temp2. This filters and smooths the input
  readings2[index2] = int(Thermistor2(analogRead(A1)));
  total2 = total2 + readings2[index2];
  index2 = index2 + 1;
  if (index2 >= numReadings2)
    index2 = 0;
  average2 = total2 / numReadings2;

  Serial.write(254);
  Serial.write(134);
  Serial.print(average1); //Display temp1
  if (average1 < 100) //Clears the third digit if two digit temperature
  { 
    Serial.write(254);
    Serial.write(136);
    Serial.write(32);
  }
  
  Serial.write(254);
  Serial.write(198);
  Serial.print(average2); //Display temp2
    if (average2 < 100) //Clears the third digit if two digit temperature
  { 
    Serial.write(254);
    Serial.write(200);
    Serial.write(32);
  }
  
  Serial.write(254);
  Serial.write(137);
  Serial.print("TGT:");
  Serial.write(254);
  Serial.write(141);
  Serial.print(tgttemp); //Display target temperature
    if (tgttemp < 100) //Clears the third digit if two digit temperature
  { 
    Serial.write(254);
    Serial.write(143);
    Serial.write(32);
  }
  
  if (tgttemp > average1) //Simple hysteresis control loop. If temp is below target temp, turn heater on. Otherwise, off. 
  { heaterstatus = HIGH ;}
  else
  { heaterstatus = LOW;}
  digitalWrite (heaterpin, heaterstatus); //Controls the output of the heater pin depending on condition specified in conrol loop.

}

Posted in Arduino Based Spa Controller | Comments Off

Arduino Based Spa Controller part 2: Brainstorming the new control system

In part 1 of this blog I went over the control functions and safety systems of the original control system in my spa. Now it’s time to figure out how much I/O I need to make a similar control system and figure out if there’s anything I’d like to add to my new control system.

I’d like my new control system to implement the safety shutoff features of the original control system. In a situation where the pump or heater fails I would like my control system to recognize the fault and shut the system down. This will utilize the current sensor array on the tub. The controller won’t use the existing control panel at the spa. I don’t have the tools for reading or flashing PIC microcontrollers, nor do I know how the control panel communicated with the old control system. For the time being I will implement a different, simpler control panel at the tub. Simple pneumatic buttons at the tub, controlling switches in the control box will be used. Maybe……

For now let’s take a look at the existing inputs and outputs the spa currently has.

Inputs:
-Tub temperature
-Heater temperature
-Water pressure switch
-Jets on/off
-Light on/off
-Target temperature up/down

Outputs:
-Pump low
-Pump high
-Heater
-Light
-Temperature display

The user interface is something I’d like to modify from the original. There are only two buttons on the original control panel that define all of the spa functions. One button controls the jets and lights. Four different functions for one button. The other button controls target temperature. Pressing the button increments target temperature until you reach 104 degrees and the cycle starts all over again until at 90 degrees. It would be nice to have a button for each function. One button for the jets, one button for the lights, and two buttons for temp control. If temperature control is going to be user defined then the control system will require some sort of display to indicate target and tub temperatures. That will come later in this blog series. For now, we’ll look into basic spa control.

All of the inputs to the control system are digital with exception of the temperature sensors in the tub and the heater. These sensors are thermistors, the resistance across the sensor changes in relation to temperature. To make the control system accurate we must find the resistance curve of the thermistors so we know what the exact temperature is based on the resistance of the sensor. I performed a little experiment with the sensors from my spa to find the sensor curve. I placed the sensors in a pot of cold water on the stove. I wired one of the sensors to my multimeter and placed a digital thermometer in the pot of water with the sensor. In ten degree increments starting at 60 degrees I documented the resistance of the thermistor with the corresponding temperature in the water. With a very low flame under the pot I gradually heated the water up to 120 degrees to develop a chart of temperature to resistance values. This was my test apparatus for finding those values:

(null)

I found both the tub temp sensor and heater temp sensor had the same resistance to temperature values. After doing this experiment it occurred to me that I never bothered to do a google search to see if there’s any information published on these thermistors. You know, like a transfer function or a chart of resistance to temperature values. Sure enough a quick google search revealed this document with Balboa Controls thermistor values. This document allowed me to verify my own readings against the published readings to verify they’re correct. Knowing these values will allow me to develop a transfer function in the controller to convert resistance (voltage) to a control value. That’ll all come in a later blog.

With exception of the temperature reading all of the outputs are basic digital outputs. No fancy analog or PWM outputs required.

This control system design in its most basic form is going to require the following I/O:

(2) analog inputs
(5) digital inputs
(4) digital outputs

In past Arduino projects the choice package has been the DIP28 Arduino PRO mini:

(null)

This little board is an entire Arduino controller in a tiny DIP28 package. This little package has 8 analog inputs and 14 digital I/O pins, MORE than enough for this project. The PRO mini will be the controller used for this design.

Still undecided how I want to handle the control panel at the top of the tub. I’ll save that for a later blog. Still lots of work to do for now.

Posted in Arduino Based Spa Controller | Comments Off

Arduino Based Spa Controller part 1: Figuring it all out

A few months back I experienced a total failure in operation with my spa at home. Upon inspection I found the relay that controlled the heater had failed and as a result cooked some components on the control board. After spending some time searching for a new control board I began to think to myself “It’s been quite a long time since I’ve laid out a PCB and made up a good Arduino sketch. This is a good opportunity!”  So instead of doing things the easy way and replacing the control board I am going to make my own.

First thing’s first. How does the spa’s control system work? How much I/O do I need to make my controller work? I’ll start this off by showing the points of failure on the original control board and explain some of the functions of the board. Lets take a look at the old control board:

Original spa control board with fried heater control relay and burnt IC’s

Upon first glance you’ll notice there really isn’t that much to the control board. A vast majority of the board population is made up of high voltage, high current switching circuits. The relay array on the far right controls the pump motor, heater, and optional ozone generator. Two relays control the pump motor: one for high speed and one for low speed. Two relays also control the heater: one for heater on operation and one for over temp shut down.  The heater control relays operate in series, both relays must be closed for the heater to function. Seems that one relay is controlled by the microcontroller and one is switched by a voltage comparator.  I’ll go into that operation a little later. The bottom of the board is all power supply, protection, and distribution circuits. The large ceramic fuse protects the pump motor common while the smaller glass fuse protects the transformer in the control box that supplies the board with 12VAC. Power for the control board is rectified and regulated off the 12VAC supply. The spa light itself runs directly from the unregulated 12VAC source. The top left of the board contains the microcontroller circuits as well as the input and control interface circuits.

The controller has three inputs that are used to determine the operating conditions of the spa. Water temperature is sampled by a thermistor located in the tub. Another thermistor samples the temperature within the heater tube. Also located in the heater tube is a flow switch. Both the thermistor and flow switch located within the heater tube are inputs that provide safety features within the control system. If there is no flow through the heater tube or if the heater tube begins to operate at too high of a temperature, the control system shuts off the heater.

The control board interfaces with a basic control panel at the top of the tub:
The control panel allows the user to check the current temperature of the tub, set the target temperature for the tub, control the tub light, and set the pump speed.

When the control system is first powered up it goes through a series of self diagnostics before operating the spa. If a problem occurs the control system will not allow the pump or heater to turn on and flash an error code on the display. I’ve never encountered an error on this particular control system personally, so I’m not sure how many codes there are or what each one means.

If the control system passes self diagnostics it will enter the control loop and begin spa operation. The control loop starts by turning the low speed pump on and sampling the tub temperature. If the tub temperature is below target temperature the heater is energized to bring the tub to the target temperature. Once the tub reaches target temperature the pump and heater are turned off. Every two hours the control system will turn the low speed pump on to check tub temperature and to cycle water through the filter. If the tub is still at target temperature the pump will run for 10 minutes to cycle water through the filter. If the tub is below target temperature the heater is energized to bring the tub back to target temperature and the pump will remain on until target temperature is obtained again.

When the user wishes to operate the spa with jets (high speed pump) they simply press the “Light/Jets” button on the control panel to enable the high speed pump. As a safety feature, the pump will only remain in high speed for a period of thirty minutes. After thirty minutes the pump and heater will turn off and the control system returns to its normal control loop. If the user wishes to continue using the jets they must press the “Lights/Jets” button again to re-start the high speed pump operation. During high speed operation the light in the tub operates.

A jumper on the control board allows the option for heater operation during high speed pump operation. This allows the spa to work on both 120VAC and 220VAC circuits. If the jumper is selected for “low current” operation, normally 120VAC circuits, the heater will not energize during high speed pump operation. If the jumper is selected for “High Current” operation the control system will run the heater during high speed pump operation to maintain water temperature during use.

The control system for maintaining tub temperature seems to be a simple hysteresis loop. Since 450 gallons of water won’t rapidly change temperature the control loop doesn’t need to be complex. I usually set my target temperature for 104 degrees. Once the water temp reaches 104 degrees the heater is turned off until the temp drops below 103 degrees and the heater is re-energized. Simple.

Going back to the picture of the failed control board. The two relays in the lower right hand corner are the relays that control heater operation. There was a jumper wire that connected the contacts of each relay in series between the two relays. That jumper wire did not seem to be sufficient to handle the current required to operate the heater and had melted during operation. The wire broke and landed on the relay coil, sending one leg of the 220VAC line into the low voltage side of the control system. One of the IC’s suffered noticeable damage from the failure, causing the control board to no longer operate.

The relays used on the control board allow a nice, compact control system within the spa. These relays, however, are barely sufficient to supply the needed current required to run the heating element, around 4.4 kilowatts at 220VAC. Designing my own control system will allow me to use components a little more durable for the task, preventing future failures.

Posted in Arduino Based Spa Controller, Projects | Comments Off

Supercharged 1UZ-FE: Travis Doherty’s rain gutter Ranger

I should preface this post with two pictures:

Eaton M122 on top of a 1UZ-FE

 

Travis Doherty's rain gutter Ranger

What you’re looking at is my friend, Travis Doherty’s Ford Ranger. After posting a few videos of this creation on YouTube I have received a few messages asking for a build thread on the vehicle. This post isn’t meant to be a detailed build thread, rather a more in-depth explanation of the power train on this vehicle. I don’t know much about the details in the chassis and suspension end of things on this project as I wasn’t involved in that part of the build. I have been involved in the power train development side of this project and can give those wondering a better idea of what’s going on in this monstrosity.

For the past seven years the truck has been powered by a Toyota 1UZ-FE engine. The engine is an all aluminum 4.0 liter V8 that was produced from 1989 to 2000 and is commonly found in Lexus LS400, SC400, and GS400 vehicles. In Travis’ truck the engine is mated to a GM TH400 transmission with manual valve body. Controlled by a MegaSquirt II engine control system, the factory distributors were removed in favor of coil packs. The 36-2 crank trigger wheel found in the later 1UZ VVTi engines is suitable for a factory wasted spark crank triggering scheme.

Mere months ago Travis needed more power out of the engine. Producing just over 200 horsepower at the wheels wasn’t enough to have more fun in the jungle gym of steel tubing. Don’t be fooled, desert trucks are considerably heavy. The truck was originally set up around turbocharging, having been formally powered by turbocharged 2.5 liter Ford/Volvo hybrid engine. Turbocharging the 1UZ was a consideration, albeit a difficult proposition due to the space constraints in the engine cage. Supercharging the 1UZ was another option, Travis being no stranger to boosting a friends’ 1UZ powered sand rail with an old Eaton M90 blower. Supercharging made the most sense. A positive displacement unit like the Eaton M series blowers provided desirable low end torque while fitting the space constraint requirements in the engine cage.

One of the best bang for the buck superchargers in the used market is the Eaton M122 supercharger found on the 07-12 Shelby GT500. Low mile pull-offs are plentiful due to the more desirable TVS-2300 aftermarket unit available for those applications. Although the GT500’s 5.4 liter engine is a bit larger in displacement to the 1UZ, the supercharger should still be plenty efficient at the same power levels, turning a bit slower at the blower’s rotors. It also doesn’t hurt having one of these low mile pull-offs in front of you, looking to be installed in something. Makes that decision easy.

Then it began. How to put an M122 on top of a 1UZ. Aside from how to put it on top, one must consider WHERE to put it on top. The M122 has a ten rib pulley where the 1UZ accessory drive has six ribs. There was a bit of fabrication work involved solving these problems. First, a hub adapter had to be machined that allowed a second crank driven pulley to be stacked on top of the factory pulley. A universal ten rib crank pulley manufactured by Vortech was used, stacked on top (in front of) the factory six rib crank pulley. This was achieved by making a hub that fit within the factory crank pulley, indexing on the threads normally used to attach a puller tool. The hub also sat on the crank pulley bolt flange of the factory pulley. This caused the crank pulley bolt to sandwich both crank pulley and adapter hub together. The hub extended to the end of the factory crank pulley with the bolt pattern that accommodated the ten rib Vortech pulley. By fitting an aftermarket pulley to drive the supercharger not only can the proper ten rib belt be used, but different size lower pullies can be used as well to change boost pressure.

Fitting the blower to the engine is simple by concept and challenging by execution. The factory 1UZ induction system has an upper plenum that bolts to a lower manifold. For this project the factory lower intake manifold has been retained. On top of the factory lower manifold is a custom fabricated adapter plenum built with such purpose and craftsmanship that one would have to look at hand made induction systems on WWII aircraft engines to truly appreciate what’s going on within this component. The supercharger mounts atop this box, the outlet of the blower funnels down to a 3″ outlet pipe. This pipe feeds into a front mount intercooler and then feeds back into a separate chamber within the plenum. This chamber feeds all 8 cylinders with boosted air. While you can’t see the adapter plenum in the picture above, you can see the outlet and inlet of the plenum that separates the outlet of the supercharger from the inlet of the engine to externally cool the charge air.

Now that we have a supercharged 1UZ, how do we make sure the engine doesn’t blow up? For now the 1UZ is being controlled by a MegaSquirt II engine control system. Running a factory crank sensor with the later 1UZ VVTi 36-2 reluctor wheel, this particular application is fired by a series of LQ9 ignition coils in wasted spark. The fuel injectors have been stepped up to 550cc flow rate by way of Series 5 RX-7 Turbo II injectors. The engine itself is internally stock, being pulled from a 1990 LS400 with 126k on the clock at the time it was pulled. The cylinder heads, however, received a bit of treatment. The valves were unshrouded, adding a bit of volume to the combustion chamber and lowering static compression ratio as a result. The anemic factory valve springs were also replaced with Crower springs to not only hold up better at higher RPM’s, but to accommodate aftermarket camshafts down the road.

The result? 333whp at 10psi of boost. 338 ftlbs of torque peak, with torque staying above 300 ftlbs from idle to about 5500 RPM where the factory cam shafts fall off. Keeping in mind that a pre-runner drive train has close to 30% loss, this same engine package in a street car drive train would be legitimately close to 400whp. Torque everywhere, and that’s what counts.

Supercharged 1UZ at 10psi boost

With that all said, hopefully that answers SOME questions that most of you out there have to ask. To date, here’s the collection of YouTube videos I have of Travis’ truck:


 

Posted in Projects | Comments Off

Rustang gets Toyota power – 2JZGTE VVTi

In recent times I’ve received a number of inquiries about the Rustang and have come to the realization that I haven’t yet told the most recent story about that project. In early 2012 I announced on forums and social media the retirement of my 2JZ powered LOLvo due to increasing number of mechanical failures. During that time I had expressed interest in swapping the 2JZ power plant from the LOLvo into the Rustang. I had started documenting the swap on Brickspeed and never finished my writings. Due to slow traffic on that forum and the interest to continue my blogs on my own site, I figured it was finally time to sit down and tell the story about the Rustang’s new heart.

As profound as it may sound, this project is literally built around a flywheel. I wasn’t incredibly serious about doing the swap in the Rustang until I had a transmission and clutch solution figured out. Unlike the LOLvo, the Rustang was to stay manual transmission. The Getrag V160 found in the MKIV Supra is exceedingly overpriced for its age. A stout transmission no doubt, I just couldn’t bring myself to spend thousands of dollars on an old, high mileage transmission. Additionally, clutches and flywheels for that transmission are also incredibly expensive. The R154 and similar AR5 transmissions are commonly used and less costly solutions for a manual transmission behind a 2JZ engine, and the best candidate for this swap. I preferred to find an AR5 transmission, a modern and updated replacement for the R154 that can be found in both the Chevrolet Colorado and Pontiac Solstice / Saturn Sky platforms. My searches came to a screeching halt sometime mid April 2013 when I saw a facebook post from my friends at Buchka Engineering had developed a button flywheel for the Volvo red block engines that accommodated 7.25″ race clutched . I asked Karl and Alex Bucha if they were interested in making a similar flywheel for my application. Sure enough they were and I began to take measurements to come up with a flywheel design.

Having such a flywheel opens up a plethora of drivetrain options for my engine. To make this project even more exciting, the A340 automatic transmission has a removable bell housing that has a large pilot opening that’s true to the centerline of the crankshaft. With a button flywheel, a race clutch, and the A340 bellhousing, the sky was the limit for transmission options. For the beginning of this project I chose to continue using the T10 transmission that was already in the Rustang. To design my flywheel I had to know a few things:

  • What is the depth of the A340 bell housing?
  • What is the distance from the A340 transmission flange to the crankshaft flange?
  • How long is the T10 input shaft from transmission flange to the end of the splines?
  • How long is the pilot shaft past the splines on the input shaft?
  • What is the installed height of the clutch pressure plate?
  • What are the dimensions of the clutch when mounted to the flywheel?
  • How thick is the flex plate?

All of these measurements were critical in determining the dimensions of the flywheel. To make the project slightly more complicated, there was a maximum thickness to the flywheel. I had to come up with a drawing that took the design limits of the flywheel into consideration while trying to maintain proper engagement of the clutch discs to the input shaft, and other considerations. After some measuring, drawing, measuring more, and drawing, I had come up with a sketch of what I wanted for a flywheel. Not having any experience with making a technical drawing, I must thank the Buchka brothers for having the patience to turn my chicken scratch into a usable drawing in order to create the final product. A few weeks later, June 2013 I had the pleasure of meeting Karl and Alex for the first time in person, delivering the flywheel that got this project up and running. This flywheel, hand made, is a work of art. I almost felt bad installing it in this application. But, this is the piece that started it all for this project:

Buchka Engineering button flywheel. The entire project created around this beautiful work of art.

Now that I have the flywheel, it’s time to figure out how to mate the engine to the transmission. The first step was to mount the clutch and flywheel assembly to the engine and verify measurements that I had produced from technical drawings while designing the flywheel. The first issue I ran into was piloting the flywheel to the engines crankshaft. When I was originally designing the the flywheel I had used the flexplate shim to extract measurements for both the crankshaft bolt pattern and centering pilot diameter. While the bolt pattern measurements were dead on, I failed to observe that the flexplate shim was a rather loose fit to the crankshaft and the measurements I specified created excessive run out when mounting the flywheel to the crankshaft. Furthermore, the flywheel pilot on the crankshaft doesn’t protrude that much from the crankshaft flange. With barely enough room to center the flexplate, there was only about .040″ of pilot left to center the flywheel. Even if the crankshaft pilot ID was correct on the flywheel, there still wasn’t enough meat on the crankshaft pilot for me to comfortably center the flywheel. A solution had to be made for this problem. However, while I was thinking up a solution for that problem I pressed on with verifying my other measurements. Another issue I ran into was the pilot shaft on the transmissions input shaft was rather short and would not extend all the way into the pilot bore of the crankshaft. This problem was a blessing in disguise, leading me to the solution for centering the flywheel to the crankshaft. Taking a few more measurements, I drew up a pilot adapter. This adapter would press into the pilot bearing bore of the crankshaft and extend to the end of the flywheel. This provided one solution to all of the problems I had at this point. This adapter would match the pilot bore of the flywheel, centering it to the crankshaft. The adapter also housed the pilot bearing for the T10 input shaft and located the bearing further out from the crankshaft, allowing proper bearing engagement.

 

Pilot adapter prototype spun from aluminum.

Test fitting prototype pilot adapter.

Final product with pilot bearing developed from the prototype

Flywheel centered, pilot bearing spaced out!

Creating this solution was a proud moment for me. This was my first time doing any sort of precision machining. Prior to this I had very little knowledge in operating a lathe and without any instruction, taught myself how to use one to make this component. Knocking out those problems, I can continue on. Now it was time to permanently mount the flywheel to the crankshaft.

Next was mounting the clutch assembly to the flywheel and bolting the bell housing to the engine block to verify more measurements. In this exercise I needed to find the following measurements:

  • Distance from bell housing transmission flange to flywheel surface
  • Distance from bell housing transmission flange to each end of clutch plate hub splines
  • Distance from bell housing transmission flange to installed height of pressure plate fingers

Finding these measurements ensured redundancy in my previous measurements during the brainstorming stage of the project. These measurements helped me determine how thick the transmission adapter plate could be, and to make sure that the adapter plate would be thick enough. These measurements would also play a role in properly setting up the clutch hydraulics, but that’s later on in the project. The clutch I’m using for this project is a QuarterMaster PRO 7.25″ triple disc race clutch. It had previously been used in a NASCAR application. The big difference between this clutch and other race clutches is the way the floater plates are captured in the clutch assembly. Unlike plates that float between the clutch mounting studs, the QuarterMaster PRO series clutches use a drum with gear teeth along the inside diameter that captures the floater plates. The drum can be seen in the pictures above, the clutch assembly below:

Quartermaster PRO 7.25" clutch discs and floater plates

Taking measurements with clutch and bell housing fitted

Now that all of my measurements have been verified, it’s time to make the adapter plate. This was another self-validating adventure in itself. Much like the pilot adapter had been my first time doing any sort of precision machining on the lathe, the adapter plate was the first time I have ever done precision machining on the mill. And just like the pilot adapter, I made a prototype adapter plate before making the real thing. I never made any drawings for the adapter plate, I just shotgunned this component. The idea was quite simple: Machine a step in the plate that fit in the centering bore of the bell housing and machine a bore in the plate dead center to the bell housing bore that centered the bearing housing on the transmission. While the lathe probably would have been a better job for this task, the lathe I had access to wouldn’t accommodate the size of this work. The vertical mill combined with the use of the rotab will do. It was a neat experience making the adapter plate. Machining the plate itself took only thirty minutes. Setting up the tooling and verifying its all true, however, took a few hours. After making the prototype plate out of .500″ tooling plate I found that the plate was too thin where it mated to the bell housing and also made a few changes to the locations of some bolt holes to better accommodate the hydraulic throw out bearing.

Prototype adapter plate on the mill with T10 bearing housing

Prototype adapter plate fitted to bell housing

Test fitting transmission to engine with prototype adapter plate

Laying out the measurements and drill locations on the final plate

Final design adapter plate in the mill

Final product adapter plate

Ford T10 transmission adapted to Toyota A340 bell housing

Now that I had a T10 transmission that bolted to my 2JZ engine, and a clutch that drove the transmission, it was time to figure out the clutch hydraulics. I acquired a QuarterMaster hydraulic throw out bearing made specifically for this clutch. Mounting the throw out bearing wasn’t at all difficult. The throw out sleeve on the transmission bearing housing had to be turned down slightly to accommodate the new bearing. Additionally, the throw out bearing assembly simply floated on the transmission bearing housing sleeve. Originally intended to be used in retrofit applications, the throw out bearing has a pocket to use a clutch fork pivot ball to locate the bearing. In my case, I simply used a bolt threaded into the adapter plate to locate the bearing. Using the measurements taken previously, I had to figure out the setup height of the bearing itself. I found that the throw out bearing needed to be mounted a half inch above the surface of the transmission bearing retainer. Instead of machining some trick adapter plate, I simply chose to purchase a few nuts and long bolts that replace the bearing housing bolts. This allowed me to precisely adjust the installed height of the bearing. Once the bearing was mounted, and setup height dialed in, the only thing left was to cut a small hole in the bell housing to allow the pressure and bleeder lines to pass through.

 

Turning down bearing housing sleeve to fit the hydraulic throw out bearing
Test fitting and spacing hydraulic throw out bearing
Hydraulic throw out bearing fitted and spaced
T10 transmission mated to 2JZ engine

And there it is. A Ford T10 transmission mated to a 2JZ engine with a functioning clutch. What a fun and incredible learning experience it was taking an idea drawn on a napkin and producing a functioning example. Before the engine and transmission could be placed in the car, the engine bay had to be prepared. The Rustang’s engine bay was pretty dirty. Years of paint and rust and holes from brackets and the like. As bad as the rest of the car looked, I wanted to make the engine bay look good. My father spent a lot of time stripping the old paint, blending holes, and removing rust from the engine bay to make it look better. I also figured the engine needed to be a little more “flashy” than the flat black theme in the LOLvo, so I decided to paint the spark plug cover as well.

 

Stripping years of paint out of the engine bay

Painting the engine bay

New color for the spark plug cover, Ford Emerald Green. Text and logos stripped and blended.

Beyond painting the spark plug cover, the only other tasks needed to be carried out before mounting the engine in the car was to freshen up the bottom end and make the MS3X wiring harness. With a little over 200k on a factory bottom end I felt it was best to put new bearings in the engine. During this process I had intended to reused the factory rod and main cap bolts. However, during the angle torque procedures I found some of the hardware to be considerably softer than others. Not wanting to take a risk on used hardware, my bottom end also received ARP main studs and rod bolts. The oil pan used on this engine for both the Rustang and LOLvo projects is a front sump configuration from an Aristo, same as the GS300 and IS300. Supra and SC300 use a mid sump configuration. The pistons and top end of the engine I left alone. 5% cold leak down across the board was convinced me I didn’t have to fix things that weren’t broken. I also decided to make the entire ECU harness out of the car on this project. I normally build the harness in the car, however, due to a tight fit in this engine bay I felt it was best to install the engine with the wiring harness.

Freshening up the bottom end with new bearings and ARP hardware

Wiring the engine on the stand

Now came the fun part. Putting the engine in the car. From the start I had anticipated the possibility of having to cut the firewall to move the engine back. When the Rustang was powered by the 351 Cleveland, the car had a 57% front weight bias with me in the car and a full tank of gas. The 2JZ engine is by no means a light engine and while it may not be as heavy as a full iron 351c, it was considerably longer and therefore would have a greater polar moment. My goal was to get the car to a balanced 50/50 weight bias, even if it meant cutting the firewall. Before getting too carried away, however, I placed the engine in the engine bay with as many as the accessories attached to simulate the actual weight of the engine and corner weighted the car. I was amazed at what I found. With a full tank of fuel, myself in the drivers seat, and the engine up against the firewall the car was at 51% weight bias to the REAR and was over three hundred pounds lighter total weight than with the 351C. I was pretty excited that I didn’t have to cut the firewall. The project now became as simple as mounting the engine and carry on. This simplified the project immensely. Moving the engine up against the firewall moved the transmission back about three inches from it’s natural habitat, however, the factory crossmember is rather long and mounts the transmission at the front of the member. Simply slotting the transmission mount holes allowed the transmission to move back while retaining the stock crossmember. The shape of the oil pan fits perfectly between the sway bar and the shock towers. Mounting the engine was as simple as purchasing brand new small block Ford engine mounts and making adapter brackets to allow the 2JZ to sit on the factory mounts. Mounting the engine in the car was a task that took mere hours. Almost as if the engine was meant to be there in the first place.

Engine test fit and centering

2JZ to SBF mount bracket. Allows 2JZ to mount directly to small block Ford engine mounts

Engine mounted on brackets

Drivetrain mounted

Factory T10 cross member still in use

After mounting the engine it was all down hill from there. Very little wiring needed to be done since the engine harness was already on the engine and the Rustang had already been MS’d on the 351c, so it was just a matter of plug and play. The cooling system had to be plumbed, exhaust system made, and induction system plumbed. The exhaust system was pretty easy, the down pipe setup from the LOLvo somehow just fit in the Rustang. A few feet of straight piping and the old muffler from the Rustang was all that was needed to make the exhaust. A new radiator was chosen for this project, a GM style Summit turn around flow radiator. For the price, it was a nice piece. However, there was no divider on the feed/return tank which would render the radiator useless. A simple cut with the bandsaw and welding a divider in fixed that problem, but I wonder how many people overlook that issue? Because of the radiator configuration I had to custom make new inlet and outlet necks for the engine since the radiator now has the inlets and outlets on the same side. The induction system ended up being easy as well. A kind donation from my room mate got me an old Spearco core from a first generation DSM intercooler kit. Although the factory grill no longer fit due to its size, the inlets and outlets fit perfectly between the radiator.

Fitting the new radiator

Fitting the intercooler

Cooling system plumbing and turbo outlet plumbing

Intercooler plumbing

Intake pipe fabbed, complete engine bay

So now what? I have a 1968 Ford Mustang fastback with a 2JZGTE VVTi engine. Time to drive it, I guess.

Posted in Rustang - 1968 Ford Mustang | Comments Off

The demise of a legend: On to bigger and better things.

Having been absent from my own blogging world for the past few years I figured it is best to preface this blog with a brief history of the daily driver that served me well for close to five years. Those who haven’t followed me on Facebook, TurboBricks, or Brickspeed are probably unfamiliar with my 1988 Volvo 245. A few years ago I was working in a very affluent area of Orange County as a calibration engineer for modern fuel injection systems. I dealt primarily with 1997 and up Chevrolet Corvettes, calibrating the factory equipped Vehicle Control Modules to accommodate customer specified engine modifications. Another platform I had become intimately familiar with during that time is the Toyota 2JZGTE engine found in the 1993-1998 Toyota Supra. The 2JZGTE engine is a legend in itself, known for insurmountable out of the box strength with countless examples exceeding 1000 horsepower on factory bottom ends. The engine is also known for the unique sound produced when fitted with a single large turbocharger.

I appreciate a vehicle that has function over form, a true sleeper. Working in an area full of exotic cars I wanted to build a daily driver that had a face only a mother could love and perform with the best. Something that would destroy the ego of one who just left the lot in their brand new Lamborghini Murciélago. My Volvo 245 fit the bill perfectly for this task. My admiration and familiarity of the 2JZGTE engine made it the perfect engine for this project. In short order I removed the anemic 160 horsepower turbocharged B230F engine from my 245 and fitted the chassis with a Japanese spec 2JZGTE engine with Toyota’s VVT-i variable valve timing system. The factory equipped twin sequential turbocharger system wasn’t appropriate for the performance figures I desired out of the 245. A single 67mm turbocharger was fitted to the engine with a cast iron log manifold for simplicity and reliability. Additionally, the stock cam shafts designed to limit engine power were replaced with Brian Crower 264 duration camshafts and the valvetrain equipped with Crower springs and retainers to compliment the new camshafts. All said and done the 245 put down 495 wheel horsepower on an everyday street tune at 16psi of boost and 590 wheel horsepower at 22psi on E85 fuel. The dirty hippy wagon that could accelerate from 60mph to 130mph in five and a half seconds (read: Bugatti Veyron territory.)

 

The heart of my Volvo 245: Toyota 2JZGTE VVTi equipped with a 67mm turbocharger

I enjoyed showing off my contraption at local car meets and the well known Irvine Cars and Coffee events. My daily beater came with mixed reviews. Some people were appalled that I’d dare show up to events that were normally reserved for exotics, factory prototypes, and collector cars. Others found inspiration in such a machine, something that an ordinary person created with basic hand tools. The car provided encouragement for those who were less skilled to follow their passion. Above all the car was different. Something out of the box that you don’t see every day. Like it or hate it, my 245 always seemed to be the center of attention when the hood was up.

My 600 horsepower hooptie showing its stuff at Cars and Coffee Irvine

Beyond the attention my jalopy received locally, the 245 found itself to be an internet sensation for a short period of time. Some years ago people on the internet were joking about making an instrument cluster for a car whose units of measurement were based on meme faces. This joke was brought to reality when Dave Barton, a well respected member of the Volvo community, made an overlay for my instrument cluster depicting the meme faces as the units of measurement. Shortly after installing the overlay and posting a picture to Facebook as well as the Volvo forums, my 245 reached a new level of stardom. Days after posting the picture of my new instrument cluster I was informed that the image had made its way to high traffic off-topic websites such as break.com and reddit. To this day I get random tags on Facebook of people still sharing the image, enjoying the humor in making such an absurd idea a reality.

The most famous image of my 245 that was seen around the world

I put close to 80,000 miles on the 245 since equipping it with the 2JZGTE engine. I drove it everywhere and it held up just fine. A little over a year ago I moved back to San Diego and found myself not driving as much, having the desire to turn up the wick even more on the underrated Toyota powerplant. E85 fuel is readily available where I live and the car found itself living on the knock-resistant fermented corn liquor. Manifold pressure was increased to the point where the fuel system hit the delivery threshold. The little Volvo was making so much power that it became downright stupid to drive on public roads. One day in the not too distant past I encountered a turbo 996 Porsche on the freeway, presumably returning to its home in La Jolla, one of the more affluent communities of San Diego. The license plate implied something along the lines of the driver being a medical doctor. A vanity plate justifying why one would own a turbocharged Porsche, just the sort of egocentrism I enjoy belittling with a peasant car marketed for its renowned safety. Goes without saying if you’re in a profession making seven figures and driving a turbocharged Porsche, you’re going to (try to)  accelerate away from an under powered Swedish tank riding your tail at 80 mph. After all, the brochure at the Porsche dealer says you’re driving a race car. The Porsche took off, the faint trail of exhaust smoke indicating rich mixtures required to make power under full boost. I gave the Porsche a few cars lead, just to let the driver feel good about themselves for just that moment. Allowing the doctor a two car lead, I tapped the downshift paddle to command the A340 transmission (yeah, the 245 was auto) into third gear, opened the throttle to full steam, manifold pressure instantly arriving at 30psi, and followed suit. Within a second, at 100mph I had arrived door-to-door with Stuttgart’s finest. Another second passed, 120mph and I’ve already pulled a car length. Another second and change later I find myself walking away at the top of third gear, 130mph. Tap the upshift paddle to command the trans into fourth gear and keep running away from Doc M.D.  Some moments later, hitting an aerodynamic wall around 150mph I began to hear a loud whine coming from the rear of the car, followed by a loud pop and a crunching sound. I immediately shut down and began my decel coast. Hurling a brick through the air at those speeds, aerodynamic drag is awfully effective at slowing down a vehicle. As I came back down to appropriate highway speeds I prepare to exit the freeway to assess the damage. Not before encountering the driver of the Porsche one last time, however. They say money buys happiness and the driver of the Porsche was sure to show me how happy he was by giving me the one finger salute. After expressing his gratitude of  getting walked on by a family wagon the disgruntled gentleman floored it and took off,  just to remind me he’s a wealthy health care professional and drives a Porsche.

So what happened? What was the noise I heard? Upon inspection after stopping the car I found the pinion flange to have excessive play in the rear end. The little Dana 30 gear sets found in the rear axles of Volvo 240’s were simply never designed to cope with 600 ft-lbs of torque. Excessive thrust loading on the pinion gear crushed the pinion sleeve and took all pre-loading off of the pinion bearings. I was able to tighten the pinion nut enough to keep the pinion gear in line, just to make it back to the shop. It was a time to make a decision. Do I want to go forward with installing a larger axle in the 245 to handle the power the 2JZGTE is putting out? This decision came with other considerations, like the fact that the chassis was starting to crack along the door sills, and that the doors were so twisted up that the windows would simply fall into the doors if you tried to roll them down. All the time and work required to reinforce the 245 to handle a lot of power simply was no longer worth it. The car served me well for five years, but it simply wasn’t designed to handle high torque engines for the long term. I decided it was best to retire the 245 and move on to a new project. Since the decision was made it was time to go for broke. I put my camcorder in the 245 and took it out for one last ride, just to show the absurdity of driving this car on the street. I tried to annihilate the rear end, but it still held up albeit making a lot of noise. After a few passes around the shop, I opened up the rear end to assess the damage. The pinion gear was *this* close to failing, as pictured below:

Chipped teeth on the pinion gear as a result of losing pre-load on the pinion bearings.

Hairline cracks at the root of every tooth. This pinion gear was about to open up like a flower!

With the footage I shot making passes around the shop one last time, I had to make a farewell video for the pile of fail that served me so well for so many years and post it up on youtube:

So what now? Stay tuned, the 2JZGTE is making its return in my 1968 Rustang. This time armed with a manual transmission and more power!

Posted in Unnamed diesel project (1988 Volvo 245) | Comments Off

Turbo Junky scam exlpained

It’s been a while since I’ve made a post, almost three years. A lot has happened in those three years and perhaps in the near future I can resume sharing with the world the things I’ve learned. You may consider it profound that a shady motorsports related clothing company ripping me off is what it took to bring me back to blogging. After four months in dispute over a small amount of money scammed from me by Turbo Junky Apparel, I’ve decided the best way to “put them on blast” is to post my own experience with this company on this blog.

I found Turbo Junky on Facebook about a year ago when a mutual friend had “liked” a picture posted of their apparel. I “liked” Turbo Junky on facebook and t ook a look at what they had to offer as I’m always buying shirts with clever prints on them (read: Woot!) They seemed to be doing a good business at the time. They were always posting on Facebook pictures of large mail carts full of filled orders being shipped out to customers, commenting that it may take up to a week to process new orders. Taking this into consideration I still wanted to buy some shirts from them. I found two shirts that I really liked and for the price ($4.99) there was no way I could pass them up. I placed an order on September 13, 2012 for two shirts and a few stickers from Turbo Junky totaling about $21 including shipping charges. Something that caught my attention during the order process was the fact that this company didn’t accept PayPal as a form of payment. This should have been the red flag right here. I wanted to pay by PayPal because I knew that there was a certain amount of risk involved buying from a company that’s already getting complaints about not being able to deliver a product. All things considered, $21 wasn’t a huge risk so I placed my order anyways. Soon after ordering I receive an email from the name of Mohommad Lufti (executive187@gmail.com) confirming my order. There was no invoice of items purchased in the email confirmation. There was just an invoice number, customer ID, and my shipping address. After the order was placed I patiently waited.

A month went by with no product received. Turbo Junky’s Facebook posts began to apologize for the delay, that due to overwhelming amounts of orders it could be up to a month before receiving an order. Many people commented on the Facebook posts, suggesting Turbo Junky increase the cost of their product and hire help to fill orders quicker. Nobody expressed disdain had the cost of the product increased, everyone was willing to pay a little more to receive their order in a timely manner. I attempted to contact Turbo Junky through every mean made available to contact them and was left without response.  I began to do research on the company. A quick Google search revealed a long history of this company selling their products on automotive forums without delivering. It seemed that roughly thirty percent of people who chimed in on forums received their order from this company. Everyone else found themselves in the same position as I did. In fact, if you do a Google search on the term “Turbo Junky” you’ll find their website is the first result. After that, pages and pages of websites and forums full of people who have been scammed from the company.

I personally gave up the pursuit as two months rolled over. My bank wasn’t interested in pursuing a twenty dollar charge made 60 days ago. It was clear I had been scammed. Around this time, December 2012, I noticed that Turbo Junky was no longer making Facebook posts related to shipping delays. Instead, they began posting images of teenage females wearing their clothing. All of the apologies and complaints had vanished from Facebook, and the ability to contact Turbo Junky via Facebook had been disabled. Comments to photos on posted by Turbo Junky were overwhelmingly positive considering the history of the company. Right around mid December Turbo Junky ceased their daily postings on Facebook, their page lay dormant. Did karma finally catch up with them? Nope.

Turbo Junky resumed flooding Facebook with posts around the beginning of this year. They claimed to be under new ownership and assured they were going to make up for their wrong doings. One of their posts said a form was being set up on their website that would allow existing customers who haven’t received their products to file a claim. That never happened. Shortly after their return the apologies and complaints vanished and they returned to their normal postings of teenage females and popular tuner car builds, every adolescent boy’s fantasy.

I posted a comment on one of their images today, expressing how I felt about the situation: “You guys post a lot on Facebook, where do you ever find time to ship out your orders?” Immediately a few posts followed in agreement with what I posted.  Moments later my post and those in agreement were gone and I was blocked from making any further posts on Turbo Junky’s page on Facebook. I then realized why they receive nothing but positive comments on everything they post.

How does a company with a long history of scamming continue their scam and not get caught?

Turbo Junky is a scam that uses clever viral marketing on Facebook (and presumably other social networks) to attract a broad audience by constantly posting images that appeal to motorsports enthusiasts. As current followers “like” images posted by Turbo Junky, mutual friends of followers can see those images and “like” Turbo Junky as a result. In the four months I’ve pursued Turbo Junky they seem to acquire 2000 more followers each month, currently at 126,000 followers. Every post made by Turbo Junky brags about their incredibly cheap shirts and products, followed by a plethora of comments praising the company for their products.  Their presentation on Facebook is flawless, no signs of dissatisfied customers or negative feedback. The cost of their products so low there’s no sense of any risk, driving up the amount of orders received. All the face(s) behind Turbo Junky have to do is watch the money roll in and make sure their Facebook page remains sterile at all times.

Filing a complaint in individual situations can be a daunting task. The domain name for Turbo Junky is private. There’s no contact address or phone number listed making it exceedingly difficult to get any sort of cooperation from (local) authorities. By the time most people realize they’ve been scammed, banks can’t be bothered to be of any help. Turbo Junky doesn’t accept paypal knowing they have stricter policies that side with the buyer in cases like this. Any posts on the internet, including this blog, go unnoticed until those who have been scammed start researching the company. Any complaint or dissatisfaction posted on their Facebook page is instantly removed and that user banned from posting on their page. In addition to their growing audience through social networking, Turbo Junky seems to have found a way to establish a long term scam without much, if any repercussions. How long will this continue? It will be interesting to see.

Addendum 01/18/13 17:18- I’ve received an overwhelming amount of support from friends on Facebook spreading the word. I’d like to thank everyone who has taken a bit of their time to share my story and get the word out. At this point I’ve written off my $21. However, keeping this momentum, together we can take action against this company and help others’ from falling victim to this scam. To add to this blog post, here are some things that can be done to further expose Turbo Junky:

-Share this blog post on your favorite social networking site. Be it Facebook, Twitter, Myspace, etc.

-Report Turbo Junky to Facebook as a scam. If you haven’t liked Turbo Junky on Facebook (at this point, why would you?) you may find them here: https://www.facebook.com/turbojunky. Just to the right of the “like” button is another button that drops down a dialogue allowing you to report this vendor to Facebook as a scam. If enough people reporting Turbo Junky as a scam should draw enough attention to Facebook administrators to have their page removed. Since Facebook appears to be Turbo Junky’s main marketing tool, having them removed may hit them hard enough to end this scam.

-Share on your favorite automotive forum. There are tons of automotive forums out there. Getting the word out across the forums will also make its way back to Facebook and contribute to a greater establishment of an already poor reputation on search engines.

Again, I’d like to thank everyone who has taken time to show their support in removing another long-term scam artist from our beloved hobby.

-

Posted in Other | Comments Off