new $EE tuning thing!

[steveo]

ill work on something a bit better. worst case is we just forbid overwriting in that one special case. I dont care about the csv extension, linux users should be smart enough to deal with that one.

if you do find a better way please do feel free to submit a patcg or whatever

[fbody_Brian]

ill work on something a bit better. worst case is we just forbid overwriting in that one special case. I dont care about the csv extension, linux users should be smart enough to deal with that one.

if you do find a better way please do feel free to submit a patcg or whatever

I think that you've probably implemented the best solution:

QFileDialog dialog;
....
dialog.setDefaultSuffix(extension);

This is how I was thinking was the best way to do it, but trying to figure out how to do it without rewriting most of logfile.cpp.
LOL

[steveo]

I think that you've probably implemented the best solution:

QFileDialog dialog;
....
dialog.setDefaultSuffix(extension);

This is how I was thinking was the best way to do it, but trying to figure out how to do it without rewriting most of logfile.cpp.
LOL

but the question is, does it behave itself with linux?

[fbody_Brian]

I'll be testing that after work today.
I have beta 4.20 right now, flashed and logged with it this morning. I'll compile the latest source this evening.

[steveo]

finally got around to adding more unused regions in the e-side to the flash routine.

i split the space at the end into three regions, with the tunercat notes field in the middle as kind of a divider...:

(offset+0x10000 in combined bin form obviously)

blank_region_a 0x8329-0x8fff
tunercat_notes_region 0x9000-0x9400
blank_region_b 0x9401-0xff8f

each of these is either skipped, or not. no fine-grained control per region. each area is scanned for ANY chars other than 0x00 and 0xff (it also considers 0x20 for the tunercat notes region as a blank), and the moment one is encountered, the entire region is considered 'used' and is written (not filled or skipped over).

this allows tunercat users to keep their notes written to the ECM and still get a signifigant speedup, and people that want to relocate tables can still take advantage of part of the unused region routine, and still have a crapload of space...

[steveo]

theoretically this is up to a 50% speedup on the e-side with no forseeable side effects. that means you can tweak your timing and fuel and get it written 75% faster than any other tool.

now im going to work on the t-side a bit more.

[steveo]

on the t-side, 28A0-38E1 appears to be all automatic transmission related junk, can't really find references outside of the code that's skipped when automatic trans bit is disabled, any objections?

edit: how about the tables at FB2F-FFD5, can they be skipped with a manual transmission?

[steveo]

new beta http://fbodytech.com/eehack-2/beta/

doesn't have any changes to the t-side write stuff (only the e-side)

[fbody_Brian]

but the question is, does it behave itself with linux?

Answer is yes, works exactly as you would expect it to now.

theoretically this is up to a 50% speedup on the e-side with no forseeable side effects. that means you can tweak your timing and fuel and get it written 75% faster than any other tool.

now im going to work on the t-side a bit more.

That's a huge improvement. That's 99% of my tuning.

also
since 4.1 I get no green indicators for fans or tcc.
also 4.1 version doesn't show up in the upper right corner
4.2 does though..

[steveo]

ahh damn ill fix those indicators. try generating random data (see the advanced tab) and then jiggle the slider around, its a good test.

The version check had a few issues im working out. the qt network stack is a bit odd.

[fbody_Brian]

ahh damn ill fix those indicators. try generating random data (see the advanced tab) and then jiggle the slider around, its a good test.

The version check had a few issues im working out. the qt network stack is a bit odd.

None of my green indicators are working, p/n tcc, a/c fans, etc.


I flashed the e-side a couple of times. It completes the flash in roughly 50 seconds!

If you generate random data, go to the analysis tab, move min timestamp to 0, click analyze, $EEHack crashes, Floating point exception (core dumped). Not that that's something people will be doing often.

I like the verbose debug window

Using monotonic reference clock.
EEHack Version 4.20
Built for : x86_64 Currently running : x86_64
Current OS : openSUSE Tumbleweed (20160111) (x86_64)
Fetched version from network.

[steveo]

I know what I've done wrong. suprised nobody using the beta noticed. it's that new font size junk, everything has display properties from a style sheet now, which I suppose overrides background colors.

the random data doesn't have a timestamp but it's not supposed to crash. I'll look into that.

[steveo]

beta 2 fixed that problem (yes i know one of the buttons is a different shade of grey..)

http://fbodytech.com/eehack-2/beta/

this adds all the t-side stuff, im pretty happy with the potential speed improvements. i'd love it if someone with a manual trans would test a flash write it to make sure their car still starts.

no more new features in this version, will release as soon as flash write is fully tested and im sure nothing breaks.

[jthompson122183]

using eehack4.2BETA2 had some errors when flashing. pcm is ok.

[steveo]

what kinda errors?

edit: just so you know, eehack's logs only record acquired engine data, they contain nothing about the flashing procedure.