isnt that just for ajup though
Printable View
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.
is it any better/different than the tool that this thread is about?
Awesome job Steveo can't wait to try it out
Now that 2-bar support works for the P66 V6 PCMs, I have some questions about this tool-it looks like it will be very handy but in my case, I need to make sure that the "over 1 bar" flag gets set and recorded in the logs, as it flips tables based on that-can Trimalyzer flip tables, given that there is a "less than 1 bar" and a "more than 1 bar" table?
yeah kinda, you will have to set and unset the filter for "over one bar" or whatever.. no big deal.
Ok, so if the flag sets and unsets and I log the flag, will can I get trimalyzer to switch based on the flag? Or do I have to manually crop and filter data and tell it specifically what table we're in?
you have to add a filter and define your tables
set the filter to false. run your analysis against the correct table
then go back and set the filter to true. run your analysis again.
shouldn't be tough at all
it'll remember your filter if you like, and it will also remember your tables.
ah, ok. That's not too bad, and will allow me to tune *just* one table at a time if I want-although I'll have a wideband in the logs too that I'll be looking at for boost control, being able to use the narrowbands to do bulk tuning will help save time.
I have tried to use this tool for MAF 6E cars, and it also works well. However, it needed some tweaks to the datalog to make it work. The MAF / SD templates accept only integer values for cells. Tuning MAF using MAF voltage, the cells have fractional values. I have added another log value with MAF Voltage *100 which solved the problem, but maybe it would be good to add a possibility to have the cells with fractional values.
Another thing - the MAF tables have the "Modify clipboard" button not working, which is not a big deal, but I can't select multiple cells in the Trimalyzer results and copy them - this is another place for improvement that came into my mind.
Anyway, the tool does it's job very well and makes tuning much easier :)
Hi Steveo,
I am trying to make it work with the new maf data [MAF CELL number and MAF CELL offset] I have in eehack available. There are some problems to solve though. There are 77 MAF cells, but I can enter only 70 in the MAF layout window. ALso there is a new parameter[maf cell offset 0-255] that weights how far from the selected cell you are. For example if you are at cell 10 and the offset is 245, you will be almost at the cell 11[or 10.96]. So if that is not taken into account the analysis will not be very accurate. Do you think it will be hard to add that in the trymalizer.
i'll look at it, I haven't looked at the source in a while, but it's doable. of course we could add it to eehack's onboard maf analyzer too
adding the extra rows is easy, but i could also do it properly and add a new row when the table is full so it can be any size. there's no limit other than the number of rows in that table (or the size of a 32 bit signed integer)
the next part, i'd have to add two input parameters for 'maf cell number' and 'maf cell offset' and make them assignable, then create a new maf analysis engine (other than loose or strict) that works on that method.
shouldn't be too hard i'll make some time for it soon
Great. I hope you find some time to add it.
You can make a strict logic also, if the cell offset oscillate around a particular cell. For example if you are constant around cell 10 with 240 offset and cell 11 with 15 offset. And specify how much deviation is allowed for strict logic will be awesome.
I found that is really important to keep the % of spread between cells, so you can add a smoothing feature that tries to anticipate the correction for whole region [5-10 cells for example] and find a breakpoint where it ups or downs the correction. It will be a good feature for ve also since it can lead to inj pw fluctuation at steady throttle if the spread is not optimal.
i think affecting adjacent cells but more weakly is the best technique for both 2d and 3d tables, that's why i built trimalyzer since spreadsheets can't do that effectively. once you average across a lot of samples, you end up smoothing regions of the table that aren't affected very much, or 'in between' cells with not enough data.
i'll try to work on it soon, lots of projects right now. you're getting better with c++, feel free to look at the source any time too. its much better written than eehack..:
https://github.com/resfilter/trimalyzer
I am sure you will find the best possible way to utilize the new datastream and make it the best tuning tool available.
Most of the coders lack the skills of the tuners or simply don`t know what is needed to write a good tuning program and the result is ultimately sub par product. In your case you combine both of it and the results are amazing. I just can`t imagine what would of happen if you still had an lt1 car around.
I am slowly getting better with the c++. Still too far from writing complex loops. Now I have a better understanding how it is translated to machine code, but the syntax is the missing point. I need to find a good basic tutorial to start with.
well, you're brilliant with low level stuff. i can't imagine what would happen if you learned to turn it into user level software.Quote:
I just can`t imagine what would of happen if you still had an lt1 car around.
i'm not a very good programmer but i'm really driven by making things that haven't been done before... eehack and trimalyzer are both completely unique.
i did test adding a bunch more rows to the table builder thing, it worked fine, but i still have to write a new engine for your 'cell based' maf tuning thing. do you think there's any real advantage to tuning this way? i've always found maf tuning to be really easy, since your changes end up being fairly predictable based on a few samples.
I've been looking at the trimalyzer-1.4b tool for $OD.
I have some interesting data to share trimalyzer-1.4b vs. the WBO2 spreadsheet located here: http://www.gearhead-efi.com/Fuel-Inj...g)-Spreadsheet
I think I have trimalyzer-1.4b correctly configured like the WBO2 spreadsheet; to filer $OD / Closed Loop / PE False / AE False / Idle Flag False / Open Throttle VE Table
Attachment 13740
Attachment 13741
Attachment 13742
Attachment 13743
Attachment 13744
I'm embarrassed to admit I was unable to figure out how to get trimalyzer-1.4b to work with WBO2.
I find it interesting the trimalyzer-1.4b BLM's vs. WBO2 data are different.
See attached .zip for .csv file used with trimalyzer-1.4b and WBO2 spreadsheet.
Thoughts?
dave w
try checking ignore integrator data and maybe use strict or loose method instead of geometric. geometric averages quite a bit in surrounding cells as well, (it's designed to get a fresh tune off the ground quickly since it 'guesses' more for cells with low counts) so comparing it to another analysis method like your spreadsheet isn't going to give you great results like you'd expect to see, however a cursory glance at your data definitely reveals your BLMs are leaner than your wideband data seems to indicate, so you do get what you put into it, is it possible your wideband calibration is a bit off?
to get trimalyzer to analyze wideband is pretty easy, just put your wideband field in trim bank a instead of a narrowband trim, remove the integrator, and use trim input type 'arbitrary value'. you can use this to analyze other stuff too, basically anything that's a number.
I'm thinking the WBO2 data is reasonably accurate (+/- 0.2 AFR). It's challenging to define / correlate an AFR vs. BLM. The AFR vs. BLM expectation is "Lean" fuel air mixtures will be similar; AFR's above 14.7 and BLM's above 128. I literally have hundreds of $OD WBO2 data logs that indicate AFR vs. BLM are not similar to one other. OBD2 tuning software ( EFI Live) is seeminly more accurate with "Serial" WBO2 data vs. 0v - 5v WBO2 data. I literally have dozens of WBO2 $OD "Tunes" that out perform $OD BLM "Tunes".
I think I have correctly configure trimalyzer for WBO2?
Perhaps the "target" of 128 in the results needs to modified to an AFR value?
I'm very interested to see if trimalyzer will show a similar $OD AFR vs. BLM data like the spreadsheet.:popcorn:
dave w
Attachment 13760
Attachment 13761
you probably do want a 14.7 target (or whatever your target is)
its in the analysis window at the top (target can be changed live)
I greatly appreciate Trimalyzer!:thumbsup::thumbsup:
I'm definitely a fan of Trimalyzer.
I was able to adjust the target, but not to 14.7.
dave w
Attachment 13767
Attachment 13768
hm i think the arbitrary input is broken. i never actually intended it to use 'target' when using arbitrary input since that wouldn't really make sense.
I was able to get Trimalyzer 1.4b to show the proper WB02 values with the settings pictured below.
dud,
Thank you very much for helping out with "how to WBO2" using Trimalyzer!:jfj:
It appears Trimalyzer shows similar BLM vs. WBO2 data, like the WBO2 spreadsheet.
The WBO2 spreadsheet uses "Average IF" to calculate WBO2 data.
dave w
Attachment 13775
Attachment 13776
ill do an update to trimalyzer to fix that and maybe make the ui more clear. i feel i've neglected it a bit
trimalyzer does the same thing, but has the flexibility to apply more math to each data point. i'd expect the data to be the same if 'strict cell' is chosen and if all filters are equal.Quote:
It appears Trimalyzer shows similar BLM vs. WBO2 data, like the WBO2 spreadsheet.
The WBO2 spreadsheet uses "Average IF" to calculate WBO2 data.
loose cell can affect multiple cells if the data point is close to a cell border. geometric is like a smarter 'loose cell', it affects adjacent cells with magnitude based on how far from the data point they are. i think it's way better, but whatever floats your boat.
ok try this, made some changes so arbitrary input should work as expected
http://fbodytech.com/trimalyzer/trimalyzer-download/
Works great!:thumbsup:
dave w
Attachment 13777
Its good to see trimalyzer is still being worked on. Even though im not very familiar with it i think its a great tool.
Just figured out how to get my WBO2 readings to show up in trimalyzer. Pretty cool!
Should I be adjusting the VE table in all map and RPM areas to get about a 13.0:1 reading? I previously just adjusted the PE AFR vs RPM table to dial in the high map areas. The PE AFR analyzer in EEhack always showed rich <70 kpa. Thanks for any input!
Attachment 14404
when power enrichment is active you want to hit about 13:1, and when not in power enrichment you want to hit about 14.7:1 (for a street car with lower emissions anyway)
if you adjusted power enrichment using the PE tables first before establishing a clean VE table on a speed density configuration, you did it backwards. you should adjust VE tables first then tune power enrichment. now when you adjust the VE tables you'll mess up your AFR in PE
edit: of course if you're running a maf, you pretty much leave your VE tables alone
Yes did VE tables first. Running in SDCL no MAF. I put different injectors in that I have more accurate info for so I decided to completely redo my VE tables. I have done about 4 or 5 logs with PE turned off to try to fine tune my VE tables with trimalyzer. The latest one I did was about a 90 min drive. Figured it was going to be as good as I could get it without a dyno so I was going to start dialing in the PE.
I just wasn't sure if I should worry about changing the VE table in the lower map regions where PE is active? It seems the changes to the PE AFR vs RPM table are consistent in the upper map regions but are showing rich in the lower map regions.
Here is a pic of my upper VE for reference. It has some hills and valleys, but the car seems to run real good.
Attachment 14405