Steve thanks for the tutorial, without it I would be scratching my head. I have actually loaded an old log and made it all work so now down to some new logs see what I can come up with. I will have to put my closed loop chip in as I have been only open with WB monitor for the last year.
6395, BHDF, 7.4 BBC lightly modded now 6395 BMHM back to BHDF
I just ran an old log with your analyzer, and I made it work the first time. That says volumes for your coding abilities, thank you for your efforts.
that's a win for sure. thanks for trying it outI just ran an old log with your analyzer, and I made it work the first time.
i added a proper option for trim as 'arbitrary input'.
so this treats any field you select as Trim A as raw data and charts it vs rpm and map for you (of course you can cheat and select non-rpm and non-map values for those axis too)
if you also have a Trim B selected, it'll give you the average of the two.
so you should be able to chart, for example, wideband afr against your VE table... or whatever you want, even if you have dual widebands.
being able to define arbitrary filters makes this super useful too.
this option disables things that would make no sense, like clipboard access, coloring in the ve table, integrator influence...
http://fbodytech.com/trimalyzer/trimalyzer-download/
Just wanted to drop a huge thanks - pulled the source from git yesterday and compiled on Ubuntu linux / QT 4.6. Nice work steveo - two huge thumbs up!
I just tested the modify clipboard function with data copied from / to TunerPro running in a virtual - nice!
Yes, this is very cool! I've been working on a tune for my cammed LT1 build and the filters helped me locate some issues I'd been meaning to track down for several days but lacked the time to do my own filtering on.Originally Posted by steveo
I'm confused. I think I correctly used trimalyzer with the attached .zip (csv file)? I've compared the trimalyzer results with my tuning spreadsheet, see attached screen shots. Any thoughts?
dave w
I'm not near a computer right now, but it looks like you're using the setting where stoich = 100% instead of 128.
ex.. 113/128 = about 88℅
Last edited by dud; 04-01-2017 at 12:09 AM.
the difference is that my software can deal with different input trim ranges, and outputs them in a standardized way
whereas i display properly converted percentages of correction required, you display unconverted raw trims in your spreadsheet (signed 8 bit int from ecm). if you look at your trims as percentages, we're actually pretty much in line i think.
this is required for mine to be a more generalized tool, as old gm ecms are raw 8 bit signed, obd-ii trims are usually a percent, where some dataloggers do signed percentage, some do whole percentage, i want the display to look the same for everyone using the software.
i guess i could make it clearer in the UI with a legend that says 'percentage' or some such thing
Posting Permissions
Reply With Quote
Bookmarks