new $EE tuning thing!

[steveo]

Also, could you possibly have it remember the narrowband/wideband selection on cruise analysis? every time I restart the program I have to reselect it.

i s'pose i could do that. i'll fix the wideband percentage thing too.

do you have a log with wideband data and the afr display hack i can have? i don't seem to have a clean one right now.

the AFR thing can be pretty sketchy as i make it override BLM, closed loop, do a BLM reset, bunch of other crazy crap to make it work. i plan to disable the feature unless patched, and use a patch to make it behave a bit better.

timing and idle should be ok though?

the new version should clear all settings when closing the 'controller' window, you shouldn't have to reconnect

it's possible i've missed some stuff, there were a ton of changes and to be completely honest i've only bench tested this stuff, not tested on my actual car yet, so i bet something is broken. let me know what else you can find.

[steveo]

i fixed the analyzer bug, when i rewrote the analyzer as a separate window, i just forgot to move the function over that actually copies the checkbox state for 'percentage' to the appropriate variable in the analyzer structure. threw in a conditional memory on that wideband/narrowband thing for you too, it clears itself if the wideband is ever disabled.

https://github.com/resfilter/eehack/...98126b2c44df6c

i glanced and i think i found the controller bug, due to thread synchronization. under the current scheme it's possible that:

- user sets the 'need to send command' flag
- event loop recognizes the flag
- event loop sends command
- user sets the 'needs to send command' flag again
- event loop goes 'ok, i've sent the command, clear the flag'

in this case your additional command happened in the middle of a send procedure and is discarded. the proper command should be sent on the next iteration anyway, but it could definitely do some weird things where your intended commands lag behind, so even though you select a 900 rpm idle, it's still at 600rpm ....

i've done a minor update to solve it in 99% of cases by clearing the flag immediately as it's taken, and when i get home i'll do some proper locking on that operation to eliminate it completely. fixed a few other functions that might be afflicted as well.

https://github.com/resfilter/eehack/...5ac0b581a31a94

[steveo]

proper fix for mode4 request serialization and locking is on github now and also in beta 7 on my site, http://fbodytech.com/eehack-2/beta/

the 'raw commands' interface had a similar bug that i worked around too

one step closer to stable, but im sure there are other problems i'll run across.

[steveo]

one other odd thing is my car now refuses to do flash read/write but datalogs fine using my 'benchmark netbook' which is an intel atom peice of crap running xp. it fails on the first part of trying to get into diagnostic mode.

but if i plug that same laptop into my bench ECM, it works fine, so i tend to blame my car, or perhaps something is wrong with the serial interface that's haphazardly wired into my dashboard...

[decipha]

hey steveo can you give me a shout on my mobile? five oh four six oh six oh five three two

[steveo]

hey steveo can you give me a shout on my mobile? five oh four six oh six oh five three two

i don't really have a long distance plan and i'm in canada, can't we do this over private message?

[decipha]

nothing important I was just gonna BS with you

[steveo]

new beta

biggest change is higher data rates due to being a bit smarter about spending time flushing the serial buffer between requests (which generally isn't necessary unless the previous request was potentially in error)

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

[decipha]

nice!!!

If you ever need webspace I can hook you up over at efidynotuning

[steveo]

hey I checked your site out and its great! i even learned a thing or two. you know your stuff. its a bit fordy but the info for new tuners is brilliant, you should consider reposting some as articles over here.

anyway thanks for the offer but im set for hosting, eehack donations cover a portion of my hosting bills, enough where I don't have to bury the thing in ads anyway...

[decipha]

thanks steveo, yeah i try to make it easier for the guys jumping into it

I'd rather just link the write ups rather than post it elsewhere as i update it frequently so having it in multiple places would make it difficult to keep it all up to date and accurate

[steveo]

i've started writing my datastream layout discovery engine. it's getting there in theory i just have to work some design issues out...

the idea is we have a memory topology definition of the entire t-side and e-side, with variables defaulting to RAW. i think i'll build my own definition format, it'll be pretty simple. the memory definition itself will be 'load once on startup' and not be runtime configurable.

i'm still a bit torn on how i want to do the calculations. i think a math engine like tunerpro has would introduce too much overhead. i might force people to use a set of hard-coded defined formulas, and if a new formula is required, you can ask.

there will be a concept of 'view levels' built right into the memory map, so we can default the ui to 'view essentials' instead of 'view everything', you wont see the 'raw' stuff unless you ask for it. view levels will be useable in graphing and stuff too so you can graph any raw memory address you want.

it'll do a discovery of the t-side on initial connect (and e-side if available) grabbing the entire datastream configuration, then build a datastream_topology which is basically just a list of pointers to definitions of memory addresses in that particular message. the raw datastream configuration will be stored in the log file.

each loaded datalog will have its own independant datastream topology (but share a memory layout definition). this increases log loading overhead slightly but not really runtime overhead.

you will be able to choose any combination of messages and vary their polling frequency a bit. having multiple selectable datastreams is a bit tricky for the dashboard and analyzer and all that, it'll just require me to rethink a bit of stuff.

consider when you have a message without RPM in it, and that one is polled often. when there's no RPM data, do you just display the last known RPM? or do you display zero? what if zero is a potentially normal state for that data, that means you're displaying false data. do you just grey the control out and make it blank? what if RPM is only polled every 30 seconds? does it just flash the rpm then turn grey again?... definitely this is the part that requires the most thought, it'll probably take more work than the discovery engine itself.

i'll need a new datalog format, so the next version probably won't load old logs.

[steveo]

4.4 release: http://fbodytech.com/eehack-4-4-release/

[steveo]

after some testing and trial runs i've decided datastream config discovery isn't the best option for eehack at this time. its' just too much work for almost no real gain.

im going to stick with fairly statically defined data but start allowing multiple messages, and continue along with my original 'passive patching' instead. there will be two datastream definitions, patched and not patched.

i think message zero is sacred and should kinda be left alone as to not break compatibility with any other logs. my accelerated logging message works well and should be left alone too.

i really want that eside message. just one message with all cool parameters we can find.

the next version of eehack will just have a goal of reading, log, and play back all t-side bytes on the 'extended' tab.

[steveo]

im thinking i don't really want or need an external configuration file for the datastream right now, and i'll just build it internally.

all available bytes, undefined or not, will be accessible as raw data for research; but people will have to approach me to add new definitions with names or equations (or recompile themselves).

this does discourage people from modifying datastream config themselves but i think if we just use eehack's passive patching to have a stock datastream and an optimal modified one we'll be better off.

any objections?