My DIY Electronic Boost Controller

Talk EMS and Computer related performance

My DIY Electronic Boost Controller

Postby Andy » Sun Mar 22, 2009 10:49 am

I've built my own Electronic Boost Controller with an Arduino.

Image

This is a replay of data logged onto my laptop from my Arduino. This is all pretty much getting it to work the first time and the video is not the best, video of a PC screen is a trick.

http://videos.streetfire.net/video/Arduino-Boost-Controller_642222.htm

The Arduino is logging the TPS (green, normally at bottom, AFM (blue normally at top), and Vacuum/Boost (red, normally in the middle). Note: '50' has been added to the vacuum/boost value to center it in my graphing. Thus if I'm drawing 15 inches of vacuum then 50-15=35, a point will be graphed at 35. If pushing 5 lbs of boost the point plots at 58... (this is a quick, dirty, fix for graphing 3 data values...) View the TPS and AFM as relative percentage open.

There is a steady 'reference line at 50 this would be at 0 vacuum and 0 boost. There is an upper reference line, which is the boost level setting, Lbs + 50, so 57 = a setting for 7 lbs of boost, 64 = a setting for 14 lbs of boost. It will change as I change the boost setting, to 7, 9, and 14 lbs of boost.

The Arduino is controlling the boost! I'm doing this through the Turbo VSV wire to the ECU, which has been routed through an A/B switch to allow the ECU or my Arduino to control the boost through the factory components. I monitor the vacuum/boost through the PIM signal wire to the ECU (still intact). Thus far I've only done limited testing. I can pull 8-9 lbs of boost w/o any controller hooked up, which I think may be the cause some overshooting at the lower settings, 7-9 lbs. But it seems to be holding right on at higher values. More testing... later today. I'll also try to get some video of it in the car on the road...

So, for < $100 I've got an EBC w/data logging. I've had the data logging capability working since December, yesterday was the first successful test of Arduino controlling the boost :).

Andy
Members don't see the above ad. Register now - it's free!
Andy
Club Member
 
Posts: 329
Joined: Sat Oct 30, 2004 12:50 pm
Location: Ohio

Postby Rick89GTS » Sun Mar 22, 2009 1:35 pm

Impressive.
You must have a background in computers/electronics/engineering?

Edit: ok, software programmer, I just read your profile
:)
User avatar
Rick89GTS
GTFour God
 
Posts: 3747
Joined: Sun Aug 08, 2004 6:28 am
Location: Great White North, Canada

Postby Andy » Sun Mar 22, 2009 1:49 pm

Thanks,
I work w/sofware and tinker with electronics.

About 3-4 years ago I built a FCD for my neighbors Track. That lead to this.... feeding the PIM signal into an LM3914 LED display driver chip
http://videos.streetfire.net/video/Toyota-Alltrac-custom_81858.htm

From there I'm now feeding the signal to the Arduino w/which I can now provide feedback to the Turbo VSV valve. Just like the ECU does.

Here are Screen snapshots that might show the data logs it a little better.

Set for 7# of boost. Note: boost values I see on the Arduino are just a tad higher than I see on my mechanical gauge.
Image

Set for 9# of boost, blip in upper referance line is where Boost setting was changed)
Image

Set for 14# of boost, just a couple of short quick test into boost, but notice on the second one, the TPS was essentially WOT. (graph scaling is still in development). Also on my mechanical gauge I was holding about 12-13 lbs, not 14, needs a tweak.
Image

Andy
Andy
Club Member
 
Posts: 329
Joined: Sat Oct 30, 2004 12:50 pm
Location: Ohio

Postby Andy » Fri Apr 03, 2009 2:41 am

I really meant to update this thread sooner with some more test results. I got some, however, testing is kinda on hold because my 21 year old brake lines are leaking. Well, at least one is... They'll all get replaced along with the fuel lines. Sucks, wasn't ready for that. Really only got to test the boost control aspect for about a week.

Here's a pic of LCD display, start up splash...
Image

I had one video attempt (lot of glare, bounce, etc, ) of it on the road, but its a QuickTime format and Streetfire compressed it so bad I deleted it.

But, I did shoot a video of the LCD display with the engine running... but just idling, again not what I wanted, but at least a quick & dirty of the LCD.
Vid: http://videos.streetfire.net/video/Arduino-Boost-Controller_643936.htm

There are several screens/displays that I toggle through

1st) Vac/Boost in large numbers, also on the right top/down are the boost setting, the Max boost measured, "Vac" for vacuum or "Bst" for boost, "Cls" or "Opn" Turbo VIS 'valve' state.

2nd) first line Boost setting, then "Vac In.Mg" or it will read "Boost #'s", third line is a bar graph of the Vacuum/Boost, forth line is the Turbo VIS valve state

3rd) Same as the 2nd, except the forth line is a bar graph of the TPS.

4th) This one is four bar graphs of the TPS, AFM, VAC, and WB O2 (WB O2 is not hooked up yet)

Not shown in the video is a display for the WBO2 signal and a display for setting the boost limit and dimming the display for nighttime.

Overall in the testing which I did get done it worked quite well. However, I wish it was a bit faster. I have seen a couple of small bumps in the boost, going just a bit higher than the setting. I've seen the boost jump by almost 10 lbs between samples, but Not exceeding the boost setting by anywhere near that.

I'm pretty sure this is due to processing speed. When I pull the data into the laptop I see a time between samples of about 240ms. It should run faster if/when it's not logging data (which it normally isn't). If I speed this up it then the reaction time will be much faster.

Solution: Ideally a faster Arduino. I've checked, there are Arduinos w/more memory, more A/D ports, but still running at the same speed. But, for $35 or so, I'll add a second Arduino to do nothing but control the boost while this one monitors everything, updates the LCD and provides the data logging. W/o the overhead the response time of the controller will get much better.

I did discover how to save better pics of the data on a PC. Below is an example, which also shows one of the 'bumps' over the boost setting. It starts just as the TPS starts to close and all w/in about 3 measurement/adjustment cycles....

Image

One thing I didn't get (yet) was a data log of a 'run' with the ECU regulating the boost.


What else?

I need to paint the LCD case, and add a few more tweaks the code and hardware. Maybe I'll put it in the 185 and log its HKS boost controller.

When I feed the WBO2 signal into the Arduino I get a reading of about 8 on both the WBO2 gauge and the Arduino/LCD. But, neither move, not good. I think I need to either add a small capacitor where it feeds into the arduino or us an A/B switch (Arduino or Gauge). I can still see real-time WBO2 on the laptop interface to the WBO2. Bringing it into the Arduino would then log it in sync with the other data values.

There's an Arduino project called "MPGuino" at http://ecomodder.com/wiki/index.php/MPGuino where they're using it to calculate real time MPG. Adding some of what they've got here would provide Injector duty cycle. +RPMs (but from my WB it looks like maybe they don't fire on deceleration, AFR=22, anyone know for sure?). This would also provide Speed and MPG...(haha)

These guys are using the duty cycle in their boost controller for a proactive response.... http://www.autospeed.com/cms/A_2541/article.html

For about $35 or so I could add a 3-axis accelomeer and get real time Gs.

But first, I need to spin by Summit Racing and pick up some $$ brake line tubing and get that project underway....

Andy
Andy
Club Member
 
Posts: 329
Joined: Sat Oct 30, 2004 12:50 pm
Location: Ohio

Postby mx6er2587 » Fri Apr 03, 2009 3:50 am

Very nice. I almost ended up building a boost controller (although nothing as fancy as yours) as part of an engineering project this year. I was outvoted by my group mates in favor of an automated blood pressure cuff. Lame.

I'm not familiar with the arduino how powerful are these chips, say in comparison to say a PIC?

edit: ah never mind they're atmel based. I'm surprised your controllers having trouble keeping up with boost control. I guess with all the bells and whistles you have your looking at a lot of overhead.

edit 2: whats your chip clocked at?
mx6er2587
Established Member
 
Posts: 1162
Joined: Sun Jan 27, 2008 12:08 am
Location: Pittsburgh PA

Postby Andy » Fri Apr 03, 2009 10:07 am

Thanks,

The key components are:

- an Arduino Duemilanove http://arduino.cc/en/Main/ArduinoBoardDiecimila
- a 4x20 LCD & LCD117 interface http://www.phanderson.com/lcd106/lcd107.html[/url]
- plus a Power Transistor (TIP102), to switch the turbo VSV selonoid on/off
Beyound that, some resistors and push buttons. The rest is in the code.

The Clock Speed is 16 MHz. There are a few Arduino variations, more memory, more i/o ports, but from what I've seen thus far they still run at 16 MHz.
It is quite fast, I don't think the camera captures every LCD refresh. The numbers change almost to fast to read with the eye. But, faster would always be better....


Andy
Andy
Club Member
 
Posts: 329
Joined: Sat Oct 30, 2004 12:50 pm
Location: Ohio

Postby Andy » Sun Apr 05, 2009 2:28 pm

About the Hardware......

Below is a schematic showing how I've currently got my Arduino wired up for boost control and data logging. It's actually kinda simple.

Image


The voltage and ground to the Arduino I take from the ECU +B and E2 to the Arduinos quick disconnect which provides internal power regulation.

Three wires are required to drive the LCD display, a ground, +5 Volts, and a (9600 baud Tx/Rs) signal wire, Arduino Pin 7. The +5 volts to the LCD is also used through the buttons to change menu displays and change settings. The buttons are connected to the Arduino Pins 5, 11,and 12, they are configured to be Inputs Currently the LCD display and buttons are mounted in a separate housing and are detachable. The Arduino continues to function normally while they are detached.

The ECUs VTA, VS, and PIM signals are taped into for monitoring of the TPS, AFM, and vacuum/boost. These three provide a 0-5V signals which are read directly into the Arduinos Analog to Digital converters. The A/D output value will be 0-1024, proportional to the voltage, and representing the sensors "value". The TPS VTA is straight forward, just convert to a percentage open. The AFM, VS, also simple, except it's reversed, as it "opens" the voltage drops. These two are only used for monitoring and logging. The PIM signal is the vacuum boost signal and neither gives a signal of about 2.5 volts, or a reading of about 512 in the Arduino. If below, 512 then translate it to In/Mg, if above the translate it to lbs/boost. Still simple, but different calculations (In/mg vs. Lbs boost) depending on the value.

The Turbo VIS VSV solenoid sire is a constant +12 volts and is normally grounded by the ECU to open the valve, which closes the wastegate to build boost. Its wire into the ECU, "TPC", is passed through the A/B switch to allow either the ECU or the Arduino to regulate the boost.

When the Arduino is regulating the boost... the +12 volts from the Turbo VIS VSV solenoid will routed to the "Collector" on the TIP102 transistor. The transistors "Emitter" is connected to a ground. The transistors "Base" is taken through a resistor to Pin 8 on the Arduino which is configured to be an Output signal. The transistors will only pass the +12 volts to ground "when" it has a 5 volt signal on the "Base". This is what I modeled after, http://www.arduino.cc/playground/uploads/Learning/solenoid_driver.pdf. (I do not have the diode they show, thus far no problems.) I chose this because of the amperage rating, "up to about 4 amps". Note: the actual transistor I'm using is a NTE 2343, due to availability/substitute by the local electronics shop, same basic NPN "power" transistor, easier to source.

Fundamental Software operation....

To regulate and control the boost, only the PIM signal is used. If the "boost" exceeds 2 lbs the digital output of pin 8, configured as Digital Output, is set High causing a 5V signal to be passed to the "Base" on the transistor, The transistor will then complete the connection between the Collector and the Emitter, this will cause the Turbo VIS VSV solenoid to activate, opening the valve from the manifold (w/+2lbs pressure) to the WG, closing the WG, to build more boost. When the "boost" exceeds the limit value then digital output pin 8 is set Low again, no voltage to the transistor it opens the connection between the Collector and the Emitter, the Turbo VIS VSV solenoid will de-activated, closing the valve to the manifold and WG, causing the WG to open and dump the exhaust pressure.

So, basically the code just spins in a loop performing the above to control the boost... But, as mentioned earlier, there is also the overhead of the other senses, updating the LCD display, and data logging if connected to a PC. Also, as it loops through, it checks the status of Pin 5, configured as Digital Input, if the button is pressed, then the code displays the next "screen". If it's on the "settings" screen then test Pins 11 & 12, also configured as Digital Input, and if pressed increase or decrease the settings value. Currently, boost limit or LCD brightness)

Data logging....
.
The USB port on the Arduino is used to log the data values onto a laptop PC. The Arduino will appear as a comm port to the PC. As mentioned earlier I wrote an application for the PC to read the data stream log it and generate graphs.


Improvements....

Where the code test for menu button press can be changed. Instead of testing Pin 5, every time through the loop I can move to Pin 2 or 3, which support interrupts and change the code to trigger an interrupt when the button is pressed. This will save the overhead of testing on each cycle. (had it like this once... it got changed for other testing.

The writing of the data to be logged is done in "little" chunks. I believe each "write" operation first "test" if the USB connection to a PC is active or not. So, if I combine the little chunks into one big chunk that test only happens once. Also, I can reduce the size of data, less equal faster.

The only actual "Time" measurements I have, thus far, are on the laptop as data arrives from the Arduino. I think I will add code to the Arduino to get a "time interval" measurement on the Arduino itself. This, I could then show on the LCD and then see what degree data logging affects the "time interval" between measurements/adjustments...

Here are couple more links about the Independent Electronic Boost Control (IEBC) using duty cycle and boost mapping.
http://autospeed.com/cms/A_2835/article.html
http://autospeed.com/cms/A_2542/article.html -- Intresting... Looks like a good product. But not as flexable as an Arduino.

I need to get some Zenier Diodes to add as they use in the MPGuino project. I would then have Injector Duty Cycle & RPMs w/which I could also potentially map the boost to the load... (and optionally Open the T-VIS plate at a whatever RPM I want)

I would think "load" is how the ECU is basing it's decision to open/close the WG. Two reasons: first from watching a light I had hooked up to the TPC wire. Second, if the ECU was using the TPC signal then FCD's would have more impact on boost than just raising the Fuel Cut. Which seems to be the only thing FCDs affect.


Andy
Andy
Club Member
 
Posts: 329
Joined: Sat Oct 30, 2004 12:50 pm
Location: Ohio

Postby lindsley » Fri May 08, 2009 10:20 am

Hi Andy,
I like the concept presented. CAn your idea be adapted to build a Wideband data logging Air fuel ratio meter?
lindsley
 


Postby Andy » Sun May 10, 2009 11:22 am

It should be able to monitor any 0-5 volt signal. My wideband is an Innovative, Summit Racing G2995, which outputs a 5 volt signal to it gauge. I've tried taping that signal with the Arduino. However, when I do the both the gauge and Arduino read a low value. I haven't yet tried but I believe the Arduino would see the signal OK if the signal was feed only to the Arduino. I may just need to add a capacitor near the Arduino... Or, I may need to add an A/B switch to the WB to then send the signal to 'either' the gauge or the Arduino, but not both at the same time.

All testing came to a stop when one of my brake lines on the 165 started leaking. It's a major pain to replace the brake and fuel hardlines...

If you are you asking it the Arduino could be used as the "controller" for a wideband sensor? That is it hooks directly to the WB Sensor and then provides the signal to the ECU? That's not so easy. Somewhere on the net I seen a DIY for this, but not with an Arduino.

To monitor and log the 0-5 signal from a WB such as the Innovative should be easy. The Innovative WB does that already. But it's then independent of everything else. I want the data logged in sync with everything else. Once I get the brake lines done I plan to try reading/logging the WB data as well.

Andy
Andy
Club Member
 
Posts: 329
Joined: Sat Oct 30, 2004 12:50 pm
Location: Ohio

Postby lindsley » Mon May 11, 2009 9:38 am

Thanks much for the response.
The two signals are low probable because the two circuits are placing to much load on the sensor.
You should be able to solve this by configuring a circuit with an OPAMP working as a Buffer.

All the best in your repairs and experiments
lindsley
 


Postby Andy » Tue May 12, 2009 9:33 am

Thanks,

I agree, I was also thinking the signal is to weak to drive both.
I'll look into using OPAMP sounds like a good solution.

I've got some LM10s on hand, but they take a 0-1 V input and amp it up 0-5 Volts. I can reconfigure the WB to output a 0-1V signal instead of 0-5V and then ues the LM10 to bring it back to 0-5 for the gauge and the Arduino. I like that....

The WB has an independent feed to the PC and their Logworks software so that will work for calibration and confirmation that I'm seeing things properly.


Andy
Andy
Club Member
 
Posts: 329
Joined: Sat Oct 30, 2004 12:50 pm
Location: Ohio

Postby redleader36 » Tue Jun 30, 2009 3:58 pm

Very impressive, andy. One of my best friends suggested using an arduino as a boost controller. I found your vid on streetfire and decided to look you up on alltrac.net.

Just a few questions. Is the stock pressure sensor accurate and responsive enough to run a boost controller? I remember hearing a while back that the stock alltrac map sensors are kind of slow to update and not very precise. Assuming that I don't use this on an alltrac, i would be using a gm 2-bar or 3-bar map sensor instead.

Also, are the stock solenoids responsive enough to keep from overboosting? I have a blitz ebc installed on my Talon with the stock Talon solenoid. I have to turn the resolution of the ebc way down to keep it from overboosting. Its just a slow responding solenoid. Just wondering if this is the case with the alltrac ones too.

Do you have arduino code or the datalogging program posted online anywhere?

Thanks in advance and keep up the impressive work!
redleader36
 


Postby MWP » Wed Jul 01, 2009 3:04 am

Well done!

Ive been wanting to make something similar for a while now.
My new ST185 came with a Blitz EBC though, so i might not get around to it.

I have been thinking about a electronically controlled & actuated BOV.
As you know BOV's are traditionally pressure operated which means they open later and for a shorter time than optimal.
My idea is to have a solenoid directly act on the BOVs piston, and then control it with a micro which reads the TPS & MAP signals.
Quickly closing the TPS with +psi from the MAP = BOV opens.

I have a few of these along with graphic OLED displays that would be perfect for it:
http://www.crystalfontz.com/product/DMOG19264ASTI.html
(they run a ATMEGA2561, with microSD slot for firmware loading & general file access... great for data logging)
MWP
Established Member
 
Posts: 1591
Joined: Mon Jun 01, 2009 11:02 am
Location: Adelaide, South Australia

Postby Andy » Thu Jul 02, 2009 1:51 am

Thanks guys,

On the "stock pressure sensor accurate and responsive enough to run a boost controller" ?
Toyota engineered it to provide consistent, accurate, and instant fuel cut on overboost. They seem to have done a pretty good job of it....

Earlier I mentioned the LM3914 chip driving the LEDs, it's reaction time is very fast. No "code" just hardware. Side by side with the mechanical gauge, my LED gauge seems to be every bit as fast as the mechanical gauge, maybe faster. So, yes on the stock sensor . I also did some of my testing with a Greddy 3 Bar sensor. For it I had to adjust the 'scaling' in the code to allow for extra 'bar' in the same voltage range. No biggie. Whatever sensor you use get the specs on it. Ideally a 0-5 volt output. Normally they are powered at 5 volts (not 12). With no vacuum or pressure it should output 2.5 volts... or there about. You can use a 5 volt voltage regulator to power the sensor with.

As part of my testing, before I ever put it in the car... I had an extra VSV. I wired it to spare battery (12 volt) and then to the transistor. I then wrote code on the arduino, just for testing, to pulse the transistor, thus activating the VSV, at variable speed and durations. It was also quite fast. I would think that the stock solenoids, if designed for boost control, should always be responsive enough to keep from overboosting.

I don't have any of the code posted anywhere, yet.....

On the BOV I think they look at the pressure difference between where they are mounted and at the manifold. Substituting the first with the TPS may be a trick. I would add a second MAP sensor at the BOV mount point first and then log the data, graph it and study it a bit first. Could be doable.

I'm thinking of using the TPS to preempt the little spike I was seeing when the TPS starts closing.. just haven't gotten to it yet....


Project Status:

I got the 165 back on the road a few weeks ago. New rear brake and fuel lines, new SS flex lines to the calipers, new side seals in the rear diff (but still have a tiny drip), and a new PS rack cause I don't want to deal with it later. Got it aligned, etc....

But, it's still not running, boosting, as well as it did. The above project was a pain, the engine was out and back in. But, not worked on, nothing should have affected the boost. However it seems that something has and I'm trying to resolve that issue before I try the Arduino again. It seems as if the wastegate is not closing. I put a MBC back in and it made no difference. Getting 6-8 lbs takes a long run out and the idle had gotten just a bit rough. No CELs. Checked the timing, it was off a bit (retarded), set it and it runs a tad better, but no change on the boost. I tried a different AFM, which changed the AFR a bit (leaner), but it still runs the same. It has a 2nd gen engine with an extended JDM harness and ECU so there could be an issue in there somewhere...

Hopefully, I'll find it this weekend...
Andy
Club Member
 
Posts: 329
Joined: Sat Oct 30, 2004 12:50 pm
Location: Ohio

Postby MWP » Thu Jul 02, 2009 10:34 am

Tried wiring the wastegate shut?
Itll quickly tell you if its a wastegate problem, or something else.
My collection of GT4 documentation: http://gt4.mwp.id.au
Daily: Celica GT4 ST185 (~170kw/atw)
Project: Toyota RA28 '77 Celica (1UZ-FE powered)
Chairman of the SA Classic Celica Club.
MWP
Established Member
 
Posts: 1591
Joined: Mon Jun 01, 2009 11:02 am
Location: Adelaide, South Australia

Next

Return to EFI Corner

Who is online

Users browsing this forum: No registered users and 1 guest