Narrowband Tuning Tool

[steveo]

users of scan9495 may have noticed their logs not loading in trimalyzer due to a format problem in scan9495.

scan9495 has been updated, see details here http://fbodytech.com/scan9495-and-trimalyzer/

[steveo]

updated the faq:

http://fbodytech.com/trimalyzer/trimalyzer-faq/

topics:

I am getting zero record counts and no data is displayed, or my data is simply crazy.
Can I load logs from two different tools simultaneously?
Why doesn’t MAF mode have the same awesome functionality as VE mode?
How do the different analysis modes work?
What do the target/max/min settings do, and when would I use them?
What if my special field name isn’t detected? What if a true/false condition doesn’t work due to a strange label in my data like “yep” instead of “enabled”?
Does it analyze wideband data?
How do filters work?

[dzidaV8]

I finally used this tool yesterday for LT1 tuning, and it's great! It also works well with WB generated trim (0-255 BLM style).

One thing I noticed, it would be better if the clipboard modifying function would retain the number of significant digits in the original table, so when I paste the modified table back to TP, only modified cells would be red. Right now TP xdf has 1 significant digit display and trimalyzer gives 3 digits back, so a value that is not modified changes from e.g. 44.1 to 44.100 and TP shows this change in red.

[steveo]

One thing I noticed, it would be better if the clipboard modifying function would retain the number of significant digits in the original table, so when I paste the modified table back to TP

lets think about that

this tool isn't designed to work with tunerpro at all, i want it to work with anything that has input/output of tabular VE data

so if the input has 2 decimal places across the board, you'd like the output to have 2 decimal places as well, that makes sense for every tunerpro use case i can think of

what if the input isn't from tunerpro, though

what if it's from software that has variable precision per table cell (probably common with data from spreadsheet input), for example lets say 1% is 1% but 1.55% is 1.55%

should it match for each cell, or should look over the input data and it use the maximum number of decimal places found?

if input can have arbitrary precision and we follow that precision (choosing the first option above), does this mean we willingly discard output precision and round off to match the number of decimal places regardless? (say a case where variable input precision has 1% trim and we have 1.55%, do we still adhere to input precision?) the current method tends to force the tuning software to be responsible for rounding off and coming up with a value that fits the limits of the calibration

lets say we require that input has consistent precision, do we refuse to work with a table that doesn't?

or would we rather have unchanged cells just output verbatim so it'll solve your problem without even caring how many decimal places are output?

i'm not saying it can't be done, or it wont, the request makes sense, just consider that such changes can have unintended effects so thought needs to go into how it's done

[dzidaV8]

It all makes sense, I agree that universal is best...
It's not really an issue, just a thought that came to me while tuning.
Anyway, I have adjusted XDF to show 3 significant digits and now I have coloured changes to help me with manual table smoothing if needed.
I think that probably the best option would be not to modify at all the cells that have no adjustment.

[84Elky]

Might look at this if Speed Density. Automatically provides analysis from any log file all data needed for quick tuning.
http://www.gearhead-efi.com/Fuel-Inj...-File-Analyzer

[steveo]

isnt that just for ajup though

[84Elky]

isnt that just for ajup though

Not just for AUJP. The default configuration is for a log file created by S_AUJP v5 using the provided ADX file, but will easily analyze any Speed Density log file (csv, xls, xlsx) produced by any program (TPro, TCat, etc.). Just need to enter the names of any log file column titles that differ. That's all. Will also likely provide meaningful data for a MAF log since the Analyzer is merely looking at the data in the log file, not how it was produced.

[steveo]

is it any better/different than the tool that this thread is about?

[84Elky]

is it any better/different than the tool that this thread is about?

Can't say it's better or different, just summarizes all important data in a log. Open it up along with the sample log file and view the data provided. Would welcome all feedback good or bad.

[delcowizzid]

Awesome job Steveo can't wait to try it out