EvoScan AFRMAP not mattching "High Octane Fuel Map" in V7 Rom
I can tell you right now, the is NO way my FUEL map is the same for 3,250 RPMs at load 128 through 3,906 RPMs at load 162. Wtf am i doing wrong here?
AFRMAP 1byte load RPM
14.70 114 3031
13.63 121 3156
12.98 128 3250
12.98 137 3406
12.98 146 3563
12.98 163 3750
12.98 162 3906
12.98 52 3875
14.70 37 3906
AFRMAP 1byte load RPM
14.70 114 3031
13.63 121 3156
12.98 128 3250
12.98 137 3406
12.98 146 3563
12.98 163 3750
12.98 162 3906
12.98 52 3875
14.70 37 3906
quite possibly because of this
Because 1 byte load isnt temp and baro compensated. According to Boosted Tuning in this thread https://www.evolutionm.net/forums/ec...based-rom.html
the 9653 rom uses baro and temp compensation for fuel and timing map lookup.
Its worth doing a save-as on your rom, changing the mut so that you can log 2 byte, then seeing if the numbers make sense. Just pick 2 locations in the table that arent being used (04 & 05?) Then setup the 2 byte logging parameter in the ecuflash data.xml to reflect that same pair of requestIDs.
no clue why you are getting the same afrmap values for the range you stated above...
Because 1 byte load isnt temp and baro compensated. According to Boosted Tuning in this thread https://www.evolutionm.net/forums/ec...based-rom.html
the 9653 rom uses baro and temp compensation for fuel and timing map lookup.
Its worth doing a save-as on your rom, changing the mut so that you can log 2 byte, then seeing if the numbers make sense. Just pick 2 locations in the table that arent being used (04 & 05?) Then setup the 2 byte logging parameter in the ecuflash data.xml to reflect that same pair of requestIDs.
no clue why you are getting the same afrmap values for the range you stated above...
The reason is because you aren't using 2byte load (temp + baro compensated). The 1byte value and the 2byte load (temp + baro compensated) show up to a 20-30 load difference at times. Use 2byte for timing and fuel. It also helps to get consistent AFRs when you smooth the tables where there are no big jumps.
Last edited by Fast_Freddie; Aug 25, 2010 at 06:55 AM.
quite possibly because of this
Because 1 byte load isnt temp and baro compensated. According to Boosted Tuning in this thread https://www.evolutionm.net/forums/ec...based-rom.html
the 9653 rom uses baro and temp compensation for fuel and timing map lookup.
Its worth doing a save-as on your rom, changing the mut so that you can log 2 byte, then seeing if the numbers make sense. Just pick 2 locations in the table that arent being used (04 & 05?) Then setup the 2 byte logging parameter in the ecuflash data.xml to reflect that same pair of requestIDs.
no clue why you are getting the same afrmap values for the range you stated above...
Because 1 byte load isnt temp and baro compensated. According to Boosted Tuning in this thread https://www.evolutionm.net/forums/ec...based-rom.html
the 9653 rom uses baro and temp compensation for fuel and timing map lookup.
Its worth doing a save-as on your rom, changing the mut so that you can log 2 byte, then seeing if the numbers make sense. Just pick 2 locations in the table that arent being used (04 & 05?) Then setup the 2 byte logging parameter in the ecuflash data.xml to reflect that same pair of requestIDs.
no clue why you are getting the same afrmap values for the range you stated above...
The reason is because you aren't using 2byte load (temp + baro compensated). The 1byte value and the 2byte load (temp + baro compensated) show up to a 20-30 load difference at times. Use 2byte for timing and fuel. It also helps to get consistent AFRs when you smooth the tables where there are no big jumps.
Ok, so I need:
"Load_Baro_n_Temp_Compensated " load option because I'm using a V7 88590715, (and thus have big maps). aka 2byte load.
To make this work, i need:
"2byte to 1byte load factor
- simple divide routine to convert 2byte load into a 1byte field and then Evoscan will convert back to 2byte.
- MATCH you LoadFactor in ECUFLASH to the SAME as your Eval in evoscan
- MaxLoad is loadfactor * 255, ie a loadfactor of 1.2 will allow a Max Loggable Load of 306, 1.3 = 331... etc (choose an appropriate loadfactor based on your existing max load)
AND change my
MUT 3D TABLE ADDRESS =
88590015
2byte load
MUT 00 = 6B42
MUT 01 =6B43
To that? Sound good to everyone? lol
I wouldnt mess with 00 and 01. Those are already setup for airflow. The MUT locations you posted is pre-v7...
I would just add those addresses to 04 and 05. Can anyone else confirm that those MUT locations arent used in stock form? Then edit the Evoscan data.xml for 2 byte load to look at requestID 04 and 05. Assuming those MUT locations arent used by something else.
The 2 byte to 1 byte factor has nothing to do with your issue. It is only for logging 1 byte load. If you are logging 2 byte load, that number means nothing.
If you are logging 1 byte load, you need to multiply that number (1.3, 1.4, whatever) by 255 to figure out your max log-able 1 byte load, which needs to be a smidge higher than the highest load you hit. The higher the multiplier (1.3, 1.4, etc), the less accurate it will be. That number needs to match in ECUFlash and the Evoscan data.xml.
I would just add those addresses to 04 and 05. Can anyone else confirm that those MUT locations arent used in stock form? Then edit the Evoscan data.xml for 2 byte load to look at requestID 04 and 05. Assuming those MUT locations arent used by something else.
The 2 byte to 1 byte factor has nothing to do with your issue. It is only for logging 1 byte load. If you are logging 2 byte load, that number means nothing.
If you are logging 1 byte load, you need to multiply that number (1.3, 1.4, whatever) by 255 to figure out your max log-able 1 byte load, which needs to be a smidge higher than the highest load you hit. The higher the multiplier (1.3, 1.4, etc), the less accurate it will be. That number needs to match in ECUFlash and the Evoscan data.xml.
Last edited by charlie.tunah; Aug 25, 2010 at 09:06 AM.
I wouldnt mess with 00 and 01. Those are already setup for airflow. The MUT locations you posted is pre-v7...
I would just add those addresses to 04 and 05. Can anyone else confirm that those MUT locations arent used in stock form? Then edit the Evoscan data.xml for 2 byte load to look at requestID 04 and 05. Assuming those MUT locations arent used by something else.
The 2 byte to 1 byte factor has nothing to do with your issue. It is only for logging 1 byte load. If you are logging 2 byte load, that number means nothing.
If you are logging 1 byte load, you need to multiply that number (1.3, 1.4, whatever) by 255 to figure out your max log-able 1 byte load, which needs to be a smidge higher than the highest load you hit. The higher the multiplier (1.3, 1.4, etc), the less accurate it will be. That number needs to match in ECUFlash and the Evoscan data.xml.
I would just add those addresses to 04 and 05. Can anyone else confirm that those MUT locations arent used in stock form? Then edit the Evoscan data.xml for 2 byte load to look at requestID 04 and 05. Assuming those MUT locations arent used by something else.
The 2 byte to 1 byte factor has nothing to do with your issue. It is only for logging 1 byte load. If you are logging 2 byte load, that number means nothing.
If you are logging 1 byte load, you need to multiply that number (1.3, 1.4, whatever) by 255 to figure out your max log-able 1 byte load, which needs to be a smidge higher than the highest load you hit. The higher the multiplier (1.3, 1.4, etc), the less accurate it will be. That number needs to match in ECUFlash and the Evoscan data.xml.
Thanks for the help and insight. I think I'm understanding this more.
The reason i posted the original Rom MUT table info was because I didn't see one for that V7, but thought that V7 was based on that rom.
I can't imagine V7 no coming setup to log 2byte. Right now my 2byte IS logging SOMETHING, it's just way wrong. Can you do me a fav and tell me what your EvoScan equation is for your 2byte load?
Last edited by Carloverx; Aug 25, 2010 at 09:39 AM.
mine's not setup for 2 byte. I just use 1 byte. Seems to work well enough.
Most likely your evoscan is setup to log requestIDs that have something else in them. So the data is useless. Add those addresses into 04 and 05, then setup your evoscan to log 04 and 05, then you should be set. Just make a copy of your rom in case the changing 04 and 05 screw anything up.
V7 isnt setup for 2 byte on purpose.
Most likely your evoscan is setup to log requestIDs that have something else in them. So the data is useless. Add those addresses into 04 and 05, then setup your evoscan to log 04 and 05, then you should be set. Just make a copy of your rom in case the changing 04 and 05 screw anything up.
V7 isnt setup for 2 byte on purpose.
mine's not setup for 2 byte. I just use 1 byte. Seems to work well enough.
Most likely your evoscan is setup to log requestIDs that have something else in them. So the data is useless. Add those addresses into 04 and 05, then setup your evoscan to log 04 and 05, then you should be set. Just make a copy of your rom in case the changing 04 and 05 screw anything up.
V7 isnt setup for 2 byte on purpose.
Most likely your evoscan is setup to log requestIDs that have something else in them. So the data is useless. Add those addresses into 04 and 05, then setup your evoscan to log 04 and 05, then you should be set. Just make a copy of your rom in case the changing 04 and 05 screw anything up.
V7 isnt setup for 2 byte on purpose.
Next question, how do i stop hitting fuel cut in teh V7 from"?
Simply move the "Fuel Cut Load X1" variables to like 400?? Hmm, or X2?
Or should i simply change the trigger delay to somethign very high?
Last edited by Carloverx; Aug 27, 2010 at 02:04 PM.
Don't just raise the delay, so that you never hit it, that'll defeat the purpose of the fail-safe.
I don't have the fuel cut load table in my rom for some reason, just the stock boost cut load table in the single solenoid section of the rom, so I can't help on how to correctly configure it, sorry!
I don't have the fuel cut load table in my rom for some reason, just the stock boost cut load table in the single solenoid section of the rom, so I can't help on how to correctly configure it, sorry!
From what I understand with Tv7 is that you do not need to log 2 byte load anymore. When I first converted over to v7 I was having issues with evoscan not doing the maptracer feature.
Heres the thread that I had started about this issue. https://www.evolutionm.net/forums/ec...e-work-v7.html
Hope this helps. Also about your AFR map not matching your wideband I remember seeing something about that in the Injector scaling threads.
Found the post that talked about matching afr map to wide band. https://www.evolutionm.net/forums/7712581-post25.html
It doesn't go into to much detail about doing it but it seems that they are using MAF compensation to make it match. Im not sure if this method would work on a SD tuned car though.
Heres the thread that I had started about this issue. https://www.evolutionm.net/forums/ec...e-work-v7.html
Hope this helps. Also about your AFR map not matching your wideband I remember seeing something about that in the Injector scaling threads.
Found the post that talked about matching afr map to wide band. https://www.evolutionm.net/forums/7712581-post25.html
It doesn't go into to much detail about doing it but it seems that they are using MAF compensation to make it match. Im not sure if this method would work on a SD tuned car though.
Last edited by drifterific; Aug 27, 2010 at 03:27 PM.
d
PS: however the original 94170715 map I have uses the same load scaling for both.
Thread
Thread Starter
Forum
Replies
Last Post
richardjh
09+ Ralliart Engine/Turbo/Drivetrain
1
Jun 18, 2011 10:16 AM







