new $EE tuning thing!

[steveo]

and let me just state how fantastic it is to have this as a native binary running on linux!
Really stoked about that.

me too.. it wasn't really an official goal, just a side effect.

it's too bad it requires bleeding edge QT to run, though, that screws us out of distribution packages for probably a year. hell, most distributions still run QT4.x

being GPL i could technically just copy qserialport into my source tree, rename the class, and then the serial driver is part of eehack's distribution, but i'd like to avoid that.

Next test.... flashing.

if datalogging and tweaking parameters works without generating errors, it should be alright.

[fbody_Brian]

an observation
when loading multiple log files (appending) if you have already selected items in the graph view they do not update or append the view until you select a different item in that graph. Once you select a new item then the graph extends to include the appended data.

here, the bottom graph shows the whole datalog, whereas the upper graph still shows the previously loaded data.
Attachment 10068

any way to have it replot on loading or appending a log file?
Edit:
Should I be submitting these things as requests/bug reports to github? or is it ok to post in this thread?

[steveo]

when loading multiple log files (appending) if you have already selected items in the graph view they do not update or append the view until you select a different item in that graph

as it stands right now, i expect when new data is added, that the user click the re-plot button themselves to update the graphs.

here, the bottom graph shows the whole datalog, whereas the upper graph still shows the previously loaded data.

having the two graphs out-of-sync due to selecting new data in one graph is certainly a case i didn't think of. i'll likely have to make it refresh BOTH graphs when selecting new data. this isn't a large amount of overhead, as plotting is very fast.

any way to have it replot on loading or appending a log file?

i'd rather force the user to do that manually, otherwise, do i draw the line just at loading a log? what about recording new data?

i originally planned to have to manually refresh all the time, but updating the graphs when selecting data sets was just too useful to pass up.

i want to avoid graphing causing any unintended overhead in the rest of the program. if a user selects a graph item, then goes to load a new log, should he really have to wait extra time for the graph to update?

perhaps i should simply clear the graph when loading new log data or recording new data, but i'd rather leave it plotted as-is

[fbody_Brian]

perhaps i should simply clear the graph when loading new log data or recording new data,

This gets my vote.

As it is now, you can clear the logged data and load a new log yet the graph still shows the previous logs data. If the user is aware of the behavior it's really not a big deal though. it's simple enough to click the replot button.

[steveo]

go grab fresh source from git, i think i fixed the graphing behavior.

it uses a simple 'data stale' state flag, and works on the assumption that data can't be loaded while the graph tab is active, and switching to the graph tab is only done when graphs are desired

it also actually 'clears' the graph when there's no data (before it just bailed if there was no data)

see if you can break it

[fbody_Brian]

it uses a simple 'data stale' state flag, and works on the assumption that data can't be loaded while the graph tab is active, and switching to the graph tab is only done when graphs are desired

I'd say that's a pretty solid assumption.

see if you can break it

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

[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!

[steveo]

I did, thanks for the tip!

I want to investigate the graph issues you are having but it always seems to work perfectly for me. first please switch to 4.0-release.

if you can poke at it and find a procedure start to finish as you start eehack, I can fix it. send me the log in question and the steps necessary to reproduce the problem.

when you see a long line that's usually a blank section with no data. do realize that eehack graphs on a strict time axis starting from the first connection point, so if you have logged for 5 minutes, parked for 20 minutes disconnected, then logged some more, you will have a 20 minute long flat line.

we do have a bug that causes graphs to desync if you don't press replot when loading new data and just expect changing aparameter to refresh everything. This is fixed in the next beta..

[troutdog311]

Thank you for the quick response Steve! That is a very good idea about the flat lines being at idle in park. I usually take separate logs for idle and even my O2s were flat lined. I just started playing with the new v4.0 and all my graphs look great except the 2 from earlier today from the beta 4.0-9 logs. I will disregard these logs and continue fresh tomorrow.
I did get my procedure mixed up. Usually pressing Re-Plot does bring the graph up to date. Thank you Steve and Brian for the hard work! I can't say it enough. If I have issues tomorrow or hopefully good news, you be the first to know.