No more Windows XP support for EEHack?

EEHack is written on top of a C++ library called QT, allowing me to develop new features rapidly, support Linux and Mac OSX, and program things in new and interesting ways.  It’s also a great way for people to develop programs that aren’t accustomed to writing GUI software.

Almost by accident, I’ve found that Windows XP is not supported by versions of QT later than 5.6.

This means that if I use the newest QT library, and I do like to keep things updated, EEHack will stop working with Windows XP entirely.  The new beta, for example, is built against QT 5.8, and refuses to start on Windows XP.

On one hand, Windows XP is now over 15 years old, and EEHack is a fairly modern program, so part of me doesn’t care, but I personally have an XP netbook I use for tuning, so I do feel the pain of people with old hardware.  Hell, you can’t even get a decent web browser for XP anymore.

I have several options I’m considering:

  1. Drop support for Windows XP and stick with current QT versions, also dropping some of the specialized compiler flags necessary to be compatible with XP.  This may result in a more stable EEHack?  Or maybe not…
  2. Stick with QT 5.6 forever, and any improvements in QT be damned.  This is the safest option…
  3. Release builds against BOTH versions of QT.  This is more work for me, but it’s possible for me to automate the process:
    1. In one gigantic installer that selects the correct version itself.  This would be a fairly large package and irritate both users since fbodytech.com’s upload speed is not awesome
    2. In separate installers and make the user choose.  I’m sure to get weekly inquiries about which version to download despite me labelling them clearly.

If we do choose option one, all hope is not lost.  Anyone can download QT with QT creator and compile EEHack themselves. This is kind of what my Linux user base is doing since I stopped releasing binaries for Linux, and it works alright.

Any opinions, please do comment.

Does this matter to you?  Do you still use XP?  Why?

EEHack 4.7 Release

Released the latest version as 4.7 (forget that minor version stuff!)

More stable, better tooltips, more settings, etc.

Download it now!

  • Fix bug that prevented ‘silence extra modules’ setting from working
  • Fix bug that sometimes prevented ‘dump ram’ setting from working
  • Stop counting errors during initial connection (unnatural serial events may be normal…)
  • Allow crazy values in linear voltage to AFR mapping (for lambada or edge cases)
  • Seperate left and right BLM values in the closed loop performance analyzer
  • Fix some tooltips and stuff
  • Parameter selector now defaults to ‘Extended’
  • Add option to always draw the dashboard
  • Tabs in settings to make room for more settings in the future

EEHack 4.6 Released

The big news is it connects to corvettes properly, and controls transmission line pressure and EGR duty cycle.

We need B-Body owners to help test connectivity on those cars (especially caddies)

Controls are now done in an ‘expert’ and ‘basic’ mode, so new users don’t have to be afraid of accidentally modifying line pressure while driving and breaking their car…

Enjoy!

 

EEHack 4.5 Beta

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!

ss444

… 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.

(download removed)

Hacking up EEHack, Preview 4.4+

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/

Threading

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.

User Interface

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.

Log Management

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.

Lessons learned..

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!!!

https://github.com/resfilter/eehack/commit/ebae2cec682f16f4629e504fb2460eb79ca97f05

https://github.com/resfilter/eehack/commit/5b7ec2f6ef575baa47128e5a4881e094156bc409

FTDI Serial Latency, and Threaded EEHack

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.

ftdi_latency

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.