algorithm or preset

Sort of like this:
algorithm: A + B = C
data: A = 2, B = 2 - result: C = 4
data: A = 2, B = 3 - result: C = 5
Or, fuel_rate = engine_RPM * ( k * engine_load ) where k is a constant stored as a part of the program. Change k, the result changes.
The structure of the control programs in the car is somewhat different from more familiar programs. Think of a number of little parts, each to take care of a particular function rather than one big program. Generally, such programs rely on tables of data as much as possible - that makes it easier to change, and somewhat more predictible and easier to troubleshoot.
As an example, consider the timing. There are a pair of advance tables, one for low-octane fuel and one for high-octane fuel. The computer starts out using the high-octane table but switches to the low-octane table if excessive knocking is detected. The tables contain some values based on load and RPM, the algorithm interpolates the real-time data to the table data and sets the timing advance accordingly.
So you can change the data in the high-octane table, say to optomize for 93 octane as opposed to 91 octane fuel without touching the code or the low-octane table. This would be a reasonable thing to tune if you live in a 93 octane state. You may get a little better performance, but you still have the low-octane table as a fallback if you have to fill up with skunky gas. What you lose is best performance on 91 octane gas, so you'd want to undo the change if you moved to Ca.
This covers mainly predictive operation. In many cases the program uses heuristics, that is to say it learns. The switching to the low-octane table is a simple example of this - the car learns that the gas sucks and responds accordingly. Actually, the car learns a lot, especially in closed-loop mode (using the O2 sensors to monitor air/fuel ratio) and stores what it learns as trim numbers - how much less or extra fuel to give it. So many of the possible table changes apply mostly to open-loop mode, which is how the car runs before it warms up and at WOT.
Of course operation at or near WOT is often what we're most interested in, even though it's really an unusual operating condition. Sort of funny. Maybe we'll be able to get some of the folks that really know what they're doing to post some more info on the subject of tuning.

Sort of like this:
algorithm: A + B = C
data: A = 2, B = 2 - result: C = 4
data: A = 2, B = 3 - result: C = 5
Or, fuel_rate = engine_RPM * ( k * engine_load ) where k is a constant stored as a part of the program. Change k, the result changes.
The structure of the control programs in the car is somewhat different from more familiar programs. Think of a number of little parts, each to take care of a particular function rather than one big program. Generally, such programs rely on tables of data as much as possible - that makes it easier to change, and somewhat more predictible and easier to troubleshoot.
As an example, consider the timing. There are a pair of advance tables, one for low-octane fuel and one for high-octane fuel. The computer starts out using the high-octane table but switches to the low-octane table if excessive knocking is detected. The tables contain some values based on load and RPM, the algorithm interpolates the real-time data to the table data and sets the timing advance accordingly.
So you can change the data in the high-octane table, say to optomize for 93 octane as opposed to 91 octane fuel without touching the code or the low-octane table.
does this imply that the tables are (re)built by the car then it uses the tables to tune itself then adjusts the tables as needed ? wow !!! not bad..
can you explain to me what the "tuners" tune. what are they modifying ?? are they creating values for the tables then telling the computer to use those tables or do they modify k ?
Normally, the A/F ratio is based on the MAF (Mass Air Flow) sensor and backed up by the speed / density calculation. This is able to handle the range from a few CFM at idle to some 600+ CFM at 6000 RPM WOT. The small difference made by a different air intake shouldn't get it all a-flutter. But a discrepancy between the MAF and calculated value will throw a code, and with good reason - something's wrong.
Do you know what code or codes you got? Most "lean" codes would be associated with the heated O2 sensor, but the cause would usually depend on other codes. For example, a P0131 H02S low code plus a P0101 MAF rationality code would indicate a lean condition due to a defective MAF.
mmmm..... learnnnnsssss....mmmm....
does this imply that the tables are (re)built by the car then it uses the tables to tune itself then adjusts the tables as needed ? wow !!! not bad..
can you explain to me what the "tuners" tune. what are they modifying ?? are they creating values for the tables then telling the computer to use those tables or do they modify k ?
The tuner would probably be modifying 'k' - or the content of the tables, it's really the same thing. This is part of data the computer uses to base it's calculations on, but only part. The learned data is factored in, as are a number of measured parameters (like engine temperature, altitude, etc.)
As in the example, changing a 91 octane timing table to a 93 octane timing table may improve performance a bit for someone who uses 93 octane gas. And the factory tables may be a little conservative anyway. But then this data would be factored in with the learned data (and a lot of other measured data, like the engine temperature) to calculate the actual timing. Much more complex than the old two weights and springs in the distributor! But much better able to get the timing right on. On the other hand, you can't tune it by stretching the spring a little bit!
So the tuner is mostly changing the basic assumptions, usually to make them a bit less conservative, or to accomodate changes to the car like headers or a cam. I'd imagine the amount of good done by tuning depends on the mods. Mods that affect a particular condition or RPM range (like a cam) would benefit most, because the change is more complex and the car's learning is less able to make up the difference.
Of course if you're really serious about it, like davidfarmer, you're going to want to gather a lot of data before changing anything. The more data the better you can tune your car to your own mods and driving style. And ideally you'd then gather more data to see how successful your changes have been.
Important things here are the long- and short-term fuel trims - the "fudge factors" the computer applies to get the right amount of fuel. Incidentally, there are separate ones for the left and right banks. If these numbers are too high you may improve operation by tweaking up the tables a bit. But be careful! If things start to not make sense - for example the long-term and short-term fuel trims don't agree, or the left and right fuel trims don't agree, you'll get a code and the dreaded "Service Engine" light.
The Best of Corvette for Corvette Enthusiasts
http://forums.corvetteforum.com/show...1&forum_id=101
Or check with ron@proautotech (tuner) who might be able to shed some light on this. As far as I know, a new intake or removing the screen shouldn't break it, but the MAF is very sensitive to contamination - a little bit of oil can throw it off.
There is another thread here that mentions an inexpensive (under $100) Innova (or something like that) code reader (just reads codes, doesn't log data, etc.) available at MallWart .. er, WallMart. I haven't tried it, but it might be worth it here to get more info.
My LS-1 with auto transmission idled even slower - around 550 RPM - but it had less cam and was a little smoother.
Some folks on the forum have called the C6's idle rough; to me it's about right for a performance engine - not Rolls-Royce smooth, but easy enough to live with.
Again, thanks for your help. I found a tuner/mod shop on the forum that is local, going to see them tomorrow. My best bet is to let someone who knows what they are doing work on my baby. Wish I had the time to learn . . .










