Toyota GR86, 86, FR-S and Subaru BRZ Forum & Owners Community - FT86CLUB

Toyota GR86, 86, FR-S and Subaru BRZ Forum & Owners Community - FT86CLUB (https://www.ft86club.com/forums/index.php)
-   Software Tuning (https://www.ft86club.com/forums/forumdisplay.php?f=88)
-   -   Data logging for noobs - OFT (https://www.ft86club.com/forums/showthread.php?t=53554)

Shad0ez 12-15-2013 06:02 AM

Data logging for noobs - OFT
 
Although there are quite a few members on this forum that have been tuning their cars for many years, there are also many members that have just started to venture into this world. There are no doubt some members that are fine with getting a tune and never bothering to check their logs to see how their engine and cpu are performing, and then there are those of us that would like to know exactly how how well our engines are keeping up with the new variables from the map that was just written on the cpu.

This is the first car I've ever owned that I've invested in a tuning solution where I can actually see the different ratios that the CPU is monitoring and I think it's pretty effing cool. I just wish I knew what everything I'm looking at meant. I've picked up on a few things just reading through the most recent posts about what the ideal AFR should be during WOT and at cruising speeds.

This may be asking a lot, but if one of the more seasoned tuners wouldn't mind sharing some of their basic knowledge and shed some light on a few things, I believe it would help many of us that are just getting started understand what we're seeing and save time from sending PM's to know if our engine is running as it should be. Below is a list of parameters that I see logged on the OFT and if someone could explain each item along with the range we should ideally be in, it would be greatly appreciated. I'm unsure if ideal parameters change depending on E85 or pump gas, so if that can be clarified as well that would be great.

MAF Voltage:
VVT intake:
VVT exhaust:
Ignition advance:
KC learned value:
AFR:
STFT:
LTFT:
Adv multiplier:

:thanks:

Kodename47 12-15-2013 08:40 AM

MAF Voltage: Voltage of the MAF sensor. There is a table that converts this voltage to g/s that the ECU then uses. This table may need to be configured to your sensor.
VVT intake: The angle of the cams of the intake VVT system
VVT exhaust: The angle of the cams of the exhaust VVT system
Ignition advance: Do you mean ignition timing? The angle before top dead centre (BTDC) that the sparks ignites in the cylinder. Too much advance and you'll get knock, but generally the more advanced you go then this increases power.
KC learned value: The ECU has a base ignition table, and an advance table. The KCL value is how much timing the ECU is adding onto the base value from the advance table. If the KCL values = the advance table then the ECU isn't pulling timing and all is happy.
STFT: This is what the ECU adds/removes from the fueling as an instant response to the target AFRs while in closed loop.
LTFT: Multiple occurrences of STFT will result in LTFTs being applied. Both LT/STFT are done on load based so you don't get a consistent reading across the full rev range or from different pedal positions. You ideally don't want massive swings in LTFT, STFTs aren't necessarily an issue.
Adv multiplier: The easiest way to describe this is the multiplier of the ignition advance table: Base ignition timing + (Ignition advance timing x IAM) = Ignition timing. FYI, Ignition advance timing x IAM = KCL. This will vary depending on knock detection. It will drop if consistent knock events are detected. It won't however necessarily drop upon every detection of knock.

jamesm 12-15-2013 11:36 AM

i log everything in that list as well as commanded afr, throttle position, fuel system status, injection mode, coolant temp, oil temp, intake air temp, and a few other less important things.

intake air temp and coolant temp are mostly used for filtering the data before processing. being able to filter on fuel system status and injection mode are also crucial to cutting through the 'noise' and getting the data to return something useful.

one thing missing is flkc. this isn't something you log in the traditional sense, it is not a steady stream of data thrown into a column. you read it from memory and (at least with brzedit) it attaches a text file to the log with the contents of the flkc table. i would consider this to be pretty crucial, as it's a full 1/3 of the knock-control strategy you can't see otherwise. i also noticed fbkc is missing as well, that is important.

the key thing i've learned about tuning from logs is that you need lots of data, you need to filter the data to eliminate noise, and you need to be able to process the data intelligently afterwards. looking at a csv file is mind-numbing, making graphs slightly less so. i use excel or apple's numbers to quickly generate scatter plots and what not as i go to help visualize things and see where the data really is.

Shad0ez 12-15-2013 02:42 PM

To those that have replied so far, thank you for taking the time to do so. It's a good start to understanding what we're looking at.

Would it be possible to take it one step further and provide a range that each of the parameters should be in?

Kodename47 12-15-2013 04:52 PM

Quote:

Originally Posted by Shad0ez (Post 1391514)
To those that have replied so far, thank you for taking the time to do so. It's a good start to understanding what we're looking at.

Would it be possible to take it one step further and provide a range that each of the parameters should be in?



The problem is there are too many variables to do this. The AFR, for example, will target different values on cruising to WOT. STFT's can produce large and rapidly changing values as you quickly change the pedal position. If you want an idea of what you should be seeing, have a look through the tables on the OFT/RomRaider maps and try and see what target value Shiv has set.

jamesm 12-15-2013 05:21 PM

Quote:

Originally Posted by Shad0ez (Post 1391514)
To those that have replied so far, thank you for taking the time to do so. It's a good start to understanding what we're looking at.

Would it be possible to take it one step further and provide a range that each of the parameters should be in?

that's not really how you want to look at it. you don't want to just watch numbers fly across a screen and look out for bad ones. you want to collect a pretty massive amount of data, throw away the noise and then look for trends in what's left. there are some things that just shouldn't be there, like timing being pulled in one way or another or significant afr error. but you might use this data to create a scatterplot of instances of > -1.4 fbkc on load and rpm axes or something like that. also it's not safe to stare at the device while driving :)

Vmax911 12-29-2013 03:28 AM

Being a noob to tuning, I'm going to bump this for further insight.


That being said, I try to look through the logs that are posted in the forum. I notice the following is quite common to see during full throttle pulls:


IAM=1
AFR 12-12.5
STFT is usually 0
LTFT seems to range between 0-9, I think lower is better.
Ignition advance seems to be in the low 20's for gasoline.


Does this seem right? Anything else I should be checking out?

brn12345 12-29-2013 07:31 AM

1 Attachment(s)
Quote:

Originally Posted by jamesm (Post 1391288)

...one thing missing is flkc. this isn't something you log in the traditional sense, it is not a steady stream of data thrown into a column. you read it from memory and (at least with brzedit) it attaches a text file to the log with the contents of the flkc table....



James, I log using BRZedit and I have logs of the FLKC in the chart without having to go and save the table as a text file. The attached is a screen shot, the light orange line is FLKC

jamesm 12-29-2013 11:43 AM

Quote:

Originally Posted by brn12345 (Post 1417439)
James, I log using BRZedit and I have logs of the FLKC in the chart without having to go and save the table as a text file. The attached is a screen shot, the light orange line is FLKC

That's similar to how ecutek presents it. It's far more useful in table format.

subwaynm 12-29-2013 11:55 AM

I would like to also thank all of the folks that have replied; because it's not easy getting into this aspect of our cars at first but appears to be necessary to get all we can from the cars.
And thanks to Shad0ez for posing the question the way you did.
Appreciated

TM 03-04-2014 01:14 PM

This thread has a lot of great information for beginners to start to understand their data logs.

My questions is: How do I know if something is out of the ordinary? AFR too high/low? KC learned value? Advanced multiplier dropping? I'm not sure exactly how to spot trouble areas. And after we locate a problem, what needs to be changed to address that problem?

jamesm 03-04-2014 01:27 PM

Quote:

Originally Posted by TM (Post 1573385)
This thread has a lot of great information for beginners to start to understand their data logs.

My questions is: How do I know if something is out of the ordinary? AFR too high/low? KC learned value? Advanced multiplier dropping? I'm not sure exactly how to spot trouble areas. And after we locate a problem, what needs to be changed to address that problem?

to understand what is wrong, you need to have a general understanding of what is correct. basically the two things you care about as someone logging their car (i.e. not tuning it), are fueling and timing.

for fueling you want to make sure that trims are low (<5%) and that you are hitting your afr targets. for now OFT can't log eq. ratio commanded (it's coming in the update though), so you'll have to correlate load and rpm with afr targets from the fueling map, then see in the log if you're on target. short trims will always be zero in open loop, so disregard that. any LTFT being applied in open loop is problematic and will likely cause you to miss fueling targets, and should be corrected. when it comes to fueling error, you should really employ spreadsheets or other tools for the closed loop portion, and use the log viewer to confirm that your on target in open loop.

timing is also very simple: it just shouldn't be pulling any, ever. at least that's my opinion, some people say knock correction is ok, and i argue that it's ridiculous to say that. knock correction costs you power vs. tuning up to the knock wall and backing off a bit, and it's an imperfection. we tune cars to be perfect. if perfect can be done (and it can) it should be. anything less is unacceptable to me. others feel differently.

for this you'll want to make sure that FLKC (when it's available to log via OFT) is always zero, and that FBKC is not consistent or repeatable. you'll inevitably have some FBKC here and there at low loads (particularly throttle tip-in), but the big thing is to make sure that it's not writing in to FLKC, or happening repeatably under high load. your IAM should always be 1, period. if it's not, you're losing significant power across the board, and something should be corrected.

the biggest misconception on this forum that i've found is that a low IAM is ok. i've read posts by people suggesting that your IAM 'should be closer to 1' in one scenario or another. this is insane to me. your IAM should just be 1, if it's not you have a significant problem. IAM is coarse correction. it is the ecu's last attempt to save itself. if it drops, you lose power everywhere, when in reality you probably just need to pull a degree or two from one little area somewhere in the advance table to make it happy and stay at 1. it's the ultimate 'looks good!' response in my opinion. one could argue that having it drop isn't dangerous as long as it stabilizes, but that isn't the point. it's incredibly suboptimal, in terms of the actual tune itself. the entire point of tuning is optimization. there is no need to accept this as 'normal'. it's been well accepted and understood for a long time in the subaru tuning community that an IAM less than 1 is not 'normal' or 'ok'. it's something requiring immediate attention if you want your tune to be anything close to optimal.

that's really about it from the 'is my car ok?' perspective. there's not much to it. just collect a lot of data for closed loop, and short logs for open loop. check that everything is on target and not pulling any timing, and that'll let you know that things are performing as intended and that you tune is safe.

TM 03-04-2014 01:42 PM

Quote:

Originally Posted by jamesm (Post 1573431)
to understand what is wrong, you need to have a general understanding of what is correct. basically the two things you care about as someone logging their car (i.e. not tuning it), are fueling and timing.

for fueling you want to make sure that trims are low (<5%) and that you are hitting your afr targets. for now OFT can't log eq. ratio commanded (it's coming in the update though), so you'll have to correlate load and rpm with afr targets from the fueling map, then see in the log if you're on target. short trims will always be zero in open loop, so disregard that. any LTFT being applied in open loop is problematic and will likely cause you to miss fueling targets, and should be corrected. when it comes to fueling error, you should really employ spreadsheets or other tools for the closed loop portion, and use the log viewer to confirm that your on target in open loop.

timing is also very simple: it just shouldn't be pulling any, ever. at least that's my opinion, some people say knock correction is ok, and i argue that it's ridiculous to say that. knock correction costs you power vs. tuning up to the knock wall and backing off a bit, and it's an imperfection. we tune cars to be perfect. if perfect can be done (and it can) it should be. anything less is unacceptable to me. others feel differently.

for this you'll want to make sure that FLKC (when it's available to log via OFT) is always zero, and that FBKC is not consistent or repeatable. you'll inevitably have some FBKC here and there at low loads (particularly throttle tip-in), but the big thing is to make sure that it's not writing in to FLKC, or happening repeatably under high load. your IAM should always be 1, period. if it's not, you're losing significant power across the board, and something should be corrected.

the biggest misconception on this forum that i've found is that a low IAM is ok. i've read posts by people suggesting that your IAM 'should be closer to 1' in one scenario or another. this is insane to me. your IAM should just be 1, if it's not you have a significant problem. IAM is coarse correction. it is the ecu's last attempt to save itself. if it drops, you lose power everywhere, when in reality you probably just need to pull a degree or two from one little area somewhere in the advance table to make it happy and stay at 1. it's the ultimate 'looks good!' response in my opinion. one could argue that having it drop isn't dangerous as long as it stabilizes, but that isn't the point. it's incredibly suboptimal, in terms of the actual tune itself. the entire point of tuning is optimization. there is no need to accept this as 'normal'. it's been well accepted and understood for a long time in the subaru tuning community that an IAM less than 1 is not 'normal' or 'ok'. it's something requiring immediate attention if you want your tune to be anything close to optimal.

that's really about it from the 'is my car ok?' perspective. there's not much to it. just collect a lot of data for closed loop, and short logs for open loop. check that everything is on target and not pulling any timing, and that'll let you know that things are performing as intended and that you tune is safe.

Thanks a lot for writing this up. It is truly appreciated. :w00t:

Captain Insano 03-05-2014 09:18 PM

Great thread. Didn't know what to be looking for as "normal" for the fuel trim values so this was a useful read. Thanks all.


All times are GMT -4. The time now is 07:00 AM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2025, vBulletin Solutions Inc.
User Alert System provided by Advanced User Tagging v3.3.0 (Lite) - vBulletin Mods & Addons Copyright © 2025 DragonByte Technologies Ltd.


Garage vBulletin Plugins by Drive Thru Online, Inc.