Dumb beginner questions...

[Rich Z]

I seem to have a lot of these, so perhaps I can just group them together here in one thread.

Number 1: I have electronic throttle control on my C5 vette, and notice that my throttle position doesn't go below something like 14 percent EVER. So I'm looking at various idle related tables that are apparently using throttle position as a trigger to select values in those tables, and they might range from 0.00% to 1.50%. Since my throttle position NEVER goes that low, what exactly does this mean to me? Are those tables NEVER used, or is there some sort of calculation done behind the scenes to produce a relative percentage somehow?

[Rich Z]

Number 2: I have a COS2 OS (I think) and am running in semi-speed density, apparently. When tuning the VE table, does the MAF need to be physically disabled, or can that be done simply by failing it in a table somewhere? Along the same lines, do I have to do ANYTHING about calibrating the MAF table? And do ALL fuel modifiers, including STFTs need to be disabled?

[ScarabEpic22]

1. Since it is DBW, the PCM uses the throttle blade to control the idle airflow instead of using an IAC valve on a cable throttle body. There is conflicting information about what the low TPS values mean, Ive heard they're absolute and that they're idle TPS minus desired TPS (so 14% TPS as idle and 6% of desired TPS = 20% TPS), I dont know for sure.

2. COS2 wasnt released "into-the-wild", so Im betting you have COS3. It depends on the MAF, sometime you can fully disable it in the tune and other times it will remain active even when you disabled it (in this case, you need to physically unplug/disable it). Yes, you need to calibrate the MAF curve at some point, unless you plan on staying full SD. The AutoVE (not Calc.VET) tutorial has the info on what tables need to be changed to disable the MAF. There are a few ways to tune the VE and MAF tables, AutoVE which requires DFCO, CFCO, LTFT, STFTs, COT, etc to be disabled and Calc.VET which doesnt need anything to be disabled. Those are the 2 most popular methods on here right now.

[joecar]

#1: GM.TP will show a minimum of 14% or so... try GM.ETCTP.


#2: If a MAF DTC is present, then you're running in SD (i.e. from the VE only)... you can make the MAF fail by editing the MAF low fail table (C2901-3).

If you want to run combination VE/MAF or MAF only then you have to calibrate the MAF table also (when calibrating the MAF you must disable VE).

If you're using a wideband for calibrating, then you must disable CL/LTFT/STFT/SOL (i.e. anything that corrects fueling ahead of your wideband).

[joecar]

More info: see posts #4 and #29 here: Summary-Notes (http://forum.efilive.com/showthread.php?14188-Summary-Notes)

[Rich Z]

Arghhh.. OK, maybe it's COS3?

As for the MAF, C2901 and C2904 are both set at 13500, so I guess that means the MAF is failed then? I checked the P codes for the MAF and they are all set to "No MIL".

So CAN I disable the MAF input to the PCM merely doing it programmatically? Since I've got the combo MAF/IAT sensor with a 5 pin connector, it's not like I can just pull the plug to physically disable the MAF without my IAT's being crazy.

I'll try that GM.ETCTP and see if that looks better to me.

Thanks!

[ferocity02]

Check out the COS tutorial, it describes how to fail the MAF in the tune. I unplugeed mine as well, but I wired in a separate IAT sensor into the manifold.

[joecar]

Arghhh.. OK, maybe it's COS3?

As for the MAF, C2901 and C2904 are both set at 13500, so I guess that means the MAF is failed then? I checked the P codes for the MAF and they are all set to "No MIL".

So CAN I disable the MAF input to the PCM merely doing it programmatically? Since I've got the combo MAF/IAT sensor with a 5 pin connector, it's not like I can just pull the plug to physically disable the MAF without my IAT's being crazy.

I'll try that GM.ETCTP and see if that looks better to me.

Thanks!
Doesn't matter how you fail the MAF (physically, programmatically, other), the MAF is not considered failed until a scantool can read a MAF DTC as being currently present (regardless of C6002 being set to No MIL).

If you don't get an immediate MAF DTC, then look at C6001 (set to it to 1-Trip) and look at C2901-3 (set the threshold so that the MAF will fail).

[joecar]

The COS tutorial and the AutoVE tutorial both describe how to fail the MAF programmatically.

[Rich Z]

#1: GM.TP will show a minimum of 14% or so... try GM.ETCTP.



OK, so I used GM.ETCTP and I'm getting the same thing I did before. Foot off of the gas pedal shows a throttle position of 14 percent, MINIMUM.

What does this do for any PCM calculations that are based on throttle position? Seems that every table I recall seeing using TP shows MUCH lower percentages when referencing an idle condition.

Yeah, I've got to read over the tutorials again. Just too much to swallow the first few times through.

Thanks.

[Rich Z]

OK, time for a new question.

Number 3: I've read many times here to try to keep the PID channels to 24 or below because the sampling rate during data logging is slower when at 25 and above.

But when is this REALLY important? I can see when data logging for VE values so you get more map cell hits per RPM range, but when else is this an important consideration? What essential FAST transient conditions might get missed if they fall inbetween samples that are important to keep in mind?

Yeah, I know the more data samples the better, but I can see where their might be times that I might want MORE channels to collect more data streams during a log, so trying to figure out where the tradeoffs need to be taken into account.

Truth be known, I would rather capture ALL of the data streams in a log, and then simply filter which ones I want to look at at the dashboard and map level (instead of the PID data level) when I am analyzing the data after the log was taken. This just seems to be a better utilization of my time than making multiple passes for data logs, setting up the needed subset of PIDs for each subsequent run, and HOPING that I have all the data collected in the same run that I might want to compare the interactions of at a later date. Obviously some of the PIDs will have to be duplicated in each run, regardless, which is just a waste of bandwidth. Anyone who has done database programming probably understands my perspective of this.

[Wheelz]

OK, so I used GM.ETCTP and I'm getting the same thing I did before. Foot off of the gas pedal shows a throttle position of 14 percent, MINIMUM.

What does this do for any PCM calculations that are based on throttle position? Seems that every table I recall seeing using TP shows MUCH lower percentages when referencing an idle condition.

Yeah, I've got to read over the tutorials again. Just too much to swallow the first few times through.

Thanks.

The ETCTP is the actual blade position. Since your car is drive by wire the computer holds the blade open instead of an IAC to maintain idle. You don't want to see this PID go to zero because it means the blade has closed off the throttle body so no (well, minimal really) air can pass through. The best I can tell the ECM blends the offset in so you don't notice it going away.

Don't worry what those tables show for blade position at idle. The ECM learns how to idle smoothly. The closer the tables are to what it's running now will only reduce the amount of time it takes the engine to learn how to idle again (which on the LS1b it forgets every time you full flash the ECM or leave it off the battery for an extended amount of time).

Don't worry about what the blade is doing when tuning idle conditions (as long as you have decent vacuum). The ECM will figure out how to get it enough air. You just have to tune spark and mixture.

[darcy]

GM.APP (Accelerator Pedal Position) seems to tie up with the idle parameters (cracker/follower) that I see.

[ferocity02]

OK, time for a new question.

Number 3: I've read many times here to try to keep the PID channels to 24 or below because the sampling rate during data logging is slower when at 25 and above.

But when is this REALLY important? I can see when data logging for VE values so you get more map cell hits per RPM range, but when else is this an important consideration? What essential FAST transient conditions might get missed if they fall inbetween samples that are important to keep in mind?

Yeah, I know the more data samples the better, but I can see where their might be times that I might want MORE channels to collect more data streams during a log, so trying to figure out where the tradeoffs need to be taken into account.

Truth be known, I would rather capture ALL of the data streams in a log, and then simply filter which ones I want to look at at the dashboard and map level (instead of the PID data level) when I am analyzing the data after the log was taken. This just seems to be a better utilization of my time than making multiple passes for data logs, setting up the needed subset of PIDs for each subsequent run, and HOPING that I have all the data collected in the same run that I might want to compare the interactions of at a later date. Obviously some of the PIDs will have to be duplicated in each run, regardless, which is just a waste of bandwidth. Anyone who has done database programming probably understands my perspective of this.

The 24 limit has something to do with how many PID's can fit on one channel or something. So more than 24 and you need another channel which drops the sample rate. If you're doing tuning and need to hit as many cells as possible with as much data as possible then the faster sample rate is very important, especially at high RPM or in boost where you don't spend much time at all. Generally speaking, you can capture most vital information for tuning in 24 PIDs. But sometimes you will be curious about another PID and want to log it as well.

One thing I don't know about is if calc pids will slow down the sample rate. Lets say you log 20 PIDs from the PCM and 5 calc PIDs... the total is over 24 but calc PIDs are calculated in the scan tool, so maybe they don't use an actual slot. You can also select cals PIDs after logging if you have logged the data that the calc PIDs need.

[ScarabEpic22]

Calc PIDs do not slow anything down, look at the channel count = 0. PID count doesnt matter, it's the channel count that needs to be less than 24 for VPW controllers for fastest frame rate. V7.5 can only do up to 24 channels at high speed, V8 will have the ability to do more (like V2 BBL'ing does now).

[darcy]

V7.5 can only do up to 24 channels at high speed, V8 will have the ability to do more .

24 channels is still a hardware limitation of the LS1B, I think you'll find, Erik.

[Rich Z]

As I've been reading over this tuning stuff, I was finding myself stumbling sometimes over the various acronyms these guys would throw around with wild abandon that I didn't have a clue about what they meant. So I had to make up a cheat sheet that I could refer to when I hit one I didn't remember what it actually meant.

A

ABS - Antilock Brake System
AFR - Air Fuel Ratio
AIR - Secondary Air Injection


B

BARO - Barometric Pressure
BCM - Body Control Module
BEN - Base Efficiency Numerator
BHP - Brake Horsepower


C

CAC - Charge Air Cooler
CARB - California Air Resources Board
CAS - Crank Angle Sensor
CC - Catalytic Converter
CCP - Controlled Canister Purge
CCV - Canister Control Valve
CFI - Continuous Fuel Injection
CFM - Cubic Feet per Minute
CID - Component ID
CID - Cubic Inch Displacement
CKP - Crankshaft Position
CL - Closed Loop
CMP - Camshaft Position
COP - Coil On Plug Ignition
CP - Canister Purge
CTP - Closed Throttle Position


D

DBC - Drive By Cable
DBW - Drive By Wire
DFCO - Deceleration Fuel Cut Off
DFI - Direct Fuel Injection
DMA - Direct Memory Access
DTC - Diagnostic Trouble Code
DTM - Diagnostic Test Mode


E

EBCM - Electronic Brake Control Module
EBTCM - Electronic Brake Traction Control Module
EC - Engine Control
ECL - Engine Coolant Level
ECM - Engine Control Module
ECT - Engine Coolant Temperature
EECS - Evaporative Emissions Control System
EFE - Early Fuel Evaporation System
EFI - Electronic Fuel Injection
EGR - Exhaust Gas Recirculation
EGRT - Exhaust Gas Recirculation Temperature
ESC - Electronic Spark Control
EST - Electronic Spark Timing
ETC - Electronic Throttle Control
EV-ETS - Electric Vehicle Energy Transfer System
EVAP - Evaporative Emission System
EVRV - Electronic Vacuum Regulator Valve for EGR


F

FFTC - Freeze Frame Trouble Codes
FI - Fuel Injection
FT. LB. - Foot Pound
FT - Fuel Trim
FTC - Fuel Trim Cell #
FUBAR - Farked Up Beyond All Recognition


G

GND - Ground
GPS - Grams Per Second
GVM - Gross Vehicle Mass


H

HEGO - Heated Exhaust Gas Oxygen Sensor
Hg - Mercury
HO2S - Heated Oxygen Sensor
HVAC - Heating Ventilation and Air Conditioning


I

IA - Intake Air
IAC - Idle Air Control
IAT - Intake Air Temperature
ICM - Ignition Control Module
IFI - Indirect Fuel Injection
IFS - Inertia Fuel Shutoff
IGN - Ignition
IIIBDFI - If It Isn't Broke, Don't Fix It
ISC - Idle Speed Control


J

K

kHz - Kilohertz
KISS - Keep It Simple, Stupid
KOEC - Key On, Engine Cranking
KOEO - Key On, Engine Off
KOER - Key On, Engine Running
kPa - Kilopascals
Km - kilometers
KR - Knock Retard
KS - Knock Sensor
KSM - Knock Sensor Module


L

LTFT - Long Term Fuel Trim
LTIT - Long Term Idle Trim


M

MAF - Mass Air Flow
MAP - Manifold Absolute Pressure
MDP - Manifold Differential Pressure
MHz - Megahertz
MIL - Malfunction Indicator Lamp
MPG - Miles Per Gallon
MPH - Miles Per Hour


N

NOX - Nitrous Oxide


O

O2S11 - O2 Sensor Voltage Bank 1, Sensor 1
O2S21 - O2 Sensor Voltage Bank 2, Sensor 1
OBD II - Onboard Diagnostics, Second Generation
OEM - Original Equipment Manufacture
OL - Open Loop


P

PAIR - Pulsed Secondary Air Injection
PCM - Powertrain Control Module
PCV - Positive Crankcase Ventilation
PFI - Port Fuel Injection
PID - Parameter Identifier
PRN - Parameter Reference Number
PTC - Pending Trouble Code
PWM - Pulse Width Modulation


Q

R

RAFIG - Required Air Flow In Gear
RAFPN - Required Air Flow In Park/Neutral
RAM - Random Access Memory (read/write)
ROM - Read Only Memory
RPM - Revolutions Per Minute (Engine Speed)


S

SAE - Society of Automotive Engineers
SC - Supercharger
SFI - Sequential Fuel Injection
SLOT - Scaling, Limit(s), Offset and Transfer
SMS - Specifically Monitored Systems
SPARKADV - Spark Advance
SRS - Supplemental Restraint System
SRT - System Readiness Tests
STFT - Short Term Fuel Trim
STIT - Short Term Idle Trim


T

TAC - Thermostatic Air Cleaner
TAC - Throttle Actuator Control
TB - Throttle Body
TBI - Throttle Body Injection
TC - Turbocharger
TCM - Transmission Control Module
TID - Test ID
TP - Throttle Position
TPMS - Tire Pressure Monitor System
TPS - Throttle Position Sensor
TVV - Thermal Vaccum Valve


U

USB - Universal Serial Bus


V

VIN - Vehicle Identification Number
VPW - Variable Pulse Width
VR - Voltage Regulator
VSS - Vehicle Speed Sensor


W

WOT - Wide Open Throttle
WSS - Wheel Speed Sensor


X

Y

Z

If you guys see any errors or needed additions, please let me know. I will edit this list as necessary to make corrections or additions.

[Rich Z]

Next question.

I'm looking at the timing tables, and there are several things that confuse me. First off there are several timing tables, so trying to figure out which one is actually in control is baffling.

I decided to try my hand at creating a map with the intention of SEEING what the timing advance actually is at any given RPM/manifold vaccum cell. But I ran into a problem.

Looking at B5932 (Base Spark in Gear) the columns are showing GM.DYNCYLAIR.DMA with values ranging from 0.003 to 0.042. When I created a map based on this table and did some logging, the only column that shows any values in it is the column for 0.042. All the rest of them are blank. Now when I look at my Data tab on the dashboard, I see that the values shown there for GM.DYNCYLAIR.DMA ranged from a low of 0.07 to a max of 1.12. Yeah, I went into boost a little bit. :) On my dashboard chart for this PID, it is showing a min of 0.00 to a max of 3.00.

There seems to be a factoring problem between the tables utilizing GM.DYNCYLAIR.DMA and the scanner pages trying to capture these values. It looks like the entire Base Spark in Gear table will never be exposed to the values of the data actually captured by GM.DYNCYLAIR.DMA. Obviously I am doing something wrong here, but I just don't know WHAT.

http://www.corvetteflorida.com/pics/DYNCYLAIR_DMA_01.jpg

http://www.corvetteflorida.com/pics/DYNCYLAIR_DMA_02.jpg

http://www.corvetteflorida.com/pics/DYNCYLAIR_DMA_03.jpg

http://www.corvetteflorida.com/pics/DYNCYLAIR_DMA_04.jpg

http://www.corvetteflorida.com/pics/DYNCYLAIR_DMA_05.jpg

http://www.corvetteflorida.com/pics/DYNCYLAIR_DMA_06.jpg

http://www.corvetteflorida.com/pics/DYNCYLAIR_DMA_07.jpg

http://www.corvetteflorida.com/pics/DYNCYLAIR_DMA_08.jpg

Can someone point out to me what I am doing wrong here?

[darcy]

Look at your units, Rich.

You're logging DYNCYLAIR_DMA in Grams/Cyl, you're table is showing Oz/cyl.
There is ~10:1 between values.

If you want to see exactly where spark is coming from log all the GM.EST_xxx_DMA pids.

[ScarabEpic22]

24 channels is still a hardware limitation of the LS1B, I think you'll find, Erik.

Re-read my last post Darcy, I said VPW (LS1B, P10, etc) can only do 24 at high fps. BUT, I agree, I wasnt \clear when I mentioned that V8 will be able to do more than V7.5. This only applies to CAN controllers.

Rich, Ive been tripped up by units as well. Have to make sure everything is set correctly in the scan and tune tools, otherwise nothing makes sense!

[joecar]

Scantool:
on PIDs tab make sure that pid has Metric units (g/cyl).

Tunetool:
- go Edit->Configure Display Units
- click on the Data column heading twice (sorts on that column), find all the Oz/cyl items in that column, highlight them all and do rightclick->Data Units->Metric.
- repeat the previous point for Row and Col columns (except do rightclick->Row Units->Metric, and Col Units).
- click ok,
- restart tunetool.

[joecar]

Scantool map:

after you set the Oz/cyl to g/cyl in the tunetool, you have to re-step the map columns...

in tunetool goto that table, rightclick in upper left corner between axes (blank tile) and do copy-with-labels;

in scantool goto that map's properties, goto the Col tab, click Paste Labels, save the map.

[joecar]

Also (to help you and me), in the map properties, on each of the Data, Row, Col tabs, click Show Units, save map.

[Rich Z]

Look at your units, Rich.

You're logging DYNCYLAIR_DMA in Grams/Cyl, you're table is showing Oz/cyl.
There is ~10:1 between values.

If you want to see exactly where spark is coming from log all the GM.EST_xxx_DMA pids.

Arghhh.... I figured I was overlooking something simple. Thanks!

I'll have to look over those PIDs you pointed out. That's new territory for me.

Thanks.

[Rich Z]

Scantool:
on PIDs tab make sure that pid has Metric units (g/cyl).

Tunetool:
- go Edit->Configure Display Units
- click on the Data column heading twice (sorts on that column), find all the Oz/cyl items in that column, highlight them all and do rightclick->Data Units->Metric.
- repeat the previous point for Row and Col columns (except do rightclick->Row Units->Metric, and Col Units).
- click ok,
- restart tunetool.


Scantool map:

after you set the Oz/cyl to g/cyl in the tunetool, you have to re-step the map columns...

in tunetool goto that table, rightclick in upper left corner between axes (blank tile) and do copy-with-labels;

in scantool goto that map's properties, goto the Col tab, click Paste Labels, save the map.


Also (to help you and me), in the map properties, on each of the Data, Row, Col tabs, click Show Units, save map.

Ah, good. Yes, that works now. I can see data cells in the map. Now, is there any way to display a map in 3D form such as I see the spark tables in the tuner tool? The map does help me to see what is going on when combined with the traces on the dashboard page, though. Of course, I don't really have a clue about what is "right" or "wrong". Are there any tutorials showing traces and maps that will show a comparison of good, acceptable, and bad data? I just don't have anything to compare what I am seeing against. Or is this a case of, if it feels good, no error codes, and no legitimate KRs, then all is good?

[Bjorn]

Hi guys, I'm new to the forum & have a few dumb questions of my own.
I've had my scan tool V1.2 for a few years now & have only really just gotten into tuning.

I just finished building an LS1 powered project car. It's an 85 swb Nissan Patrol with an LS1 from a 2000 Holden Commodore & a 4L60 with a few mods, cam, headwork, headers, single 3" exhaust, FAST 90mm TB & manifold. I also have a fairly stock 5.7L 2001 VX Commodore wagon which I'm not happy with the state of tune. Whoever tuned it did a terrible job, cut the MAF sensor plug off the loom & locked the PCM :( It's just got a cold air intake & catback twin 2.5" system.

Please correct me if I'm wrong here.
1: To make a maffless tune I need to unplug the MAF & or change the C2901 figure to 0 which should prevent the DTC P0103 from coming up? This makes it run in SD (not sure what SD stands for?). I also have to cut & paste the high octane spark table over the low octane table. Have I missed anything? I'm sure I have.

2: Am I able to completely reflash the locked PCM to make it usable? I bought another PCM from a VX clubsport to swap it with but having a locked one is kinda usless.

[Rich Z]

First off, "SD" stands for "Speed Density". If I understand it correctly, it means the PCM determines fueling from the speed of the engine (RPM) and the density of air (via the VE table) predicted to be in each cylinder at a particular RPM when the fuel injector needs to spurt fuel there. Someone can correct me if I am wrong....

And testing my own understanding, increasing the value of a cell in the VE table tells the PCM that the air density is MORE there, so the PCM tries to inject more fuel to make the AFR richer than before the change. Conversely, making the cell value smaller tells the PCM that the air density is LESS, therefore the PCM injects less fuel to make the AFR leaner.

As for locking the PCM, personally I would not allow ANYONE to take over ownership of my PCM in that manner. And, in my opinion, those tuners that engage in such a practice really need to get over themselves. As best I understand, once the PCM is locked, you are pretty much screwed if you can't get the original tuner to unlock it.

Now this brings up my own question. Why is the high octane table copied over to the low octane table? And is it cause for concern, if for a good reason, that my tune is not set that way?

A secondary question is that if you copy the HO table to the LO table, what happens if you get a bad load of gasoline sometime?

[Bjorn]

Cool, sounds like I'm barking up the right tree.
From what I've found so far & it could be wrong but makes sense to me. By unplugging the MAF it makes the PCM run in SD mode which uses the MAP sensor, Main VE table & rpms, but automatically goes to the LO spark table hence the cut & paste of the HO table.
But in saying that I completely understand what you're saying about bad fuel.
I'd assume that by changing the C2901 figure to 0 that it would basically bypass the MAF & leave the PCM using the HO spark table as normal?
As for the locked PCM I completely agree with you Rich Z. What gets me is why lock a crap tune?
Ok it's ment to have 218.6 rwkw but the gear shifting & the general state of tune leave a lot to be desired.

[Rich Z]

So is copying the spark high octane table to the low octane table even necessary to do? I'm looking at the AutoVE Tuning Tutorial (page 9) and it says

If you upgrade your PCM to EFILive's Speed Density custom operating system, step 13 is not required. EFILive's Speed Density operating system restored dual spark map and full adaptive spark control when running MAF-less.

[Bjorn]

So is copying the spark high octane table to the low octane table even necessary to do? I'm looking at the AutoVE Tuning Tutorial (page 9) and it says

Apparently not after reading that.
Thanks, I hadn't gotten to that yet & it deffinately helps to ask silly questions.
Now I've just got to work out how to upgrade the operating system.

[joecar]

...
Please correct me if I'm wrong here.
1: To make a maffless tune I need to unplug the MAF & or change the C2901 figure to 0 which should prevent the DTC P0103 from coming up? This makes it run in SD (not sure what SD stands for?). I also have to cut & paste the high octane spark table over the low octane table. Have I missed anything? I'm sure I have.

2: Am I able to completely reflash the locked PCM to make it usable? I bought another PCM from a VX clubsport to swap it with but having a locked one is kinda usless.
1: to run MAF-less a MAF DTC must trigger (doesn't matter how you cause it to trigger).

With a COS adaptive spark still works when MAF is failed (so you don't have to copy HO to LO), this is a feature of the COS's.

2: locked PCM can't be read nor written.

[joecar]

Cool, sounds like I'm barking up the right tree.
From what I've found so far & it could be wrong but makes sense to me. By unplugging the MAF it makes the PCM run in SD mode which uses the MAP sensor, Main VE table & rpms, but automatically goes to the LO spark table hence the cut & paste of the HO table. That is correct for the OEM OS's...

the COS's retain adaptive spark (HO/LO sliding) when MAF is failed.




But in saying that I completely understand what you're saying about bad fuel.
I'd assume that by changing the C2901 figure to 0 that it would basically bypass the MAF & leave the PCM using the HO spark table as normal?No.

Changing C2901 causes a MAF DTC to trigger with MAF physically present, so OEM OS will fail to LO.

[joecar]

So is copying the spark high octane table to the low octane table even necessary to do? I'm looking at the AutoVE Tuning Tutorial (page 9) and it says

If you upgrade your PCM to EFILive's Speed Density custom operating system, step 13 is not required. EFILive's Speed Density operating system restored dual spark map and full adaptive spark control when running MAF-less.

That is correct, the COS's reatain adaptive spark when the MAF is failed (i.e. MAF DTC present).

[joecar]

First off, "SD" stands for "Speed Density". If I understand it correctly, it means the PCM determines fueling from the speed of the engine (RPM) and the density of air (via the VE table) predicted to be in each cylinder at a particular RPM when the fuel injector needs to spurt fuel there. Someone can correct me if I am wrong....
Close... in SD the PCM determines airmass from the VE table (VE table being speed vs density table)... it then looks up the commanded fuel (B3605, B3647, and B3618 if PE enables) and converts the commanded fuel to AFR (using B3601), and then calculates the fuelmass required by the airmass to meet the commanded fuel AFR.



And testing my own understanding, increasing the value of a cell in the VE table tells the PCM that the air density is MORE there, so the PCM tries to inject more fuel to make the AFR richer than before the change. Conversely, making the cell value smaller tells the PCM that the air density is LESS, therefore the PCM injects less fuel to make the AFR leaner.The PCM computes cylinder airmass from the VE table, and it computes the fuelmass required to maintain the commanded AFR (from B3605, B3547, B3618, converted to AFR by B3601)... the AFR is not richer or leaner, but the fuelmass is the same ratio with the airmass as stated by the commanded AFR... so if the airmass is increased (via increase in VE table) then fuelmass is increased.

i.e. 3 steps:
- PCM computes cylinder airmass from B0101,
- PCM computes commanded AFR by looking up B3605, B3647, B3618 and B3601,
- PCM uses those two to compute cylinder fuelmass.



As for locking the PCM, personally I would not allow ANYONE to take over ownership of my PCM in that manner. And, in my opinion, those tuners that engage in such a practice really need to get over themselves. As best I understand, once the PCM is locked, you are pretty much screwed if you can't get the original tuner to unlock it.
A good tuner is proud of their work and don't mind showing it... a bad tuner is ashamed and wants to hide it.




Now this brings up my own question. Why is the high octane table copied over to the low octane table? And is it cause for concern, if for a good reason, that my tune is not set that way?

A secondary question is that if you copy the HO table to the LO table, what happens if you get a bad load of gasoline sometime?
Non-COS: HO copied to LO because failed MAF causes failover to LO table, and you want to tune VE with HO timing.

COS: when MAF is failed the HO/LO adaptive spark is retained... i.e. if no KR is present then you're running from HO table.

[Rich Z]

Thanks for that description of the process, Joe. Pieces are starting to fit together in my head about this stuff.

But the more I think about it, especially in relation to working with the VE table, the fuzzier the concepts get the closer I look.

I'm running data logs to try to dial in the VE table is perfectly as I can, and the entire process gets kind of fuzzy around the edges on me. I've been reading about the relative benefits of speed density MAFless tuning as opposed to using the MAF, and it sounds good to me thinking that with a SD tune, you are actually working off of the actual air mass predicted to be IN the cylinders themselves, instead of a signal from the MAF sensor saying "Hey PCM! There is this much air coming your way and going to be in the cylinders soon. Be ready for it!" With the MAF, wouldn't there be a delay between the time that the MAF generates a signal and that air mass actually gets to the cylinders? Small, yes, but I would think more noteworthy the faster the engine is spinning.

So, following this to a logical rocky road path, what about the signal delay from the wideband and stock O2 sensors? I'm doing these data logs determining the difference between the commanded AFR and the AFR actually signaled by my wideband. But won't there be a delay between when the AFR is commanded by the PCM and that exhausted gas charge gets to the wideband? Again, a small delay, yes, but the higher the engine RPM, doesn't this get to be something that should be accounted for?

Even worse, what about the delay between when the MAF generates it's signal and when the wideband actually generates it's signal saying that THIS is what the AFR is NOW?

I guess this just is not EXACT nor PERFECT at all. Which is why you try to get a good number of hits for each cell by try to maintain a stable RPM for as long as you can. Which, quite honestly, is quite a challenge trying to tune my car on the street. And I guess this explains somewhat the benefits of smoothing the VE table. Choppy peaks and valleys just aren't a good thing when the granularity of the table is 400 rpm between cells. So obviously the PCM has to do it's own extrapolation when you are doing, say, 5400 rpm and the cells are at 5200 and 5600. The more accurate the values are at 5200 and 5600 in the table, the more accurately the PCM can extrapolate what that 5400 AFR should be.

Anyway, just thinking out loud about how I think this all works.

How did our cars even run back in the old days with a carburetor and a distributor? :)

[joecar]

MAF delay: yes.

O2 delay: yes.

WB delay: yes.

[Bjorn]

Thanks Joe, Very helpfull.

It took me a few minutes to work out the COS, "custom operating system".
So how do I know which one to use with my PCM?
I had a look at "upgrading to an EFILive custom OS" but didn't see one that matched my current OS "09376077" 2001 VX Commodore.

http://forum.efilive.com/showthread.php?498-Upgrading-to-an-EFILive-custom-O-S

[joecar]

MAF delay: yes.

O2 delay: yes.

WB delay: yes.However, note that the PCM takes the MAF pre-delay and O2 post-delay into account (unfortunately EFILive does not have these parameters).

[joecar]

Thanks Joe, Very helpfull.

It took me a few minutes to work out the COS, "custom operating system".
So how do I know which one to use with my PCM?
I had a look at "upgrading to an EFILive custom OS" but didn't see one that matched my current OS "09376077" 2001 VX Commodore.

http://forum.efilive.com/showthread.php?498-Upgrading-to-an-EFILive-custom-O-SIf you don't see your OS listed in the COS tutorial, then you have to swap to an OS that is listed and is compatible with your PCM.

[Bjorn]

Thanks for that Joe, very helpful & greatly appreciated.

[Rich Z]

GM.APP (Accelerator Pedal Position) seems to tie up with the idle parameters (cracker/follower) that I see.

BTW, that was exactly what I needed! Thanks! Now my pedal position actually shows zero percent when at idle.

[Rich Z]

Truth be known, I would rather capture ALL of the data streams in a log, and then simply filter which ones I want to look at at the dashboard and map level (instead of the PID data level) when I am analyzing the data after the log was taken. This just seems to be a better utilization of my time than making multiple passes for data logs, setting up the needed subset of PIDs for each subsequent run, and HOPING that I have all the data collected in the same run that I might want to compare the interactions of at a later date. Obviously some of the PIDs will have to be duplicated in each run, regardless, which is just a waste of bandwidth. Anyone who has done database programming probably understands my perspective of this.

Found myself thinking about this the other day and it brought a BASIC "how the heck" type of question to my mind.

HOW does the PCM know what sort of data to send out when we are doing a data logging capture? Does EFILive tell the PCM what data stream it wants via PIDs selected for logging? Kind of like "Hey PCM! This is EFILive. I'm going to be needing the data for ONLY the following PIDs. OK?" I have to assume that ALL of the data is not available at all times coming from the PCM, so I am presuming that there is some sort of hand shaking data taking place that sets up the PCM to generate the data stream that is wanted.

Yes/No?

[joecar]

Yes, scantool tells PCM which pids it wants.

[Rich Z]

I know I've probably looked this up or figured it out in the past at least a dozen times, but do positive trims (STFT and LTFT) mean that the fuel mixture is actually LEAN or RICH? I can see how it could be either way, depending on how you look at it. On one hand it could be saying that it is lean and the PCM is adding fuel (therefore "+"), or it can mean that it is rich (therefore "+") and the PCM has to subtract fuel. There seem to be instances of negative logic being applied throughout this tuning stuff, with little guidance of WHEN that is the case.

[Rich Z]

And speaking of negative logic, I need to make certain that I am looking at something correctly.

When I created my map from B0101, I'm using the data parameter from BEN factor Bank 1, Serial Wideband, LS1 style (factor).

After doing data logging, I run the suggested filter and then cut and paste with labels the values in my map. Then I paste with multiply those map values against the B0101 table.

From what I can figure, it looks like the map values over 1.00 are telling me that the cells are showing lean, which when multiplied to the respective cells in B0101 make those VE values LARGER, indicating that the PCM has to add more fuel for those affected cells. In the case of the map cell values being lower than 1.00, multiplying them against the relevant VE cells in B0101 makes those cell values SMALLER, indicating that the PCM needs to add LESS fuel because the map data was indicating richer mixtures.

In other words, the larger the VE cell values, the more fuel is needed to be able to reach stoich. If the VE value in a cell is too small, the data in the map will indicate that the cell is running too lean, so fuel needs to be added by increasing the efficiency value. When the efficiency value in a cell is too large, then the collected map data will indicate that the cell is running too rich and LESS fuel needs to be provided by decreasing the efficiency value.

Of course, it's entirely possible that I have this COMPLETELY backwards in my mind..... :Eyecrazy:

[joecar]

This is a trick question that everyone gets wrong:


I know I've probably looked this up or figured it out in the past at least a dozen times, but do positive trims (STFT and LTFT) mean that the fuel mixture is actually LEAN or RICH? I can see how it could be either way, depending on how you look at it. On one hand it could be saying that it is lean and the PCM is adding fuel (therefore "+"), or it can mean that it is rich (therefore "+") and the PCM has to subtract fuel. There seem to be instances of negative logic being applied throughout this tuning stuff, with little guidance of WHEN that is the case.Neither...

but rather the STFT and/or LTFT mean that airmass is either:
- under-computed: PCM adds a proportional fuelmass, but this is under sufficient, in which case the HO2Sx1 voltage spends most of its time low, this causes LTFT to go positive to maintain trim;
- over-computed: PCM adds a proportional fuelmass, but this is over sufficient, in which case the HO2Sx1 voltage spends most of its time high, this causes LTFT to go negative to maintain trim;

i.e. the trim is an indication of the cylinder airmass being under or over actual airmass;

maintaining trim means that the LTFT is compensating for cylinder airmass being incorrect (remembering that fuelmass is proportional to airmass).

[joecar]

And speaking of negative logic, I need to make certain that I am looking at something correctly.

When I created my map from B0101, I'm using the data parameter from BEN factor Bank 1, Serial Wideband, LS1 style (factor).

After doing data logging, I run the suggested filter and then cut and paste with labels the values in my map. Then I paste with multiply those map values against the B0101 table.

From what I can figure, it looks like the map values over 1.00 are telling me that the cells are showing lean, which when multiplied to the respective cells in B0101 make those VE values LARGER, indicating that the PCM has to add more fuel for those affected cells. In the case of the map cell values being lower than 1.00, multiplying them against the relevant VE cells in B0101 makes those cell values SMALLER, indicating that the PCM needs to add LESS fuel because the map data was indicating richer mixtures.

In other words, the larger the VE cell values, the more fuel is needed to be able to reach stoich. If the VE value in a cell is too small, the data in the map will indicate that the cell is running too lean, so fuel needs to be added by increasing the efficiency value. When the efficiency value in a cell is too large, then the collected map data will indicate that the cell is running too rich and LESS fuel needs to be provided by decreasing the efficiency value.

Of course, it's entirely possible that I have this COMPLETELY backwards in my mind..... :Eyecrazy:
In a manner of speaking.

BEN > 1: VE cell is lower than actual, so BEN multiplier is increasing VE cell;
BEN < 1: VE cell is higher than actual, so BEN multiplier is decreasing VE cell;

(i.e. just like you said, but in terms of airmass)


then note that fuelmass is proportional to airmass.


Also note that when not at stoich fueling, the cylinder airmass still has to be correct to achieve the desired fueling (e.g. from PE table).

[joecar]

i.e.
- first, VE table models the cylinder airmass;
- then, fueling is determined by looking it up (stoich or OL fueling table or PE fueling table);
- then fuelmass is calculated from those two;

keeping airmass and fuelmass separate makes it easier to think about and to tune.

[Rich Z]

OK. I think.

The way I've been looking at this might not be the way that tuning actually works.

But perhaps the logic path I have taken to get there is wrong.

I'm looking at airmass as being a factor that is DETECTED (via MAF) or CALCULATED (via VE table) and fuelmass as being a factor that is CONTROLLED (via fuel injector pulse width commands from the PCM). With that in mind, I just think of this in a relationship whereby the PCM is able to CONTROL the air/fuel ratio in the ONLY way it can: By controlling the pulse of fuel from the fuel injectors. The PCM cannot CONTROL airmass at all, and is only REPORTED that value either directly by the MAF or interpolated via the VE table. When the PCM then detects the ACTUAL afr as reported from the O2 sensors, it can either reduce the pulse width if the afr is richer than it should be, or increase the pulse width if the afr is leaner than it should be.

So under the above assumptions, I tend to look at the fuel trims as being exactly what they infer: FUEL trims. Meaning, FUELMASS is being adjusted to accommodate an inaccuracy of a previously determined airmass for which the PCM applied what it thought was the correct amount of fuel.

The act of "tuning" is actually calibrating the airmass (via a correlation between the frequency signal of the MAF and the airmass that references in a conversion table, or values in the VE table that are predicting the actual airmass based on engine rpm and engine vacuum) in order to try to make the PCM's calculations of what fuelmass to use be more accurate.

Hmm, let me back up a bit, thinking about how the fuel trims actually work. Well, I've been thinking of the STFTs as being pretty much an instantaneous determination of the afr (with inherent delays that are going to take place from the time the PCM determines what amount of fuel is needed at a given instant for a particular cylinder to the time that the exhaust that results from that cylinder firing actually gets to the relevant O2 sensor), and the LTFTs as being sort of an averaging value of a set of STFTs. But there is a complication. Aren't both STFTs and LTFTs basically a SINGLE value that applies no matter what the MAF is detecting and which value is being selected from the VE table based on RPM and kPa? So unless the engine is running in a perfectly stable condition with airflow or engine rpm and intake vacuum CONSTANT, the fuel trims will never be accurate across every possible value that the MAF can detect for airflow, and not for every cell in the VE table. Which, of course, is why the MAF table is not a single constant, nor is the VE table a single value. The STFTs and LTFTs are correcting for errors across the entire spectrum of possible conditions for which the PCM is required to supply a calculation for fuelmass. Which, of course, is the purpose for calibrating the MAF table and the VE table. But heck, even if you got those calibrations PERFECT, can the output of the O2 sensors EVER be flatlined directly dead center between showing too rich and too lean?

So why do the O2 sensor outputs always seem to be showing either too rich or too lean? It would seem to me that TOO much fuel is being added when the O2 sensors detect that the exhaust is showing lean, and then TOO much fuel is being subtracted when the exhaust shows a rich condition. Which makes the O2 sensors bounce up and down like yo-yos trying to compensate and are actually OVER compensating. I guess it seems OK to think that the average afr is actually stoich, but in reality, the engine is spending half of it's time running too rich and then the other half running too lean for every cycle of the O2 sensors.

So, hmm again. Why doesn't the signal of a wideband oscillate in the same manner that the narrow band O2 sensor does? For that matter, why don't the STFTs exactly match the O2 output signals? Are they doing some sort of averaging or in some way determining HOW much compensation to apply and any given instant?

Sorry, just doing some thinking out loud here as I try to put the pieces together in my mind.

[joecar]

Everything until you get to STFT/LTFT yes, basically.

STFT/LTFT: yes, LTFT is the average trend of the STFT... yes, both are applied, but remember that the STFT is zeroed everytime it bumps the LTFT.

O2 voltage swinging: this is as-designed since the O2 sensors are narrow band (have a very sharp slope)... the only way the PCM can determine the correct trim is by constantly cycling the O2 voltage around stoich (so the PCM fuels a little richer than stoich, watches the transition, and then trims a little leaner, watches the transition... as long as it sees the transition in the correct direction then it keeps tracking and trimming in CL.

When you use STFT only (e.g. as in SOL) the wideband does tightly oscillate around stoich since the STFT are instant and not learnt, see the attached image.

When you use LTFT the wideband does not appear to oscillates because the LTFT that was previously learnt is being applied, so you don't see the oscillation.

[Rich Z]

Interesting.... So when you say the STFTs are zeroed, that implies that they are a cumulative average over a period of time. At least to me, anyway. So they really aren't instantaneous? Just shorter duration than the LTFTs but still averaging over a set period of time? I guess when I get around to re-enabling my STFTs, I need to look at them more closely. But I do recall that their influence created a low amplitude sine wave out of the wideband's signal in earlier scans I did a while back.

I'm looking at the image and see that the two O2 sensors are not matched with the same peak voltage values. Would that be considered as being a problem? Is one sensor actually detecting a difference in the exhaust stream compared to the other, and that is reflected by it's voltage output? Or is it just variance in tolerances of the sensor itself with it being normal to have some sensors with a wider or narrower voltage range than others?

Also, I've read in several places that some people recommend setting the switching points of the O2 sensors to 450mv. If I remember correctly, there is a table in the PCM for switching points and different values are being used across the cells of that table. That table seems to imply that there are different demands trying to be met by altering the switching point rather than using a static single value. So what would I be sacrificing by ignoring the mutli-valued table and instead using a single static value?

With the above in mind, does changing the switching point of the O2 sensors, either higher or lower, have any beneficial results that could be considered and utilized?

Oh, and another thing. How many people will switch their wideband sensor to the opposite side to verify that there isn't a dramatic difference in the oxygen content of the "other" engine bank?

[joecar]

STFT are instantaneous based on average front O2 voltage... when the STFT travels past some threshold (positive or negative), the LTFT is bumped in that direction (relative to where it currently is) and the STFT is zeroed...

i.e. the STFT are instantaneous (from the average O2 voltage) on top of where the LTFT is currently...

(i.e. so the LTFT is influencing fueling, which influences the average O2 voltage, which influences the STFT.

The LTFT is the learnt average trend of the STFT.


( also note the historic names of STFT and LTFT:
STFT = Integrator
LTFT = Block Learn Multiplier
)