Lots of users hang around there, and that’s where most new features and bugs are discussed.
Despite my lack of an LT1, EEHack isn’t asleep, just moving slowly..
A new beta is in progress, mostly thanks to the crew from gearhead-efi.com.
New features include working y-body connectivity, definition fixes, and new controls.
EEHack has been a large project for me, and it’s met and exceeded most of its original goals, and added many that I never planned for. A tool that was just supposed to control timing advance now flashes bins (at least sometimes…..), analyzes data and makes tuning suggestions, graphs dynamically, and is extensible via definition files. I don’t even like thinking about how many hours I’ve put into it.
So, I’ve sold my Trans Am and I’m taking a break from major EEHack feature development
This isn’t the end. I’m happy to keep maintaining the software, fixing bugs, and adding features as my users required. Also I’ll get another GM car later, but it’ll probably be a V6 (which is a good thing, since it’ll drive me to add V6 support).
For now, I’m going to play in antique Bosch/Toyota land. It’ll be like a vacation.
Taking a small break from EEHack development (since I don’t have an LT1 at the moment).
I’ve decided to release the current build.
It’s really stable but I’ve labeled the new y-body and b-body connection features as ‘experimental’ as they don’t seem to work for anyone yet. I hope to get that stuff working soon. For now, though, unplugging the fuses for any CCM/BCM modules seems to enable a stable connection so you can at least flash.
There’s also a new version of the EEX XDF, with some improvements to the automatic transmission stuff.
With the direction that Windows is moving in, I believe that Linux is the future for many oldschool ECM tuners.
One cool thing about EEHack is that it runs almost effortlessly in Linux, being written in QT. One of our more advanced users and beta testers, Brian, uses Linux almost exclusively with each new release and has reported no major issues.
The major hitch in that plan is that EEHack requires QT 5.6 due to some issues with serial ports in older versions, which is a brand new thing, and most distributions don’t package it yet.
So, to assist users in installing EEHack on their 64-bit linux systems without having to compile or install or whatever, I’ve decided to provide a generic package for Linux users. Sorry, 32-bit guys, providing two packages is too much work.
It requires no installation, no root access, and should simply ‘unpack and run’.
Give it a shot and let me know how it goes!
Ready to go!
Re-visited log playback this morning to fix a few small glitches.
Working on a new version, it’s almost ready…..
The biggest changes are multi-message support and a less rigid data model for parameters.
In short, eehack can now extract more data.
LOTS MORE DATA.
I’d come to realize that eehack was fairly limited in that respect. I’d tried to focus on parameters only useful for average tuners so you weren’t overwhelmed with a bunch of bells and whistles, and so I wasn’t overwhelmed trying to maintain such a large dataset, meaning EEHack suffered in its ability to diagnose problems, or deal with unique situations.
Now, instead of just few dozen parameters available in a fixed dashboard, we have dynamically generated tabs full of clean, extensible data!
… I kept the ol’ dashboard alive, though.
Even though over 1,000 hand written parameters are in there (yes, I spent a long time on this definition file), there’s a simple view filter so you don’t have to scroll through a whole bunch of data to find what you’re looking for.
I kept the definition fairly simple for people that want to try modifying parameters themselves, your favorite spreadsheet software should do the trick. People wanted three decimal places for the MAF AFGS. Fine, add it yourself. Add decimal places, change names, whatever you like, eehack will mostly cooperate with you.
EEHack now reads everything from onboard electrical diagnostic chip output to the corvette-only transitional OBD-II junk.
The other big news is thanks to kur4o’s hacking of the e-side, we can leverage this new expandable device and message independent data model in combination with the passive patching during flash system to get a new message from the e-side (the e-side usually doesn’t like talking).
… Don’t understand what this means?
Basically, not only does EEHack now rip the existing datastream apart, it also has all sorts of parameters available from the ‘other motherboard’ that weren’t even possible to access before. There’s cool stuff over there. Things like individual spark constructs, VE lookup results.. we’re working on more.
Unfortunately, the move to multi-messages means your old logs wont load, but the good news is the new log format is much more compact and awesome, it is half the size, and stores vin, calibration id, patch version, and much more.
Give it a shot if you’re brave… and please help me test all these new features. Official release will be soon.
New 4.4 version of EEHack is out.
It’s a lot of new code, so there may be small bugs, but I think it’s ready for general use.
In general, the UI is better, and the datalogging is faster and more stable.
Just a preview of what I’m working on with the next EEHack. This is really fresh code, but if you’d like to try it, it seems pretty stable! http://fbodytech.com/eehack-2/beta/
EEHack has always been a single-threaded program, meaning events happen in a strict sequence. This is easy to program, but can perform in a sub-optimal way in some situations, and really makes timing of operations a bitch.
The new version of EEHack has a well-isolated and almost completely non-blocking datastream interaction thread, meaning even slow computers should get exceptionally fast and consistent logging speeds, and there’s less of a chance of anything getting in the way of things like flash writes or timing advange modifications.
EEHack was written around a single gigantic window class from hell, making it nearly impossible to grow any further without serious rework.
The new version of EEHack was rewritten with modularity in mind, with seperate modules like ‘datalogging’ and ‘controlling’ and ‘flashing’ that have no direct interactions with each other, but share a common datastream and datalog set.
Older versions of EEHack dealt with multiple logs by simply appending one to the other. This worked very well for feeding the analyzer large amounts of data, but made multiple logs hard to work with. The new version will have a log selection interface to deal with this issue.
Even if you think a program will never grow, write it from the ground up like it will.
Look how much work it took after-the-fact to implement threading, log management, and ui segmentation!!!
I’ve found that lowering the latency on an FTDI serial device to 1 or 2 milliseconds gives improved performance for datalogging and other communications, at least at the 8192 baud rates we work with.
Give it a shot!
The next version of EEHack, which uses a threads, message queues, and switchboards instead of simple order-of-operations and timers, approaches 17 samples per second in ‘patched’ mode on several test systems with the reduced latency.. which is probably about the maximum you’ll ever see on this old ECM.