Two questions

1. How consistant is ECU with calculating what current load it is for a given set of conditions (How accurate does determine what timing or fuel value to use)?For some few plots I cant figure out where evoscan gets the timing value.
2. I noticed the more things you log the longer the interval for each reading. Would this effect the number of given knock counts? Just making sure.

Thanks for the response

 

If you use the AIRFLOW/RPM*852 formula it seems to be pretty accurate for calculating what load cell you're in. I asked a similar question a few days ago and after a lot of back and forth this is what I came away with and it seems to work.

What do you have your cable connected to, an older machine? I ask because I log all outputs and even so the updates are damn fast, faster than any other car I've owned and done logging with using the standard OBD2 stuff.

 

the formula using 852 works BUT it isn't as consistent as using the timing block method. With the timing block method you can 100% find your load cell EVERYTIME! Until something better comes along that is the only way I will tune.

 

actually... I find the 'timing block' method a bit ambiguous. since the table only has RPM in values of 500, and the timing can vary 3-4 degrees sometimes in both horizontal and vertical directions, you're left only looking at a possible "block" of values to consider. I have very rarely found it easy to find my load this way either. (not to mention its very time consuming)

 

If you don't get an exact timing number to reference you have to look in between load cells to figure out where you fall map. Since you know the RPM it’s easy to find the actual load cell your in, that’s assuming your timing map doesn't have 8's everywhere.

It does take a little to getting used to but once you figure it out it's as if someone turned on the light switch. I'm an accountant so maybe it makes sense to me because I work around numbers all day…

 

The timing/rpm lookup method really kills me when I tune.. I usually block in my tunes for the first few passes, then smooth them out later as I alter the load and boost levels.. so there will be adjacent cells with duplicate values until I finish tuning..

I really hope Colby releases an update for ECUFlash with the shared memory logging so you can see all the real-time values and other values otherwise hidden from OBD-II.. Or we need to find the MUT-III call for the load cell.. Even if its just a matrix value referring to the leftmost cell, to the rightmost cell (I think that is what it actually does and therefore we're not looking for that value, we're looking for load) It then matches the load value to the column number and looks up vs RPM.. seems most logical for me..

So what that means is if you guys are using Evoscan, you should look for registers that have values referrencing the column number and not load value.. This would in reality make map tracing alot easier to do since its a distinct location on the map's matrix. THAT IS IF THIS APPLIES which I think it might because otherwise we should have a true load value somewhere..

 

I just don't get how this could yeild any meaningfull result with Evoscan since it clips airflow values at 1603.95. Once you hit the 1603.95 ceiling and the airflow keeps climbing (like it obviously will unless your boost is dropping way off in the upper revs), you cannot count on the formula again until your airflow drops below that 1603.95. In my opinion, that makes the formula useless until the Evoscan author can get around this airflow ceiling.

Please correct me on how I'm wrong about this.

 

When I made my own device to use a 3d map with bilinear interpolation I took the "load" and "RPM" values and used div (integer division) to get the lower zone's x & y location, and mod (modulus) to get the x & y offsets. Location would be converted to address by x+(y*rowlength). Then I'd lookup the four values by address, address+1, address+rowlength, address+1+rowlength. Then I'd cross multiply the four values by (1-xoffset), (1-yoffset), yoffset, xoffset and divide away all the multipliers that had got in there.

Result was interpolation using integer code, and I strongly suspect this is how the SH2 does it. The code is too big and unlabelled to work on for me though at this stage. If we started to know which locations and registers were used for what, and some of the routines were labelled I'd have a start, but this is beyond my skill level at present.

 

Yep, that was kind of what I was getting at in a discussion on my forum.. Although I do suspect the actual value (the cell location in the map) is somewhere in one of those MUT-III responses, only we weren't looking for values like that.

It does appear that is similar to what the ECU is doing, only your dead right about how difficult the code is to trace.. Its unbelievably circuitous because it seems that it had evolved from earlier code, and was not a rewrite from scratch.. The code is somewhat modular and therefor functions do appear to be grouped together, if that helps you any.

 

I did look for values that might have been the highest significant bytes of load, or a column value, basically anything that followed a "loadish" pattern and couldn't find anything to &H9F. We need those RAM values I think. I know Jason @ Mynes referred to previous disassembly of the routines, if this information was open source things could move on a bit?

 

I don't have all the I/O data to make disassembly easy.. But if you want I can create a subforum on my site, and post an 03 rom in it, then we can all work on disassembling and documenting it.

 

That might be good. I've looked on openecu as well, and there was little open development work going on there, but would that be the natural place for it?

 

Normally I would say yes, but I think it needs to be done as an independant effort since the tools required to do this aren't easy to come by and very few would be able to contribute useful info. This type of work needs to be heavily moderated.

 

We can try...

 

http://www.aktivematrix.com/forum/index.php?c=7