If Ex is supposed to be VTA why did you tee it in between your metered intake and intake manifold?

Metered air is ATM, but it prevents a vac/boost leak. Intake manifold is a vac source so it can pin the WG open during cruise. The check valves are there to prevent both sides of the WG diaphram from seeing boost pressure and failing it shut. This lets me run WG open during cruise, pin shut during spool and modulate when at setpoint.

https://cimg3.ibsrv.net/gimg/www.rx8...57a5e0c1a6.jpg


any updates?

Yeah, got halfway through redoing all the electronics, the water tank, and replacing the wastegate, then went back on my shift rotation. I have a few days off and should be updating soon.

The setup under the hood still looks like crap, but the electronics package is clean, and I'm willing to show my trunk tank now. :)

Here is what has kept me down: PTP turbo kit exhaust manifold was threaded for what I think WAS 5/16.

Guess who put the m8 bolts into the exhaust manifold... Now I'm gonna just convert the threads. Yes it will lose some bite on the threads, but the two are close enough (especially now) that I don't think it matters. The other options are to pull the manifold then drill out and re-tap the holes larger, or drill out just use a bolt and nut.

It's darn hot out there though, so I'm waiting until I have everything in hand to button it all up.

I'm also rethinking a lot of the electronics. After viewing the specs on a teensy 3.1 I'm now planning on using one in conjunction with an arduino. I can get rid of several of the analog inputs and associated conversion tables and just use the CAN bus values for MAF, IAT, RPM. It may also be possible to add new PIDs for Manifold pressure, knock, water injection rate, and WG demand. If that works the new PIDs should be readable with any car scanner for logging. Long term I'll also be looking at controlling the Oil pressure gauge. Could use the teensy alone to control everything, but the next version will be a hybrid to avoid converting the analog inputs to 3.3volt compatible and I haven't figured out how to control PWM frequency on the teensy.

When I get everything back up it will be time for the real fun. Until then here is a pic of my ugly water tank. Paint once for rust, twice for dust, and three times for water tightness.

isn't that a particle accelerator??? :p:

Wastegate is installed and car is running. After learning more about the PWM on the teensy, I'm ditching the Arduino completely. Did my first hello world sketch tonight, will be trying OBD2 either tonight or tomorrow. I'm really optimistic about getting new PIDs for logging.

Hardware limited on creating PIDs for the can bus right now. Turns out I needed a converter board which is now placed on order, but I've gone ahead and modified some code so I should be able to add any PID the ECU doesn't already provide. Waiting to install the electronics packages as a complete unit with code. I think this will be the final revision. Already planning to add oil temp, pressure and trans temp PIDs.

Just spent an afternoon writing a odb2 engine simulator and creating new PIDs in torque. I've created several hardware revisions that I'm not satisfied with, but I'm getting close to what will go into the car permanently. Now I need to try plugging the hardware to the CAN bus and reading the new PIDs with it in the car.

Trial and error in the pursuit of perfection. :)

Connected it to the car and both read Existing PIDs and created new ones. The ECU simulator let me test it all in the air conditioning and it worked first try. Now to finish the hardware. I'm setting it up with 8 analog inputs, 5 PWM outputs to MOSFETS, and a couple spare digital outputs. If I need to add any hardware I'll run a second processor with i2c on a separate board. This way I won't have to pull the thing to upgrade if I decide to add sensors or any extra outputs.

I also figured out how to send raw OBD2 commands via torque and decode them so I can now set my boost setpoint from the phone, or water injection rates. This should allow for changing things on the fly without a complicated interface.

One step forward two steps back. I'm troubleshooting an obd2/CAN problem. If I request MAF or RPM from the ECU as often as I need to control boost/Water injection then the blue tooth obd2 adapter goes crazy and either won't read or reads some values wrong. It's quickly turning into a catch 22, either have everything work right or be able to log the correct values.

Still looking for an easy fix.

Edit: It's an issue with the ELM327 adapter, and any others using the same interface style. If you poll a PID that it's looking at too many time it will flood the adapter and prevent it from seeing anything else, it also causes some garbled data. Not a CAN problem.

I can't run cobb and goodbox at the same time or they both freak out. MY info screen goes all slott machine and the cobb pulls crap data.

Don't know if this helps any.

Yeah, it's a similar issue. I finally set it to poll RPM every second if it doesn't see the info. That way it won't cause an issue if an obd2 adapter is plugged in. I'll just get MAF with an analog input like before. Other alternative is to use either the E-shaft or ignition coil signal to get actual rpm. We'll see. Wasted two days trying to get this to work.

I wouldn't say wasted, this is all valuable whether proving or disproving. Annoying for you maybe but thanks for letting us know in any case.


A while ago we were looking at an OBD sensor interface that would sit on the bus and inject oil pressure and temp readings - we found a manufacturer (in the UK IIRC) that had just the module (it would measure and report anything) but they weren't interested in supplying us with just a few units. Such a shame.

Anyway I've been following silently up to now but just wanted to say good work, fascinating stuff.

I have exactly that working right now. Should be able to do it with under $40 of hardware. Pm me if you want code. Eventually I'll add it to the arduino diy thread.

Mega Update:
Had the car down a couple days for a suspected vacuum leak. After using every trick I could think of I started suspecting the MAF sensor, when I pulled it the problem was obvious. Turned out to be a Fram air filter problem...

The electronics are done ready for install. Everything has been bench tested. I have two boost setpoints one for 4k and one for 8k they can be configured via Torque. The 4k setpoint is for 4k and below, the 8k setpoint is for 8k and above, and in between it interpolates based on rpm.

WI can also be set in Torque, default is 25% but at the push of a button it can go to any value I set. A value is also give for actual water injection demand in g/min. It even has a test button so I can unplug the preturbo elbow and measure flow for 15sec to determine the flow rate.

New PIDs are availible for MAP sensors (pre and post TB), water injection demand, water injection %, WG demand, fuel pressure , and knock. And there are 8 total analog inputs for other sensors (5 still unused.) There is one digital output for a lockout relay, four MOSFET tied outputs for WI, WG, PWM control of the fuel pump, and one spare.

Now to fight the heat and get it installed so I can go back into boost.

Fram makes garbage? Who knew? :dunno: :lol:

Yeah, they make crap filters of all kinds. It was what I found first and I thought with an air filter I'd be safe...:lol:

Hardware is in the car now, but I keep having a reoccurring issue with the knock sensor. For some reason it fails to initialize and I have no idea why, it will work perfectly a dozen times and then refuse to work at all. Its connected with ICSP and everything apears to work correctly but it keeps having the same exact reading and won't update. So.... No boost yet.

Awesome work Haralan! This takes dedication :)

Think I found the problem, it a hit or miss in SPI due to interfacing a 3.3 and 5volt chips. Looking for an easy workaround. Also trying to diagnose a P1687 for the MOP.

Tried the knock sensing chip at 3.3 volts. It ran fine but same issue. It all stems from getting the chip (TPIC8101) into advanced mode so I can read knock values directly. For whatever reason some code gets it there, some doesn't. It's not the actual command I'm sending the chip but rather something else causing interference. Maybe it's one of the PWM pins, or maybe the CAN interface, but I'm having no luck tracking the issue down. At this point I don't even know if it's software or hardware. Could even be a compiler issue.

So I'm reworking the hardware to run the knock chip with a 5volt Arduino micro which has never failed. This also gives me PWM pins of the proper frequency and a 5volt analog in. Still running CAN off the Teensy to keep the refresh rate up, and because it works well.

Tying it all together with I2C, which will allow for more hardware later.

Haven't checked the OMP yet, but I suspect an issue in the wiring. Some of it was getting close to exhaust piping. May have to rewire and shield better.

OMP was just a bad connection. May have to soldier the wires to the connector like I did with the power steering connectors.

I have my first set of logs from the new setup. Everything reads well, and the teensy can reply to OBD2 requests just as fast as the ECU, so logging is beautiful. I'm having problems with I2C between the chips. If I can't figure out the hardware/software issue gonna rework the system to serial.

Two steps forward, one step back. Will post pictures on Monday when I have a day off.

I'm jealous. I really admire electronics wizards like yourself!

PC817 and a isolated 5v power supply. 24v-5v 1.5a for your PWM outputs to prevent feedback and making notice and freaking out the PCM.