PDA

View Full Version : Controlling timing with 2 Bar OS?



Redline Motorsports
September 13th, 2006, 01:49 PM
I am putting together a file for a tune tomorrow and was wondering; since the MAF is disabled, how does the PCM referenced the timing based on load? The spark table is still using grams/cylinder which is based upon MAF readings. Now that the MAF is gone, what does the PCM use for its load reference? The map is the only thing left!

Thanks

Howard

dc_justin
September 13th, 2006, 05:04 PM
I am putting together a file for a tune tomorrow and was wondering; since the MAF is disabled, how does the PCM referenced the timing based on load? The spark table is still using grams/cylinder which is based upon MAF readings. Now that the MAF is gone, what does the PCM use for its load reference? The map is the only thing left!

Thanks

Howard

MAF is not used exclusively for airmass (g/cyl). In MAF mode it uses a blend of MAF and VE lookup. With MAF disabled, the PCM calculates the airmass based on VE.

Redline Motorsports
September 14th, 2006, 12:33 AM
What happens when logging data and trying to determine what timing cell you are in? Does the logging data still reports grams/cylinder when the MAF is eliminated? If not how do you know which cell you are in? Shouldn't there be a timing map that is rpm vs. map........just like the fueling table?

Howard

dc_justin
September 14th, 2006, 01:30 AM
What happens when logging data and trying to determine what timing cell you are in? Does the logging data still reports grams/cylinder when the MAF is eliminated? If not how do you know which cell you are in? Shouldn't there be a timing map that is rpm vs. map........just like the fueling table?

Howard
When logging data, you should use GM.CYLAIR_DMA as opposed to the calculated MAF Airmass value.

joecar
September 14th, 2006, 03:34 AM
DYNCYLAIR is what the PCM computes for cylinder airmass;

DYNCYLAIR includes combined MAF/VE data when the MAF is present and operating;
DYNCYLAIR uses VE table data when MAF is failed (DTC P0101-3);

PCM uses DYCYLAIR to reference into the spark tables;

The PID is GM.DYNCYLAIR_DMA as shown on the axis of the spark tables.

dc_justin
September 14th, 2006, 11:10 AM
DYNCYLAIR is what the PCM computes for cylinder airmass;

DYNCYLAIR includes combined MAF/VE data when the MAF is present and operating;
DYNCYLAIR uses VE table data when MAF is failed (DTC P0101-3);

PCM uses DYCYLAIR to reference into the spark tables;

The PID is GM.DYNCYLAIR_DMA as shown on the axis of the spark tables.

PID Description shows DYNCYLAIR_DMA as being the Speed Density PID for airmass. With CYLAIR_DMA being just Air Flow Grams/Cyl (NOT the MAF derived CALC.CYLAIR).

I've logged both DYNCYLAIR_DMA and CYLAIR_DMA in MAF and SD and in MAF they vary, in SD, they're the same...

joecar
September 14th, 2006, 11:57 AM
lol, I know, it's confusing me to the point where I need a few beers... :D

In the tune tool, the lo/hi octane spark tables show GM.DYNCYLAIR_DMA on one axis,
so that is the one to log, and it seems to work in both MAF and SD modes.

Edit: I just now went into the Scan Tool, and the only one of those air flow pids that had a description was CALC.CYLAIR... need more beer immediately. :cheers:

TAQuickness
September 14th, 2006, 12:18 PM
beer sounds good.

!hijack

dc_justin
September 14th, 2006, 12:29 PM
lol, I know, it's confusing me to the point where I need a few beers... :D

In the tune tool, the lo/hi octane spark tables show GM.DYNCYLAIR_DMA on one axis,
so that is the one to log, and it seems to work in both MAF and SD modes.

Touche. :cheers:

So either the " - Speed Density" comment on the Scan tool is incorrect, or the PCM uses the SD lookup value to calculate spark or the header on the tune tool is incorrect... I feel a test coming on. :D

Redline Motorsports
September 14th, 2006, 03:22 PM
Holy crap stop all the drinking! LOL! Maybe we need another section just for cocktail conversations!

The pid that I have been using, while retaining the MAF, has been the calc.cylair. I just checked in FS and don't see the GM.DYNCYLAIR_DMA pid.

If I am not mistaken, aren't DMA pids raw data?

What do you guys do when tuning over 105 kpa for a map? I know that fueling has a range of 105 to 285 kpa (2bar) but the spark table onlys goes to 105. Is this where the A0010 table comes in? Does the last timing value in the high octane table become the main spark value and then get retarded from the above noted table?

Appreciate the clarifications!

Howard

dc_justin
September 14th, 2006, 03:37 PM
Holy crap stop all the drinking! LOL! Maybe we need another section just for cocktail conversations!

The pid that I have been using, while retaining the MAF, has been the calc.cylair. I just checked in FS and don't see the GM.DYNCYLAIR_DMA pid.

If I am not mistaken, aren't DMA pids raw data?

What do you guys do when tuning over 105 kpa for a map? I know that fueling has a range of 105 to 285 kpa (2bar) but the spark table onlys goes to 105. Is this where the A0010 table comes in? Does the last timing value in the high octane table become the main spark value and then get retarded from the above noted table?

Appreciate the clarifications!

Howard
Definitely use something other than calc.cylair from now on. If you watch it, that value will bounce all over the place...

And yes, once you go aboce 1.20 g/cyl, the spark value used will be that final column. If you're using A0010, then once you're above 105kPa, it will subtract that timing value from whatever value the PCM is referencing at that point, whether it be 2400rpms and .96g/cyl or 5600rpms and 1.4g/cyl...

Redline Motorsports
September 18th, 2006, 01:29 PM
You guys have me all confused:bash: . The load axis is noted as GM.DYNACYLAIR_DMA so it would make sense to log that data so it corelates to the spark table. I guess I always thought the MAF was responsible for providing a gm/cyl. value. Is it correct that a DMA is a raw calculated pid vs. actually measured? If the MAF is deleted from the equation, the map is all thats left to report load. I still don't see why a table that shows map vs. rpm could not be used with a custom OS.

Is this the best pid to also use when the MAF is still used?

dc_justin
September 18th, 2006, 01:34 PM
Is this the best pid to also use when the MAF is still used?

Yes. Never use the MAF derived airmass value for spark reference.

Redline Motorsports
September 18th, 2006, 02:05 PM
I guess if I understand it correctly; this pids includes the VE as part of the final value vs. just raw MAF readings.....hence the reason it is still valid without the MAF?

dc_justin
September 18th, 2006, 02:07 PM
I guess if I understand it correctly; this pids includes the VE as part of the final value vs. just raw MAF readings.....hence the reason it is still valid without the MAF?

Exactly.

And using the MAF exclusively, you'll see your airmass readings bounce around a lot more than they should.

nitrorocket
September 19th, 2006, 03:08 AM
I know my timing table I log tthat matches the timing table maps in the software only go up to 1.2 grams if memory serves correct. When I get to this point it just stays at the 18 degrees I have commanded in that area of the high octane tinming map. I don't think you can adjust anymore from this point unless you use the timing value based on boost table. I am running 235 KPA.

Does this help?

joecar
September 19th, 2006, 04:00 AM
Howard,

Yes, the _DMA pids are the actual values in the PCM's memory that the PCM is using to index tables.

If you didn't see GM.DYNCYLAIR_DMA do this:

a. go File->Enter VIN and make sure the OS id is correct (also shown at the bottom of the Scan Tool window)

b. in the PIDs tab, click on the "Caption" column heading to sort on that column, then scroll down to the "D"s and you should see that PID.

Joe

Redline Motorsports
September 19th, 2006, 06:00 AM
Joe,

I just tried doing that and still don't see any DMA pids. Went back to the file>vin and made sure the OS matched the OS in the tune file. Which by the way is # 02020003. The vin is shown with xxxxxxx as it must be because of the custom OS?

The only available pid I see is GM.DYNCLAIR

What am I missing?

Howard

On another note; which map pid should be the one logged and will it report over 105 kpa with the 2 bar sensor/custom os?

I thought that one of the pids could read into boost??

dc_justin
September 28th, 2006, 03:35 PM
Touche. :cheers:

So either the " - Speed Density" comment on the Scan tool is incorrect, or the PCM uses the SD lookup value to calculate spark or the header on the tune tool is incorrect... I feel a test coming on. :D

Stay posted... I think I can prove that the spark table does not actually reference DYNCYLAIR_DMA, but instead utilizes CYLAIR_DMA... in fact I'm certain I can. My CYLAIR_DMA is pegged at 0.81g/cyl (a Problem in boost) and DYNCYLAIR_DMA jumps up to 1.0. Timing that is referenced is from the .81g/cyl region, not the 1.0. I have no adder tables that would cause this appearance, only tables that would subtract from the timing.

Shooting an email off to Ross re: that and a couple of other items.

Justin

Whippled 496
December 30th, 2006, 09:51 AM
What did you ever make of this test Justin?

dc_justin
December 30th, 2006, 11:59 AM
What did you ever make of this test Justin?Assumption was correct. The value shown in GM.DYNCYLAIR_DMA did not match up with the actual run timing. The DMA PID maxed at 0.86 g/cyl while timing was being used from the 1.00 column. I can post up portions of a log in 15-20 minutes.The question at hand now is which PID is the correct to ues. New assumption is GM.DYNCYLAIR as that and GM.CYLAIR are the only ones of those type available in the 2006 truck pcms...

Edit:
I've attached an image showing this. Note that DYNCYLAIR_DMA stays flat, while the DYNCYLAIR and CYLAIR_DMA both follow the timing dip and throttle blip.

http://www.marketitright.com/ss/tuning/dyncylair.gif