awesome that's a good starting point. if any of those masks have MAF capability i'll get them working soon too.
awesome that's a good starting point. if any of those masks have MAF capability i'll get them working soon too.
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
Will try it this eve after work
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.
Last edited by steveo; 03-23-2017 at 08:47 PM.
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.
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.
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.It seems to me though tables with greatly different values could effect the transition from one to the other.
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.
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
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 blanktunerpic.JPG tunerpicb.JPG tunerpicc.JPG
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.
Last edited by maxpowerta; 03-26-2017 at 08:40 PM.
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.
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)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).
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
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.
Bookmarks