For questions not covered here, here’s the original EEHack monster thread for reference.
- How do I see the target AFR, enable speed logging? Why did these features disappear suddenly when updating to a new version?
- Where is the user’s manual?
- Is EEHack the right program to use for me?
- Help, EEHack won’t connect!
- How do I edit my bin with EEHack?
- Why don’t I see any analysis results?
- How do I use $EEHack to “scan for codes”?
- How do I get more optimal performance from my ALDL interface?
- What is “Speed Logging” and how does it work?
- Would (Speed Logging) cause other programs that rely on an ADX file not to be able to read the information correctly?
How do I see the target AFR, enable speed logging? Why did these features disappear suddenly when updating to a new version?
In older versions of EEHack which featured my original flash tool, these features were enabled quietly in the background by slipping some code into the bin you were flashing.
Now that the flash tool has been removed and replaced with flashhack, it didn’t make sense to transfer all of that code over.
You will need modify your bin by installing the “EEHack Patch V3” patch that is located in later versions of my EEX XDF file to enable these features.
Where is the user’s manual?
It’s built in to every button and control in EEHack itself.
Each feature of eehack is documented with ‘tooltips’, meaning if you hover your mouse over an option you will get some help or additional info.
I tried my best to design EEHack so everything is obvious enough that you can poke around and figure it out on your own.
Is EEHack the right program to use for me?
If you aren’t tuning your car and just want to do basic diagnosis and read codes, have no interest in learning about fuel injection systems, and are not generally being excited about finding new capabilities of your car’s ECM that might make it run better, I’d recommend trying Scan9495.
Help, EEHack won’t connect!
I’m always hesitant to blame the cable in these cases (since if it ends up being my code’s fault then i feel bad)…
… but it’s always the cable
… ’cause my code is never bad
Try other software and see if that works. Some of them (scan9495) uses more conservative communication practices, but glitches would usually show up there, too.
It’s really rare that all the other software works fine, but not EEHack. In reality, my software doesn’t interact with the serial port directly, it uses QT’s serial port abstraction layer, written by real programmers, not hacks like me. so there’d have to be a bug in that, or a bug in the usb/serial driver. otherwise every user would be affected.
Also ensure you’ve selected the correct vehicle type in settings. Due to how other devices that share the ALDL data wire behave, different LT1 variants have different requirements for communication (the F-Body configuration is the easiest to connect with, by far.)
Even if the correct vehicle is selected, some Cadillac models simply have too much crap on the ALDL bus and are kinda hopeless for mission-critical things like flashing, but if you pull some fuses for stuff like ABS and SIR then it should behave. I added the ‘silence extra modules’ option to try to help deal with this, but your mileage may vary.
Another aldl problem I’ve seen involves people powering their laptops from their car’s cigarette lighter, you can end up with weird ground faults if your power supply sucks. Try running off of battery power (so the only ground to your car is through the aldl port)
How do I edit my bin with EEHack?
You don’t. That’s what EEX (with tunerpro) is for:
EEHack provides the data analysis necessary to tune, but doesn’t edit the bin.
Many people have requested automatic tuning tools (which would implement the changes in the analyzer), but I think this is generally a bad idea, since blindly entering data usually results in bad tunes… and I don’t want EEHack being blamed.
Of course I did create the trimalyzer tool to ease transitions from trim data to VE table corrections, if you want to try that out.
Why don’t I see any analysis results?
Each analysis has its own thresholds and conditions that need to be met for data points to be considered valid.
If the analyzer module considers the data to be unreliable, it simply won’t be displayed.
Analyzing cruising AFR with your ordinary O2 sensor, for example, your car must have spent a reasonable amount of time in closed loop, but not in power enrichment. Having one or two data points at a certain RPM range certainly isn’t reliable data. You can lower the “Minimum counts for valid cell” to override this behavior.
Check that your BLM cell is moving around from 1-18 freely, check that your O2 sensors are switching, that closed loop is being entered, that the coolant temperature gets high enough, etc.
In short, make sure your car is making it into closed loop if you are analyzing closed loop, and record more data across the entire operating range for best results.
If you require more control over the thresholds and filters, I suggest trying Trimalyzer.
How do I use $EEHack to “scan for codes”?
The main datalog window will display basic error codes, but there is an extended set that provides more useful information.
To access it:
- Open the Datalog module
- Go to the “*Diag” tab
- Press “Snapshot”
Any error codes set or stored will be displayed in the “Error Codes” box in the bottom right hand corner.
“Streaming” this message is possible too, but slows down the rest of the datastream substantially.
How do I get more optimal performance from my ALDL interface?
EEHack behaves best with very low serial latency.
The default FTDI windows drivers usually set a 16ms latency, and we’ve found EEHack is best with 1ms latency:
What is “Speed Logging” and how does it work?
The factory “main” datastream message contains information such as error codes, air conditioning thresholds, and other junk that increases its size. The size of this message restricts the rate at which it can be acquired, which decreases logging resolution and the amount of valid data.
To get more precise and robust datalogs, EEHack installs a small patch during the flash write procedure. It effectively removes an uncommonly used datastream message for retrieving extended emissions information on corvettes, and replaces it with a shorter optimized message.
This message focuses on air, fuel, and spark parameters, and is designed specifically to have the correct parameters for tuning and analysis.
To gain access to this message during logging, you will need to install the “EEHack Patch V3” patch that is located in the EEX XDF file. Afterwards simply disable the ‘Main’ message (un-check the ‘stream’ box in the *Main tab) and enable streaming in the Speedlog/OBDII tab.
This stops error code retrieval during scanning, but feel free to ‘snapshot’ the diag message to check for codes manually…
Would (Speed Logging) cause other programs that rely on an ADX file not to be able to read the information correctly?
I was very careful to ensure that any changes made by eehack wouldn’t harm any other tools you might want to use
Speed logging uses a datastream message that no other software and ADX files even deal with, which was for late model corvettes which had an extra chip with some ‘experimental’ emissions diagnostic functionality.
The stock datastream message that all other tools use is still in place, lightly modified, but again, we chose bytes that other datalogging tools don’t even acknowledge (and don’t actually matter for anything), such as b-body EGR position and corvette rear o2 voltage, replacing them with more useful things such as AFR target.