OFT - Guide To Dialling In Your OTS Base Tune

[Wayno]

It doesn't matter if you get more power and prevent bogging down running it leaner. Anything under 11.5 in that area will feel shit generally.

Originally Posted by solidONE

^ It would be a good idea for those of you messing with the load limits to log the cam timing as well to better determine whether the lean spots are caused by scavenging effect. The valvetrain noise caused by aggressive overlap may also contribute to knock, or rather "knock". (in quotations because this may not be real knock)

[Dru670]

is this v86 MAF Scale an improved version over the OTS stg 2 tune in terms of a drop in filter and silicone intake pipe?

[solidONE]

Originally Posted by steve99

their is a FLKC (fine learning knock correction table ie learned knock table, so yes ecu learns where knock happens and stores it. While we log FLKC and see it instantaneously its also stored for a period in a table similar to the one below.

their is a whole lot of algorithms applied by ecu to work out if it will decrement or increment iam and when it will return the flkc timing it stores. When you see positive FLKC this is the ecu returning some stored flkc

that learned table is storred in ram and gets cleared on ecu reset or flash

their is a whole lot of info on romraider site

see the flashing-RESET-Learning link below

the romraider guys have done it with learning view but its not set up for brz/86 ecu

Has this table been defined on the FRS/BRZ?

[steve99]

Originally Posted by solidONE

Has this table been defined on the FRS/BRZ?

No

The flkc table is actually in the RAM area ie random access mamory that is lost on complete power off of ecu.

The ROM or flash area is a differnt mamory area in ecu and is non-volitile ie its permanent untill you re-flash it.

tunes and definitions are for the ROM or flash memory area of the ecu. A "tune" that you flash contains a mixture of program instructions and tables/data, these are intermingled throughout the rom/tune.

A definition is an index into this mess of instructions and tables and it allows romraider to extract the tables from the correct locations in the rom/tune and display/scale them into a human readable form, which you can then edit/change and then reflash to alter the "tune" of the engine.

Each time the recompile a new rom calid these tables and instructions and ram locations can change, this is why you need to carefully match definitions and roms, and why the logging ram address are often different between different calid

The FLKC table above is created in ram a different area by the program instructions in the ROM area, the ram also holds all those logging addresses you read out with tactrix or oft or ecutek. The RAM is like a scratchpad temporary working area the ecu uses for high speed calculations and temporary storage of run time data.

The ROM is like the hard disk on your computer and the RAM is like the RAM on your computer.

The program above showing the FLKC stored table access,s the ram area of the ecu to read that data, it possible the oft guys could display it but would require someone to wade through the program code to see where its written to in RAM for each separate rom calid.

also it would require 64 ram addresses to be read, which would be quite slow, although that data is not likely fast changing, you clould probably interleave it.

But i doubt anyone is going to go to the trouble

[Wayno]

Originally Posted by Dru670

is this v86 MAF Scale an improved version over the OTS stg 2 tune in terms of a drop in filter and silicone intake pipe?

Did you try shiv's scales first? They likely don't need to be updated.

[Hyperblue302]

Originally Posted by Wayno

Did you try shiv's scales first? They likely don't need to be updated.

lol

[Kodename47]

Originally Posted by solidONE

Has this table been defined on the FRS/BRZ?

The boundaries are defined in most defs:
Fine Correction Rows (RPM)
Fine Correction Columns (Load)

[solidONE]

Originally Posted by Kodename47

The boundaries are defined in most defs:
Fine Correction Rows (RPM)
Fine Correction Columns (Load)

Now to figure out what each of these tables do exactly. I suppose these table control what is being stored onto the table steve99 posted. I should be able to reduce the amount of knock correction is being applied or speed up the rate in which the computer increase the IAM after having subtracted due to knock events stored by changing some of these values, I assume.

Edit: I've decided to make some small conservative changes to a few of the fine correction tables and see what kind of effect it will have. Reduce the knock correction per knock event from -.65 to -.35. Increased the positive limit from 3.5 to 4.0. Reduced the "no knock" delay period from 125 to 100. I suppose I'd have to really wring the engine out to the point where IAM get reduced to see the effects on some of the changes. Also I dont have any sort of a "baseline" log to really compared it to. So this is all for shits and giggles, butt dyno type deal.



A little test log before applying the changes and reflashing my ecu:
http://datazap.me/u/solidone/z6-test...og=0&data=1-11

Little ticky-tack -.65 FLKC corrections here and there. Nothing major.

[solidONE]

http://datazap.me/u/solidone/z6-kc1?...zoom=1969-4752

Here's the 1st log after having applied the changes in the above post. The effect it had on FLKC was just as expected. In areas where I would have gotten -.69 FLKC before the adjustment to the "Potential change" table I'm now seeing -.34 FLKC instead. Since I did not changed the maximum flkc of -5, I don't believe I've compromised too much in terms of safety compared to the stock tables. I hope.. What do y'all think?

Here's a quick second log I took just now with a 3rd to 4th pull and 3rd gear pull right after.
http://datazap.me/u/solidone/z6-kc1?...1&zoom=447-966

Looks like the FLKc still managed to go to -.69 here toward redline.

Another thing that I think is interesting is that before I made the changes, there were many instances where FLKC only goes up to -.29 even though the value in "potential change" table was -.65.

log right before I applied the changes above, with -.29 FLKC in many areas:
http://datazap.me/u/solidone/z6-test...3166-2524-3588

[Kodename47]

Originally Posted by solidONE

Another thing that I think is interesting is that before I made the changes, there were many instances where FLKC only goes up to -.29 even though the value in "potential change" table was -.65.

Stored timing retard plus an increment of added timing?

Beware that increasing the Positive FLKC limit may impact on IAM increasing if below 1.

[solidONE]

Originally Posted by Kodename47

Stored timing retard plus an increment of added timing?

Beware that increasing the Positive FLKC limit may impact on IAM increasing if below 1.

That makes sense, but it's impossible for me to know 100% without the ability to log or view the stored FLKC values.

The intent of changing the the positive limit and decreasing the delay period value is to cause the IAM to recover a bit quicker than it does with the stock table. I'd have to drive the car pretty hard or get a bad tank of gas to see the effects. I will try to capture it in a log and compare it to a old log to see the difference this change made.

[Kodename47]

Originally Posted by solidONE

The intent of changing the the positive limit and decreasing the delay period value is to cause the IAM to recover a bit quicker than it does with the stock table.

The delay I understand however, based on the usual logic, I would assume that the positive limit could lengthen IAM recovery. I'd suggest that one the limit is reached the multiplier increases regardless. By making this higher then in some circumstances you'll need more positive FLKC before IAM increases. This is all relatively irrelevant anyway as one would hope you're not facing 3.5/4 degrees of FLKC retard in the 1st place.

Also, to make the delay obvious then reduce it by half. Probably not a bad idea on a car running well dialed in.

[solidONE]

Originally Posted by Kodename47

The delay I understand however, based on the usual logic, I would assume that the positive limit could lengthen IAM recovery. I'd suggest that one the limit is reached the multiplier increases regardless. By making this higher then in some circumstances you'll need more positive FLKC before IAM increases. This is all relatively irrelevant anyway as one would hope you're not facing 3.5/4 degrees of FLKC retard in the 1st place.

Also, to make the delay obvious then reduce it by half. Probably not a bad idea on a car running well dialed in.

The increase in the positive limit is to deal with those rare instances where IAM inexplicably drop under cruising low load steady throttle. Not sure if you've had this happen on your personal car, but I've see it quite a few times. Usually this happens while commuting on the highway flowing with traffic in 6th gear. Dont know exactly why this happens but it seems like a "glitch" of some sort. Or maybe bad gas? I dont know.

As far as the delay goes, I didn't want to get too greedy right off the bat, if you know what I mean. lol

[Wayno]

In my experience nothing is inexplicable. Better solving the actual issue which causes IAM drop in the first place than working around it and creating more complexity.

Originally Posted by solidONE

The increase in the positive limit is to deal with those rare instances where IAM inexplicably drop under cruising low load steady throttle. Not sure if you've had this happen on your personal car, but I've see it quite a few times. Usually this happens while commuting on the highway flowing with traffic in 6th gear. Dont know exactly why this happens but it seems like a "glitch" of some sort. Or maybe bad gas? I dont know.