Gauge Cluster Weather Station

In a previous post I played around with an Acura Legend gauge cluster I found at a junkyard:

I found the workshop manual for the car online, which included a detailed schematic of the cluster:

Since I had all the information I needed to display pretty much any data I wanted on the cluster, I mulled over what would make sense to display. I settled on local weather conditions, with the tach representing relative humidity (x10), the speedometer showing temperature in Fahrenheit, the temp gauge displaying barometric pressure, and the fuel gauge indicating percent of the moon visible. I plan on putting this in my garage when it’s finished, it will make a nice looking (and useful) indicator. To measure all these parameters I bought an Arudino Pro Mini, RHT03 temp and humidity sensor, BMP180 barometric pressure sensor, and a SparkFun real time clock module.

Interfacing with the temp and real time clock were relatively straight forward, they both use I2C communications and I followed some examples for each. The RHT03 uses it’s own 1 wire communication scheme, I followed the tutorial here which I found in the product comments. A note on using 3.3V and 5V components on the same I2C bus: both breakouts come with pullup resistors on the data lines to VCC. Since the real time clock was 5v nominal and 3.3v tolerant, I desoldered the pullups on it, letting the BMP180 breakout pull the bus to 3.3V.

The tutorials for the sensors showed how to get data from the sensors, but I wanted the fuel gauge to show percent moon visible. I knew the time, so I thought how hard could it be to calculate percent visible? Hard. Harder than I thought, at least. I ended up “flattening” the time to minutes since Jan 1, 2014. Given that, I looked up the closest full moon after Jan 1. By subtracting the difference, I had a t=0 that corresponded with a known full moon. By taking the “minutes since known full moon” and dividing by the lunar month, I ended up with a float representing the number of lunar months since t=0. I converted the division to an int (which truncates the decimal), subtracted (number of moons * lunar month) from time since t=0, which gave me time into the current lunar month. From there I calculated the percent visible keeping in mind that halfway through the calendar there is a new moon, so  in one month the percent visible goes 100-0-100.

With that, I had all the information I needed. The next step was to get the Arduino to talk to the guage cluster in it’s native language – a variable frequency square wave. I tried a few different software methods, but all of them were either unreliable or used up a ton of processor power. I settled on a XR4151CP-F voltage to frequency converter which can be “programmed” (in a very loose sense of the word) with an external RC network. I tried going through the calculation they provided, but I couldn’t make any sense of it. They put some equations in the datasheet, but none seemed to really predict anything, even using the values in the example. I ended up building the example circuit and adding capacitance to CO until I got in the range I needed, 150 Hz at 5V output for the gauge cluster and 400 Hz for the tach. Since the V to F converter takes an analog voltage, I designed a RC filter using this calculator to convert the PWM output to a nice smooth analog value.

 

Once I had everything built it was time to check the linearity, and map speed to the PWM duty cycle. The Arduino uses an 8 bit int for output, so the range is from 0-255. I incremented the PWM output and recorded frequency and speed:

This was interesting, but kind of the opposite of what I needed. I have temperature (MPH) and want to know the PWM value to output. Note that I truncated the speed data on either end to remove the saturation. I could have adjusted the V to F converter to get rid of that saturation, but it’s so high that I’ll (hopefully) never see it, it would mean the garage was 140*F!

Ah, that’s better. I had excel plot a linear trend line and display the equation. Now I have a PWM value as a function of speed (temperature)!. I plugged this into my program and…

Holy crap it works! The speedometer accurately displays temperature. This was the biggest hurdle, as the tach is the same setup, just different range. I’ll have to use a transistor array on the output for the tach since it only responds to a 12V square wave, but that’s not difficult. Both fuel and temp sensors were voltage dividers with rheostats on the low side, and the gauges are damped heavily enough that I can replace the sensor with a transistor and vary the PWM duty cycle to emulate the sensors.

And with that, I’m going to call it a night. I’ll probably try out the tach in the same manner, but avoid hooking a whole other circuit for it, it takes like 45 minute to build it. With the proof of concept working, I’ll design a board in eagle and send it out to get made! On a side note, if you would be interested in either a populated or unpopulated board for a cluster of your own, let me know and we can discuss.

As for the motor controller, I ended up just buying a Curtis 500 amp DC motor controller from Ebay for the golf cart – I simply didn’t have time to finish the one I started on. I’d still like to revive the one I designed, maybe turn it into a completely overpowered switched mode power supply.

Setting up a string alignment on a AP2 S2000

I did a string alignment on my 04 AP2 S2000 this past weekend, and wrote a DIY on a forum about it. Setting it up is the hard part – once I had the difference in front and rear track width the alignment was time consuming easy. Enjoy!

 

I wanted to add more camber to my mostly stock 2004 S2000 and I couldn’t find any shops to do it, so I decided to do it myself. This won’t cover the actual adjusting – that’s covered very well by Rob Robinette – but rather how to set up the strings on a stock AP2.

The goal is to set up two strings, both parallel and equidistant from the car’s center line. This isn’t very hard, but it’s tedious the first time. I made a string holder setup using suction cups like this one, but I didn’t know the difference between front and rear track widths measured from the center caps of the stock wheels. Enter… some conduit:

I bought two piece of conduit and made some notches in them exactly the same distance apart – I actually just clamped them together and filed a notch in both pieces on each end. I then put them on jack stands as shown above, one in front of the car and one behind it. I wanted to fix one fore and aft, so I pushed the rear snugly against the rear bumper.

The idea here is to create a parallelogram, since measuring the diagonals to make a box would be difficult at best. For those who slept through that geometry class, a parallelogram is defined as a four sided shape that has two sets of equal length sides (think a rectangle that got pushed over). By definition, the two equal length lines are parallel. Since the notches (which hold the strings) are the same distance apart, all we have to do is make sure the strings are the same length to create our parallelogram. I used a tape measure like so:

159″ was a nice round number, so I moved the conduit in front of the car until both sides measured the same:

Hooray beer parallelogram! Now that we’ve got two parallel strings… near the car, it’s time to center it. This is an iterative process, since the front affects the rear and vice versa. I started by measuring the distance from the string to the center cap on the left and right sides in the front, adding, and dividing by two. This should get you in the ballpark, so move to the rear and do the same. Repeat as many times as it takes to get the distance the same left to right. In my case it took 3 rounds, and the distance was 3.025″ in the front and 1.875″ in the rear. And here is what we’re looking for: how much wider the rear track is at the center caps. Subtracting the two gives you 1.15″ per side

I did a sanity check and measured the total toe in the front, which ended up being 0 as expected. With the difference in track width known, I put the suction cup setup on to test it out. I set the rear string to center cap distance at 1.5″ and adjusted the front until I got 2.65″:

Look at that, they’re parallel! From here I can do an alignment without having to re-box the car every time, just by putting the suction cups on and adding 1.15″ to the front center cap to string distance. This will obviously be dependent on what wheels you’re running, but if you follow the conduit method you can find the track width delta for any set of wheels. Oh, I also figured out what the S stood for…

Happy aligning!

Acura Legend Gauge Cluster – Controlling with Arduino

Went to the junk yard today and grabbed a gauge cluster from an older Acura legend to crack open. Each gauge is an air core gauge, which are pretty handy if you ever need a good, repeatable gauge for a project. Usually you’ll need a driver IC (unless you feel like using up 4 outputs and writing some code), so I was interested to see what they were using back in the early 80s. It turns out they used a Toshiba T8557C, which apparently does not have a datasheet ( that I could find, or was a proprietary IC). After some fooling around, it looks like this thing takes a variable frequency square wave (from the transmission, no doubt) and converts that to output. I wrote a quick Arduino sketch to output whatever frequency I send the Arduino over serial:

/*

Variable frequency output for Acura Legend air core speedometer
Driven by a Toshiba T8557C IC
Speedometer reads 0 from 0-8Hz, max speed at 146 Hz
*/

unsigned long last = 0; //last time loop ran
unsigned long f = 73*2; //initial frequency
unsigned long t = 5000; //time interval between digital pin cycles, 1/frequency
boolean flag = false; //toggles digital pin 10 on and off
unsigned long lastSweep = 0; //last time a sweep calculation ran
void setup()
{
pinMode(10, OUTPUT); //Toggles pin 10 on and off at a varrying frequency
Serial.begin(115200);
Serial.println(“Input frequency (Hz)”);
Serial.setTimeout(10);
}

void loop()
{
if (Serial.available() >= 1) //If there is serial data in the buffer
{
f = Serial.parseInt(); //assign it to f
Serial.println(f);
f = f*2; //1 Hz is 2 switches per second (low-high-low)
}

t = 1000000/f; //t = 1/f, time per cycle

if (micros() – last > t)
{
flag = !flag;
digitalWrite(10, flag); //toggle pin 10 at a varrying frequency

// Serial.print(f);
// Serial.print(“, “);
// Serial.print(val);
// Serial.print(“, “);
// Serial.println(micros()-last);
last = micros();
}

// if (micros() – lastSweep > 20000) //if uncommented, will sweep from 0-146 hz, then return to 0 and repeat
// {
// if (f >= 292)
// {
// f = 0;
// }
// f = f + 1;
// lastSweep = micros();
// }
}

 

The code is pretty self explanatory, there’s also a sweep function at the bottom because HEY LOOK I MADE A THING THAT MOVES. As a note, the tach uses the same driver IC but only seems to like 12V input, where the speedo was ok with 5v input. Odd, but they also had different signal sources when they were in the car. I could wire up a transistor to do that… but that was more effort than I felt like putting into it at the moment.

Any of these gauges (4 total) could be used with a driver IC of your choosing, making it easier to include them into your project. The gauge readings (the numbers) are also easily replaced. The two larger gauges would make for really cool temperature and humidity gauges… I’ll add it to the list of projects.

I’m not very familiar with CAN busses, but I’m sure newer clusters could be hacked much easier via CAN.

A Successful Failure

They say you lean the most from your failures…

Started the day off by cleaning (sanding the oxide layer off) the heatsinks and applying the thermally-conductive-but-electrically-insulated pads. Old FETs were then desoldered and two of the final ones added. the first thing I did was check install a 10k pull down resistor on the low side gate to see if  it would help with the voltage spike when the high side turned on:

Nope. Next step was to check the gate rise times with the new FETs. The new FETs are supposed to have 2.1 Ohm resistors built into the gates, so the rise time should be slower:

Slightly. Which is good, since I liked how fast they were switching without ringing. Since everything checked out, it was time to solder in the remaining FETs:

Looks pretty sweet, right? It was kind of a pain, since I had to install the heatsinks, “tack” solder the gates in to hold them where they were, then take everything apart and finish solder it. Not surprisingly the gate turn switching time increased by quite a bit, since I multiplied the gate capacitance by 6. Below shows the gate, then the M+ out traces. The M+ now has a discernible curvature to it on the rising and falling edges due to the longer switching time:

I had to increase the dead time to  ~3/4 of the pot’s  adjustable range, adding quite a bit of dead time. It was interesting to play with the dead time and hear the speed of the motor go up as the dead time went down. Enough testing, let’s move something a little bigger!

I tested the logic side first. The voltage regulators were doing their jobs well, keeping the 5 and 12V busses where they should be. The 5V regulator was getting quite hot, which after doing some mental math, was dissipating 11W of heat. I had a TO-247 heatsink laying around so I slapped it on there and it kept the regulator to a reasonable temp. Hooking up the batteries to the controller was… exciting, to say the least. All of those caps acted like a short for the 1000+ amp voltage source that were the batteries. I got a nice POP as they charged. The final system will have a precharge resistor so I don’t cook the contactor when that happens. Also, next time I hook it up I need to precharge them so I don’t, you know, weld the cable to the controller.

With the power and motor hooked up it was time to test the the controller on something a little more it’s own size. I assumed I had left the ground connected to the logic, and went to connect the logic power. I was greeted with a loud POP and a bright flash as the batteries arced to the logic power…. uhh.

It turns out I hadn’t connected the logic ground, and in doing so there was no current flowing through the regulators. Resistors, which the linear regulators I’m using essentially are, can’t drop a voltage if there isn’t any current. Logic supply voltage must have flown up to 48V, cooked the FET driver, and caused the FETs to momentarily shoot through. I’m pretty sure it cooked my bootstrap diode too, because even after I replaced the driver IC I’m just getting positive supply voltage on the high side gate output. At that point I gave up for the day, and I’m going to take a few days to step back and take a breath.

The arduino survived though, so at least I have that going for me.

Mechanical work

Made good progress on the mechanical stuff this week. Drilled and tapped he holes for the MOSFETs, voltage regulators, and added holes for the thermistors and bottom plate. Today I made the bottom plate that all the boards and heatsinks mount to. Aside from barely punching through the heatsinks on the voltage regulator holes, everything went together as planned. I’ll fill those with RTV when everything goes together for the final time so water doesn’t get in.

On the electrical front I had a pulldown resistor on the high side gate, but instead of going to the source for those FETs (M+ out) I had it going to my logic ground. I corrected that today, and I’m going to try to add pulldown resistors at the gates on the low side and see if it helps the voltage spike when the high gate turns on. I know it’s a bandaid, but I’m not sure what’s causing it.

Wheels up test tomorrow! Hopefully I’ll have a video with no flames in it.

 

Gate driving… and shoot through?

I was reviewing the scope trace I posted yesterday, and noticed that the low side gate drive has a spike in it exactly when the high side turns on (red is high gate and yellow is low gate):

 

 

So I adjusted the dead time to see if it was shoot through, or if it followed the high side gate. Turns out it follows the gate, and was not shoot through:

 

 

This concerns me, since a voltage spike at the gate could cause it to turn on (even partially), and cause shoot through. The magnitude of the spike is ~1.75V normally, with occasional spikes up to 2.75V:

 

 

Next I compared the M+ bar (between high and low side FETs) to the low side gate, to see if the spike was causing the low FET to conduct and cause shoot through (thus lowering the voltage available to the motor):

 

 

Low side gate is in yellow, +M is in red. It doesn’t look like it’s dropping the voltage available to the motor, so it must not be conducting much? The real way to tell would be to have a very fast current sensing probe. Looking closer at the motor versus gate voltage, there is some oscillations in the motor voltage but the frequency doesn’t match and the edge is still somewhat sharp:

 

 

Looks like the FETs are switching at 160ns – pretty fast! I went hunting for the source of the spike, so I made my way back from the gate to the driver. The spike was at full magnitude immediately after the gate resistor on the logic board (ruling out the wiring between it and the FET), but dropped to ~0.5V BEFORE the gate resistor… huh? In order for there to be a positive voltage at the gate, across the gate resistor, would mean that current would be flowing OUT of the gate, even after it’s off.

Could the driver ground be going negative relative to the source? I checked the source on the low side FET, and the voltage is stable. I also checked the low side ground on the gate driver, and it was the same story as before the gate resistor – ~.5V variation. In fact, I probed everywhere on the gate drive IC, and the only place I see the spike is after the parallel gate resistor. Maybe the resistor is picking up noise from the power stage? That’s the only explanation I can think of. Either that, or there is some drain-gate leakage voltage (voltage bumps on the gate when drain to source voltage spikes). If you have any insight, let me know.

I also measured the high side switching times. It’s a bit longer at 290ns, which is understandable since it’s bootstrapped and has to reach a higher voltage than the low side. It looks like the high side FET turns on fully when the gate reaches ~10V – perfect, since all of the miller plateauing happens after that:

 

 

 

I’m not sure what to do about the voltage spike on the low side FET gate, so moving forward I’m just going to keep an eye on it. The next step is to finalize all of the mechanical stuff – drill and tap the heatsinks for the FETs and regulators, install final standoffs, and add RF shielding between logic and power stages. I should get a package this week with all of the stuff I’ll need, so hopefully by next Saturday I’ll have it to the point where I can test it on the cart.

In an unrelated note, the current sensor has a fair amount of drift in it – It should read 2.5V at rest, and it fluctuates around 2.87V. I wonder if it has to do with the supply voltage fluctuating – I grabbed a 0-200k pot for the 5V regulator instead of a 0-10k, which means it’s very sensitive to small changes in pot position.

First motor turned!

Hooked up the rest of the connections from the logic board to the power stage today. I also added two of the 63V MOSFETs for testing. I hooked a very small motor up to it when everything was connected and… it ran! I kept a close eye on the gate to ground traces (connecting the high side probe ground to the bottom of the high side MOSFET would have shorted it directly to ground, since I was probing the low side as well). All of the low duty cycle funkiness disappeared once everything was hooked up correctly.

I was drawing… mabye an amp or 2 through the small motor, so I hooked up a 1/10th scale RC car as a larger load. Everything looked great up to about 8 amps, where my power supply started to get upset and drop voltage. Success so far!

I added a scope shot below. The gate turn on\off looks pretty good. I don’t have a super sharp turn on for either high or low side, so once I have all of the MOSFETs in there I may decrease the resistance a tad. The good news it that these are logic level MOSFETS, meaning they should be on by 5V. In the scope image below you can see that they get to 5V very quickly, I’m driving them to ~10V there. I need to play with the regulators, but I should be getting around 12V. I need Req of ~9 ohms so I don’t overload my gate driver (1.4 amps total), right now I’m probably around 10. The new FETs have a 2.1ohm resistor in series on the gate, so those will turn on even slower.

Overall, a very rewarding day. It was a little over a year ago I started learning about how motor controllers worked, now I have a functional controller sitting on my desk 

 

Buss bars and more assembly

Sunday I soldered in the buss bars, caps, and TVS diodes. One of the buss bars had to be trimmed to fit through my current sensor. If there is a rev 2, I’m definitely to do it how most other people do it and just use big copper bars bolted down to the PCB with some conductive paste. It might make mounting the current sensor a little more difficult, but I won’t have to hack up buss bars and they’ll end up being mechanically stronger. The buss bars were installed in using an …innovative method. I cranked my soldering iron up to max and heated up the bottom PCB pad while with the other hand held a lighter on the bus bar. I needed the lighter, otherwise I couldn’t get enough heat into it to make a good solder joint

 

 

I’ve also been doing some preliminary work on the gate driver IC. Everything works as it should between ~30% and ~70% duty cycle, but out of that range I start to see glitching like the driver is cutting out. Scope traces confirm this, but it’s not on a regular interval. Above 70% makes sense – the high side is bootstrapped, so it starts to drain the cap faster than it can recharge it. Below 30% is puzzling, I’m hoping that since I don’t have any FETs hooked up it’s not drawing enough current through my 12V regulator, thus browning out the driver. I’ll do more testing with this once I get everything hooked up, I didn’t have the low duty cycle issue on the breadboard.

I also connected the current sensor to the logic board and powered it up. After a few minutes of panicking because I thought I had a short in the PCB (VCC to Gnd on the sensor showed a short, but I was in the mega ohm range and it was just drawing power from the multimeter) Everything was connected and a quick program was written for the arduino to spit out the reading. The current sensor outputs a voltage from 1-4V corresponding to -400A to 400A through the sensor. After a little math I came out with a function relating analog reading to current ( f(10 bit analog reading) = current). There was a ~75A offset since the sensor wasn’t centered perfectly, but after that I got a reliable 0 reading from the sensor. I won’t be able to verify until I hook the controller up to a load.

 

 

The next step is to connect all of the gates and the rest of the wires between logic and power boards.

Assembling

Spent most of the day assembling the logic board, and everything is populated. Next time I’m definitely using some better connectors, the pin headers were meant to be used between boards, not to have wires soldered to them. Both linear regulators seem to be doing their jobs correctly, and the basic program I wrote to use the gate driver to drive into nothingness (no MOSFETS) also works.

The power stage still needs to be assembled and everything mounted to the heatsinks\chassis. I received the new 100V caps and MOSFETs, and the caps are pretty big. They give the controller a “don’t mess with me” look . I also have to trim the positive buss bar to fit through the current sensor.

After 6 months of staring at a computer, visual progress is finally being made! Pictures:

 

PCB Arrival

The PCBs arrived today!One of the legs of my gate driver is shorted to another, but other than that it looks good. My only concern is that I left thermals on for my buss bars – so I’m going to try to push 400A through (5 holes * 4 thermals * width * 4 oz PCB thickness). Getting the buss bars out of the old controller was a pain, so hopefully it will at least make it easier to get them in. Now the fun part begins!