Narrowband Tuning Tool

[steveo]

i'm writing a new tool for narrowband tuning as an alternative to using spreadsheet-based tools or tunerpro's history table thing. it will be based on eehack's analyzer, but way more general purpose and easy to use.

for input, you will provide CSV log files.

the program will build a 'log profile' when the very first log is loaded. the log will be parsed for header information and attempts will be made to automatically determine common fields like 'Coolant Temperature' or 'BLM Cell' or 'LTFT' or 'Power Enrichment Active' to build a profile of parameters that are used for BLM-based tuning. i will do some analysis of common XDF files to determine common names.

afterwards the user will be presented with a list of these parameters to confirm that they're correct, and offered the option to select alternative fields instead, or to 'fill in the blanks' if something has an uncommon name. the user can also select unit of measure for temperature based fields or whatever.

then the parameters available will automatically be parsed into a rough 'filter list', with parameters such as 'if closed loop active == true' and 'if coolant temperature > 50' to help reject rows with crappy data. the filter list will be user editable, arbitrary parameters can be added, and will be saved on exit.

this should provide fairly easy to use ecm-independant input from any sane datalogging tool, including scan9495, tunercat, tunerpro with nearly any adx file, eehack, whatever else, and given a reasonable log format, an inexperienced user can probably just press 'ok' at this point and get good results, but an advanced user can carry on adding their own filters to get the best data possible.

for output:

maf or speed density will be selectable. one or two bank o2s. integrator data can optionally be used with a tuneable strength parameter. this will not analyze wideband or power enrichment data.

there will be three modes, and i will work on getting the first mode functional right away.

first mode is the 'works-for-everyone' case to simply output a list of trim averages, so a list of corrections that need to be made to the existing table(s), exactly like eehack's analyzer works now.

second 'manual' mode will provide two VE tables with selectable number of rows/columns and intervals, etc. the user will manually mirror the VE table from their XDF, then they can paste the data in, and it'll spit back out a new VE table.

third 'automatic' mode will load the bin file and make the changes itself (within reason). this will be restricted to some very common masks that i'll add myself to ensure that we aren't breaking bin files by accident. the program will also do some fingerprinting to ensure that we're working on the correct mask. i will add new masks on request.

i'm thinking that new tuners will be able to get a new VE or MAF table nailed with a minimum amount of effort or knowledge with this kind of design.

any users? beta testers?

timeframe is probably within the next month or so for a beta.

[htrdbmr]

Count me in, if anyone needs help like that it's me!

[steveo]

Count me in, if anyone needs help like that it's me!

ok, i'll make sure the new beta works with your stuff

- what mask are you running
- can you provide me a sample of an exported CSV log from tunerpro (one that has closed loop activity)
- can you give me the bin and xdf you're playing with too?

[htrdbmr]

ok, i'll make sure the new beta works with your stuff

- what mask are you running
- can you provide me a sample of an exported CSV log from tunerpro (one that has closed loop activity)
- can you give me the bin and xdf you're playing with too?Will do, probably Friday.

[notime2d8]

Count me in too if I can help. I'm running a 7427 TBI MAF setup 0D. But it will be a month before I'm road ready...need new tires.

[Terminal_Crazy]

Hi Steveo.

This sounds a little like i've been trying to write but WAY more detailed.
I used to use TTS Datamaster. Years ago (around 10) i wrote some software to read the PCM data. Originally for the ABS system, then to filter and adjust the maf tables & BLM's.
I think there is a hell of a lot more knowledge around here than there was back then.

Then recently after building the 383 i started looking a better filtering tool to process the data. I only recently managed to start programming again because of this.
You are more than welcome to look at what i've got. It's basically command line type stuff but it does update a copy of the VE tables.
It will read in the CSV file and normalise the headings to a default reference that can be used in the program.
I have a list of matching headings for TTS Datamaster, EEHack, Scan9495, EEHackv2 and EEHack-speedlog, (as you seem to have changed the heading names).
It's a bit hard wired and really needs some form of scripting language that could be processed by the program and rerun.

Other earlier bits of code i cobbled together processed BLM's, Ignition timing, Maf tables, RMS of variation of requested idle speed.

You are welcome to any of it if you want, even just for a laugh.

Mitch
Terminal_Crazy

[steveo]

(as you seem to have changed the heading names).

If you find any mismatches like that, you just edit the definition file and i'll push your changes into the main branch


I'm running a 7427 TBI MAF setup 0D

will work on that too

[steveo]

Then recently after building the 383 i started looking a better filtering tool to process the data. I only recently managed to start programming again because of this.
You are more than welcome to look at what i've got. It's basically command line type stuff but it does update a copy of the VE tables.
It will read in the CSV file and normalise the headings to a default reference that can be used in the program.

yeah that's pretty much the idea. i think an automatic detection routine with a dictionary with manual overrides is key to making it universal but also noobable, i'm thinking a pop up a window with some drop-down boxes would be ideal (it automatically selects its best guess at an entry, but doesn't force you to do anything, and always asks the user if it's a sane choice). i will build a really idiot proof ui for it in qt.

[sturgillbd]

Sounds like an awesome tool. Thank you steveo for all of your contributions to the tuning scene!

[myburb]

I could help with beta. Runs well enough that I haven't made any changes for a year. BBC lightly modded. Running steady open loop with MAT input. 6395/7427 $OE. I data log in closed loop narrow band and then make my tune for open loop based on that data. If you think I could help just let me know.

[dave w]

Sounds like a very interesting tool to tune with. I developed a somewhat similar tool for WBO2 tuning ( http://www.gearhead-efi.com/Fuel-Injection/showthread.php?5381-Wide-Band-O2-(WBO2 ... see pics on post 25) using the average "IF" function in Excel ( https://support.office.com/en-us/article/AVERAGEIF-function-faec8e2e-0dec-4308-af69-f5576d8ac642 ).

dave w

[htrdbmr]

I just completed installing a new motor 383, 10 1/2:1, 225/231 w/.540",114 lobe sep. 36 lb injectors in a Superram[ I've only got 200 miles on it, and the tune is ok, but far from done. I'm using S_aujp v5, attached is preliminary info.1148311484

[steveo]

ui is almost done!

[Xnke]

This would be great to use with the P66 ADX that Robert built-I'd definitely use it! Seeing as he's written the stuff for most of the 60*v6 computers, I'm sure the fields would be close enough to the same to let it work for most of them, too.

[brian617]

I like the sound of this as well. Motivation to order another obd1 cable since mine gave up the ghost last fall sometime.

7427 $OE

[steveo]

This would be great to use with the P66 ADX that Robert built-I'd definitely use it! Seeing as he's written the stuff for most of the 60*v6 computers, I'm sure the fields would be close enough to the same to let it work for most of them, too.

this program will definitely work with any log that has rpm, map, and at least one BLM value in it. it isn't going to use the ADX file in any way (you'll have to export the log as CSV for it to function)

the only caveat is that if you have a stupid or uncommon name for any of those fields in your ADX, you're going to have to manually select the field before it'll let you analyze the log, but that will be really easy to do....

[Stokes1114]

I will def try this out...Im using 16168625, $E6. Count me in! I will change to $0D if needed...$E6 is stock Im working with now

[Danspeed1]

You guys on this site never cease to amaze me. I spent the last six months attempting to learn tuning, though i was a hot shot, only to get on here and get blown away by how knowledgeable everyone is. Incredible stuff... can't wait to see the finished product

[steveo]

progress so far:

- it loads logs (any number of logs) into efficient data structures for analysis
- it removes logs from these data structures without crashing.. this part took a lot of head scratching
- it 'maps' parameter columns, kinda, but not automatically yet. the important part is the column mapping data structures are complete
- the ui properly handles one and two o2 sensor vehicles in a way that doesn't look too crappy, this took a bit of work

i know it's not much, but it's a start.

next i work on the filtering engine including it's automated configuration, and try to build a dictionary system so i can get the parameter automapping off the ground

so here's where i could use some help

need to build lists of common adx column names for my dictionary file

LBLM=Left Blm,Bank 1 BLM,Left LTFT, they ideally are in order of rough likelyhood. not case sensitive

anyone care to browse some ADX files and help me with that? or at the very least, read their own ADX and give me the column names for:

BLM (L/R/SINGLE):
INT (L/R/SINGLE):
RPM:
MAP:
COOLANT TEMP:
MAF:
CLOSED LOOP ENABLE FLAG:
BLM ENABLE FLAG:
CURRENT BLM CELL:
WOT ENABLE FLAG:

[Stokes1114]

progress so far:

- it loads logs (any number of logs) into efficient data structures for analysis
- it removes logs from these data structures without crashing.. this part took a lot of head scratching
- it 'maps' parameter columns, kinda, but not automatically yet. the important part is the column mapping data structures are complete
- the ui properly handles one and two o2 sensor vehicles in a way that doesn't look too crappy, this took a bit of work

i know it's not much, but it's a start.

next i work on the filtering engine including it's automated configuration, and try to build a dictionary system so i can get the parameter automapping off the ground

so here's where i could use some help

need to build lists of common adx column names for my dictionary file

LBLM=Left Blm,Bank 1 BLM,Left LTFT, they ideally are in order of rough likelyhood. not case sensitive

anyone care to browse some ADX files and help me with that? or at the very least, read their own ADX and give me the column names for:

BLM (L/R/SINGLE):
INT (L/R/SINGLE):
RPM:
MAP:
COOLANT TEMP:
MAF:
CLOSED LOOP ENABLE FLAG:
BLM ENABLE FLAG:
CURRENT BLM CELL:
WOT ENABLE FLAG:

I will take a look at my file tonight when I get home and let you know

[steveo]

thank you, the more data the better.

[buddrow]

I may have to give this a whirl, have a friend with an LT1 that is in desperate need of a tune. Keep up the great work Steveo!

Bud

[steveo]

I may have to give this a whirl, have a friend with an LT1 that is in desperate need of a tune. Keep up the great work Steveo!

Bud

for an LT1, this isn't really going to do much that eehack doesn't already do, though

[steveo]

running into a snag with my dictionary thing, i tried to over-optimize it and ran into some kind of hash table maintainance nightmare that i can't seem to debug. i think i'll just rewrite it and give up some speed, i guess nobody minds an extra few hundred milliseconds on the first log load.

[joegreen]

This sounds sweet. Keep up the good work.

[steveo]

progress is slow, moving soon, but i have auto-detection of fields working.

it also seems to detect single and dual bank closed loop configurations.

next i'll do some automatically filled filters. this will be like (pseudocode):

if (coolant temperature field exists) then add filter coolant temp > 80

but where i'm struggling is, how do i know the unit of measure?

i'm pondering a system where i'll run a min/max value tally when the thing is loaded, so at least i can 'guess' if it's farenheit or celcius.

the alternative is to leave it up to the user, but i find that to be not noob-proof enough

[steveo]

... do we want knock event mapping?

i think we do.

ill copy that right out of eehack.

just watch this spiral out of control.

[dave w]

I'm an Excel user. The attached screen shots are from my WBO2 Tuning Spreadsheet. The example posted is the average if formula for 1000 RPM _ 50 Kpa filtering out AE / PE / Open Loop then using the Idle Flag for averaging the AFR's of RPM's greater than 900, RPM's less than 1100 and Kpa's greater than 45 and less than 55 Kpa's. The average if formula processes the data on the sheet named "Insert Datalog". Maybe this type of logic will help with your Narrow Band Tuning? There are similar formulas for Count If, along with Standard Deviation forumlas if desired.

dave w

[steveo]

you have a hell of a spreadsheet setup, dave. i did glance at one of your spreadsheets when i wrote eehack's analyzer routines, it verified that at least real tuners were doing what i assumed would work well. after filtering to determine valid data points, it basically does a cell selection routine then does a gigantic average. you're doing the same stuff, but in implementation you're using formulas, and i'm doing it functionally with operational loops on each row. the result is the same.

i will build my initial versions like that for sure

...but in the end my plan is to have a decaying radius of trim for each data point, kind of like a heat map, so each point will affect a spread of cells in that region instead of just a single cell selection. if tuned correctly this would allow a reasonable amount of interpolation in areas where data isn't present.

think about it from doing hand-tuning without such analysis tools, which we have all done. i want to mimic that effect, so that minimal initial data coverage can result in way more reasonable corrections. if you're making a 30% correction to a particular cell, that means that the adjacent cells are guaranteed (or almost guaranteed) to require at least 15% (or 1/2 of that adjustment) and even that 2 cells away might still require 5% adjustment. whereas if you're making a 5% adjustment to a cell it might be localized.

this might involve mapping all of the data at a much higher resolution, then downscaling it to the target size, which is pretty easy. kind of like painting a picture of your fueling corrections, then pixelating it at whatever resolution your VE or MAF table happens to be.

[steveo]

longer project than anticipated, but i make a bit more progress every day.

i have the filter system working, as well as its interface. it now has a really fast system in place to identify 'boolean' values based on a dictionary, so it can work with on/off fields such as power enrichment, closed loop, errors, whatever else, as long as they use a string that's known by the dictionary.

[steveo]

here's my dictionary so far, still obviously need some help filling it in, so if you want to use this software for your particular application, help!

(the first column is the reference and can't be modified)

read your ADX and help fill in more values



BLM Bank A,Left BLM,LBLM,LTRIM,BLM
BLM Bank B,Right BLM,RBLM,RTRIM
INT Bank A,Left INT,LINT,INT
INT Bank B,Right INT,RINT
BLM Cell,BLMCELL,CELL
RPM,Engine Speed,ENGRPM
MAP,Manifold Absolute Pressure,MAP(KPA)
MAF,MAF,Maf Frequency,AFGS,Airflow g/s,Engine Airflow
Coolant Temp,COOLTMP,Engine Coolant Temperature,Coolant Temp C
Timestamp,Current Timestamp
Closed Loop,Loop Status,Loop
WOT,Power Enrich Active,Power Enrichment,PE,Wide Open Throttle
TRUE,1,closed,close,set,active,true,enabled,enable ,on,ok
FALSE,0,open,unset,inactive,false,disabled,disable ,off,err,error


edit: just to clarify, single bank configurations just use BLM/INT bank A.

[steveo]

here's the ui so far, everything was auto-detected from the log itself, except TPS% which i added just to prove it works ...

[Terminal_Crazy]

Steveo:
List of fields as I've sourced them.
Best read in a non proportionaly spaced font. CSV probably works also.


|
| Heading Translation Table
|
| © TC Software
|
| Author : Mitchell D. Crawford / Terminal Crazy
|
| Purpose : Table of matching heading names by each app as it saves CSV Data
|
| Created on 01.11.2015 20:53
|
| Version 0.01
|
|
|ref DataMaster, EEHack, Scan9495, EEHackv2 EEHack-Speedlog
|================================================= ================================================== ==================================================
|
rec, Rec Num, sequence
|
AC_psi, A/C Press, , A/C pressure (psi), AC Pressure(psi)
AC_temp, A/C Temp, , A/C temp (°F), AC Evaporator Temperature(c)
afgs, AFGS, maf, MAF (gm/sec), MAF Airflow(g/s)
baro, Baro, baro, Baro pressure-kPa, Barometric Pressure(kpa)
ccp_dc, CCP DC, , EVAP(CCP) d/cyc, Charcoal Canister Purge Cycle(%)
temp, Cool Temp, cooltmp, Coolant temp (*F), Coolant Temperature(c)
cyl_id, Cyl ID#, , , Cylinder ID RAW
delta_rpm, , Delta RPM %, RPM variation %, RPM Variation(%)
egr_pos, EGR Actual Pos, , , EGR Position Feedback(counts)
egr_dc, EGR DC, , EGR duty cycle %, EGR Duty Cycle(%)
cell, Fuel Trim Cell, blmcell, BLM cell#, Block Learn Mode Cell
iat, IA Temp, iat, Intake air temp(*F), Intake Air Temperature(c)
iac_min_pos, IAC Min Pos, , Min IAC Position, IAC Keep-alive Position
iac, IAC Pos, iac, IAC Position, Idle Air Controller Position
idle_target, Idle RPM, idletarget, Target idle speed, Idle Target RPM(rpm)
volts, Ign Volts, volts, Ignition volts, ECM Input Voltage(v)
lbpw, Inj BPW Left, lbpw, B1 base inj p/w-ms, Left Injector Pulsewidth
rbpw, Inj BPW Right, rbpw, B2 base inj p/w ms, Right Injector Pulsewidth
knock, Knock Count, kcount, Knock counts, Knock Counts
lo2, Left O2 mV, lo2, Bank1 O2 sensor-v, Left Oxygen Sensor Volts(mv)
lblm, LTerm-LC, lblm, B1 LT fueltrim/BLM, Left Block Learn Trim
rblm, LTerm-RC, rblm, B2 LT fueltrim/BLM, Right Block Learn Trim
map, MAP, map, MAP (kPa), Manifold Absolute Pressure(kpa)
mapV, , , MAP (volts), MAP Sensor Voltage(v)
oil_temp, Oil Temp, , , Corvette Oil Temperature(c)
ro2, Right O2 mV, ro2, Bank2 O2 sensor-v, Right Oxygen Sensor Volts(mv)
rpm, RPM, rpm, Engine RPM, Engine Speed (High Res)(rpm), Engine Speed(rpm)
rpm-16, RPM-16, rpmperiod, Engine RPM filt'd, Low Res RPM(rpm)
runtime, Runtime, , Engine run time -s, Engine Run Time(sec)
advance, Spark Advance, sparkadv, Spark adv degs, Spark Advance(deg)
kr, Spark Retard, kr, Knock retard degs, Knock Retard(deg)
speed, Speed, vss, Speed (MPH), Vehicle Speed(mph)
lint, STerm-LC, lint, B1 ST fueltrim/INT, Left Integrator Counts
rint, STerm-RC, rint, B2 ST fueltrim/INT, Right Integrator Counts
tps, TPS %, tps, TPS %, Throttle Position(%)
tpsV, TPS Volts, , TPS volts, TPS Voltage(v)
|
|
| Wideband is read into PCM on A/C pressure but EEHack converts to a A/F Ratio rater than a pressure value.
wideband_AC, , wideband, , Wideband O2 @ AC Pressure(:1)
wideband_D27, , , , Wideband O2 @ Pin D27(:1)
|
cl_enable, , cl_enable, Eng. closed loop, Closed Loop Enable
pe_enable, , pe_enable, Power enrichment, Power Enrichment Active
blm_enable, , blm_enable, Fuel trim enabled, Block Learn Mode Enable
fan1, , fan1, Fan1/Lo relay, Fan 1 Enabled
fan2, , fan2, Fan2/Hi relay, Fan 2 Enabled
|
|
ccp_enable, , , , Charcoal Canister Purge Enable
AIR_enable, , , A.I.R. pump relay, Air Pump Enabled
AC_enable, , , A/C clutch relay, Air Conditioning Enabled
AC_clutch_status, , , A/C clutch status, AC Clutch Status
AC_request_status, , , A/C Request, AC Request Status
|
|
lo2_ready, , , Left O2 ready, Left O2 Ready
ro2_ready, , , Right O2 ready, Right O2 Ready
|
|
time, Frame Time, , Time of day
timestamp, Time Stamp, timestamp, Total scan time -s
|
|
| DataMaster Entries
, DRP mS
, Inj DC Left
, Inj DC Right
, LTerm-LP
, LTerm-RP
, STerm-LP
, STerm-RP
|
|
| These are in Scan9495 ONLY
, , , Version 2.1.3 Date
, , , Date
, , , Fuel enable (VATS)
, , , MALF43a
, , , MALF43c (open)
, , , MALF43d (short)
, , , Number of DTC's
, , , DTCfail
|
|
| EEHack V2
, , , , TCC Enable
, , , , TCC Brake Switch
, , , , TCC Control Enable
, , , , Left+Right Block Learn Trim
, , , , Left+Right Integrator
, , , , Transmission Selected Gear
, , , , Shift Position PARK/NEUTRAL
, , , , Shift Position L1
, , , , Shift Position D2
, , , , Shift Position D3
, , , , Shift Position D4 (OD)
, , , , PRNDLFLG Bit 4
, , , , Shift Range REVERSE
, , , , Minor Loop Reference Period(msec)
, , , , Heated Windshield Request
, , , , Power Steering Request
, , , , Oil Change Reset Switch
, , , , Oil Level Switch
, , , , Park/Neutral from SDINMW1
, , , , Cruise Control Active
, , , , Input Mode Word 2 Bit1
, , , , Trans Perform Switch Pressed
, , , , Transmission Mode A
, , , , Transmission Mode B
, , , , Transmission Mode C
, , , , Spark Retard Request
, , , ASR active, ASR Active
, , , , Shift Solenoid State A
, , , , Shift Solenoid State B
, , , , Output Mode Word 1 Bit 4
, , , , Output Mode Word 1 Bit 5
, , , , Output Mode Word 1 Bit 6
, , , , Output Mode Word 1 Bit 7
, , , , Output Mode Word 2 Bit 4
, , , , Output Mode Word 2 Bit 5
, , , , Output Mode Word 2 Bit 6
, , , , Output Mode Word 2 Bit 7
, , , , CAT Converter Over Temp
, , , , Engine DTC Error Occurred
, , , , Transmission DTC Error Occurred
, , , Kickdown pattern, Kickdown Pattern
, , , Injector flt this run, Injector Fault Detected
, , , Reset oc'd this run*, Reset Occurred
, , , , Corvette Fuel Enable,
, , , , PRNDLFLG Bit 7
, , , , Raw Shift Position Byte
, , , , AC Pressure Sensor Voltage(v)
, , , , Unused Byte 32
, , , , Post-Cat O2 Voltage (Corvette)(mv)
|
|
| EEHack V2 Extended or hacker patched output
, , , , Power Enrichment Spark Adder(deg)
, , , , MAF Raw Frequency(hz)
, , , , VE Selected Value(%)
, , , , Engine RPM (Low Res)(rpm)
, , , , DFCO Delay Counter
, , , , E-Side Status Word 0x0035
, , , , Burst Knock Active
, , , , Power Enrichment Active
, , , , Overheating
, , , , Base (Main/Ext/Closed) Spark Adv(deg)
, , , , EGR Spark Mod(deg)
, , , , Coolant Temp Spark Mod
, , , , E-Side Status Word 0x0034
, , , , VE Fueling Calculation Active
, , , , High Resolution Signal Failure
, , , , Ignition Off
, , , , E-Side Status Word 0x0001
, , , , Engine is Running
, , , , VATS Test Passed
, , , , SPI Checkum OK
, , , , E-Side Status Word 4
, , , , Power Enrichment AFR Target(:1)
, , , , AFR Target(:1)
|
|
|
|
|

Where have all me spaces gone.
Bloody computers.
CSV is probably best now anyway.

Mitch
Terminal Crazy

[steveo]

thanks man that's a great start!

[steveo]

ok so i've been playing with more advanced forms of analysis algorithms and i'm getting really excited. this entire thing might be optimally represented in a way that opengl will do all the work for me.

[Chewy1576]

Noob question... Where do you go to see the column header info? I'll go through $0E if it would help.

[steveo]

they're the names of the actual parameters in the ADX. they're also in the 'export log' function.

[steveo]

very very early alpha version, please help test the various features and see how it behaves with actual data in it. it doesn't do anything but chart the data yet.

http://fbodytech.com/files/trimalyzer-alpha1.zip

a few notes:

- logs must be CSV (comma seperated) files. in tunerpro, you have to 'export log' to get a csv format log.
- they all have to have identical fields and ordering right now (so exported from the same program)
- for single o2 sensor (single bank) cars, just set BLM bank A.

this version uses an experimental type of analysis. instead of putting data into a 'cell' with 'borders', which would have no interpolation ability whatsoever, we use some geometry.

each data point kinda forms a circle of effect (actually an oval, we scale map and RPM different), and the center of each table cell is an observer. if the observer is located within the range of the data point, it counts towards its average. this should better reflect the reality of trims being an imprecisely located data point, and the usual logic that if one cell is affected, the surrounding cells also require modification or smoothing.

of course these are not literally circles, since checking distance between the two points is cheap mathematically, we can just check the range of radius between points, so the analysis happens very quickly.

i may add a bit of magnitude adjustment vs. distance later which might result in better data, early attempts failed because my math skills are a bit shitty.

let me know how it works so far and i'll keep going

[steveo]

oh and just to be clear, i am not tuning chevs anymore, so i wont be testing this software in real world conditions, i rely on you guys to do that, i'm just doing this as a fun project.

[sturgillbd]

Getting ready to do some datalogging so I will try it in an hour or so. Thank you!!!!!!!!!!!!!!

Brian

[Terminal_Crazy]

Hi
Got annual MOT due shortly. Car has been running really well in OL SD but I've put it back to CL SD for the ticket.
Been out today for half an hour and ran the log through the analyzer.
VE tables came out 97 to 101. I presume this is %age.
Worst blm was 16 at 121/ 127

I was expecting a much richer result just swapping back to narrowband after tuning on the wideband as the wideband appears much more lean whilst cruising.

Nice one Steveo, excellent as ever.
Keep it coming.

Mitch
Terminal_Crazy

[steveo]

yes it's percentage

in default configuration it rejects tps < 1 so it isn't going to help you with idle (aka cell 16) (assuming it found that field, otherwise it wont add the filter for you)

stand by for next version with hugely improved analysis interpolation!

tricky part is, there's so much math now that we have to tune the tuner. there are all these scalars and multipliers to make the analysis behave correctly without adding data to the wrong cells. i think in the end it'll be awesome.

[steveo]

this one is more better:

http://fbodytech.com/files/trimalyzer-0.2a.zip

uses data point distance scaling to feed a weighted average system, with high pass filtering to remove noise and clipping at the top to ensure maximum strength of data points near the target.

also added a UI for the advanced tuning settings, so users can experiment with different parameters to try to figure out how to optimize this thing for me.

it has a checkbox so you can disable the interpolation and try a traditional cell-bounded analysis.

feedback please

edit: fixed that link .....

[steveo]

analyzed a bunch of logs and tuned it a bit more

http://fbodytech.com/files/trimalyzer-0.3a.zip

if you had used that last alpha version, once you install this, use advanced settings -> reset all

also has knock event map

[steveo]

the math in the above version has a flaw. it works alright... but...

will fix it later tonight.

[steveo]

well a week of progress is great so far,

this version fixes the math in previous versions (which was an attempt to demonstrate an idea) with a bit more consistent math that actually works.

i was overcomplicating it.

it kinda ends up making each data point relationship into a vector, the magnitude of that vector defines its weight within the average. it is maturing quite a bit and finally giving good trim maps, making this an awesome linear analyzer that may end up being good at relating tons of different kinds of data to its target tuning cell.

so basically, the closer the data point (your trim vs rpm vs map) is to the target 'observer' point (the dead center of the ve table cell), the more effect it has on that observer. it uses a proper slope calculation with noise filter highpass (meaning data from too far away of cells has zero effect) and clipping at the top (meaning stuff close by is always 100%)

we don't have to worry about a hysteresis or anything near cell boundaries so data near a boundary will affect neighboring cells, since it doesn't care about literal cell boundaries, it just tries to gather surrounding data in a way which makes sense, and each data point can affect any cell 'within its reach' with varying effect.

it also has a visualizer now, so you can see how this interpolator is actually mapping its data points to cells,

11537

i also fixed a one-off bug in the knock analyzer so the points are in the right spot... added a few other small tidbits.

enjoy

http://fbodytech.com/files/trimalyzer-0.3.1a.zip

[dzidaV8]

Seem like a great idea to me! Not only for narrowband, I thing the same algorithm could be used for wideband data. Will make tuning much more precise.

This corresponds perfectly with the idea I've been developing for a while: a standalone datalogger that would plug into ALDL port like small ELM327 adapter and log to .csv file on SD card. You could collect a LOT of data just driving normally without any cables or laptops cluttering the car!

So I'll be glad to test your software as I progress with this datalogger device :)

[sturgillbd]

I tested the software on Saturday and it seems like it will be great. Ill try .3.1a.when the weather breaks. Great work steveo!

[steveo]

Seem like a great idea to me! Not only for narrowband, I thing the same algorithm could be used for wideband data. Will make tuning much more precise.

This corresponds perfectly with the idea I've been developing for a while: a standalone datalogger that would plug into ALDL port like small ELM327 adapter and log to .csv file on SD card. You could collect a LOT of data just driving normally without any cables or laptops cluttering the car!

So I'll be glad to test your software as I progress with this datalogger device :)

i did that with linux and a raspberry pi once.

ncurses interface, cheapo ebay backup camera as a screen (optional).

it worked as soon as you turned the igntion on, added small wifi adaptor and some scripts so it automatically uploaded logs when i parked in my driveway

http://fbodytech.com/misc/raspberry-pi-dashboarddatalogger/

the software is old but you could probably screw around and make it work?

[steveo]

i've decided modifying bins in place is something i'm not going to do

instead the user will:

- use my analyzer to get their data
- copy their entire VE table from tunerpro
- click a button in the analzyer (this will modify the data in the clipboard)
- paste the modified VE table back into tunerpro

checks will be made to ensure the copied data matches the layout of the table in the analyzer, and if failed, it will refuse to modify it.

preset table layouts will be available for common masks (and to assist in cases of multiple VE tables in the same bin, etc)

MAF analysis will work in the same way

sound easy enough?

it'll go ahead and display your modified VE table too, so you know what you'll be pasting.

[Terminal_Crazy]

Evening Steveo.
Some feedback for you on 31a.

I like the VE Analysis display although these now show a range of 101 - 88 with the same data.
That's more of what i was expecting switching from Wideband to narrowband than in the 1st version.
The main bulk of the VE table is about 97 to 93 with a few dips.
Not an issue for me as i'll go back to OLSD after the ticket. The lean surge & knock is back with the narrowband O2's.

What i did wonder about is where you feel the MAP & RPM boundaries occur.
Whilst writing my analyzer I plumped for the row/column value as the MAX for that cell, ie the 20 MAP cell was for upto 20. 20.01 to 25 went in the 25 MAP cell.
I don't know whether it would be better to use the value as the center point for the cell.
THE $EE VE table goes from 20 to 100. Using my stratagy the VE values are plotted as 15 to 100 MAP.
Conversely we could have 20 to 105 if using the lower bound or centered would give 17.5 to 102.5.
The same would go for the RPM's although that has a 7000 column which would be sufficient for the 8051 PCM
I wondered your thoughts and thinking on this.


Also i think the Knock Count Map & VE Interpolation Map screens would be better suited to having their own tab rather than a button at the bottom of the Visual Analysis page.

I also think the Process Logs button should be at the bottom of the main window, after you have scanned down / altered any settings.

What is this written in ? i guess you are using QT again?


Excellent stuff!

Mitch

[steveo]

What is this written in ? i guess you are using QT again?

yup



What i did wonder about is where you feel the MAP & RPM boundaries occur.
Whilst writing my analyzer I plumped for the row/column value as the MAX for that cell, ie the 20 MAP cell was for upto 20. 20.01 to 25 went in the 25 MAP cell.
I don't know whether it would be better to use the value as the center point for the cell.
THE $EE VE table goes from 20 to 100. Using my stratagy the VE values are plotted as 15 to 100 MAP.
Conversely we could have 20 to 105 if using the lower bound or centered would give 17.5 to 102.5.
The same would go for the RPM's although that has a 7000 column which would be sufficient for the 8051 PCM
I wondered your thoughts and thinking on this.

depends how it's labeled, as far as i know generally when you see a 20kpa column (if labeled properly), it's 0-20kpa. the next column labeled 30kpa is actually 20-30kpa. this is kinda ambiguous i know, in eehack i drew my labels right on the cell borders.

im making three modes for ve analysis
strict will put the data in the cell only,
loose will put the data in the cell but with a hystersis-like boundary (so if it's right near a boundary, it affects two cells),
interploation mode uses pure geometric analysis and relates things to the dead center of the cell, with weighted averages and crap.

im thinking early on, people will use interpolation to get the ve table approximated, then 'loose' mode will be good for 'fine grained' adjustments


Also i think the Knock Count Map & VE Interpolation Map screens would be better suited to having their own tab rather than a button at the bottom of the Visual Analysis page.

considering the visualization tab really does the same thing and there's no reason to view both at the same time or flip between them, i think im going to re-use the page at least for now.

same with the fuel mapping. since ve and maf analysis performs similar functions but aren't often used simultaneously, i'll leave them on the same page, it'll let me re-use a lot of controls and code more easily

kinda fits with this being a general purpose tool with different operating modes


I also think the Process Logs button should be at the bottom of the main window, after you have scanned down / altered any settings.

perhaps. i dont even really like the main window layout much. i'll work on that a bit later after the analyzer is working properly

[Terminal_Crazy]

yup


depends how it's labeled, as far as i know generally when you see a 20kpa column (if labeled properly), it's 0-20kpa. the next column labeled 30kpa is actually 20-30kpa. this is kinda ambiguous i know, in eehack i drew my labels right on the cell borders.



That's the way I'd read the tables, just wanted confirmation.
Cheers

Mitch

[dzidaV8]

i did that with linux and a raspberry pi once.

ncurses interface, cheapo ebay backup camera as a screen (optional).

it worked as soon as you turned the igntion on, added small wifi adaptor and some scripts so it automatically uploaded logs when i parked in my driveway

http://fbodytech.com/misc/raspberry-pi-dashboarddatalogger/

the software is old but you could probably screw around and make it work?

Thanks for reminding this project, I think I've already stumbled upon it some time ago on your website.
I'm doing something much simpler and cheaper - ATXmega with USB interface and SD card, so the device would work as standalone datalogger, and when connected to PC as normal ALDL virtual COM interface. The whole thing shouldn't cost more than $25 in parts.
I hate driving with laptop on the seat and cables cluttering the interior, and the PCB will be about the size of ALDL plug itself.

For me the idea is to use it for fine tuning rides - after I have tuned it, people can normally drive with this device, and after some time I have TONS of data to perfect the tune.

Going back to your program, I also think it is best to leave bin modification in TunerPro. It's better to know exactly what is being modified.

[steveo]

I'm doing something much simpler and cheaper - ATXmega with USB interface and SD card, so the device would work as standalone datalogger, and when connected to PC as normal ALDL virtual COM interface. The whole thing shouldn't cost more than $25 in parts.

you should open source your code and make it at least kinda adaptable to different aldl data sets; i'm sure other people would like to build one

[steveo]

i'm making major progress, i'd say the ve analyzer is almost done.

i have all three analysis modes working very well, i have a new method of table size defining with a better ui, a preset system, and i almost have the system working that modifies tables copied to the clipboard, so implimenting the trim modifications should be a few clicks for tunerpro users.

now, i have RPM as a row and MAP as a column.

are there many XDF files that have the oppisite (RPM columns and MAP rows?)

im wondering if i should add that option either by allowing my own table to rotate, or to allow clipboard data to be parsed in an alternate way.

[steveo]

what are the most popular masks? (so i know what presets to make)

[Eds]

what are the most popular masks? (so i know what presets to make)

For me it is $A1 and using the following XDF A1 28March2014.xdf: http://www.gearhead-efi.com/Fuel-Injection/attachment.php?attachmentid=6817&d=1396023537

[sturgillbd]

I use $0D and $61

16197427 and 1228746

[Chewy1576]

I use $0E

[steveo]

awesome that's a good starting point. if any of those masks have MAF capability i'll get them working soon too.

[steveo]

http://fbodytech.com/files/trimalyzer-0.5a.zip

1. do your analysis and configure your table (or choose preset), make sure it looks good, and try the different interpolator methods to see what you like.
2. copy the appropriate ve table data from tunerpro that matches the table region you've configured
3. click 'modify clipboard data'
4. paste your data back into tunerpro

one thing is it only does regular table steps, so for irregular ve tables that are like 20,30,40,50,80,100 it will have to treat that as two tables (one from 20-50,10steps and one from 50-100,20steps) for now. i've reflected that in the presets.

please test! let me know how it works

[sturgillbd]

Will try it this eve after work

[steveo]

i think one thing i did not anticipate in my initial design was that most VE tables have more than one interval on map, rpm, or both.. for example they'll go 20,30,40,50,80,100 or something

so i think i will write in support for arbitrary column definitions and drop my current method of base/n_values/interval

will make it take a bit longer for users to define a simple fixed interval table, but the presets will be perfect this way, and i'm seeing a lot less fixed interval tables than i expected.

problem is this adds complexity, as intervals don't involve any actual lookup, but now i'll have to write a super speedy way to figure out cell borders. i'd like to keep it fast, since right now it's working well with auto-refreshing, so any changes to layout or analysis engine can update almost instantly.. my analysis algorithm is cell iterated rather than data point iterated (it finds the appropriate data point groupings for each cell, not the appropriate cell for each data point), the increased complexity of arbitrary cell border definitions during analysis should only be affected per number of table cells. i think it'll be alright.

[steveo]

almost done! just trying to figure out a system to 'remember' your custom tables, since they're a bit more painstaking to define.

i increased the internal precision of the analyzer and it's yeilding more uniform data now too.

[Eds]

As a noob, I'm impressed with your work and the analyzer is progressing nicely. The current version is a little cumbersome setting up tables to analyze but you know that and are addressing it. Actually though, I personally don't find that as an issue. It forces me to pay particular attention to areas that need it.

I'm interested in your opinion on how you would address situations where there are more than 1 table that covers the same area within the tune. An example would be, main VE and idle VE tables that use similar rpm and map. I do realize the code addresses which table applies at any given moment. It seems to me though tables with greatly different values could effect the transition from one to the other.

[steveo]

It seems to me though tables with greatly different values could effect the transition from one to the other.

since default interpolation method uses distance to cell centerpoint as its metric for whether to include the data point, or not, it checks values way out of range to see if they're relavent, it isnt' going to naturally exclude your 1800 rpm data just because the table starts at 2000rpm, but data at 1800rpm will have very little influence compared to 2100rpm data. in fact the default method throws out the cell border completely, and just judges distances. so ideally, the transition should be fairly seamless. this has yet to be proven, but i've loaded a lot of test cases and flipped between high/low tables and checked 'em out.

you can do idle VE analysis too! you just have to define the filters yourself. you could filter TPS% < 1 and vehicle speed < 1 or something like that, and away you go.

in the new version, tables are also cumbersome to define, but 100% flexible, you will be able to save your layouts as USER1, USER2, etc, and give them a notation so you remember what it is.

[steveo]

another one,

- improved algorithm even more
- fully editable tables with custom presets that can be added/saved/deleted
- supports both types of ve table axis (rpm=col and rpm=row)
- supports logs with both 128-based trims as well as 100%=ideal and 0%=ideal (you have to manually select that, it's not auto-detected)

http://fbodytech.com/files/trimalyzer-0.1b.zip

[maxpowerta]

I've been trying to get this to work but after i process the log and go to the table analysis all the cells are blank11546 11548 11549
I've attached my log file, am i just setting this up wrong or does it not work with $8D? the log is from SAUJP v4 and was logged using ALDL droid.
thanks.

[steveo]

it should be working, your configuration looks ok, there's something about this log format that it doesn't like, though. i'll look into it.

[Eds]

Steve, On the new version of analyzer, I see a minor error. On the analysis page, table analysis window, Table layout, option reads "$EE : Upper VE Table (2000-2000RPM)". I believe based on your earlier versions of the analyzer it should read (2000 - 4000RPM).

[steveo]

Steve, On the new version of analyzer, I see a minor error. On the analysis page, table analysis window, Table layout, option reads "$EE : Upper VE Table (2000-2000RPM)". I believe based on your earlier versions of the analyzer it should read (2000 - 4000RPM).

thanks, fixed that (actually should be 2000-7000)

[steveo]

I've been trying to get this to work but after i process the log and go to the table analysis all the cells are blank

according to my parser, the header shows that there should be 268 columns of data, but there are 231, a clear format violation

this seems to be due to your datalogging software adding colums of non-adx defined stuff like azimuth and accelerometer data, but not actually putting any actual data there?

i could default to zero-fill the tail end of those rows, but i'd rather see your software fix itself, since i think a good csv parser should reject a line with a mismatched number of columns.

is there an option in 'aldldroid' to remove those things?

i also note an extraneous comma at the end of each line, which is probably another glitch in your datalogger... not that it bugs my parser very much, but it shouldn't be there

[steveo]

i've added a compile-time workaround for the aldldroid format bugs. i will remove it when aldldroid generates nicer csv files.

http://fbodytech.com/files/trimalyzer-0.2b.zip

also in the case of maxpowerta's log, there is a 'closed loop' column that is detected, and a filter generated, but is entirely empty, so you have to fix or remove that filter.

[maxpowerta]

i've added a compile-time workaround for the aldldroid format bugs. i will remove it when aldldroid generates nicer csv files.

http://fbodytech.com/files/trimalyzer-0.2b.zip

also in the case of maxpowerta's log, there is a 'closed loop' column that is detected, and a filter generated, but is entirely empty, so you have to fix or remove that filter.

Wow that was quick! thanks very much that did the trick. Also there is a flag for android sensors datalog which i had set, ive now turned it off and ill try a new log.

[steveo]

this did make me realize i need to display better errors. rejecting the entire log was way too sliently done. actually im more happy it didnt crash.

[Eds]

With the Trimalyzer 0.1b or 0.2b I am having an issue trying to analyze a VE table. Initial error is rows or columns do not match. The edit tab on Analysis page is not highlighted. New tab is highlighted. When I click New, the Table Editor does not allow me to enter multiple map and rpm values to create table with an area to match the section of the VE table I want to evaluate. Could you explain how to use these features?

[steveo]

With the Trimalyzer 0.1b or 0.2b I am having an issue trying to analyze a VE table. Initial error is rows or columns do not match. The edit tab on Analysis page is not highlighted

please give me the log and a screenshot so i can see what's going wrong

edit: i think i've deciphered what you're trying to say here. you can't edi' the built in table presets. you need to create a new one.

not sure where the trouble is here, just enter the column and row values as they're displayed in your tuning software?

again please screenshot what's wrong. if your table values wont work, it'll tell you why, and grey out the 'save' button.

11550

[steveo]

source code released on github: https://github.com/resfilter/trimalyzer

[Eds]

If I make entries into the table editor as you did in Ed's Layout it is fine. I want to edit or create an area of the table to evaluate. Say for example: map 25 - 40 and rpm's 2000 - 2800.

11551

[steveo]

please demonstrate why it isn't working for you

but imo you're trying to do something that shouldn't need to be done, my program analyzes the whole data set, why would you only want a small portion?

edit: in the background of your screenshot i see your attempt to make a nonesnse table. i am glad that my software wouldn't let you make it.

[steveo]

tutorial: http://fbodytech.com/trimalyzer/trimalyzer-how-to/

[steveo]

bump for more beta testers! so far it's working pretty well, i tried it on a friend's tpi car that trims were out to lunch (didnt have time to reprogram with the changes, but the analysis looked sane..)

if you can't test it for me, at least throw me some CSV logs from your own driving and let me parse them so i can ensure it's working with maximum number of environments.

if you make a custom table that works properly, please screenshot (and tell me what mask it's for) it so i can add it to presets too

[Chewy1576]

Here is a screenshot for my headers and filters with $0E. I would attach the log I'm using but it's forced open loop for WBO2 tuning. The $0D table you already have configured works for $0E also. I'm going to be swapping the intake, throttle body, and injectors soon so I would be starting all over anyway.

11556

[Stokes1114]

11557

Ive only ran 2 logs through it so far, but seems to be giving very uniform results. I am using $E6 for 16168625.. the screenshot is for the off idle VE table. Its the same setup as the $0D mask. I could load old datalogs csv if you would like to try for yourself. Ill do some more logs and post results tomorrow evening.

[steveo]

Ive only ran 2 logs through it so far, but seems to be giving very uniform results. I am using $E6 for 16168625.. the screenshot is for the off idle VE table. Its the same setup as the $0D mask. I could load old datalogs csv if you would like to try for yourself. Ill do some more logs and post results tomorrow evening.

cool! those are some huge trims, can you send me that log? that might be a good test case to see if my algorithm is tuned properly..

[dud]

Love the program. Using the "Loose Cell" setting, it pretty closely matches what my spreadsheets come up with. What I like the most is that it is quicker than excel when loading several datalogs. And I don't need a separate tool for ALDLdroid and TunerPro.

Thanks for the source too. I use linux for pretty much everything I do and I have been able to compile the program on linux and it works great. Just have a bug when trying to copy contents of the clipboard into TunerPro(running on wine). I think it has to do with the way X11 (linux) sees the clipboard. Not a biggie though. I can use a native linux text editor to do the hand off. The clipboard works fine if I'm running both programs, Trimalyzer & TunerPro, with wine.

I'm no programmer by any means, but I have edited the dictionary to include some extra terms so the "Field Mappings" will be auto detected. I also edited the "definition" files trying to get more filters to be auto detected. No joy on that one though.

I too am using the $E6 mask.

I've attached some screenshots of the way I set it up.

[dud]

Here are some datalogs from TunerPro and ALDLDroid.

[steveo]

Love the program. Using the "Loose Cell" setting, it pretty closely matches what my spreadsheets come up with. What I like the most is that it is quicker than excel when loading several datalogs. And I don't need a separate tool for ALDLdroid and TunerPro.

Thanks for the source too. I use linux for pretty much everything I do and I have been able to compile the program on linux and it works great. Just have a bug when trying to copy contents of the clipboard into TunerPro(running on wine). I think it has to do with the way X11 (linux) sees the clipboard. Not a biggie though. I can use a native linux text editor to do the hand off. The clipboard works fine if I'm running both programs, Trimalyzer & TunerPro, with wine.

I'm no programmer by any means, but I have edited the dictionary to include some extra terms so the "Field Mappings" will be auto detected. I also edited the "definition" files trying to get more filters to be auto detected. No joy on that one though.

I too am using the $E6 mask.

I've attached some screenshots of the way I set it up.

great progress

i can teach you to add default filter detection with new fields etc, but later versions will save your filters for you, so i doubt i'd even bother.

can you please give me details of what you've added to the dictionary so i can merge your improvements? definitely the dictionary needs improvement.

one way to help fix the 'wine bug' thing would be to paste the contents into windows notepad or something windowsy running in wine and see what it spits out when trying to directly convert. 'spreadsheet table-like' data is just tabs between fields and linefeeds between lines. i betcha it's the linefeed char that is screwing us over, since windows and unix have different line terminators and QT is likely trying to be smart and convert where it isn't necessary. we may be able to work around that conversion issue somehow by dealing with both types of linefeeds manually.

[dud]

I included a copy of the modified dictionary file in the previous attachment.

Looking forward to the upcoming features. So glad we have talented people like you willing to share.

[steveo]

I included a copy of the modified dictionary file in the previous attachment.

Looking forward to the upcoming features. So glad we have talented people like you willing to share.

oh alrighty i'll have a look

this is kind of a side project to another similar program i'm writing for work. it also parses huge amounts of csv data into usable structures and does analysis on it, so i can share a bunch of functions and ideas, kill two birds with one stone. otherwise i might not be writing it.

[steveo]

fyi to define your parameter,

1. add a new unique value to definition.h's STDMAP_* enumeration, while leaving STDMAP_N_VALUES at the end. this gives us a numerical value instead of a lookup. the 'dictionary' uses this.



enum {
STDMAP_LBLM = 1,
STDMAP_RBLM,
STDMAP_LINT,
...
STDMAP_TPS,
STDMAP_FOO,
STDMAP_N_VALUES
};

2. add a new case to defintion::name_of_parameter. this translates the above enumeration to a string used both in the user interface (so the user knows what they're trying to match up to), and the dictionary.txt file.



case STDMAP_KNOCKCOUNT:
return QString("Knock Counter");
break;
case STDMAP_TPS:
return QString("TPS%");
break;
case STDMAP_FOO:
return QString("Foo");
break;


3. add a line starting with Foo to dictionary.txt (you need to redefine Foo here as well, since the first field doesn't actually count for a lookup value), these are not case sensitive:


Foo,FOO,bar,etc,other definitions,blahblahblah

4. add a definition to automatic filter detection function in mainwindow.cpp (MainWindow::populate_filters()), see data_filter.h for possible filter operations.


add_filter(definition::STDMAP_FOO,data_filter::GRE ATERTHAN,1.2345);

[steveo]

0.3 beta:

- start new changelog
- add support for external dictionary.txt file
- general code cleanup and bug fixes
- save/recall filter option added

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

[dud]

Excellent. The "Remember" feature works great.

Believe it or not I actually had the "definition" and "dictionary" files edited as you described. The "mainwindow" file is what I was missing. Edited it and it worked.

I still feel kinda like a cow trying to read the newspaper when looking at this stuff though. :-)

I'll try compile it in linux later. Gotta get ready to go to work now.

[steveo]

the only ui hitch is that when you remember something, it no longer uses filter autodetection on startup. you have to click the auto button if you want that to happen, and there's no 'clear' function.

just fyi i saw you added some true/false identifiers to your dictionary to deal with alternate cases

that should not be necessary as the dictionary is generally case insensitive (i convert both dictionary and search entries to uppercase)

.. unless you've observed differently, i haven't actually tested it much


Believe it or not I actually had the "definition" and "dictionary" files edited as you described. The "mainwindow" file is what I was missing. Edited it and it worked.

easy misunderstanding due to my weirdo use of classes. mainwindow.c handles the propogation/creation/deletion of the list of filters, the filter class itself is simply a ui element that contains isolated data about the filter and a front end to edit it (mainwindow contains multiple filters, but filters have no knowledge of each other whatsoever), and to further confuse matters, the list of filters is actually contained in the analysis class, since mainwindow doesn't use the filters, only manages them.

i do hate object oriented programming, so i think i subconsciously make bad design decisions on purpose.

[Stokes1114]

cool! those are some huge trims, can you send me that log? that might be a good test case to see if my algorithm is tuned properly..

Here is the csv log file that I ran through. This was the first change from the stock bin. Please let me know if it looks to be doing right. Before this one tune I would run rich all the time, 105-120..now Im seeing some in the low to mid 130's at highway steady speeds. Im going to keep running logs through. Great tool, and thanks for making this for everyone!

[steveo]

your results look good. i also see about the same data but a bit broader from my own analysis routine to the 'loose cell' routine which is a good sign. it would definitely be good to know if it ends up making your trim table work properly if you keep running it


Here is the csv log file that I ran through. This was the first change from the stock bin. Please let me know if it looks to be doing right. Before this one tune I would run rich all the time, 105-120..now Im seeing some in the low to mid 130's at highway steady speeds. Im going to keep running logs through. Great tool, and thanks for making this for everyone!

[steveo]

new version, biggest new thing is that when you select a custom mapping, it remembers and priorities it over auto-detection.

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

0.4b BETA:
- support dark ui (see advanced settings)
- auto-detect filters on startup again (must manually press recall)
- remember the last mapping selected and prioritize it over the dictionary

[maxpowerta]

First i'd like to say thanks for making this tool, it is immensely helpfull and saves me from cutting and pasting to and from spreadsheets. I do most of my tuning and prom burning on an old xp laptop and when i tried to run this on that machine i get the attached error. Any idea what i can do to fix it?11574

[Stokes1114]

11576Here is my log file from my drive home, and a pic of the results. This program is so nice..So much faster than using spreadsheets. For me at least, since Im no pro at excel. Could you explain how the colors relate to the severity?

[steveo]

glad you like it!!


Could you explain how the colors relate to the severity?

blue ideal, red rich, green lean. i based the color scheme on datamaster (since many people are accustomed to them)

now, i wouldn't go ahead and insist on what's 'ideal' and 'rich' and 'lean', so in the advanced settings, you're free to change TUNE_VISUAL_LEAN_TRIM and TUNE_VISUAL_RICH_TRIM to suit your tastes. it is percentage trim based. defaults are > 103%+ lean and < 97% rich.


I do most of my tuning and prom burning on an old xp laptop and when i tried to run this on that machine i get the attached error. Any idea what i can do to fix it?

unfortunately i write my software using libraries that are incompatible with windows XP, so it wont work. i also have an xp tuning netbook, so i feel your pain, but the advantages of using modern versions of QT are just too great for me. sorry

[steveo]

new version:

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

0.5b BETA:
- redefine ui, now a single window with context switching
- a few other misc ui changes
- add per-filter statistics printout on analysis
- fix 'about' screen

[dud]

Lovin the polish. The clean output in the parser log is a very nice touch.

[troutdog311]

I'd love to test this out even though I got my WB installed and has help tremendously. I'm still learning and love to dial in my VE a little more easily. The only problem is I run in SD OL mode. I still get NB/WB o2 feedback but don't get BLM/INT due to OL as you know. Looks like a great program though!

[steveo]

if ya have wideband output in your csv file, use 100% mode and use the wideband value in place of the trim value, it'll do it

[myburb]

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.

[htrdbmr]

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.

[steveo]

I just ran an old log with your analyzer, and I made it work the first time.

that's a win for sure. thanks for trying it out

[steveo]

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/

[spfautsch]

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!


being able to define arbitrary filters makes this super useful too.

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.

[dave w]

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

[dud]

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℅

[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

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

[steveo]

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℅

to be clear there's no real setting for this. i ask for input format, but always output a whole percentage (100% = good, 90% = remove 10% fuel, 110% = add 10% fuel).

i am starting to think +10% or -10% would be more readable

[dud]

to be clear there's no real setting for this. i ask for input format, but always output a whole percentage (100% = good, 90% = remove 10% fuel, 110% = add 10% fuel).

i am starting to think +10% or -10% would be more readable

Sorry to cause confusion. I was away from the computer and forgot that's how it worked. The numbers threw me the first time I used the program too until I realized the output was actually percentages.

[steveo]

new version posted that solves above display ambiguity issue, allows different trim display calculation to suit different users (defaults to +/- which can't be misinterpreted)

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

[dud]

Excellent!

[dave w]

i am starting to think +10% or -10% would be more readable That would similar to how I use EFI Live fuel trims, which range from +25% to -25%. dave w

[steveo]

That would similar to how I use EFI Live fuel trims, which range from +25% to -25%. dave w

well now everyone has their preferred method available

coming next: maf analysis

[steveo]

maf analysis is done (doesn't do the clipboard table editing thing yet, though)

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

[maxpowerta]

I have a question concerning filters, It appears my ALDLdroid csv files have some weird formatting errors for certain parameters. For instance the "error 44" column seems to indicate the power enrichment state, and "error 45" appears to be AE MAP, and the "O2 sensor rich" column seems to be AE TPS. If i wanted to filter out all the data where "power enrichment" is active I would think I should select "error 44" for the filter but when PE is active it shows "Power" in the .csv file so what do i set the filter operation as? should it be true, false or something else? the log file is attached. Thanks for the great work on this tool it is a great help!

[steveo]

aldldroid needs to fix its csv format. as a paying user you should really request a review of that kind of behavior

[steveo]

here is the dictionary file, you can see all the viable true/false values allowed.

you can edit your adx file that aldldroid uses to change the value. or you can copy the dictionary.txt to the same directory that your trimalyzer.exe is, and edit it carefully to add 'power' or whatever to the true line.

be careful editing it, it has to be perfect, it's not really checked for errors so it will probably just crash if you add anything odd.

https://github.com/resfilter/trimalyzer/blob/master/dictionary.txt

[maxpowerta]

Perfect! that did the trick, thanks. One observation I've made and I'm not sure if you intended it to be this way or not but, Every time you press "redefine input" and then go back and reprocess the log. The parser log does not reset, under "filtering" it just keeps counting up. This caused me some confusion when i noticed the # of discarded records exceeded the total number in the log.11586

[steveo]

ah, thats a bug. i'll fix that.

[dud]

Here are some pictures comparing Tirmalyzer with my spreadsheet using the same filters.

EDIT: This is with an ALDLDroid log using $E6 mask. Added the log I used.

[steveo]

thanks very much for that detail. the data looks pretty decent

does your spreadsheet use integrator data? to make the comparison for error checking you might have to disable it. the new version will have a toggle for it. otherwise looks pretty good.

also feel free to play with the hystersis values in advanced settings to tune "loose cell" mode

[steveo]

oh and the wb data is likely quite different due to the 'minimum records' setting in advanced

it writes off a cell as junk based on trim behavior so might have to lower it when analyzing small wideband data sets

[steveo]

0.9 BETA:
- some code cleanup and general optimization
- ammended dictionary
- fixed bug where filter statistics were not reset
- ignore integrator in arbitrary input mode
- add option to more easily ignore integrator
- add option to use leanest trim in dual bank configs

.... you should know where to get it by now

[dud]

thanks very much for that detail. the data looks pretty decent

does your spreadsheet use integrator data? to make the comparison for error checking you might have to disable it. the new version will have a toggle for it. otherwise looks pretty good.

No my spreadsheet doesn't use Integrator data. I hadn't thought about the integrator. I ran the log again with the integrator disabled and got the exact same numbers in all three modes as if the integrator was enabled. Another bug maybe?

I'm still impressed with the data. The data presented is after using Trimalyzer to tune my ve's with the "Geometric" method. I also used it to adjust my PE AFR (WBO2), and the output on the dash gauge is more in line with your tool than my spreadsheet. Go figure. :thumbsup:

[steveo]

my tool uses the integrator data but not in its entirety, it just skews the blm value with it slightly to get pre-learning and inter-blm-cell type data. this is done with a reduction multiplier, it's in advanced settings. TUNE_INTEGRATOR_REDUCTION. by default 38%

[Stokes1114]

Heres my results from my log done today. Im now on my 5th run through your program. Started out extremely rich and now its definitely not as bad. Does it look as though its leaning too much?11597

[steveo]

well it's definitely not rich now, that's a bit too lean for my liking though, might have gone too far.

[Stokes1114]

Ran it through with a new log and seemed to help a bit..Overall worked perfectly to get the table very close and quick. I think i just need to fine tune now. Was it loose or strict that would be more helpful in that case?11601

[steveo]

yeah it's definitely pretty good! remember that 132 is only a 3% fueling error, which is really nothing, it's just running at nearly 15:1 instead of 14.7:1, and that's just until your trims take effect. totally safe unless under really heavy load.

loose should be ideal even for fine tuning. by 'loose' it just means that samples close to the border are averaged into both cells. it's not spreading the data around very much. you can tighten the boundaries on map and rpm hysteresis (go a bit lower). i think there's no reason to use 'strict', rather just see you tune 'loose' until it behaves for you...

i wonder if at this point not using the integrator might help it get closer too. some configurations have a stable integrator and some don't.

edit: since obviously the shape of the table is pretty good, maybe just *0.98 the whole table in tunerpro and see where that gets you.

[Terminal_Crazy]

yeah it's definitely pretty good! remember that 132 is only a 3% fueling error, which is really nothing, it's just running at nearly 15:1 instead of 14.7:1, and that's just until your trims take effect. totally safe unless under really heavy load.

loose should be ideal even for fine tuning. by 'loose' it just means that samples close to the border are averaged into both cells. it's not spreading the data around very much. you can tighten the boundaries on map and rpm hysteresis (go a bit lower). i think there's no reason to use 'strict', rather just see you tune 'loose' until it behaves for you...

i wonder if at this point not using the integrator might help it get closer too. some configurations have a stable integrator and some don't.

edit: since obviously the shape of the table is pretty good, maybe just *0.98 the whole table in tunerpro and see where that gets you.

Steveo: Would it be better to have a configurable target value so you can calc the results to target 125 say rather than 128 ?

Thanks
Mitch

[Stokes1114]

yeah it's definitely pretty good! remember that 132 is only a 3% fueling error, which is really nothing, it's just running at nearly 15:1 instead of 14.7:1, and that's just until your trims take effect. totally safe unless under really heavy load.

loose should be ideal even for fine tuning. by 'loose' it just means that samples close to the border are averaged into both cells. it's not spreading the data around very much. you can tighten the boundaries on map and rpm hysteresis (go a bit lower). i think there's no reason to use 'strict', rather just see you tune 'loose' until it behaves for you...

i wonder if at this point not using the integrator might help it get closer too. some configurations have a stable integrator and some don't.

edit: since obviously the shape of the table is pretty good, maybe just *0.98 the whole table in tunerpro and see where that gets you.

Thanks for the tips Steveo! Im pretty new to tuning, but looks like I started at the perfect time.. I will give the no Int a shot first with another datalog and see how it does.. Will also compare it to just the TP *.98. Ill update tomorrow evening after.

[steveo]

Steveo: Would it be better to have a configurable target value so you can calc the results to target 125 say rather than 128 ?

Thanks
Mitch

i'll have to think about the implications of that. not sure if it's a good idea or not. it might be a really good idea.

[steveo]

Thanks for the tips Steveo! Im pretty new to tuning, but looks like I started at the perfect time.. I will give the no Int a shot first with another datalog and see how it does.. Will also compare it to just the TP *.98. Ill update tomorrow evening after.

that's cool, can you post a copy of the original bin, and the one that you last posted? i want to diff the tables and see how the shaping worked after 5 passes of my geometric interpreter thinger.

[steveo]

i found a bug that was preventing the integrator values from being used a lot of the time. explains why int and non-int values are so close. will fix it soon.

[steveo]

i'll have to think about the implications of that. not sure if it's a good idea or not. it might be a really good idea.

this is throwing me for a loop, but i think it's a very good (and all too easy) idea to have a control for target. thanks for the idea!

implementation-wise, all i really have to do is minus or plus the resulting value in the table, right? if we're at -2% and the target is -2%, +2%=0%=no modification required. or if using raw trims, if the trim is 124 and the target is 126, +2=126 trim. super easy to skew the table like that.

i think it would work well as long as you don't really change your target. you could probably get decent results targeting -2% or something (~125 in raw blm terms) especially as a new tuner, as everyone knows a hair richer is better than a hair leaner.

[steveo]

try the new version....

RESET YOUR ADVANCED SETTINGS WHEN INSTALLING THIS VERSION

the integrator strength needed to be nerfed a bit, i lowered the default to 25%

also new version lets you specify an arbitrary trim target in real-time

[steveo]

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

[Stokes1114]

that's cool, can you post a copy of the original bin, and the one that you last posted? i want to diff the tables and see how the shaping worked after 5 passes of my geometric interpreter thinger.

Here is a copy of my stock bin and the latest bin that Im running, after the 6th pass through as of last night. I did another log today and Im getting ready to run the log through. Will post results soon

[Stokes1114]

11606
Heres my log from today and pics of the results in loose mode, one using Int and the other not.
The ability to change the target is awesome..Def gonna have to play with that a bit!

[steveo]

you should definitely hand-shape some of your ve table. you have a few spikes creeping up there.

i can see where trimalyzer's data has defined a new curve where you've actually driven, but you still have massive spikes where it meets areas that have no decent analysis data. you might not notice till you go haulin' a load up a hill or something.

a perfect example of where a hand-made approach is needed to supplement any tool

yours (not good)

11609

mine (kinda good)

11610

[Stokes1114]

1161111612
Did some hand smoothing and did a log.. Ran the log through Trimalyzer. I can see how it really doesnt take much to make the table start going rich/lean.

[steveo]

that's for sure!

BUT

do you notice how uniform your trims are now? they're all mostly 118-120. it means you got the shape of the table right, but the overall needs a slight tweak.

[Stokes1114]

that's for sure!

BUT

do you notice how uniform your trims are now? they're all mostly 118-120. it means you got the shape of the table right, but the overall needs a slight tweak.

Ya definitely helped the shape. I hand tuned and ran another log through. The trims are looking great as of now. A couple tiny spots to still adjust but overall very nice. Heres the results11614

[steveo]

there ya go, leave it there for sure!

[steveo]

1.1 BETA:
- display busy cursor more often when the interface is locked up
- add maximum and minimum trim specifications
- don't lose analyzer method setting when switching between similar layouts
- enforce appropriate range in advanced settings
- error checking on dictionary
- remember last used directory when loading log files
- allow drag and drop of logs onto main window

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

[dzidaV8]

So, I've made some tuning over the weekend, and logged data using EEhack. After that I tried your tool but got stuck with EEhack datalog format. Is there a way to export eehack log files to .csv format?
I'm not using Tuner Pro for $EE logging as I was never able to get stable data with it.

[steveo]

from my tutorial...


You will need to export all of the logs as CSV format.

Why? Because… Trimalyzer doesn’t use definition files, and doesn’t actually care what kind of car you have, or what datalogger you use. Universal is good.

Most dataloggers allow CSV export.

In EEHack, Datalog > *Main > Export CSV.

[steveo]

from screenshot...

11635

[dzidaV8]

Thanks, I don't know how did I miss that... It's always hardest to find things that are right in front of you ;)

[steveo]

Thanks, I don't know how did I miss that... It's always hardest to find things that are right in front of you ;)

there's a lot of stuff in eehack.

all i could do is design it kinda logically so most people can find most things.

above example proves that even when i write a manual (http://fbodytech.com/trimalyzer/trimalyzer-how-to/) for something, people don't always know the manual is there, or still miss it just as easily

[dzidaV8]

Yeah, now I feel stupid... The fact is that you documented it well, I was just too lazy to look for it and asked straight away.

But, back to the topic, now I'll try to mess around with it and I'll let you know how it turns out.

[steveo]

Yeah, now I feel stupid... The fact is that you documented it well, I was just too lazy to look for it and asked straight away.

But, back to the topic, now I'll try to mess around with it and I'll let you know how it turns out.

that's ok, you are average example user.

if you didn't find it, i need to throw some more links up to it, or maybe a button in eehack that says 'export for trimalyzer' or something. i have that ability.

things are obvious to me because i wrote the shit, how am i supposed to know if it's easy for other people to find?

so your inability to find it yourself is honestly a big help.

[dzidaV8]

One more thought, as for now this software is for NB tuning. Most of my logs are from driving with WB O2, so the BLMs and INT values are of course useless. My thought is that it would be more universal to add a function to compare two values to calculate an error, e.g. Desired AFR - Measured AFR = Fueling error with adjustable factoring, and then to use that calculated trim value as BLM trim map adjustments. What do you think?

[steveo]

One more thought, as for now this software is for NB tuning. Most of my logs are from driving with WB O2, so the BLMs and INT values are of course useless. My thought is that it would be more universal to add a function to compare two values to calculate an error, e.g. Desired AFR - Measured AFR = Fueling error with adjustable factoring, and then to use that calculated trim value as BLM trim map adjustments. What do you think?

it already supports wideband or arbitrary input, but as far as calculating difference to target AFR and auto-populating your VE table like it already does for narrowband data, i doubt i'll do that. i never really intended this for wideband tuning anyway.

although i think if you use wideband value as 'trim' and leave it in 'percentage' mode, then set your target 'percentage' to a fixed afr 'target' it should calculate the fueling error against a fixed target for you, so if you wanted to tune to a fixed open loop value, i think it'll work. (untested)

[Stokes1114]

Just out of curiosity, what else are you doing with the program, or what is keeping it in beta? I could possibly try some more masks or maybe another pcm if it would help at all. Least I could do since it got my fuel table in check so quick, and for the extra help. I may switch over to $OD and try from another bin

[steveo]

Just out of curiosity, what else are you doing with the program, or what is keeping it in beta?

nothing, in particular. like all good software i think it should stay in beta until it has a few more users that have done real-world application testing. in other words, waiting for people to fault it or break it or recommend different advanced settings so it behaves better.

i'd kinda like it to tune maf tables in the clipboard as well, but it's a side goal (and there are two distinct types of maf calibration and i'd have to do both of them).

[dud]

One more thought, as for now this software is for NB tuning. Most of my logs are from driving with WB O2, so the BLMs and INT values are of course useless. My thought is that it would be more universal to add a function to compare two values to calculate an error, e.g. Desired AFR - Measured AFR = Fueling error with adjustable factoring, and then to use that calculated trim value as BLM trim map adjustments. What do you think?

I changed line 73 in analyzer_calc.cp from "return trim_in / 100;" to "return trim_in / 14.7;" and compiled the program and it seems to work very well as long as I use "Percentage" mode. Also have to set "BLM Bank A" to your WBO2 and disable the integrator. The WBO2 numbers and narrow band numbers work out to the same error from 14.7 and 128 respectively. Now I have clipboard function with WBO2.

Please correct me if I'm wrong steveo.

Here is a screen shot for comparison.

[Chewy1576]

Here's a log I took this morning. I'll make adjustments and burn a new chip when I get home tonight.

11663

[Stokes1114]

Have decided to try the $OD MAF code.. Have all the parts to convert over and should have it all ready and installed within the week. I will be using the program to get the maf table in check. I will post my results as soon as I start. Thanks Steveo

[maxpowerta]

Hi, could you define how the dictionary file works? I'm trying to filter out all instances of say acceleration enrichment or power enrichment. So in my case acceleration enrichment is defined by AE MAP, AE TPS. now of course because of ALDLdroid issues these are listed in columns that make no sense (error 45 and o2 sensor rich) so how do I go about setting up the dictionary file/filters to remove these records from the correction? here is a log example to show what i mean.

[steveo]

the dictionary has nothing to do with it, its only for autodetection. set up your own filters, its pretty easy...

[BlackZR1]

This looks like a great tool but I must be doing something wrong - my output does not look right.
The Geometric view shows all “nan”.
If I use method: strict or loose some cells contain values. Empty cells say “nan” and there is no color coding.
I am using csv exported from TunerPro. I tried the csv file that Stokes1114 attached in post #147 and got the same result. I tried it on 2 different Windows 10 machines with the same result.
Thoughts?

Thanks,
Roger

[Eds]

At the lower left of the page that displays the table, note the display box. Click the drop down arrow and pick 0-255 (128=good). You will probably want to modify the display to match your VE table.

[BlackZR1]

At the lower left of the page that displays the table, note the display box. Click the drop down arrow and pick 0-255 (128=good). You will probably want to modify the display to match your VE table.

Thanks for the reply Eds. I tried what you recommended but Geometric method still does not work and the Visual Analysis tab is blank as it was before. Empty cells read "nan" and no color coding.

Roger

[steveo]

please post the csv log you are analyzing and a screenshot of the main page, and ill figure out whats going on here.

i assume you didnt touch any advanced settings? i have to ask

[BlackZR1]

Thanks Steve. My csv and screenshot of first page is attached in post 168. I also tried Stokes1114 csv he attached in post #147 with same result.
No i didn't touch advanced settings.

[steveo]

Thanks Steve. My csv and screenshot of first page is attached in post 168. I also tried Stokes1114 csv he attached in post #147 with same result.
No i didn't touch advanced settings.

it definitely works fine for me, i'm not really sure what's going on here.

i honestly haven't tried it in windows 10, but i assume others have.

i wonder what's different about your system than the rest of us...

maybe an internationalization bug, what country are you from?

[Chewy1576]

I'm using it with Win 10. Works fine for me.

[BlackZR1]

it definitely works fine for me, i'm not really sure what's going on here.

i honestly haven't tried it in windows 10, but i assume others have.

i wonder what's different about your system than the rest of us...

maybe an internationalization bug, what country are you from?

I'm from Pittsburgh, PA.
I've tried it on my new work-issued Win10 laptop as well as my older home Win10 desktop. Both yield identical (bad) output.

[Terminal_Crazy]

I'm using Windows 10 (upgraded from Windows 7 )
Working great here.

Thanks Steveo.

[steveo]

I'm from Pittsburgh, PA.
I've tried it on my new work-issued Win10 laptop as well as my older home Win10 desktop. Both yield identical (bad) output.

there has to be a common factor, i just tried it on a windows 10 computer at work and no problemo.

[Stokes1114]

Used nothing but win10. Has always worked great

[BlackZR1]

there has to be a common factor, i just tried it on a windows 10 computer at work and no problemo.

SUCCESS!
After trying it on a 3rd machine, Win7 with same result I remembered a previous post where Steve said to reset advanced settings.
So even though I never installed a previous version or messed with the advanced settings I went to the advanced settings page and clicked on "reset to defaults" and now all is good.
I do notice that the "VE Interpolation map" button that was present on an earlier version (post #46) is no longer there.
Thanks to Steve, Stokes1114, Terminal_Crazy, Chewy1576, & Eds for help narrowing this down.

Thanks,
Roger

[steveo]

glad it works now

not sure why that would happen. it initializes to default values that aren't defined yet, and 'reset' just deletes everything. ill have a look over my code in that area.

[steveo]

SUCCESS!
After trying it on a 3rd machine, Win7 with same result I remembered a previous post where Steve said to reset advanced settings.
So even though I never installed a previous version or messed with the advanced settings I went to the advanced settings page and clicked on "reset to defaults" and now all is good.
I do notice that the "VE Interpolation map" button that was present on an earlier version (post #46) is no longer there.
Thanks to Steve, Stokes1114, Terminal_Crazy, Chewy1576, & Eds for help narrowing this down.

Thanks,
Roger

i'm having trouble finding the source of this problem,

do you still have a computer which exhibits the problem that you haven't reset settings on yet?

if you do, don't reset it, i want to look at the registry entries...

[steveo]

i'm having trouble finding the source of this problem,

do you still have a computer which exhibits the problem that you haven't reset settings on yet?

if you do, don't reset it, i want to look at the registry entries...

never mind, i've found the problem.

i'll fix it soon.

[steveo]

fixed

[spfautsch]

Hey steveo - are MAF layouts working at all? Anything I touch related to a MAF layout gives me a fatal error "inappropriate engine in analyze_maf()".

I know you're going to tell me I'm capable of looking for myself, but I just enabled MAF in my tune after getting my VE tables dialed in really well and lo and behold my idle / low tps splits went from 17 to 6 (LT1 w/ comp cams 467 / xfi280). Needless to say I'm both baffled and excited. All of a sudden I no longer need to goose the throttle while slipping the clutch.

I have some changes relative to knock event noise filtering I need to figure out how to push to git for you to peruse. I emailed you about this - was seeing anywhere from 10-30% of my knock events were corrupt frames (assuming caused by comm noise).

edit: Speaking of splits, if it wouldn't be a ton of work I'm sure the non-$EE folks would greatly appreciate something similar to eehack's "CL Performance" tab.

[steveo]

Hey steveo - are MAF layouts working at all? Anything I touch related to a MAF layout gives me a fatal error "inappropriate engine in analyze_maf()".

I know you're going to tell me I'm capable of looking for myself, but I just enabled MAF in my tune after getting my VE tables dialed in really well and lo and behold my idle / low tps splits went from 17 to 6 (LT1 w/ comp cams 467 / xfi280). Needless to say I'm both baffled and excited. All of a sudden I no longer need to goose the throttle while slipping the clutch.

I have some changes relative to knock event noise filtering I need to figure out how to push to git for you to peruse. I emailed you about this - was seeing anywhere from 10-30% of my knock events were corrupt frames (assuming caused by comm noise).

edit: Speaking of splits, if it wouldn't be a ton of work I'm sure the non-$EE folks would greatly appreciate something similar to eehack's "CL Performance" tab.

i'm thinking my spam filter caught your email.

with git, what you want to do is a 'pull request'. https://help.github.com/articles/about-pull-requests/

this is a bit overkill so you can also just email me a diff or tell me what you've changed.

i'm not sure if it's really necessary, if you have 'corrupt frames' you need to have your ADX file or whatever check the checksums and reject records that fail... way too many ADX files ignore that checksum. it's there for a reason; if it doesn't pass, then you have bad data somewhere.

i thought about adding the cl performance tab thing. unfortunately BLM cell number, o2 voltages, etc are kind of a requirement, it might require too much user input. i'm going for minimal time to complete an analysis for most use cases here. i will reconsider it.

[steveo]

sorry i forgot all about maf layouts.

they're working, as far as i know. they're badly tested. they don't automatically modify the table in the clipboard yet, but they should work.

i'm not sure why you're getting that error, but i'd guess somehow that it's allowing you to select the geometric analyzer, when that doesn't work with a two dimensional table. try selecting loose or strict cell. it's supposed to disable that option when analyzing maf. i'll look at it.

[spfautsch]

i'm not sure if it's really necessary, if you have 'corrupt frames' you need to have your ADX file or whatever check the checksums and reject records that fail... way too many ADX files ignore that checksum. it's there for a reason; if it doesn't pass, then you have bad data somewhere.

I'm happily ignorant of what an ADX file is. I use eehack for logging. Perhaps you've heard of it.

I'm relatively sure I have bad data, as it seems unlikely I was doing 75mph with 400+ measured g/s from the MAF (that was disabled in the calibration) one frame after 45 mph and 0.0 MAF.


i thought about adding the cl performance tab thing. unfortunately BLM cell number, o2 voltages, etc are kind of a requirement, it might require too much user input. i'm going for minimal time to complete an analysis for most use cases here. i will reconsider it.

I hadn't thought about BLM cell #s in logging data. I'm sure we could all live without o2 voltage data points but the cell #s are certainly critical and it hadn't occurred to me that it might not be a standard parameter to log. Forgive me, it's been nearly 10 years since my last foray into PCM tuning.

Whatever the case, trimalyzer has been a godsend for getting my VE tables tweaked. I've been blessed with a precipitation-free forecast for the next few days so I'm hoping to take full advantage and make some headway with MAF enabled. Thankfully you made that easy enough with eehack. Thanks again steveo, you rock!

[steveo]

Hey steveo - are MAF layouts working at all? Anything I touch related to a MAF layout gives me a fatal error "inappropriate engine in analyze_maf()".

i found that bug, it was in the actual analysis selector box.

when you change to maf mode (or back to ve mode) it has to repopulate that box, since the 'geometric' analysis has to be removed (or added).

repopulating the box was triggering an event that caused the table to be redrawn before it's actually ready, since other parts of the code expects that selector box to already be populated. it also caused the table to be drawn twice on initial analysis.

posted a new version that fixes that bug, so maf analysis should work now

[spfautsch]

Sweet, thanks!

My next question - why isn't eehack discarding munged data? (see question in eehack discussion (http://www.gearhead-efi.com/Fuel-Injection/showthread.php?4956-new-EE-tuning-thing!&p=65331#post65331))

[dzidaV8]

OK, I'm trying to analyze logs from $6E MAF ECM. (log attached).
The MAF sensor table gets populated, but there's 50% enrichment everywhere. I created new column with WB Trim (WB AFR / Target AFR * 100) in the log file using excel.
I can see that "Target" in Table Analysis is always 128, no matter what I select in the Trim Input Type box.

[dzidaV8]

I've tried making the trim column match BLM (0-255) (WB AFR/Target AFR) * 128
But the result is the same - everywhere 50% rich.

[EDIT]
Found the issue, header line in csv file had extra commas that skewed columns for trimalyzer. Working now :)

[steveo]

yes, if your csv files are screwey, trimalyzer will fail.

earlier versions would have refused to load that file, but since alsldroids csv export isn't very good, i had to break error checking (the number of header columns should match the number of data columns or data bad, imo)

[davidneson]

how do you make cell 16 false steveo

[steveo]

how do you make cell 16 false steveo

press 'add filter'.

find your BLM cell field in that list (typing 'cell' or 'blm' in the search field will probably help).

select operation 'Not Equals'.

set that filter's value to 16.

this will allow all records with blm not equal to 16.

alternatively filter for less than 16. this also rejects cells 17 and 18 (a good idea imo)

[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-Injection/showthread.php?4248-S_AUJP-v5-Log-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

[Xnke]

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?

[steveo]

yeah kinda, you will have to set and unset the filter for "over one bar" or whatever.. no big deal.

[Xnke]

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?

[steveo]

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.

[Xnke]

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.

[dzidaV8]

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 :)

[kur4o]

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.

[steveo]

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

[steveo]

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

[kur4o]

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.

[steveo]

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

[kur4o]

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.

[steveo]

I just can`t imagine what would of happen if you still had an lt1 car around.

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.

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.

[dave w]

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-Injection/showthread.php?5381-Wide-Band-O2-(WBO2-Tuning)-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

13740

13741

13742

13743

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

[steveo]

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.

[dave w]

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

13760

13761

[steveo]

you probably do want a 14.7 target (or whatever your target is)

[dave w]

you probably do want a 14.7 target (or whatever your target is)

Ok, I just need to figure out how. Any hints on how to set the target to 14.7?

dave w

[Stroked 388]

Ok, I just need to figure out how. Any hints on how to set the target to 14.7?

dave w

It should be open loop AFR Target and closed loop AFR Target I believe

[steveo]

its in the analysis window at the top (target can be changed live)

[dave w]

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

13767

13768

[steveo]

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.

[dud]

I was able to get Trimalyzer 1.4b to show the proper WB02 values with the settings pictured below.

[dave w]

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

13775

13776

[steveo]

ill do an update to trimalyzer to fix that and maybe make the ui more clear. i feel i've neglected it a bit

[steveo]

It appears Trimalyzer shows similar BLM vs. WBO2 data, like the WBO2 spreadsheet.

The WBO2 spreadsheet uses "Average IF" to calculate WBO2 data.

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.

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.

[dave w]

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.

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.

I'm liking the flexibility the Trimalyzer!:thumbsup: Ultimately, "A Good Tune" is the goal for using Trimalyzer. How "A Good Tune" is achieved is up to the Tuner. Trimalyzer is an AWESOME "Tuning" tool!:jfj:

dave w

[steveo]

ok try this, made some changes so arbitrary input should work as expected

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

[dave w]

ok try this, made some changes so arbitrary input should work as expected

Works great!:thumbsup:

dave w

13777

[joegreen]

Its good to see trimalyzer is still being worked on. Even though im not very familiar with it i think its a great tool.

[Casey96SS]

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!

14404

[steveo]

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

[Casey96SS]

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.

14405