What’s in store for the next release??
First off, since it’s now a flash tool, the next version will start transparently patching your bins as they’re programming for more/faster/better data to play with. Since we’re the flash tool and the logger, we can slip in some code into the unused aldl modes and messages. There is a bunch of unused aldl code that can be abused for more data.
These patches will be silent and safe, and have a persistently stored version byte (which can be fetched immediately on connection) so EEHack will tell you if your ECM version and EEHack version are out of sync, and enable enhanced features only with the correct patches installed.
First patch is an easy one, I have constructed a shorter message for speed logging which doubles the sample rate (if you don’t mind giving up error codes, a/c temperature, or anything else useless for actual tuning…)
A kind LT1 enthusiast is donating a wideband to me, which is a BIG deal since now I’m inspired a bit…
Tweaking the datastream opens up some possibilities, as does kur4o’s recent patch to enable memory dumps on the e-side just like the t-side already has. With open loop AFR target in the datastream and higher sampler rate and direct access to the bin, this means the analyzer can compare open loop AFR target with actual wideband AFR at an increased resolution, giving you an accurately corrected VE table with no messing around or reflashing while you’re building it. The existing tables themselves, if required, can be dumped from the bin without reading the whole thing…
Hell you can even force open loop without flashing, so the idea is, if you have a wideband and you feel your AFR is drifting out of whack, just click connect, force open loop, take a drive, and hit ‘analyze’ when you get home.
What about the flash tool?
Other than more stress testing and stabilization… It’s getting way faster data rates too, abusing the fact that EEProms erase to 0xFF (11111111) to decrease the serial bottleneck. This means that 0xFF bytes don’t need to be transmitted for them to be programmed, they’re already in the correct state we just have to play with chunk sizes a bit to reduce write traffic in certain areas.
We can also blank out unused/unreachable sections of the bin, for example, automatic transmission tables in manual bins don’t matter, and MAF tables in VE only bins don’t matter either. This is also transparent, and doesn’t involve modifying your bin as it’s stored on disk. Could save thousands of bytes, and with our already existing single-sided write, we could be sitting around waiting for flashes a lot less…..
Stay tuned.