Idea for controlling the 3900 VVT/VI

[robertisaar]

and it's totally not ghetto either, i swear!

http://www.arduino.cc/

fairly cheap, has a 16MHz processor available, enough PWM controls for this and enough more to keep me busy...

from what i figure, i'll just keep the 7X crank sensor working with the OBD1 PCMs, and use the high res and cam sensors to do a compare, the same way the factory 3900 PCMs do... but at a much lower cost.

i'm still reading up on it and trying to learn the exact mnemonics, but this is looking to work perfectly...

is the cam phaser something that runs on 5V or 12V? i think the arduinos are only capable of 5V PWM... but i'm not exactly an expert on this type of stuff.

from what i've read, the variable intake is meant to run on 12V, but even with 5V it will still function correctly, just slower...

[Tijoe]

FYI, I just started another post where I am asking to get latest news regarding LZ9/3900 engines and the GMLAN control system.

[robertisaar]

FYI, I just started another post where I am asking to get latest news regarding LZ9/3900 engines and the GMLAN control system.

i saw it, but didn't really have anything to add to the thread based on the questions you asked.

i'm looking to control VVT and VI without any kind of restrictions(and the way i think it should be run) and with easily found, cheap, dependable hardware.

i'm not sure if the GM PCMs are capable of meeting all of those specifications...

[robertisaar]

this is what i've come up with thus far.

based on what i believe to be correct, VVT and VI should be easily controlled with the Arduino setup.

VI control should be based on the total amount of airflow in the system. when it reaches a certain point, it should open, bypassing the long runners that help develop torque in the low-RPM ranges. this exact point will depend on a few variables, mainly VE at specific RPM/MAP thresholds. less influential factors are air temp, humidity, altitude.

finding the optimal opening point would best be done on a dyno, running the engine twice, once with the valve open, once closed, and then compared to see where the torque curves overlap. the amount of airflow where the curves overlap is where the valve should open to allow the maximum amount of torque at all RPMs. a cheaper method may be to VE tune with the valve open and closed then make WOT runs and find where there is the greatest amount of fuel being injected. when the open runner condition has a larger amount of fuel being injected, there is more air being drawn in, therefore, a correct place to switch the valve. another method would be to install a MAF sensor and watch it's readings with the valve opened and closed while at WOT.

VVT is a related beast. and from what i can tell(with the stock cam), is essentially a power adder. retarding the cam adds power. it's therefore safe to assume that, at least with an automatic transmission vehicle, pressing the throttle down farther is telling the car you want more power. if the TPS signal can be tapped or copied, then retarding the cam based on TPS is a great idea. unfortunately, MAP does not always directly follow TPS. so the previous method will work great on a MAF based system. speed-density vehicles will need to reference MAP to accurately control the VVT function with success and consistency. it is safe to assume that when the engine is at barometric pressure(such as would be expected when WOT), the cam would best be fully retarded. full advancement may be more challenging to determine since idle does not happen at maximum vacuum. depending on many things, an engine could idle anywhere from 30-50kPa. since this difference will exist, even with seemingly identical engines, it would be best to individually tailor each VVT tune.

a lookup table for both can easily give all of the customization needed. a 2D table is sufficient for the VVT operation for both speed-density and MAF systems though a 3D table could be used to prevent and limit the amount of advance/retard allowed based on RPM. a constant/scaler could also be used to make a minimum RPM theshold for the 2D table. a 3D table would likely be necessary for VI operation in a speed-density system, though a MAF system could get away with a 2D table referincing just airflow. a speed-density could also just have a scaler/constant that is intended as an activation threshold, and then copying the main and base VE tables from the ECM into the Arduino and having it calculate airflow. the issues with this is using CPU cycles and the fact that O2 correction cannot be taken into account.