I datalogged the intake temps this time around and found them to be peaking 80 deg F, which is lower than the temp at which timing begins to get pulled. I zeroed out the table just to experiment and my timing was back to normal. Is the table referencing the MAF temp sensor or the temp sensor used for speed density ? I will post my latest log tomorrow . Thanks guys

 

The patch replaces the maf intake temp with one from the IAT sensor so yes the ecu will see it as the MAF intake temp and treat it as such.

 

I used jitter fix #1 on the ride in this morning, and the hiccup definitely seemed more prominent. Im going to try #3 this afternoon on the way home and see what I find.

I appologize for asking this again, but really want to make sure Im approaching this correctly.
When should the kpa-load table be modified? Can someone give me an example of why and how they modified this table? Im sorry if thats SD 101, but its not obvious to me.

 

Think of the kpa-load table as a global VE/fueling table. The 3D fueling table is then your fine adjustment.

A good example would be at idle. Your kpa-load isn't going to be 1:1. You might idle at like 50 kpa, but your load isn't going to be 50...it's more like 30 or something like that. When I tuned SD, I used MAF logs to match maf based load to SD based load. That way your fueling and timing tables are going to follow more what you're used to already and you won't be losing many of the cells' usability without rescaling, etc.

 

Thank you. I guess the main reason it was confusing me is because in the "How to tune SD" thread, it says to tackle the VE map first, then move on to kPA-Load. This way seems to be the opposite. My kPA-load being 1:1 is probably why Im having to adjust so much in the low kPA areas of the VE map.

But as I recall, my logged kPA was roughly the same as Load1B. And seems resonable (around 30 at idle). So that would indicate the kPA-Load table is correct. Maybe Im using the wrong formula to log kPA?? Should it be straight x or a formula in evoscan? I dont have the formula Im using right in front of me....

I do have a few long logs from before making the switch and will double check my MAF loads vs SD loads.

 

Is the GM air temp sensor calibration/scaling formula different from the stock MAF sensor? Cuz my timing keeps getting pulled despite lower intake temps. It pulls 3 degrees out which correllates my intake temps have reached 185 deg F.

My car is not knocking and I am also verifying the temp is only 75 deg with the stock MAF temp sensor. I also double checked my MAT sensor scaling tables which indicate .103v is 150 deg F and .773v is 75 deg. Does the scaling for this IAT comp table need to be adjusted as well? Correct me if am wrong, but I could only guess that the GM sensor is referencing the stock MAF sensor scaling for temperature and getting a higher temp reading than the actual.

 

Your scaling tables that you mentioned are *C, not *F.

Looking at one of my ROMs, I have 85C (185F) at .55 Volts for the GM sensor.

 

^ yes your right. My value at .55v is also 85. I just couldn't see the actual units because my screen gets cut off.

I just went over the other tables and found some differences in the "IAT Scaling" table between mrfred's orignal 8859 MAT patched rom and my current ROM. Does that matter?

 

The scaling should be right, really i just copied the scaling from the last SD patches.

If your seeing .55volts out of 5 volts it really makes me think you have a grounding issue or a line issue adding a lot of resistance to the measurement.

 

Sorry but .55v or .552 to be exact is just the value i'm using to describe what I see in ecuflash which correlates to 85 deg C.

If the IAT comp table used to reference the MAF intake sensor and now it's referencing the GM IAT sensor, woudln't it be in-correct? The post-intercooler temp is higher than ambient due to increasing pressure...

But it still doens't expalin why it pulls timing despite being set to a higher air temp.

 

No.... the volts its reading is clearly wrong.

Here's a breakdown of known volts and temp values for a GM IAT.

degF R Volts
212 177 0.515
194 241 0.676
176 332 0.887
158 467 1.166
140 667 1.517
122 973 1.948
113 1188 2.194
104 1459 2.455
95 1802 2.725
86 2238 2.998
77 2796 3.268
68 3520 3.531
59 4450 3.776
50 5670 4.002
41 7280 4.205
32 9420 4.383
23 12300 4.536
14 16180 4.663
5 21450 4.768
-4 28680 4.852
-22 52700 4.971
-40 100700 5.041

 

I'm even more confused now. Let's start over please. I just wanted to make sure I did the MAT patch correctly and verify the values I pasted were correct. So I looked at mrfred's pre-patched ROM and under the category "MAT" and sub-category "Fuel Temp Sensor Scaling" the value at 0.552 volts = 85 deg C.

I never logged air-temp voltage. How do you do that?

The formula I have in EvoScan is 1.8*x-40 = deg F
So how do I get a voltage out of the "x" part please?

Thanks

 

I really don't understand why you are trying to get the voltage out of it anyhow your sensor is reading the same as unplugged just fix it and it will work again.

 

Are you still recommending changing this table to try and alleviate the hiccup/cough/jitter? It happens 10-15 times on my commute. If you still want more logs, Id be happy to trim some down to where the issue is. Im assuming you want RPM, Load, IPW logged? Just let me know and I'll post some up.

thanks

 

On the way home I tried to capture it. Didnt realize until I got off the freeway that I was logging to screen. These are the only 2 logs I can identify it in. The other 10 didnt seem to catch it I stopped the log after every occurance, so I knew it was at the end of each one, but it must be such a quick event that it just wasnt enough data to catch it while logging to screen. This is while using jitter fix #2. BTW..none of the jitter fixes seem to make a difference (in case that hasnt been stated)

Line 79 (IPW)
Line 80 (timing)
Line 579 (timing)

LogID	LogEntryDate	LogEntryTime	LogEntrySeconds	LogNotes	TPS	RPM	Load1B	TimingAdv	WideBand	AFRMAP	OMNI4BAR(PSI)	OMNI4BAR(kpa)	ISCSteps	InjPulseWidth
77	4/5/2011	44:40.9	9.81015		31.76470588	3500	75.4	31	13.01356864	14.58604651	-4.2133	70.2372965	58	3.84
78	4/5/2011	44:41.0	9.9371		31.76470588	3500	74.1	32	13.01356864	14.58604651	-4.2133	70.2372965	58	3.84
79	4/5/2011	44:41.1	10.06407		31.76470588	3500	72.8	32	13.01356864	14.58604651	-4.2133	70.2372965	58	8.704
80	4/5/2011	44:41.3	10.19405		31.76470588	3531.25	71.5	21	13.01356864	14.58604651	-4.2133	70.2372965	58	3.84
81	4/5/2011	44:41.4	10.32403		31.76470588	3531.25	70.2	32	12.93529413	14.58604651	-4.2133	70.2372965	58	3.84
82	4/5/2011	44:41.5	10.45099		31.76470588	3531.25	71.5	32	13.01356864	14.58604651	-4.4502	68.603871	58	3.84
83	4/5/2011	44:41.7	10.57946		31.76470588	3531.25	71.5	32	13.05270589	14.7	-4.4502	68.603871	58	3.84
576	4/5/2011	50:16.6	73.3436		30.98039216	3031.25	74.1	32	13.20925491	14.7	-3.9764	71.870722	57	3.84
577	4/5/2011	50:16.7	73.4706		30.98039216	3031.25	74.1	32	13.24839217	14.7	-3.9764	71.870722	57	3.84
578	4/5/2011	50:16.8	73.59757		30.98039216	3031.25	74.1	32	13.24839217	14.7	-3.9764	71.870722	57	3.84
579	4/5/2011	50:17.0	73.72553		30.98039216	3031.25	157.3	14	13.28752942	14.7	-3.9764	71.870722	57	3.84
580	4/5/2011	50:17.1	73.85252		30.98039216	3093.75	75.4	32	13.32666668	14.7	-3.7395	73.5041475	57	3.84
581	4/5/2011	50:17.2	73.9795		30.98039216	3031.25	75.4	32	13.63976472	14.7	-3.7395	73.5041475	57	3.84
582	4/5/2011	50:17.3	74.10748		30.98039216	3031.25	75.4	32	13.09184315	14.7	-3.7395	73.5041475	57	3.84