new $EE tuning thing!

[steveo]

I'll try my hardest. I did get the graphing to completely stop working yesterday. I kept loading logs, then playing with max zoom and replotting. at one point i scrolled to an area that didn't have a graph showing, because the graph hadn't been re plotted to reflect loaded log files, I then zoomed in, and when I scrolled back, there was no graph anymore, and no matter what I did it was all just one straight line across the graph. had to restart eehack to get it to work again. In the terminal I had a couple of illegal poly errors, or something similar. I imagine it would be fixed with the latest source, as it was probabably due to the stale graph data

i doubt it was due to stale data. you load a dataset directly into the plotter, then it becomes independent of the log buffer. pressing 'replot' (or my automatic replotting) is like taking a snapshot of the data to work with.

i'm using a third party plotting library to generate and manage the graphs called qcustomplot. it's very powerful.

there are smaller graphing libraries, and i also wrote my own that worked okay, but i decided to use it so i could take advantage of some other features later.

look at some of the cool shit it can do with your data: http://www.qcustomplot.com/

my two graphs are actually two seperate instances of qcustomplot, but it's capable of doing both graphs as one instance, whiche would be easier to manage. i couldn't get it working (hell i'd only used c++ for a month or two when i started writing this thing) so i just basically added another graph widget and synchronized their time axis during scroll/zoom events.

an illegal poly error is likely a bug in qcustomplot itself, but if we can reproduce it, i can fix it.

[sherlock9c1]

Steveo, I just started using the analysis tools. LOVE them - they look very similar tools I built in Excel to do the same VE and MAF calibration adjustments.

Question - in the Cruising AFR tab, the test vehicle was lean across the board. A few of the cells are green; looks like +5% turns them green? If the meaning of the colors is written into a tooltip, I must have missed it. Can you clarify?

[steveo]

Steveo, I just started using the analysis tools. LOVE them - they look very similar tools I built in Excel to do the same VE and MAF calibration adjustments.

cool! im glad you like them.

even if you aren't a programmer, you may be interested to read my analyzer code. it is functional per-record so you can see how i do my filtering.

https://github.com/resfilter/eehack/...r/analysis.cpp

the analyzer, underneath, is incredibly simple. it uses a 'giant average' in a floating point number rather than trying to do a running average histogram, which, across a large data set with proper filtering, should give much more useful data and reject 'blips' fairly naturally.

Question - in the Cruising AFR tab, the test vehicle was lean across the board. A few of the cells are green; looks like +5% turns them green? If the meaning of the colors is written into a tooltip, I must have missed it. Can you clarify?

yeah i do need to put a key there. im out of pixels!! arrgh

i made them the same as in datamaster, since most lt1 guys are used to datamaster. here's the coloring code:

if(trim > 134) ui->afr_maf_table->item(maf_axis,1)->setBackgroundColor(Qt::green);
if(trim < 122) ui->afr_maf_table->item(maf_axis,1)->setBackgroundColor(Qt::red);

so, green is lean (trim fuel added), red is rich (trim fuel removed).

when using percentages on trim negative/positive naturally becomes a change needed to a particular table, for example if a cell is -5%, you need to remove 5% from that particular table area in your bin. there's nothing backwards or unintuitive there.

look at the settings page, percentage display does have some options.

i expect many experienced tuners to disable percentage mode entirely, personally im so used to looking at 'difference from 128' in every other lt1 tool, percentages screw with my head a lot..

but for new tuners, there's NO need for them to see raw trims. im suprised any tools ever displayed raw trims. it'd be like reading raw temperature or rpm bytes that aren't converted to human-readable values. no point at all.

[sherlock9c1]

Got it. I stopped using Datamaster for anything other than data acquisition a long time ago and built my own tools in Excel that have proportional shading and % difference. I even put in spots to dump existing BINS and then it'd multiply the MAF and VE tables by the % to give you the new values; then you just copy and paste them in. So yeah - it was dumb that the original tools even displayed 128 at all.

[steveo]

even put in spots to dump existing BINS and then it'd multiply the MAF and VE tables by the % to give you the new values; then you just copy and paste them in.

i could so easily do that with eehack now, since it does read/edit/save bins and has knowledge of their basic layout. what makes me not do it is that people will expect eehack to automatically tune their shit for them.

it's really common that some data doesn't make sense, sensors lie.

so i'd rather just draw the line and say 'eehack doesn't tune, only gives you information'. it is tempting though

[sherlock9c1]

Yep. Or folks with dirty MAFs, leaky intakes, busted exhaust manifold bolts, fuel pressure out of spec, dying O2s, weak ignition coils / ICMs wanting a tune anyway... I could go on.

Like the time I had a car that knocked like crazy at 2000rpm across multiple load ranges no matter how much timing I pulled. Then the owner found the the drivetrain hitting the floorpan in a certain area. Once he fixed that, the knock went away. But I digress.

I think VEmaster used to do that. You've got the source code out there, and EEXtra has the memory addresses; just leave it at that and let those who want to build their own setups.

[troutdog311]

I can't remember if I had posted this earlier and didn't see it in this thread. Let me catch you up to what I've seen that is odd. I have been having graphing issues though everything else "Main/Analyzer and others" work great. The graph data isn't loading and this had happened to me before in Beta 4.0-3. I'm still currently using 4.0-9 at the moment and what was odd is when I was using 4.0-3 all older logs that had been taken Pre- beta 4.0-3 graphed fine when loaded, even really early versions, just none of the 4.0-3 logs though it worked the first few recordings.
I updated to 4.0-9 I think Wed and oddly all my 4.0-3 logs worked great when they didn't while I had 4.0-3 installed. Then my first 2 logs using 4.0-9 graphed fine tand my next 2 logs had no graphing data to view. This happened in 4.0-3 except it had flat lines across the board now 4.0-9 is simply blank. Tonight still using beta 4.0-9 none of the logs show data like it would do in 4.0-3 not even the really early logs.
Another thing that isn't a big deal though may have something to with the issue. Say you load a data log and go over the graphing, when you load the next log the previous graph is still present. What I've been doing to refresh the graph is selecting Max Zoom and sometimes another graph option like Normal, SPK or BLM for example. In Pre beta 4.0-3 versions this did happen and found by simply hitting "X Clear" it wouldn't happen though in the beta 4.0-3 and beta 4.0-9 this didn't help. I usually had to restart the program to refresh the graph. I'm loading the newer version as we speak and will let you know if any of my 4.0-9 show graphing.
Not complaining just trying to help with the little bugs I've seen so far. I hope you got that little bit of beer money too :) and Happy New Year!