Question, ECU load determining accuracy
Pls ignore my comments below, the joke is on me, since I wasn't paying attention and I was using the wrong numbers to calculate the load value...
LOL, the IPW based formula needs quite a bit of work, IMO.
I adjusted my Injector Latency scaling and Accel Enrichment last night, and the "constant" for the C*IPW/AFRMAP went from 3000 to 225 and now varies even more from the other two load calculations (i.e. timing map lookup, or MAF/RPM*C).
I've attached an Excel spreadsheet that lists my cars mod list, the ECU map changes I made, and two WOT pulls - one before the changes and one after.
l8r)
LOL, the IPW based formula needs quite a bit of work, IMO.
I adjusted my Injector Latency scaling and Accel Enrichment last night, and the "constant" for the C*IPW/AFRMAP went from 3000 to 225 and now varies even more from the other two load calculations (i.e. timing map lookup, or MAF/RPM*C).
I've attached an Excel spreadsheet that lists my cars mod list, the ECU map changes I made, and two WOT pulls - one before the changes and one after.
l8r)
Last edited by Ludikraut; Aug 26, 2006 at 11:51 PM.
Originally Posted by Ludikraut
LOL, the IPW based formula needs quite a bit of work, IMO.
I adjusted my Injector Latency scaling and Accel Enrichment last night, and the "constant" for the C*IPW/AFRMAP went from 3000 to 225 and now varies even more from the other two load calculations (i.e. timing map lookup, or MAF/RPM*C).
I've attached an Excel spreadsheet that lists my cars mod list, the ECU map changes I made, and two WOT pulls - one before the changes and one after.
l8r)
I adjusted my Injector Latency scaling and Accel Enrichment last night, and the "constant" for the C*IPW/AFRMAP went from 3000 to 225 and now varies even more from the other two load calculations (i.e. timing map lookup, or MAF/RPM*C).
I've attached an Excel spreadsheet that lists my cars mod list, the ECU map changes I made, and two WOT pulls - one before the changes and one after.
l8r)
Also, you should subtract the injector latency from the IPW. After doing that to your 'after changes sheet' the load seems to be in line with your before changes sheet.
Also, keep in mind that the formula with the MAF HZ won't be valid anymore once the logging limit of 1603 HZ is reached,
Eric
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
I've found the code in my ROM that uses the octane number and it does indeed interpolate between the low and high octane fuel maps to give what appears to be the AFRMAP number, or something similar.
I've been looking at the overboost cut routine. It takes one of two RAM values that appear to have (Load) 16 bit scaling. It takes the byte value for the boost limit map (Load8) 8 bit and quadruples it and compares it and the lowest of the two RAM values. If the load is below the limit, then it simply resets the boost cut counter to the value in the ROM. On exiting this routine it stores a truth flag to say if this counter has elapsed to zero and seems to have links with the rev-limiter routines.
I'm looking at the fuel map load lookup to see if it uses similar addresses to the 16 bit load scaling above.
I hope to then look for routines that link the load values I've found in RAM with serial output/Evoscan request ID stuff to see if I can modify the code to chuck out the "load".
This is very slow progress of course.
I've been looking at the overboost cut routine. It takes one of two RAM values that appear to have (Load) 16 bit scaling. It takes the byte value for the boost limit map (Load8) 8 bit and quadruples it and compares it and the lowest of the two RAM values. If the load is below the limit, then it simply resets the boost cut counter to the value in the ROM. On exiting this routine it stores a truth flag to say if this counter has elapsed to zero and seems to have links with the rev-limiter routines.
I'm looking at the fuel map load lookup to see if it uses similar addresses to the 16 bit load scaling above.
I hope to then look for routines that link the load values I've found in RAM with serial output/Evoscan request ID stuff to see if I can modify the code to chuck out the "load".
This is very slow progress of course.
Originally Posted by l2r99gst
It looks like you divided the wrong columns in the sheet after the adjustments.
Also, you should subtract the injector latency from the IPW. After doing that to your 'after changes sheet' the load seems to be in line with your before changes sheet.
Also, keep in mind that the formula with the MAF HZ won't be valid anymore once the logging limit of 1603 HZ is reached,
Eric
Also, you should subtract the injector latency from the IPW. After doing that to your 'after changes sheet' the load seems to be in line with your before changes sheet.
Also, keep in mind that the formula with the MAF HZ won't be valid anymore once the logging limit of 1603 HZ is reached,
Eric
No, I used the same columns for both, i.e. C * InjPulseWidth / AFR ... the columns are just in a different location on the two spreadsheets. I realize the MAF Hz formula is useless past 1603.95, but I am too lazy to blank out those cells.
l8r)
Last edited by Ludikraut; Aug 26, 2006 at 11:50 PM.
Originally Posted by jcsbanks
Looking at the data so far, how about:
5 * injector scaling * (IPW-latency) / AFRMAP
5 * injector scaling * (IPW-latency) / AFRMAP
That would've been pretty close prior to me adjusting the latency and Accel Enrichment, but it's way off on my current tune.
l8r)
Last edited by Ludikraut; Aug 26, 2006 at 11:49 PM.
Originally Posted by Ludikraut
No, I used the same columns for both, i.e. C * InjPulseWidth / AFR ... the columns are just in a different location on the two spreadsheets. I realize the MAF Hz formula is useless past 1603.95, but I am too lazy to blank out those cells. 
l8r)
l8r)
You divided by the actual AFR it looked like, not the AFRMAP value.
Eric
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
^ agree, change reference from AB to K and put back your original 3000 on your adjusted version. I don't think this works with a lot of knock correction or with sudden throttle transients unless AFRMAP also includes acceleration enrichment...
I've been hunting some more, and I can pretty much confirm that the octane value does interpolate timing between pairs of ignition map(s), identically to the fuel maps.
Still looking for the area where it receives requestIDs and decides what to chuck out... tomorrow
I've been hunting some more, and I can pretty much confirm that the octane value does interpolate timing between pairs of ignition map(s), identically to the fuel maps.
Still looking for the area where it receives requestIDs and decides what to chuck out... tomorrow
Last edited by jcsbanks; Aug 26, 2006 at 04:16 PM.
Originally Posted by jcsbanks
I've found the code in my ROM that uses the octane number and it does indeed interpolate between the low and high octane fuel maps to give what appears to be the AFRMAP number, or something similar.
I've been looking at the overboost cut routine. It takes one of two RAM values that appear to have (Load) 16 bit scaling. It takes the byte value for the boost limit map (Load8) 8 bit and quadruples it and compares it and the lowest of the two RAM values. If the load is below the limit, then it simply resets the boost cut counter to the value in the ROM. On exiting this routine it stores a truth flag to say if this counter has elapsed to zero and seems to have links with the rev-limiter routines.
I'm looking at the fuel map load lookup to see if it uses similar addresses to the 16 bit load scaling above.
I hope to then look for routines that link the load values I've found in RAM with serial output/Evoscan request ID stuff to see if I can modify the code to chuck out the "load".
This is very slow progress of course.
I've been looking at the overboost cut routine. It takes one of two RAM values that appear to have (Load) 16 bit scaling. It takes the byte value for the boost limit map (Load8) 8 bit and quadruples it and compares it and the lowest of the two RAM values. If the load is below the limit, then it simply resets the boost cut counter to the value in the ROM. On exiting this routine it stores a truth flag to say if this counter has elapsed to zero and seems to have links with the rev-limiter routines.
I'm looking at the fuel map load lookup to see if it uses similar addresses to the 16 bit load scaling above.
I hope to then look for routines that link the load values I've found in RAM with serial output/Evoscan request ID stuff to see if I can modify the code to chuck out the "load".
This is very slow progress of course.
I know we have been discussing this on aktivematrix, but it seems like the people are looking for OBD-II mods, and logger mods.. Hopefully that stuff will turn up soon.
Originally Posted by l2r99gst
Ludi,
You divided by the actual AFR it looked like, not the AFRMAP value.
Eric
You divided by the actual AFR it looked like, not the AFRMAP value.
Eric
That's what I get from staring at too many logs over the past few days. I stand corrected.
JCS, the formula is actually a lot closer when used with the correct values ... works for both of my logs. Sorry for the confusion on my part.
l8r)
Originally Posted by jcsbanks
Looking at the data so far, how about:
5 * injector scaling * (IPW-latency) / AFRMAP
5 * injector scaling * (IPW-latency) / AFRMAP
I guess thats what happens in the midst of a Evo ecu techno revolution - when you step away from this thread for one day, you miss out on a whole lot of good stuff.
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
And there will hopefully be further developments because I have found the 10 bit real load figure in the ECU code. I just need to work out how to dump it out the serial - this is the hold up. So a small change to the ROM would probably do that once I find the location to twiddle. And then a new requestID in Evoscan.