Question on evo live map, load/timing not corresponding
#1
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Dec 2003
Location: Ventura County, CA
Posts: 357
Likes: 0
Received 0 Likes
on
0 Posts
Question on evo live map, load/timing not corresponding
I went out trying to tune my 96530006 ROM (upgraded from 94170008).
I noticed the timing was not following the 1-byte load that I was logging.
From what I understand the timing follows the barrow+temp compensated load, which is what the 1-byte is. But there is a condition where timing will not follow that load, what is that?
Edit: My 1-byte multiplier is 1.2. I'm not sure that makes a difference here.
I noticed the timing was not following the 1-byte load that I was logging.
From what I understand the timing follows the barrow+temp compensated load, which is what the 1-byte is. But there is a condition where timing will not follow that load, what is that?
Edit: My 1-byte multiplier is 1.2. I'm not sure that makes a difference here.
#2
Evolved Member
iTrader: (2)
Here are some notes that I have from a thread where mrfred posted on the disassembly:
spark advance lookup: For air temp below 77F, baro+airtemp compensated load is used for spark advance. For temps above 77F, then baro compensated load is used.
afr lookup: for closed loop conditions when load is < ~20, uncompensated load is used, otherwise, baro+airtemp compensated load is used. This means that baro+airtemp compensated load is used essentially all the time for AFR lookup.
spark advance lookup: For air temp below 77F, baro+airtemp compensated load is used for spark advance. For temps above 77F, then baro compensated load is used.
afr lookup: for closed loop conditions when load is < ~20, uncompensated load is used, otherwise, baro+airtemp compensated load is used. This means that baro+airtemp compensated load is used essentially all the time for AFR lookup.
#4
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Dec 2003
Location: Ventura County, CA
Posts: 357
Likes: 0
Received 0 Likes
on
0 Posts
Okay. I logged a 1byte (air+temp load), barometric load, and raw load, all three.
I'm looking at some logs and I have an example...
At 3500 rpm
1byte - 205
barometric load - 219 (should be following this)
raw load - 228
my timing is 5. In my timing map the nearest 5 I have is at load of 260.
Timing at 220 and 240 load is set at 6 in my map.
How am I getting a 5? My logged octane number is 100.
Is the eval formula wrong for timing? x - 20 ?
I'm looking at some logs and I have an example...
At 3500 rpm
1byte - 205
barometric load - 219 (should be following this)
raw load - 228
my timing is 5. In my timing map the nearest 5 I have is at load of 260.
Timing at 220 and 240 load is set at 6 in my map.
How am I getting a 5? My logged octane number is 100.
Is the eval formula wrong for timing? x - 20 ?
#5
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Dec 2003
Location: Ventura County, CA
Posts: 357
Likes: 0
Received 0 Likes
on
0 Posts
One thing I thought of is it could be that I changed the load scaling on the timing and fuel tables.
If I read the map according the the stock scaling then the timing makes sense.
Do the tephra roms not allow rescaling of load on the timing + fuel maps?
If I read the map according the the stock scaling then the timing makes sense.
Do the tephra roms not allow rescaling of load on the timing + fuel maps?
#6
Evolved Member
iTrader: (7)
Join Date: Nov 2006
Location: Pittsburgh
Posts: 772
Likes: 0
Received 0 Likes
on
0 Posts
This is interesting...
I kept quiet about this because maft pro has always fudged my load #'s. But when I recently moved to the new rom V7.6 w/ 1 byte load... they went stupid. I mean total bull****. I was seeing nearly 50lbs/min in GM /sec and 260 load...
I was contemplating dumping the Maft-Pro and going to SD on the ecu - in hopes it would FIX this. But I think it would actually make it a lot worse. Maft Pro locks the IAT down to 80* and does it's own temp compensation for SD. So I should see less variation in load than even you would.
I kept quiet about this because maft pro has always fudged my load #'s. But when I recently moved to the new rom V7.6 w/ 1 byte load... they went stupid. I mean total bull****. I was seeing nearly 50lbs/min in GM /sec and 260 load...
I was contemplating dumping the Maft-Pro and going to SD on the ecu - in hopes it would FIX this. But I think it would actually make it a lot worse. Maft Pro locks the IAT down to 80* and does it's own temp compensation for SD. So I should see less variation in load than even you would.
#7
Evolved Member
iTrader: (2)
Okay. I logged a 1byte (air+temp load), barometric load, and raw load, all three.
I'm looking at some logs and I have an example...
At 3500 rpm
1byte - 205
barometric load - 219 (should be following this)
raw load - 228
my timing is 5. In my timing map the nearest 5 I have is at load of 260.
Timing at 220 and 240 load is set at 6 in my map.
How am I getting a 5? My logged octane number is 100.
Is the eval formula wrong for timing? x - 20 ?
I'm looking at some logs and I have an example...
At 3500 rpm
1byte - 205
barometric load - 219 (should be following this)
raw load - 228
my timing is 5. In my timing map the nearest 5 I have is at load of 260.
Timing at 220 and 240 load is set at 6 in my map.
How am I getting a 5? My logged octane number is 100.
Is the eval formula wrong for timing? x - 20 ?
Let's see the log and your timing map.
Eric
Trending Topics
#8
EvoM Community Team
iTrader: (15)
Silly question since I don't use the live map - are you sure that your load axes are scaled in the map storage location AND the live map location?
#9
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Dec 2003
Location: Ventura County, CA
Posts: 357
Likes: 0
Received 0 Likes
on
0 Posts
Silly question since I don't use the live map - are you sure that your load axes are scaled in the map storage location AND the live map location?
Did you have any knock at all? If you expect 6 and get 5, that may be close enough that simple interpolation to other cells or logging speed may be contributing to that.
I have been logging at the default 15625 baud.
#10
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Dec 2003
Location: Ventura County, CA
Posts: 357
Likes: 0
Received 0 Likes
on
0 Posts
Should I be using 2-byte RPM? Or speed up my logging rate?
I was under the impression 2-byte RPM is just to get better resolution data, not on-time data.
edit: I logged 2-byte RPM today. No revelations from that. I tried logging at 31250 baud but I kept getting an error. I'll try 62500 tomorrow.
I was under the impression 2-byte RPM is just to get better resolution data, not on-time data.
edit: I logged 2-byte RPM today. No revelations from that. I tried logging at 31250 baud but I kept getting an error. I'll try 62500 tomorrow.
Last edited by roger smith; Aug 19, 2009 at 06:23 PM.
#11
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Dec 2003
Location: Ventura County, CA
Posts: 357
Likes: 0
Received 0 Likes
on
0 Posts
I believe I found the answer to my problem.
I didn't know there were two different timing values that can be logged.
MUT06 and 33.
I've been logging 06 which doesn't follow the timing map.
I will confirm this on the weekend, hopefully.
I didn't know there were two different timing values that can be logged.
MUT06 and 33.
I've been logging 06 which doesn't follow the timing map.
I will confirm this on the weekend, hopefully.
Thread
Thread Starter
Forum
Replies
Last Post