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.
Last edited by spfautsch; 05-09-2017 at 04:10 AM. Reason: forgot something...
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.
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.
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 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!
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
Sweet, thanks!
My next question - why isn't eehack discarding munged data? (see question in eehack discussion)
Last edited by spfautsch; 05-09-2017 at 09:50 PM. Reason: add url to eehack thread
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.
Last edited by dzidaV8; 05-15-2017 at 12:36 AM.
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 :)
Last edited by dzidaV8; 05-15-2017 at 12:54 AM.
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)
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)
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/
Bookmarks