EEHack 2019 update

[steveo]

i've decided to release an updated version of the official eehack this year, there are a few bugs to fix, and small features i've been meaning to add

been a bit lazy about doing this, since my build environment and installer packaging scripts were lost in a malfunction, but i'll start fixing that stuff soon..

any suggestions or bugs you've noticed would be appreciated.

[kur4o]

Steveo, great to have you back on the drawing board.

There are some bugs that lead to crash but are very rare. When you open the window to select an item but instead of selecting an item you press ok without any selection being made.

Only once I exprerienced a crash while starting a flash session, but it was while I was doing the v6 testing and couldn`t relate it to anything but pc or cable issue.

I have a list of new features but it is upto you how you want to make the update. Just some bugs fixed or major improvements.
I hope you add the latest patches and extra mode 4 controls and expand their capability to many new exciting controls.

[steveo]

i'll look at some of those new patches but i do have policies to adhere to as far as affecting usability of other logging tools or whatever. the EOIT timing stuff is pretty exciting for sure, but i'd rather just figure out how to tune it effectively without having to have real-time control over it, then put it in EEX.

i might also be interested, if i cant incorporate all the cool stuff, in posting your modified version on the eehack page as an experimental and more advanced version, if you're ok with that... but i'd want it "forked" and named something else like eehack-kur4o with different versioning so people dont get confused. there's nothing wrong with a fork at all.

some other stuff i want to do...

- make some new cable testing routines to help identify if the serial cable is possibly causing issues as that's my number one bug report

- fix some cases where packet checksums are not used, i want to audit some of that code, im concerned some flash routine sections might be affected so my retry code might not be used where intended

- bugs where pressing ok without a selection crashes the thing in those popup search windows, i want to fix all of those

- make an old school 'brute force' connection routine which crams a ton of silence ECM and silence CCM packets for like 30 seconds then checks for connection stability, in case the other routines dont work (seems some odd configurations have bad timing and can't deal with the new advanced routines, especially with b-bodies, so old versions that did use more simple methods are still in use)

- the file save location bug in windows 10 which is also a mystery, i don't understand it yet but i do use windows 10 now so i'll probably chase it down

[kur4o]

i might also be interested, if i cant incorporate all the cool stuff, in posting your modified version on the eehack page as an experimental and more advanced version, if you're ok with that... but i'd want it "forked" and named something else like eehack-kur4o with different versioning so people dont get confused. there's nothing wrong with a fork at all.



I don`t mind if you add it to the side. Actually I have been thinking about asking you to make an installer package for a long time. Now it is some time confusing to use it.
You can transfer whatever you like as an essential tuning tools to the official version, or make a 2 part patch, basic logging patch and more advance tuning patch.

The core of the latest patches don`t affect any logging capability, I only added some 2-3 bytes of info to the datastream but that is really not essential to the patch itself and can be ommited.



Some of the cool stuff I have been thinking is
-an instant fuel economy display.
-mode 4 playback.
-Auto MAF tuning with wideband.
-Auto VE tuning with wideband.
-I know it is been talked about but if it is possible to add some improvement on the graph window, like 2 more graphs and a cursor showing the current value of the chart[It really makes looking at graph much more easier].


I know the list could grow up pretty quickly.
Here is the latest source I found on file with the def file to use with the patch. I see that bytes 34,35 and 55,56 on mode 01 msg 01 are changed, also improved the labels of mode 01 msg 03


Testing serial cables will be a feat. I had one that can log and read without problem. When it tries to write, the flash starts good only to fail after about 2000 bytes. Possible cause overloading or overheating. Another one i hard modded[made 1 from 2 damaged, soldering was a nigthmare] works only at lower rates. It quickly errors on full speed and the built in safety speed lowering feature saved me from chips programming.

Number one reason for failed flashes is noisy, crap PC power supplies, bad grounds on the car side also plays major role. And of course there are some mystery cars where flash always fails no matter what you do. I am still struggling with one v6 car to make it possible to flash in car, and still have no clue where it fails.

[steveo]

-I know it is been talked about but if it is possible to add some improvement on the graph window, like 2 more graphs and a cursor showing the current value of the chart

i could do a rewrite of graphing so you could add any number of graphs. might be a good idea. i usually had the dashboard open too so it shows the value in there, but i'll think about just adding it to the graph window...


Testing serial cables will be a feat. I had one that can log and read without problem.

yeah you're probably right, but since they're loopback cables, writing random chars as fast as possible at 8192 baud and looking for echo errors might be a good start

[spfautsch]

Very excited to see you're planning to code on this again!

Please don't take this as a complaint steveo - I've got a dozen irons in the fire, but after several years of use probably have 3 dozen things I'd love to improve / help improve / standby and watch while someone else improves - in eehack. I wish I could say I'm just as capable of tweaking / fixing them as you are, but after working on some things in trimalyzer I quickly found that your code methodologies are so much more evolved I'd just be creating spaghetti for you to untangle.

Before I go on I should drop in the qualifier that I just (i.e. literally a couple hours ago) got my car to a spot mechanically where I think I might actually be able to drive it and finish the diy-ltcc project this year. So that's my primary focus. But eehack is and always will be the most important tool in my tuning toolbox.

But... one thing that I ran into while playing with my newly installed wideband is that the codebase I'm running that I got from kur4o a few months ago (shows v4.90) is that the cylinder balance test crashes the app for me immediately. Not the end of the world, but it's a lot easier to click one button in the test screen than to do all 8 cylinders in sequence from the control window.

Another feature I'd love to have is the option to display / analyze wideband data in units of lambda instead of AFR. No fuel we can buy these days burns at a stoichiometry of 14.7:1. I know it's a simple correction of 8% or whatever for E~10, but I'm a little bit OCD and would rather see units of lambda since that's what oxygen sensors measure. And if you want to get "crazy" about it I can go on about reading from a fuel composition sensor (aka flex-fuel) to find out what stoich should be.

Another thing I started to implement and then pulled the chute on was while logging to tie the spacebar to a function that would record audio from the pc microphone for [N] seconds so when my car does something funny I can blindly slap the spacebar and record an audio note to help me find the anomaly in the log (because the .wav file will be stored with a filename matching timestamp?)!!! :-)

Just the ideas at the very top of mind - I've had dozens more, at least half of which I'm sure other folks would find useful. To be honest I haven't even read the entirety of this thread but I will attempt to catch up once I have a car I can drive 30 miles without stopping to check for pushrod relief holes. :-D

[steveo]

Please don't take this as a complaint steveo - I've got a dozen irons in the fire, but after several years of use probably have 3 dozen things I'd love to improve / help improve / standby and watch while someone else improves - in eehack. I wish I could say I'm just as capable of tweaking / fixing them as you are, but after working on some things in trimalyzer I quickly found that your code methodologies are so much more evolved I'd just be creating spaghetti for you to untangle.

evolved!?

a lot of eehack is pretty spaghetti-like, that's what happens when you're learning new stuff while writing a major project..

this will definitely be a bit more of a bug fix release, definitely wont be adding a ton of new stuff.


But... one thing that I ran into while playing with my newly installed wideband is that the codebase I'm running that I got from kur4o a few months ago (shows v4.90) is that the cylinder balance test crashes the app for me immediately. Not the end of the world, but it's a lot easier to click one button in the test screen than to do all 8 cylinders in sequence from the control window.

kur4o made quite a few changes, his program is a fork, not an update. honestly it should have been renamed rather than just bump the version number up to avoid confusion, at this point it's a bit of a different code base. if official eehack also crashes i'd be into fixing that..

i'll be updating the official eehack only


Another feature I'd love to have is the option to display / analyze wideband data in units of lambda instead of AFR. No fuel we can buy these days burns at a stoichiometry of 14.7:1

i can manage that, but have you tried simply modifying the definition file? (totally untested but might work)

i'll think about adding a switch in preferences like i did for metric/imperial.


Another thing I started to implement and then pulled the chute on was while logging to tie the spacebar to a function that would record audio from the pc microphone for [N] seconds so when my car does something funny I can blindly slap the spacebar and record an audio note to help me find the anomaly in the log

marking log timestamps quickly is something i also thought about and then completely forgot. that's a really useful thing for sure. i might be able to add something quick for that, recording audio is a twist i never thought about.. i was figuring hitting a button or whatever would just flag a timestamp, and you could easily see those in the graph or jump to them in the dashboard. i might not get around to that.

[steveo]

more actual to-do stuff:

- add delay timer to flash routine (flash sometimes fails if you do it too quickly after connecting)

- investigate inability to save bin being read

- add lambda units option to preferences for wideband readout

[fbody_Brian]

Nice!

I'd definitely like to try out an update. I have not had any issues with the version I am using currently though.

As long as I can get it to compile on linux! sources available still, right?

[spfautsch]

kur4o made quite a few changes, his program is a fork, not an update.
...
i'll be updating the official eehack only

No worries.


have you tried simply modifying the definition file? (totally untested but might work)

As in adding a multiplier to the field i.e. 0.068027211? Doesn't seem to have any effect when I look at a datalog.


i'll think about adding a switch in preferences like i did for metric/imperial.

That, or an option in the wideband config to allow the user to directly modify the conversion formula. Or just a preset with N / 2.50.

Thinking about this makes me curious how the target afr is derived. That's a patch no?

[babywag]

evolved!?

a lot of eehack is pretty spaghetti-like, that's what happens when you're learning new stuff while writing a major project..

this will definitely be a bit more of a bug fix release, definitely wont be adding a ton of new stuff.



kur4o made quite a few changes, his program is a fork, not an update. honestly it should have been renamed rather than just bump the version number up to avoid confusion, at this point it's a bit of a different code base. if official eehack also crashes i'd be into fixing that..

i'll be updating the official eehack only



i can manage that, but have you tried simply modifying the definition file? (totally untested but might work)

i'll think about adding a switch in preferences like i did for metric/imperial.



marking log timestamps quickly is something i also thought about and then completely forgot. that's a really useful thing for sure. i might be able to add something quick for that, recording audio is a twist i never thought about.. i was figuring hitting a button or whatever would just flag a timestamp, and you could easily see those in the graph or jump to them in the dashboard. i might not get around to that.

I think it's great you're working on updates.
I suggest keeping the versions separate. or possibly an advanced option to enable/disable them and patches if including changes?

Tried Kur4o version a while back and whenever I tried to use the cool additions my engine would just shut off.
The patched .bin almost made me fail smog testing as well. During testing the engine kept just shutting off.
Guy let me retest for free, went home flashed a non patched .bin and it gave no problem 2nd time.
It's my DD so can't have that or troubleshoot why it kept just shutting off.

[steveo]

No worries.



As in adding a multiplier to the field i.e. 0.068027211? Doesn't seem to have any effect when I look at a datalog.



That, or an option in the wideband config to allow the user to directly modify the conversion formula. Or just a preset with N / 2.50.

Thinking about this makes me curious how the target afr is derived. That's a patch no?

the target AFR is a patch, yeah. kur4o found out where in memory it was being stored and i modified the factory datastream over something useless (actually it's for the rarely-implemented EGR position, but no dataloggers ever read that anyway)

[steveo]

I think it's great you're working on updates.
I suggest keeping the versions separate. or possibly an advanced option to enable/disable them and patches if including changes?

Tried Kur4o version a while back and whenever I tried to use the cool additions my engine would just shut off.
The patched .bin almost made me fail smog testing as well. During testing the engine kept just shutting off.
Guy let me retest for free, went home flashed a non patched .bin and it gave no problem 2nd time.
It's my DD so can't have that or troubleshoot why it kept just shutting off.

that's why i only make really conservative changes to eehack's official version. i want it to be something that doesn't break your car, stop other tools from working, etc., and if i don't fully understand how something works or its implications i wont put it in

i definitely will never merge the two, lots of programs have a 'bleeding edge experimental fork' and a 'trustworthy stable and polished' version so this is no different

[spfautsch]

the target AFR is a patch, yeah. kur4o found out where in memory it was being stored and i modified the factory datastream

Curious, does the patch do something different to plug 14.7:1 in when in closed loop or is it simply reading the same target AFR byte from memory? The reason I ask is b/c I'm likely going to change the closed loop AFR (along with all the base AFR tables) in the tune to match the fuel.

[steveo]

nope it just reads the byte from memory

if you change the target it should read properly

[kur4o]

Some of the most annoying stuff I have found, that might get better.

Opening multiple log files or importing them. Now it is one by one.
Remember some of the settings. Com port, Log folder, Bin folder.


AFR target will affect only the trims. Pcm will remove more fuel, since it gets its data from 02s sensors and finds the fuel stoich from them. Bad news is that the stoich of etanol blended fuel is not the stoich the 02s are set for and at 14.2 they will be deep into the rich side. The 02s can read reliable only at 14.7 which will be around 0.454mv.
At 14.2 you will be at 0.700 range.

The afr target read by the patch is the afr target the pcm is currently using. At closed loop it is always 14.7. At open loop it gets it from the OPEN loop AFR table.
At power enrichment it is percentage taken from the closed loop target. If you change the closed loop target you will have to fix the PE tables also.

[hbomb2k]

Maybe this is a bug that needs to be fixed for the 2019 update ??? Or maybe I am just a noob.

I am a new tuner and I have really been looking forward to getting into the EEHack and getting to work. Unfortunately I have an error.

Here is my log:

EEHack Version 4.70
Current OS : Windows 10
Built with THROTTLE_MS=2
Opened serial port COM7 Description USB Serial Port MFR FTDI
START SILENCE ROUTINE
SERIAL: WAITED_TOO_LONG in serial_read_packet
SERIAL: WAITED_TOO_LONG in serial_read_packet
START SILENCE ROUTINE
SERIAL: WAITED_TOO_LONG in serial_read_packet
SERIAL: WAITED_TOO_LONG in serial_read_packet
START SILENCE ROUTINE
SERIAL: WAITED_TOO_LONG in serial_read_packet
SERIAL: WAITED_TOO_LONG in serial_read_packet
START SILENCE ROUTINE
SERIAL: WAITED_TOO_LONG in serial_read_packet
SERIAL: WAITED_TOO_LONG in serial_read_packet
START SILENCE ROUTINE
SERIAL: WAITED_TOO_LONG in serial_read_packet
SERIAL: WAITED_TOO_LONG in serial_read_packet
START SILENCE ROUTINE
SERIAL: WAITED_TOO_LONG in serial_read_packet
SERIAL: WAITED_TOO_LONG in serial_read_packet
START SILENCE ROUTINE
SERIAL: WAITED_TOO_LONG in serial_read_packet
SERIAL: WAITED_TOO_LONG in serial_read_packet

Not very experienced with serial communication protocol so I don't really have much to add.

Other than that my cable works perfect with Scan9495

Really excited to get into tuning but I really need a hand figuring this out. Thank you all.

[lionelhutz]

Bad news is that the stoich of etanol blended fuel is not the stoich the 02s are set for and at 14.2 they will be deep into the rich side. The 02s can read reliable only at 14.7 which will be around 0.454mv.
At 14.2 you will be at 0.700 range.


O2 sensors read rich/lean or above/below stoichiometric. They have no clue what the fuel is and will switch at stoichiometric no matter what AFR stoichiometric occurs at. Used on E85 they would switch above and below .45V at around 9.7AFR just like they do it at 14.7AFR for straight gasoline.

That's why you often hear of lambda. If you set the AFR meter to display lambda then you always have the perfect AFR when lambda is 1. A lambda around 0.9 is a good place to begin for power enrichment.

If you set the AFR meter to display 14.7AFR when lambda=1 then you have the "perfect" stoichiometric fuel ratio when the meter displays 14.7 for straight gas, E10, E85 or any other fuel mix and it would be wrong to try to tune so the meter displays the proper AFR for the fuel in use.

[spfautsch]

kur4o, I love you like a brother, but you just made my central nervous system segfault.


AFR target will affect only the trims. Pcm will remove more fuel, since it gets its data from 02s sensors and finds the fuel stoich from them.

This is essentially a true statement. Oxygen sensors tell the ecu when the combustion process is at stoich. Stoich = 0.454v. Agreed?


Bad news is that the stoich of etanol blended fuel is not the stoich the 02s are set for and at 14.2 they will be deep into the rich side. The 02s can read reliable only at 14.7 which will be around 0.454mv.

I think this statement is a bit misguided.

A nernst cell a.k.a. oxygen sensor measures the concentration of oxygen in relation to the other gases in the exhaust stream. Stoichiometric combustion is stoichiometric combustion, whether you're burning nitromethane, methanol, ethanol, gasonline (aka iso-octane), gasoline-ethanol blends, or even coal. It identifies the complete conversion of all the carbon, hydrogen and sulfur components into their fully oxidized counterparts (CO2, H2O, SO2).


At 14.2 you will be at 0.700 range.

That statement is true if and only if the fuel being burned is pure iso-octane. However, if the fuel being burned is a blend of approximately 10% of oxygen carrying ethanol and 90% iso-octane a.k.a gasoline, at roughly 14.2:1 air to fuel you should still be at 0.454v because that's stoich for the mixture of fuel(s) being burned. Now I will concede that this isn't an accurate description of what pump gas is generally composed of, but that's a subject for a whole other discussion. Additives have their own stoichiometry, some of which are quite far from what we'd commonly consider to be a fuel-like substance.


The afr target read by the patch is the afr target the pcm is currently using. At closed loop it is always 14.7.

I would hope at closed loop it is at whatever values are stored in the "stoich afr target" table.


At power enrichment it is percentage taken from the closed loop target. If you change the closed loop target you will have to fix the PE tables also.

Yes, that's a beautifully correct assessment. In that statement you can replace the word "percentage" with "lambda". Which is a measure of how far from stoich the combustion process is.

[roachjuice]

I’ll definitely download this and give it a shot! I love EEHACK!

[steveo]

Some of the most annoying stuff I have found, that might get better.
Opening multiple log files or importing them. Now it is one by one.
Remember some of the settings. Com port, Log folder, Bin folder.

damn i was sure i made it so you could drag/drop logs onto the dashboard window, and select multiple files in the log loading window. maybe i'm thinking of trimalyzer. that'll be an easy fix.

com port should always be remembered, i thought the log folder and bin folder was too, i'll have to check into that

[steveo]

kur4o i lost the thread where we discussed the timer that's preventing flash from working, what did you say, was it 10 seconds since last ECM reset?

[spfautsch]

Sorry to butt in but I experimented with it after kur4o mentioned the delay and 10 seconds [edit: after key on] gave 100% success.

Anything on the flash window was effected (read and write).

[steveo]

butt in all you want: that's great it works. i plan to just figure out how long since last connection was made and use that (so if you've already been connected for 10 seconds, it wont delay anything)

anyway fast is a goal so if it's less than 10 seconds i'd like to know too


Remember some of the settings. Com port, Log folder, Bin folder.

kur4o i cant reproduce the problem where the log and bin folder isn't remembered. i put it in 'settings' so it's locked to a single value, that way if you go check out a log from a different directory, it'll still go back to your main log directory afterwards. i liked it better that way.

want more details about com port not being remembered

[steveo]

Stuff i did fix today:



- Fix hard crash when selecting custom dashboard parameters
- Code cleanup to fix compliation with newer QT versions
- Ensure checksums are actually checked
- Fix a bug that causes flash write to fail sometimes (initial connect timer)
- Allow multiple log selections in the load log dialog

[spfautsch]

anyway fast is a goal so if it's less than 10 seconds i'd like to know too

I agree, faster is always better. If you lack a test mule / testbench PCM I would be happy to test it extensively when you put the source tree up.


want more details about com port not being remembered

This is the only "wierdness" I've also experienced, and I attribute it to the usb cable being unplugged (or the usb>rs232 adapter otherwise "removing itself") while eehack has a handle open to the port (device node in my case's technical parlance). But keep in mind I'm running on linux so a vastly different com port abstraction layer is in place (/dev/ttyUSB0 is my first com port, thank you Linus). What I've seen is that the program holds the device node file lock after the device has been removed, so when the adapter "magically" reconnects the kernel creates it with a different port number (/dev/ttyUSB[1/2] in my case). I've learned to live with it however, so not worth much effort on my account.

I feel dumb to ask but was there ever a function in the kur4o fork where it was possible to switch the MAF disabled bit on and off without a reflash? I asked about this several years ago, and I've just started to do some tuning and realized I don't see it on the control window. That would be "the shiznit"".

[kur4o]

I just checked the timer and it is $64 cycles before it expires. $64=100 * 100ms[my guess]=10 seconds. The timer is also reloaded when the pcm returns to normal communication, mode 00. At tside the timer is at byte_2a6 memory location. It can be logged for extra precision. It expires when it reaches zero, it is a countdown timer.

I never realized that you can specify a log/bin folder in the settings. I was under impresion it will remeber the last open folder.
Now on the comm port. Whenever I open eehack it always goes to comport 10[ I have some bluetooth coms never used and are alot]. It doesn`t remember the last used com port when the program is closed, always goes to 10 at startup and have to be set manually each time when the program is started. The comports starting with double digit are always on top, my current order is comms 10,11,12,13,14,20,21,40,6,7,3. Not sure how they are sorted but definitely not numerically.

[spfautsch]

I have some bluetooth coms never used and are alot]. It doesn`t remember the last used com port when the program is closed, always goes to 10 at startup and have to be set manually each time when the program is started. The comports starting with double digit are always on top, my current order is comms 10,11,12,13,14,20,21,40,6,7,3. Not sure how they are sorted but definitely not numerically.

This, in a sentence (several actually) is a great synopsis on why I refuse to run anything other than linux on my bare metal. When I plug a usb>rs232 device in, and there are no others connected it's always created in the device tree as /dev/ttyUSB0 regardless of what USB port it's connected to, etc. VirtualBox is your friend when you "need" to run something on Winblows.

[kur4o]

I feel dumb to ask but was there ever a function in the kur4o fork where it was possible to switch the MAF disabled bit on and off without a reflash? I asked about this several years ago, and I've just started to do some tuning and realized I don't see it on the control window. That would be "the shiznit"".

It is there a green button labelled SD mode between fuel and spark controls. If you are running speed density it will be labelled MAF mode. The patch takes the VE/MAF settings from the bin you are flashing and applies the correct code.
Be warned that between switching there is a chance the pcm reads max AFGS for split second and engine stalls. Sometimes it stall sometimes it don`t. Raising the rpm prior to switching cures the possible stall condition completely.

The real "shiznit" is that I expand the patch to a momentary external switch to control VE/MAF mode with a button and a led indicator. Combine that with a button to control closed/open loop and it is the first step to modes control knob for different driving situations.
I still need to make it remember the last used mode on ignition off.

[kur4o]

If the timer hasn`t expired the pcm will response with 02 00 to mode 0d request.

[steveo]

ahh perfect. ive seen that in logs never knew what it meant.

[spfautsch]

It is there a green button labelled SD mode between fuel and spark controls. If you are running speed density it will be labelled MAF mode.

I'm not seeing it so I'll have to sift through the code and see what's up, maybe I have an older source tree. I'm hoping to get my ve tables remapped over the weekend so that would be very useful.

I was going to beg steveo to include that, but it if could potentially stall by flooding maybe that's not a great idea for eehack-stable. I found with big injectors, max afgs signal from the maf can cause a really nasty flood condition really quick.

steveo I had the pleasure of logging my commute today and thought of a couple minor things I'd added but might not have gotten to you back in 2017.

* if it isn't already, would it be possible to make the knock count field the same size as the others on the dashboard?
* could you add the frame # or timestamp to the mouseover info of a knock event?

[steveo]

i suppose i can do that

a few things on the dashboard are going to get resized for sure

[spfautsch]

Oh, steveo. It's so ironic you would decide to do a 2019 bugfix release when I've just gotten my wideband functional. No good deed goes unpunished...

So I finally had the opportunity to do some wideband tuning on my rig. I have a nice hilly road that's scarcely traveled where I can run at whatever speed in whatever gear I want and set the cruise control so I get nice conformal bands of data at 1400, 1600, 1800, 2000 rpm - you get the point - so I can baseline my VE table. Then I go into eehack's analyzer and am rudely reminded of the fact that it's hardcoded to 500 rpm divisions. I figure I can fix this easier than build my own analyzer spreadsheet. I may have underestimated my spreadsheet skills.

Feature request: ->[you know what my feature request is for the speed-density analyzer table]<- Hell, I think most ppl would be thrilled with 0-4000 rpm because anything over that is better done on a dyno.

If you're bored, another feature request would be ability to filter on another parameter (i.e. spark advance > 10 degrees) on the wideband analysis. I'm seeing results that are very obviously DFCO influenced and would like to filter them out of the very low load cells but have no mechanism to do so.

I'm going to dive into some spreadsheet tools for a quick solution, but thought I'd make the request if you're so inclined. I know others have requested similar changes.

[steveo]

use trimalyzer. i built it because eehack has suboptimal ve analysis. i know its not 'integrated' but its a fairly minimal step to export as csv. it allows arbitrary filtering.

[spfautsch]

I'll revisit trimalyzer after I've had some coffee but I don't recall being able to use it to analyze wideband data (i.e. target afr vs measured afr). Is the source tree on github the most current code?

I had eehack sort of working using 200 rpm divisions, but couldn't get it to draw beyond rpm row 14. I guess the table needs scroll bars, etc. and I'm lazy.

Edit: Thanks. Man, does eehack ever spoil a tuner. I was almost going to whine about having to massage the data in a spreadsheet to get trim based on wb afr / target afr so it could be used in trimalyzer. Now I know what it feels like to be my classmate that lives down the street. You know the type - asks for help working on his car, and then when you're underneath it with dirt falling in your eyes and need a socket he's busy taking a phone call.

That's slick - I had missed the arbitrary input preset and had completely forgotten how universal it is.

[steveo]

I'll revisit trimalyzer after I've had some coffee but I don't recall being able to use it to analyze wideband data (i.e. target afr vs measured afr). Is the source tree on github the most current code?

it does analyze arbitrary values now, it was broken before.

you can point it at anything and it'll plot the percentage difference against a single target value, but it wont use a secondary field as a target so it wont do the actual afr vs live open loop afr target that eehack does.

it's not up to date on github. i'm starting to hate github, also microsoft owns it now. planning to delete that and just distribute tarballs. i'm a lone developer so collaborative revision control isn't really worth the time.

i'll get you an up-to-date tarball for trimalyzer later today

and i guess i'll consider making it match the real VE table in eehack, it does make sense

[kur4o]

I have never run into this issue, but might just ask.

What will happen if the cable is disconnected mid flash from pc side or from pcm side. Is there any way to recover and what is the proper procedure. I know that the flash routine will stay in the pcm ram indefinite time, but will eehack be able to resume on that condition.

I vote for a second arbitrary value on trimalyzer, value selectable or input of predefined value.

How about a user configurable cells layout on maf and ve input in eehack to match the bin table size. Adding the maf cell at the datastream is not that hard and can give very accurate trims.


If you want to add maf/ve switching and maf cell datalog I can improve the current v3 patch a little.
The maf/ve switching doesn`t flood the engine at all, I have tested thorougly. If the rpms are real low on idle it can stall 1 to 5 ratio. It just needs some time to stabilize during the input switching.

I also tested the cyl balance test on the dark magic v4.9 fork and eehack didn`t crash, so the problem lies somewhere else.

I have been thinking for more tests added. Like opti signal test at idle. Super fast logging of cyl id at idle with mode 3 command and looking for cyl id deviations. I don`t know if it is possible but at least 50 frames per second will be needed for 20ms low res period, or 100 for 10ms resolution. Did you test the limit of mode3 refresh rate.

[steveo]

What will happen if the cable is disconnected mid flash from pc side or from pcm side. Is there any way to recover and what is the proper procedure. I know that the flash routine will stay in the pcm ram indefinite time, but will eehack be able to resume on that condition.

if you disconnect the PC side, eehack will probably just freeze.

if you disconnect the cable side, theoretically, the ecm has not recieved the checksum of that packet and should discard it, never writing it. if it's connected again really quickly, it should re-send that packet.

once a few attempts have been made to re-send the packet, it'll return to the erase state and start over. it'll do this indefinitely, as far as i know. as long as the ECM doesn't reset from the programming loop for some weird reason, theoretically it should be okay

it's not that well tested, though. try not to yank the cable when programming.


I have been thinking for more tests added. Like opti signal test at idle. Super fast logging of cyl id at idle with mode 3 command and looking for cyl id deviations. I don`t know if it is possible but at least 50 frames per second will be needed for 20ms low res period, or 100 for 10ms resolution. Did you test the limit of mode3 refresh rate.

that's pretty cool for sure. actually lots of sensors could be tested more reliably with a huge acqusition rate. the mode3 is pretty fast with a regular parameter, i'm sure that'd work fine, but i never actually tested the timing.

[spfautsch]

I also tested the cyl balance test on the dark magic v4.9 fork and eehack didn`t crash, so the problem lies somewhere else.

I think you can probably disregard that bug report if it's the first you've heard it.

I've noticed all manner of strange things with what I've been using which I believe is from the zip you put in the $eehack thread here (http://www.gearhead-efi.com/Fuel-Injection/showthread.php?4956-new-EE-tuning-thing!/page70&highlight=tuning). But I routinely have about five different forks of eehack on my laptop at any given moment. Before last friday I'd never seen the MAF mode / SD mode become visible on controller.ui, so after looking at the source I did some searching and found the mode4 definition file. This worked a couple times (the buttons became visible), but when I try switching modes nothing happens. In addition I've noticed other very basic things like the play button on the datalogger window has stopped working.


if you disconnect the PC side, eehack will probably just freeze.

I've thankfully never seen this happen while flashing, but more than once I've had the usb adapter disconnect spontaneously while logging. I suspect the way the serial libraries handle stuff like this is different on windows. But with linux eehack shows a connection error and tries reconnecting while it holds a handle open to the device node. As I mentioned previously the adapter gets a new device node when the kernel reconnects to the ftdi bridge chip. I've re-connected to the new device node in eehack without crashing or restarting the program so it's theoretically possible. But I'd rather not test, thanks.

What I did to analyze my wideband data was to take the delimited file from eehack and add a calculated field to the sheet i.e. =(AM3/L3)*100 where column L is target afr and AM is my wideband. The results seem to indicate it worked acceptably.

14276

Anyway, this leads me to my next question steveo. Is there documentation regarding how to do what you were talking about with lambda in the definition file? I attempted to customize mine to add the converted ADC voltage, but it doesn't seem to be working when looking at a pre-recorded .eedata file. I guess to summarize I'd like a idiot's guide to the eehack definition file, because it seems there's something I'm missing and I think there's a lot of hackish functionality I could create there if I simply understood how it was intended to work.

EDIT: Nevermind, I think I figured it out. I can at least see lambda on the dashboard.

Reason I'm looking for this is to try and determine the stoichiometry of what's in my tank. 14.2:1 is way too rich, and 14.7:1 seems lean. I'm planning to use my MAF and wideband in open loop and adjust the target AFR to see what I can come up with. Assuming my injector flow rate and MAF calibrations are within reason it should be more scientific than trial and error.

[kur4o]

I myself have at least 20 different version and sometimes it can get really messy what works.
Anyway here is the really well latest tested version that should work better with you unless there is some linux compiler bugs thatI am unware of.

For the SD/MAF button to show and some of the other goodies, you must connect to the pcm prior to starting the enigne. It needs it once on eehack session. It is a pcm bug preventing eside to communicate while the engine is running, and some of the controller config data is extracted from eside.
For the best of all tuning experience you can test the realtime ve/maf tuning. The interface is some awkward to use but saves alot of time and reduce the flashes to a minimum.


And don`t overtrust the wideband reading. It can be really off. ALways use as a reference the narrowband voltage reading 0.454v=14.7 afr=1 lambda.

I constantly get 15-15.6 wideband afr readings on a closed loop run. The individual cyl trims can throw the afr form 12.5 to 16.5 if not properly tuned at idle. The idle tune should start with that.

[spfautsch]

Thanks, I never caught that tidbit about connecting before startup. Honestly, the control interface is very difficult to use if you have to click on controls to do things. That's why I added all the key mappings and focus reassignments in steveos version - so sliders can be adjusted with the left/right arrow keys, and things like forcing AFR can be done by pressing the 'F' key. I'm not condoning doing stuff like that while driving, but there's no way I could with your fork. Even with a mouse it would be difficult with the car strapped to a dyno much less moving. Don't take offense - the work you've done is incredible. I simply hate all software that cannot be used without a mouse. It's (the mouse) the single biggest time-waster humans have ever invented for themselves.

0.454v = 1 lambda <> necessarily equal 14.7:1

I've seen similar things in closed loop. That's why I'm giving the wideband very little attention unless running in open loop. I don't want to see the integrator oscillations, just the raw baseline fueling calcs at work.

We need to find a place to host your sources beside in posts here... or is there one and I just missed that? I just found steveo's sources on fbodytech and proudly became the first to download the trimalyzer-1.5b source. Knowing that github is owned by microsoft makes me want to pull my stuff down on principle alone, so that's out.

[spfautsch]

Hey steveo I thought of one other thing when I was flashing earlier - I know it probably is dependent on the parameter being configured in the definition file, but if it's not a huge amount of trouble it would be really informative (and for newbs maybe you can make it bark at them about bricking their ecu) to show the input voltage on the flash window.

kur4o I've been messing with the wideband with the Innovate serial logger and noticed the non-linearity of the D27 input - did putting the input on D25 improve this?

[kur4o]

I hard wired pin D25 to read injector voltage for my ls1 injector patch and didn`t have the chance to try it on the wideband input. I suppose it will be much more stable and accurate since there will be no voltage potential difference. The resolution will sucks but if you can reset the wideband to read 11-16afr = 0-5 volts it will have enough resolution. Innovate 1wire ground widebands design is bad due to using PWM modulated heater for the sensor. I did some experiments and could see the afr changing with the frequency of the PWM circuit. I also have some terrible emi noise from the gauge and used all kind of tricks to settle it down.


0.454v = 1 lambda <> necessarily equal 14.7:1

I am sure the narrowbands 02s are set to read 14.7 at 0.454v.
1 Lambda is the perfect mixture of air to fuel[cleanest combustion process] and is different for different fuels.
1 lambda equals to

Petrol 14.7:1
Diesel 14.6:1
Methanol 6.4:1
Ethanol 9:1
LPG 15.5:1

Here is good write up about it.
AFRlink (http://www.endtuning.com/afr.html)

Given this to trick the narrowbands to read lower lamda, fattening the switch voltage of the o2s upto 0.545-0.57 might give you the best results. If you fatten more it can result with poor CL performance. Some real time play with 02 swing voltage will get you to the max of deviations.


The key shortcuts for the eehack controller window are already there by your request and are working great. I had plans to expand them to more controls but never get there.

[spfautsch]

Innovate 1wire ground widebands design is bad due to using PWM modulated heater for the sensor. I did some experiments and could see the afr changing with the frequency of the PWM circuit. I also have some terrible emi noise from the gauge and used all kind of tricks to settle it down.

Was the signal stable over the serial output or was the modulation only present on the analog output?


I am sure the narrowbands 02s are set to read 14.7 at 0.454v

Sorry to have to continue to split hairs with you but no, they're set to read lambda at 0.454v. I will agree that with "petrol" that's 14.65 parts air to 1 part fuel.

The problem is here in the states the retailers are no longer required to specify how much ethanol is in the product they're selling as gasoline, and our government heavily subsidizes corn ethanol production as a "clean" alternative fuel. They aren't even required to acknowledge it's presence. Yet I can pour a cup of distilled water in a gallon of this so-called gasoline, and it magically dissolves. What is it dissolving into? Water doesn't bond molecularly with petroleum based fuels. It's why I laugh hilariously when I see people buying methanol based fuel "drying" additives.


Some real time play with 02 swing voltage will get you to the max of deviations.

I definitely want to work with this, but it will be a final finishing touch. Right now I'm painting in very broad strokes. I have a set of modified injectors that I need to find the flow constant of. They're rated at 42lb/hr, but it will barely idle with the injector constant below 42.3. It likes 42.7.


The key shortcuts for the eehack controller window are already there by your request and are working great. I had plans to expand them to more controls but never get there.

I know - wasn't belittling your work, it's brilliant. Simply pointing out that clicking some of the controls while sitting in an idling car with a lumpy cam is difficult at best.

Quick question while I'm thinking about it - is it safe to use steveo's version with the v4 patches?

[kur4o]

they're set to read lambda at 0.454v
I completely agree with this statement. Maybe we are using different terminology for the same thing.


Was the signal stable over the serial output or was the modulation only present on the analog output?


i didn`t compare it with the gauge serial datastream. I guess there will be no variation on the serial output. It Affects only the 0-5 output.

Which reminds for a past eehack addition request.

Steveo, can you add a wideband stream through a second serial port. Most of the wideband gauges have a serial output. That way we eliminate all the havock related with setting accurate reading through a 0-5v input.



Quick question while I'm thinking about it - is it safe to use steveo's version with the v4 patches?


The v4 patch is backwards compatible with all previous version of eehack. The stock mode4 message structure is intact. I added new stuff to some unused bits and extended the message on request. So is it pretty safe to use and all controls will work as expected.

[spfautsch]

Maybe we are using different terminology for the same thing.

No, you're just assuming I'm burning iso-octane when in fact it's a blend of ethanol, gasoline, and other stuff.


Steveo, can you add a wideband stream through a second serial port. Most of the wideband gauges have a serial output.

This is where I was heading. The problem is that we would have to reverse engineer the serial datastream for each vendor.


The v4 patch is backwards compatible with all previous version of eehack. The stock mode4 message structure is intact. I added new stuff to some unused bits and extended the message on request. So is it pretty safe to use and all controls will work as expected.

Thank you - I thought this was the case but didn't want to find out I was wrong at 75mph.

[steveo]

i can't imagine i'll have the time to implement and test supporting another serial port wideband input, the way eehack is written that'd be an entirely different datastream, it wasn't written with this kind of stuff in mind so it'd either be really hacky or a lot of work.

i know there's lots of stuff it'd be nice to have guys but i'm still focusing on bug fixes, i have other stuff to work on too

[lionelhutz]

I am sure the narrowbands 02s are set to read 14.7 at 0.454v.



Not one O2 or UEGO sensor made has a clue about AFR numbers. Every O2 sensor display of AFR is due to someone having programming a lambda to AFR lookup for the display.

Do you happen to mean that the PCM is programmed to interpret the 0.454V output from the O2 sensor as an AFR of 14.7:1????

In reality, the PCM will closed loop tune to the fuel assuming the base VE and MAF tables are close and the fuel stoichiometric ratio doesn't deviate too far (and BLM limits allow it). I would expect it could close loop tune to the various typical ethanol blends other than E85, it would likely tune OK in the 0-15% blend range.

[Casey96SS]

Would it be possible to add an easy way to switch off PE mode? It would be kind of convenient to do that when tuning VE tables and not have to flash a separate tune with PE disabled.

[spfautsch]

i can't imagine i'll have the time to implement and test supporting another serial port wideband input

Sorry, I wasn't implying you should do the work.


the way eehack is written that'd be an entirely different datastream, it wasn't written with this kind of stuff in mind so it'd either be really hacky or a lot of work.

I'm pretty good at "hacky". ;-)

I may attempt this for the Innovate controllers once you're finished with the bugfix release (as a fork). Offhand, how much work do you think it would entail to define an input that derives it's data from something other than the ALDL data? I'm guessing a bunch... This will probably be a good project for next winter, if at all.

Edit: hmmm, splicing another datastream into the .eedata would be really useful with my ignition controller.

In the mean time I'll have to play around with narrowing the output range of the LC2 and see how much it improves the nonlinearity.


i have other stuff to work on too

What nerve? You mean you have a life outside of writing software for us freeloading bums? ;-)

[steveo]

if you do want to do it

eehack's log format is obviously designed to differentiate between data packets based on a pair of 8 bit values, the device and the message number

so one approach is perhaps use a false device like 0xFF that'd never be used, but then make an exception in the datalogger so when device $FF is requested the request never happens, and another function is used to fill that array with data from your separate port. at least this approach would allow use of the already working timecoding, request rates, etc.

the other approach would be to maximize data rate by using interrupts from the second serial port then insert that data into the log, bypassing the existing request/response functions, conversion with the definition file, etc.. maybe even in a separate thread would be a good idea.

the ui and the datalogging are separate enough in current versions, where if you had a thread grabbing serial data, and you formed a proper log 'packet' or whatever i called it, you just have to generate a QT signal to tell the rest of the program that new data has arrived and it'll probably handle the rest of displaying, realtime graph updating, etc. without complaining

there's a bit more involved to doing it properly, such as another serial port selection area in the settings dialog (and related back end in the settings storage)

[kur4o]

Some of the innovate documents I have gathered regarding serial datastream. If the interest arise I will make some serial logs of actual communication between gauge and innovate`s Logworks3.

[spfautsch]

Unless you're willing to tackle it I wouldn't spend much time on it right now kur4o. As mentioned I probably won't have time to work on anything like this for 5-6 months.

steveo I think your first approach with the dummy device ID might be the smart way to go. I'm envisioning parsing the UEGO controller stream in a separate thread and handing the data off to the datalogger.

This is all conjecture because I've got my plate full. This week aside from trying to get my yard work done in between rain showers, I'm pulling my engine back out because the shaft mount rockers work so well that I think I've bent an intake valve.

[steveo]

just so you guys know i've been working on this a bit still in my spare time

looking back at it, i decided to spend time to redo some of the ui.

when i wrote it i just slapped some qt library fields and widgets together for a lot of the ui elements like the dashboard, but that was before i knew anything about qt ui design, so i'm going to remake the dashboard.

for example i used QTextEdit and QPlainTextEdit for a lot of output fields. QTextEdit is like a mini web browser.. so actually the dashboard is like 50 mini web browsers. you can display images, html links, and table in the packet rate field if you wanted to.

it's a testament to how good the QT ui library is that nobody has noticed

should improve performance as well as make it more scaleable/resizeable on different/newer operating systems

[steveo]

new beta please test, includes source: http://fbodytech.com/files/eehack-beta4.8.zip

here are some of the changes

Combine the launcher and datalog window as the primary window, I always liked it better that way
Major UI overhaul to fix scaling and performance issues with dashboard and other modules
.. Use more dynamic layouts in most areas
.. Analyzer and autospark not done yet, but still functional
Ensure packet checksums are actually checked everywhere
Allow multiple graphing windows to be opened at once (just click the graph button again)
Add timestamp to moouseover of each knock event in analyzer
Fix a bug that prevented the 'bad checksum' override for bin reading to fail
Fix colored field indicator operation in dashboard for high/low conditions in the definition file
Fix hard crash when selecting custom dashboard parameter with no parameter selected
Code cleanup to fix compliation with newer QT versions
Maybe fix a bug that causes flash write to fail sometimes (initial connect timer)
Allow multiple log selections in the load log dialog
Dropping github RCS so remove references to it in 'about' dialog
Fix minor bug that prevented settings from propogating to the dashboard

[Terminal_Crazy]

Hi Steveo, Just having a play.

I like the single main page. I didn't like having to move the panel to the side everytime I ran it.

I'm running it on my desktop atm as my in car laptop screen has cracked. Will that still fit in a 1024x800 screen ? (obviously i need a better laptop)
I guess it still auto connects with the ignition switched on ? That was awesome when I took it for a dyno run. I just gave it to the lads & it recorded every run.

I loaded a log and had a play.
In the graph window logged some data. opened a second one and tried to view more data. Nothing plotted in the second+ screen.
checked in the first and it displays. I've lost the 1st graph and none of the others plot any data
... Settings definition file was set to a previous version (Kur4o's) so reset that & re run EEHack. No data is being displayed

In the Analyzer window, hovering over the knock count does display the timestamp but needs reducing by1000. #5741@ 788.9 displays as 788949

I've just ordered some Speed Engineering 1 3/4 Longtubes.
Can EEHack be configured to display Dual Wideband inputs in AFR & Lambda equivalent ?
Are the input curves of the AC Pressure & D27 similar enough for this?

Playback: Fast button doesn't seem to run any faster on or off.

Excellent stuff Steveo.
Thankyou

Mitch

[steveo]

thanks i'll check that stuff out. i just noticed cpu use when in 'fast' is pretty high, im pegging your CPU, so i'll have to do some profiling. it should fit in 1024x800 ...

[steveo]

i've fixed the graphing and the knock timestamp. the higher than normal cpu use is a bit odd i'll have to play with it

[steveo]

Another quick update, this one makes the graphing work properly again, makes the UI look a bit nicer (missed a library in the last release..) but I also re-implemented the dashboard’s caching engine so processor use should be reduced dramatically. Thanks to Mitch for the quick testing. Please let me know how it works for you!

http://fbodytech.com/files/eehack-beta4.8.1.zip

[Terminal_Crazy]

beta4.8.1

Errored initially as no definition file was found. Selected and starts up ok.

Multiple graph views display data.
1st graph window displayed the posaition indicator. Subsequent windows didn't.
However, when scrolling the main window playback position slider, the graph window position indicator bars appeared & move all together when scrolling the position.

Knock timestamp works.

Playback:
cpu usage 22% on slow. 26% approx when running fast.(same as beta4_8).
Position indicator now counts about twice as quick on fast as opposed to slow.

Excellent!

Mitch

[NomakeWan]

The 4.8.1 update did indeed fix the graphing error and made it display a little better on my netbook (1366x768). It still prefers if I have "auto-hide taskbar" enabled (otherwise the VIN/CALID sections get squished vertically), but it works well with auto-hide enabled.

Aside from the functional changes I noted in my EEHack Read Fail thread (all good things), I noticed the new version has a couple of minor bugs. Carried over from 4.7, the checkboxes for "unsaved log" and "unsaved notes" under the "warnings on exit" in settings still do not do anything (the program always warns on exit regardless of this setting). I can't tell if "Save Invalid BIN" works because the read process actually fails this time before completing, but I assume it's probably working now. In the graph display, "Transmission Selected Gear" does not appear to be working properly as the graph scale isn't whole numbers, goes off the top edge, and doesn't actually appear to indicate 1st or 2nd gear. Also, it still appears that the indicator for "Transmission Perform Switch Pressed" is reversed, indicating "ON" when not depressed and "OFF" when depressed. Those are all old bugs, though.

The new bugs I noticed, most were fixed with 4.8.1, though clicking "Now" for "new version notification" results in a network error regardless of network status on both 4.8.0 and 4.8.1.

[steveo]

i'll look into that stuff, thanks to both of you for trying again. the checksum bugs were really annoying to fix so i'm glad that worked.

is the selected gear really broken everywhere or just the graphing module?

can someone else confirm the 'transmission perform switch' is backwards? it'd be a simple definition file fix but need to make sure..

[NomakeWan]

Oh, it's only the graph. It works perfectly in the datalog screen. :)

[steveo]

graphing was more for fluid floating point parameters rather than 1-4 integer stuff and you might be the first person to try to graph it (not saying its not useful to have... ) i'll see what I can do about that

the unsaved log and notes settings are fixed thanks for pointing that out. was a fundamental issue that needed fixing anyway, the code was all there, but the 'close window event' wasn't processed properly.

[spfautsch]

Compiled in QT creator 4.10 built for 64 bit Red Hat (actually running on Ubuntu 18.04) zero errors or warnings. :thumbsup:

The dashboard being the main window is a vast improvement! :happy:

The main window seems like it's picking up the wrong available desktop dimensions at startup. The auto-size makes the window larger than the available horizontal space roughly by the size of my taskbar (which is immovable and anchored to the left edge in Unity) and the main window title bar. When maximized it's similarly taller than available desktop minus the title bar. The other windows (graph, control) are sized correctly when maximized.

Even with the dynamic scaling the size of the important stuff on the dashboard is hard for this old man to see. This may be a Unity / linux specific thing. Curious to see what it looks like on windows. Maybe add a "blind operator mode" that bolds all the fonts?

It seems like all my keyboard accelerators and other ui changes were culled. :sad:

[kur4o]

Here are some screenshot with lower display resolution. ON high res displays it is much better sized and readable.
The main buttons does look a bit oversized, compared with dashboard part, maybe a row orientation will save some of the long white spaces on the dashboard fields. I know it is a work in progress and will get better and finer. Sometimes it gets rescaled in fullscreen, and little of the right part moves out of field.

The multiple graph windows can be seen at same time only if the dashboard is minimized. If not minimized you can only bring up only one graph. I now it is been talked about but bringing a small displays in the graph windows to display the current selected value in the graph window will be great. Otherwise it is all guessing or swithcing to main dashboard to see the exact value the cursor is at.
Also the graph window looses the selection when closed. It could be the result of multiple windows. If you accidently close the graph window, the selection of fields must be done again.



One other idea I had that might intrigue you is the lack of relation with the bin version and the log, and date, time stamp of the log.

Now I got this idea to stamp the name of the bin in ascii characters during flashing. Just like patch version is stamped, but it will be the name of the bin. e and t side independant. When the log is started a mode3 retrieval of the name of the bin from e and t side, and date, time can be added in the log, displaying the name of the bin the log is taken with. It is important that we don`t lose version compatabily with previous version, so you must be creative.
That way you never lose track at which bin version you got the right setting dialed.

[spfautsch]

I guess I should have attached a screencap to demonstrate also - 1366x768 is my lcds native resolution.

In terms of important screen real estate, I would suggest trying to compress the height of the playback and log management frames - lots of empty horizontal space there. Also if QT will let you I think the labels should be removed - their purposes are fairly obvious for these two frames.

14597

[steveo]

yeah sizing isnt working very well i agree

ill spend more time on it

[kur4o]

I have one cable[ I made 1 cable from 2 with different failures,soldering sucks] that always gives some errors during flashing, but the auto speed reduction helps for successful flash. A checkbox for low speed read,flash can cure most people problems with unknown cable performance. I have seen good cables to fail only when overloaded at 20-30% flashing time. Maybe they are good untill it gets too hot and freaks or the ftdi chip is some china crap.


I am sure you will nail that autoresize feature. It is only downscaling that gives some trouble, upscaling on good res display plays really nice.

[steveo]

ui design is a real pain in the ass, which is why i used QT, but it has its own problems

i really like your idea of storing the name of the bin in the bin itself. i already pull maf, auto trans, and patch level flags from memory at the same time as the vin and calibration ID, wouldn't be hard to grab a bit more data.

of course one problem is eehack sometimes only flashing one side so like you said we'd want to make that independant. obviously storing a bin ID on the e-side isn't a big deal, but do you have a way to reliably retrieve it with the engine running? i guess your e-side comms patch is enough, does it work well enough with the engine running and ECM unlocked? i haven't played with it a lot.

[mecanicus]

ui design is a real pain in the ass, which is why i used QT, but it has its own problems



I had simular problems on an other program.
It`s easier to build three versions. 14 inch laptop, 17 inch laptop and 19 inch desktop.
Highest respect for your work

[kur4o]

To get any info from eside the engine must be not running. That includes the maf bit itself. The eside gets pretty busy when runnig the engine and ignores any aldl requests.
A single connect before starting the engine can retrieve all the needed data. It will be known limitation.

The best way is to apply the bin name, date and time of flashing to both sides. If flashing only one side, it will get updated with the new bin name, anyway the unflashed side will remain the same as with the previous bin version.

I will look for free space that can be used to store the bin name. Maybe a limitation of the lenght of the name can be set. A 40 characters +date time[12 characters]

[steveo]

thanks thats food for thought. i really like your suggestions but now i have to think about implementing.
im having trouble figuring why eside stops comms with engine running as a non running engine still works pretty hard (look at all the engine parameters that still update)

[steveo]

we do have a decent free space map in the flash routine (i set a bunch to 0xFF so we can use that for whatever)

[kur4o]

ONe of the main routine[IRQ} on eside is triggered on each opti low res pulse, It doesn`t run without an active low res signal. That is still an assumption but it buggs the processor really hard. All other code is scheduled to run from some internal timers interrupts.

Eside have tons of free space. Using the last portion of the bin at FE00 will clear most of the patches from interference.

Tside is really short on free space. Some available addresses are $2004-$2014 , $3D33-$3D83, $FF84-$FF9F, These clears all the patches I have on tside so far.

If you came up with something I will be more than happy to test it.

[steveo]

here's another new installment, hope the user interface is a bit better among other things. there's still a bit to do, but hopefully i'm getting closer. please let me know

...

If you’d like to try my next attempt at EEHack’s new version, this one plays around with the user interface a bit more (the last one didn’t scale very nicely). Added a small button near the ‘about’ button that enlarges the dashboard and main interface for full screen while driving (a bad idea, of course). Also rewrote some old code related to log playback that could cause crashing in some circumstances. As a bonus, playback speed is now variable.

Please let me know how it works for you!

http://fbodytech.com/files/eehack-beta4.8.2.zip

[kur4o]

Steveo,
Can the wideband settings somehow get saved with the log file and loaded from there just for playback. If you are trying to open a log with unknown wideband setting you are screwed.

I will give it a try for the new beta and report ASAP.

[steveo]

that's a good idea, but my concern is if we're always loading that stuff from logs, if you find your wideband formula was wrong and you correct it, it doesn't affect past logs. the common use case for eehack is for a single person tuning his own cars and most people dont own two lt1s with two widebands

[NomakeWan]

Super minor, but it appears tooltips are a little broken with the new version. On just the main dash panel I found these:

Speed RPM is Coolant Temp
Speed VSS is Intake Air Temp
Idle Steps and RPM are Narrowband O2
Patch is Wideband O2
MAF/E-Side Comms/Auto Trans are Power Enrichment
Transmission TCC, P/N and all Actuators are blank
User Parameters are all Narrowband O2
Stat(us), Error Count, Acq are all blank

That’s all I’ve found so far. I still don’t have access to my Corvette so I can’t do functional tests yet.

[steveo]

ah yeah thats not hard to believe, i had to recreate all of those controls. i'll give it a once over

[steveo]

anyone else done any testing?

keep in mind i dont even have a working ECM to test this with right now so if there are any bugs and i release it....ALL YOUR FAULT

just kidding but please let me know if any remaining bugs before i release it

[NomakeWan]

I just did some runs with 4.8.2 in both of my cars. Seems to run very well. Even bothered to flip on the OBDII stuff and give that a peek, and it seems to run well too. Only bug I ran into was that it didn't want to do the power balance test due to the TPS fluctuating between 0.0% and 0.8%, but that's quite likely a problem with the TPS. Figure I'll bring it up anyway.

EDIT: Yeah, tested it on the other car and the TPS stayed at 0.0%, so it's probably just the TPS on the one car is out of adjustment. Time to fix that.

[kur4o]

The most obvious bug is the main window rescaling when in full screen, and there are parameters windows rescaling when changing color[the font size changes].
It does work better with low res displays that beta 1, but might get a little better.

I didn`t make any functionality tests, Also compiled it with 5.6.0 for greater compatability with older OSs. If you need the files and exe from 5.6.0 I will zip it for your. That way you can post a version for guys using ancient hardware.

[steveo]

if there are layout and ui issues can i see screenshots? it would really help

[kur4o]

It was the LG mode that auto rescales stuff on the ui. In normal mode it is rocksolid.
It usually happens when a parameter window changes color, after the next change of color it rescales and changes font size.


In the source code I saw special fuel economy field left but never used. Do you want to help me to make it functional with adding the proper formulas. It will be hard coded but at least working. The main issue will be to add datastream parameters in the hard coded formula. We need rpm, Lbpw, Rbpw, mph, fuel flow constant, which can be taken from datastream, user defined or bin extracted.

[steveo]

get me the formula and i can probably make it work. that’d be pretty cool.

[kur4o]

At zero mph the result will be out of range, it needs to switch to liters/hr or galon/hr{I need to revise how these are calculated and will update the post when ready}.

[kur4o]

Here is the static flow in l/hour and gallons/hour formulas.

I also added INJ dc% if you want to add that too.

[steveo]

that's some good stuff. i don't know if i'll use it in this version or not just because i want to get the thing released but i'll see what i can do

i see that the large mode is a bit of a fail, i might just leave it disabled for this release as well just so i can get it rolled out.

[spfautsch]

I'm not thrilled with what it does when maximized and the default size for me is still taller than available desktop height on a 1366x786 display. This is probably an outside case b/c I'm running Ubuntu Unity and the task bar is permanently pinned to the left edge. I don't think anything critical is getting clipped off but I'd be perfectly happy if it would maximize correctly. But for some reason it never loses the title bar like the graph window does when it's maximized, and thus is still larger than the available desktop height. I'll tinker a little with the source and see if I can find what differences there are between graph and the main ui. If I can figure that out I'll log my commute with it this evening.

It's not important, but I'm about to die without the spacebar attached to the play/pause function.

http://www.pfautsch.com/wp-content/uploads/beta-4.8.2-main-maximized-150x150.png (http://www.pfautsch.com/wp-content/uploads/beta-4.8.2-main-maximized.png) http://www.pfautsch.com/wp-content/uploads/beta-4.8.2-graph-maximized-150x150.png (http://www.pfautsch.com/wp-content/uploads/beta-4.8.2-graph-maximized.png)

[Terminal_Crazy]

Appologies for being away for a while.
Just spent a small fortune on a Thermal Spray system so I'm now able to spray Thermal Barrier Ceramic coatings.

Laptop screen cracked a few weeks ago & now it's spread across most of the screen.
Had the car in garage for a few weeks while we were away, on a trickle charger. Battery is now toasted & won't hold a charge.

So I'm unable to test at the moment until I can get these sorted.

Mitch

[spfautsch]

Scrunching the main buttons down to a height of 32 and setting the default font to 9pt got the main window to fit - the controls on it were too large to render the window maximized so it "wrapped". I noticed you removed the titles from the playback and log frames, but unfortunately QT doesn't seem to let you recover the lost real estate the title occupied.

http://www.pfautsch.com/wp-content/uploads/9pt-font-150x150.png (http://www.pfautsch.com/wp-content/uploads/9pt-font.png)

I have a similar issue on the settings window that's causing the wideband settings to get "smushed". I don't have time at the moment but possibly reducing the default font and getting rid of the update checking frame would give a bit more real estate.

I'm not sure I would classify the large mode a fail - it seems ok to me. The only problem I have is the default font size goes really small when I switch large mode off.

Update: No issues logging.

In all I think there's just a bit of polish needed for those of us with lower resolution displays. I think the temperature, speed and idle frames could be compressed to eliminate unused space, and the size of the DTC text widget reduced to give the important fields more real estate. The adaptive font scaling is a little weird at my resolution - i.e. the O2 fields are using a size smaller font than the BPW fields because of the width of the information, but the larger font looks like it would fit easily.

Also, to make the key accelerators work all that's needed is:


#include <QShortcut>

[JustinSEO]

Steveo,

I had emailed you awhile back about some logs and info from a flash routine that started to error out mid flash and the retry script went wacky on me. Not sure if you received it. I have soldered some sockets and put new chips on that ECM so will be trying to reflash soon.

Couldn't ever find out if it was the computer, the ecm or the cable. I don't think it was software related but instead of a failure it should pause in place, allow you to check connection and then start the erasing again in my opinion.

[steveo]

hey justin! yeah maybe it should be a user choice. i think knowing what i know now i could write a more robust recovery but i ditched all my testing gear. i was going for automatic and it does retry on failure but maybe a manual mode wouldn’t be a bad idea. ideally just use interfaces that are stable of course....

[JustinSEO]

hey justin! yeah maybe it should be a user choice. i think knowing what i know now i could write a more robust recovery but i ditched all my testing gear. i was going for automatic and it does retry on failure but maybe a manual mode wouldn’t be a bad idea. ideally just use interfaces that are stable of course....


What's weird is I had used the same interface many times over without issue or cause for concern on stability testing, or flashing/downloading bins. It's really a picky system.


Question: Are we still connected to the datastream during the upload? I am unsure because I cannot see it while flashing, but if we were then the Flash utility could easily grab current "state" of the car such as Ignition Voltage (which should represent PCM voltage some what) and then check if the cable is alive and give us a flag in the log or in the queue. Otherwise the manual option like you stated would be great, even if it was an advanced used setting.


I have a spare PCM or two that I am currently working on chipping and programming the chips outside of the car and I was wanting to ask about uploading one side or to one chip. If we make changes to the Engine such as spark and fueling; will uploading to the E side only work? All engine parameters are fine to change on the E side? I have to split these bins in half when I do the initial flashing and if I can get a proper flash from EEHack after with only the changes I need it could be useful for me. I wish I had finished the bench testing harness to do more with it, but I haven't had the time.

[steveo]

during flashing we have our own datastream with unique commands. the datastream you think of from logging no longer exists as the ecm is executing some custom code that is uploaded. that routine can easily get values from ram to check battery voltage or whatever... but also the routine tends to error out if battery voltage is low. other flashing programs might do a better job than this. there is no need for a special “is cable alive” routine as that’s pretty obvious based on whether the ecm is responding to each chunk of data

you can totally upload only one side in fact eehack will do this automatically based on comparing your new bin to the last one uploaded. it requires you not modifying the original bin. this is just so flashing is optimal and you dont have to worry which side you’re modifying.....you can just check or uncheck the boxes yourself to do that manually

[steveo]

by the way for initial programming to socketed chips splitting a bin wont work. the address lines are scrambled so your programmer’s view and our view of the raw data are quite different. look in the original $ee thread on here and there are some starter bins, then flash from there to your custom bin

[NomakeWan]

I just noticed this today since I accidentally flashed my '95 with "Patch Bin" checked in EEHack and ended up using Speedlog. With Main streaming disabled and Speedlog streaming enabled, the resulting eedata file does not get read by the "Analyze" button in EEHack. It works fine when you export CSV and open that CSV in Trimalyzer, of course, but I just thought it was odd that EEHack couldn't use its own specific data.

I absolutely freaking love how fast EEHack's flash routine is. I'll take 40 seconds over 3 minutes!! Good lord I have got to figure out the comms issue on my '94 so I can use EEHack instead, it's so much better...

[steveo]

it was working before can you please send me that log??

[steveo]

the flash routine was fun to speed up

kur4o and i verified some regions that weren’t actually used for anything so i just don’t write those, and they get set to 0xff by default.

then i played with only flashing one side at a time if you only change one side

finally some timing optimization to see how hard i could push the ecm without sacrificing reliability and also not load the host cpu or anything

i bet i could do better if i still had a test bench going

might build another

[roachjuice]

Is it Necessary to check the “EEHack patch” when flashing to take advantage of speeding up a flash?

[steveo]

nope. patch has nothing to do with it. skip unused regions does save some time

[NomakeWan]

Sure thing. See attached. I also noticed that the Graph function doesn't work either. This log was created using 4.8.2 and was read using 4.8.2. I've been using that version exclusively since it came out (because I was mostly working on the '94 which had read error issues that the beta fixed).

[roachjuice]

nope. patch has nothing to do with it. skip unused regions does save some time

Ah gotcha. Thanks. I assume this Is on the new beta one right? I’ve seen it on the older version and it took about 40 seconds a side. Which isn’t bad honestly.

[steveo]

the new beta doesn't have many changes to the flash routine at all

[NomakeWan]

nope. patch has nothing to do with it. skip unused regions does save some time
Speaking of unused regions, how much available space is there left 'empty'? How much headroom did the engineers give themselves on the ROM space?

Great job between you and kur4o on the flash routine, I was blown away the first time I flashed a change. Might have to bust out an oscilloscope and figure out a way to rig it into the ALDL on the automatic car, I'm so desperate to figure out what's wrong with it LOL

[steveo]

there’s quite a bit of unused space definitely enough for some 3d tables but the problem i always had was most of it is on the wrong side.

[steveo]

Sure thing. See attached. I also noticed that the Graph function doesn't work either. This log was created using 4.8.2 and was read using 4.8.2. I've been using that version exclusively since it came out (because I was mostly working on the '94 which had read error issues that the beta fixed).

wow there is definitely some kind of issue. did you notice that the warning indicators on the dashboard go crazy when your speed log is playing back?? i can't find the cause of it yet. there is a lot of ugly code in the datalog and also datalog definition parsers and handlers.

[NomakeWan]

I noticed it but ignored it since this was the first time I had used the Speedlog function, so I just thought that using Speedlog altered how the Dash worked or something like that.

Best of luck. As always, if there's anything I can do to help, just lemme know and I'll get on it. Due to issues with my daily driver I've switched to daily-driving the '95, so I can log just about anytime.

[steveo]

the whole thing is a mess so there’s probably a single bug somewhere

the whole thing with eehack is it was designed to have different data sets for different patch versions. that way when a patch alters the datastream the program is aware of it and can conditionally load the different definitions in the datastream.

its supposed to be robust enough where logging an old patch with a new eehack will be seamless if something big came up

something is causing the “new patch version recieved” callback to not reach the modules or maybe the modules arent handling it properly

your log definitely has the patch version correct

its just odd since i haven’t changed anything related to that in the new beta

was it working with the last stable version??

[NomakeWan]

I never tested it with the latest stable version. I'll test that for you on my commute tomorrow.

[steveo]

i've found two of the problems and the dashboard and extended log windows are now working as intended

the graph window actually does work as intended but it is multi-message aware and you need to actually select the obdii/speedlog data set to graph it. i know this is a bit inconvenient and people have asked before that the data seamlessly gets pushed into message 1's datastream but that's just how eehack is designed to work with the multiple messages, and the ability to define those things separately is invaluable for people that want to further hack the datastream (also allows people to stream the obd-ii data if they wanted to, and if the patch is not installed). if you add any 'custom parameters' selecting the correct datastream is also important.

the analyzer isn't fixed yet, not sure whats up with that, it's supposed to be like the dashboard and use data from either message automatically.

[steveo]

fixed the analyzer, it was some botched code...but that means it must have been broken in the last version too and nobody said anything. which leads me to another question, does anyone even use speed logging except this one guy?? i'm disapointed, it's one of my personal favorites

anyway thanks for finding those bugs. i have to work on the analyzer a bit now, the ui isn't really acting like it should with some recent changes. i'm starting to really hate ui design

[kur4o]

I guess nobody noticed since the average guy didn`t know if it is normal behaviour or some form of limitation, including me.
One more problem is e-side playback logging doesn`t work, you get no definitions available instead of the data. Since it doesn`t work with engine running anyway I didn`t want to bother you.

I was planning to modify the speedlog message while tuning some startup issues, but never got into that. I want to remove some stuff from the message and add add some other and make it much shorter than it is, and shooting for 30-50 frames per second. I also wanted to ask you about it is realtively safe to do it and how the data is parsed into the dash window. Does it need to have in the datastream message all the dashboard fields populated and defined or I can skip some of them like idle, baro, blms.

[rharris]

Hi Steve,

I am new to the eehack program and apparently new to this computer. From what I see so far it looks like a master piece for LT1 owners, thank you! I have loaded the program on my computer but it will not run, the program does not recognize the USB port. The cable was recently purchased from OBD diagnosics for my application. I have a 1994 corvette so it is a unique cable with a USB port, not a seriel port connection. The program comes up but when I try to connect it gives me an error. The program does not recognize the serial port and gives none as an option in settings. I am retired and left the computer world years ago so please make it simple. What am I doing wrong?

Thank you,
Rich Harris

[kur4o]

Hi Steve,

I am new to the eehack program and apparently new to this computer. From what I see so far it looks like a master piece for LT1 owners, thank you! I have loaded the program on my computer but it will not run, the program does not recognize the USB port. The cable was recently purchased from OBD diagnosics for my application. I have a 1994 corvette so it is a unique cable with a USB port, not a seriel port connection. The program comes up but when I try to connect it gives me an error. The program does not recognize the serial port and gives none as an option in settings. I am retired and left the computer world years ago so please make it simple. What am I doing wrong?

Thank you,
Rich Harris

Start troublshooting with the most obvious. Check if the device is installed properly. Open device manager and see if there are any available com ports. If non are present it might be a driver issue.

[NomakeWan]

Hi Steve,

I am new to the eehack program and apparently new to this computer. From what I see so far it looks like a master piece for LT1 owners, thank you! I have loaded the program on my computer but it will not run, the program does not recognize the USB port. The cable was recently purchased from OBD diagnosics for my application. I have a 1994 corvette so it is a unique cable with a USB port, not a seriel port connection. The program comes up but when I try to connect it gives me an error. The program does not recognize the serial port and gives none as an option in settings. I am retired and left the computer world years ago so please make it simple. What am I doing wrong?

Thank you,
Rich Harris
What kur4o said is correct. The most likely answer is that you do not have the correct driver for the cable. The cable is intended to use FTDI's VCP (Virtual COM Port) driver. If your system mistakenly installed a non-VCP driver (such as a D2XX driver), that means it's not exposing a COM Port to the system, which means $EEhack won't see it either. Please make sure you're using the latest VCP driver from FTDI, which can be found here: https://www.ftdichip.com/Drivers/VCP.htm


steveo,
I would've noticed the bug in 4.70 had either of my cars been patched, but as you recall the whole comms error thing on my '94 had me too spooked to use the flashing function in $EEhack. It was only once those problems started getting ironed out that I had enough confidence to try it on the '95, which led to finding the bug. I did go ahead and get a log for you on 4.70 regardless, and indeed, it works fine (except the analyzer, as you found out). I also noticed the message selection thing when testing graphing, but I guess I never spotted it in 4.8.2. That's my bad. I've attached the log just for completion's sake.

To be honest the only non-bug-related suggestions I could provide for features would be potentially rolling real-time analysis in, and having patches be individually selectable (for instance, if I want speedlog but not E-side comms). By real-time analysis I mean something like what tuning suites like Crome or Hondata have, where you can sit on a dyno with the laptop plugged in and work through your cells by changing throttle and load and watching the O2s. The Analyzer/Trimalyzer do this after the fact once data is collected, but I wonder if there's a way to have a realtime graphical representation so that you know when you have sufficient data collected to make cell adjustments?

Just thinking out loud. As I've said tons of times before, I love this program even as it is. :)

[steveo]

i could do realtime analysis but id rather you just hit the analyze button. it will work with the car running wont it? imo real tuning either happens at home sitting at a desk studying the data......or with an emulator

[NomakeWan]

Sure. But for example, say you have hundreds of records for a few cells and then...less than 70 for others. Less than 10 for still others. You won’t find that out until you analyze the data, then have to go try again. Some sort of visual cue for when sufficient data has been gathered for particular cells would be helpful for doing that analysis at your desk later, at least from my perspective. Similar to the map tracing functionality in other programs, I suppose, but tailored to how the Analyzer/Trimalyzer handle data to provide VE/MAF changes. Though since wideband O2 is accepted as an input, there’s no technical reason why wideband map tracing couldn’t work too, as many other suites do.

I do think there are lots of folks with dynos who would disagree with the assertion that you need to sit at your desk or bust out an Ostrich to do “real” tuning, though. Especially since I don’t know a good way to plug my Ostrich into a ‘95 LT1 PCM. ;)

[kur4o]

NomakeWan,

data tracing is really not possible due to pcm limitation. If the eside didn`t stop talking with the engine running alot more could have been made.

For now the extended version of eehack gives realtime control for any load dyno situation you have and for sure you can nail the tune in less than an hour with the real time VE table and Maf table control, add to that spark and fuel control and you can perfectly dial the engine with no analysis tools but only accurate wideband input.

By load dyno I mean the ability to set the engine running at 2000rpm and 90kp map for example, first adjust the ve cell at that range than adjust best spark advance while playing with the fuel and watch for the dyno output to get the best settings.

For the extended version of eehack search for a thread called the ultimate $EE patch thread.

[NomakeWan]

Oh, I believe it. But after seeing how the Analyzer/Trimalyzer work, it should be possible to create a pseudo-map-trace that is merely a visual representation of the MAF table or VE table, perhaps with colors for cells indicating at a glance whether that cell has sufficient data points to use for later analysis. Drive around as normal, logging the whole way, then glance and see if there is anything specific that was missed while still logging. Take care of those cells, then go ahead and run the analysis as normal.

[steveo]

ah, so what you're asking for is some kind of overview that tells you which areas of the log have enough data coverage. that could be useful. i just got confused because you asked for realtime analysis in the same sentence. that data is in trimalyzer (hover your mouse over a cell) but it's hard to overview in its current form.

i started working on the analyzer a bit last night and i was struggling with it a bit, it was written really poorly. i wonder if i should just rip the analyzer right out and embed trimalyzer in its place (does the eehack analyzer do anything cool that trimalyzer doesn't...?)

[spfautsch]

I really like the basic CL Performance tab, and the idle average data on the Cruising AFR tab. Gives me an idea of how the CL routine is working and where trims are at a quick glance.

I also frequently look at knock events and then jump to that timestamp in dash to try and figure out what was happening around the time of the knock. In fact I would love to be able to double-click a knock event and have it jump to that point automatically like the graph does.

[steveo]

In fact I would love to be able to double-click a knock event and have it jump to that point automatically like the graph does.

in the context of a graph jumping to a timestamp makes sense since it's always viewing a single log...

...but the knock timestamp is already a bit faulty in that the analyzer can be either in the scope of a single log or multiple logs. if analyzing multiple logs the timestamp becomes meaningless.

i guess i could jump to the current record within the range of the current log and if it's in another log it's the user's problem, or if it's outside the range of the current log it'll just not do anything, but i hate being misleading (the timestamp is already potentially misleading).

to do it properly we'd need to make each data point aware of which log its from and then switch to the correct log when jumping to that point, but that's needlessly complex and we'd need a system to switch to arbitrary logs avoiding all the potential crash points in doing so

maybe a simpler solution is to make the analysis contain knowledge of whether it was generated from multiple logs or not, then disable things concerning timestamps subsystems if it was.

[steveo]

i should mention since we're talking about the knock analyzer, i was struggling to make the analyzer scale to different window sizes, so i went ahead and transplanted trimalyzer's knock analyzer into the next version. it was originally based on eehack's knock analyzer, but it's faster, has less rounding errors, scales for window size, labels inside the grid, etc

i did add the extended tooltip per knock point data from eehack back in since i thought it was a bit nicer, since it has timestamp data it does counts per millsecond rather than counts per point (a more useful metric since the gap between knock count increments is arbitrary and has a huge potential effect on event magnitude) also merged the color coded WOT/non-WOT points.

i think y'all will like it

[spfautsch]

I realized all those limitations when I added the timestamp to the knock events, and have encountered plenty of instances where I've suffered the wrath of said laziness.

I wouldn't over-complicate it - if it's easy to do just make it jump to the point in the log that's currently selected on the dashboard. The user can figure out whether or not it's the right log. And if the timestamp is greater than the length of said log do nothing. Or, just ignore this whole idea since it's kind of a nitpicky request.

[NomakeWan]

I'll also add that I like the PE analyzer in EEHack, so that's another thing it does that Trimalyzer doesn't. Just to glance at and make sure I'm good until I get a wideband and it becomes even more useful.

Good stuff on the knock analysis! Can't wait!

[steveo]

trimalyzer can totally do that too. just use o2 voltage as an arbitrary input and filter for pe active rather than the default

[kur4o]

As you are already there please adjust the maf scaling in the analyzer from 0 to 77 cells. I have finally managed to convert the maf cell scalar to human readable and now it shows a value from 0.00-77.00 with the values after the dot showing the interpolation factor between 2 adjacent cells from .00 to 0.99.


So if the value reads: cell 9.50, it means the maf value that is being used is taken exactly at the mid point between 9 and 10 cell. That way you can accuartely nail the maf curve. Also the fast tps changes must be excluded from the analysis, maybe adding some delta tps calculations with a threshold. With fast tps change the maf values change is smoothed down and does happen slowly over time.

[steveo]

are you suggesting changing from afgs/trim to hz/trim??

right now there is no real cell analysis for the maf in eehack

[kur4o]

For sure It will be very cool to do it. Actually it will be exact cell number instead of hz/trim so 1468hz will be cell1, 1616 will be cell2 and so on. You will even know the exact interpolation between adjacent cells.
I will slightly modify the patch to include the maf cell/hz value in the datastream.

Right now I have it streaming at byte 34 and 35 and the conversion looks like
34,MAF_FREQ_CELL,MAF CELL,,BASIC,16,2,0.00380625,1,0x00,0xFF,,1,77,1,77

the ditched bytes are really unused
34,B34RAW,Unused Byte 32,,HACKER,8,0,,,0x00,0xFF,RESEARCH,,,,
35,DIAGO2B,Post-Cat O2 Voltage (Corvette),mv,EXTENDED,8,0,4.44,,0x00,0xFF,,,,,
So it is not a big deal loosing them.

[steveo]

it'll be a bit of a pain as i need to handle both original and patched bins (so the old maf analysis has to stay too) but i'm into it. email me the patch and tell me how it works

[steveo]

email received and im looking into it

[steveo]

hey im getting a bit involved with the analyzer and im thinking that i’ll just write a bit of extra code to allow the user to apply VE, MAF, and maybe even knock event changes directly to the bin. the stupid thing needs a rewrite anyway so i figure why not. i would leave smoothing up to the user. what do you think about that?

[JackOfAllDaves]

Hi Steve, Im brand new to this forum only minutes after downloading your $EEHack software. I am a semi retired old guy, closed my shop in 1986. Since building my dream shop two years ago, ive attracted a few customers, this one a 1996 Camaro SS Z28 with a 16214399 ECU. We had to rebuild his stock LT1 motor into a 383 Stroker kit by Eagle. Consequently, I had to furnish it with PaceSetter headers, thus a myriad of changes to displacement, fuel management, o2 sensors, and deletion of Air Pump, etc.

I am expecting to spark it up first time tomorrow. I almost ordered in a HP Tuning kit for $399 from Summit, but I may never see one of these again, who knows? Can you help me? Is your $EE software compatible with reprogramming, flashing the EEPROM on this unit? I was a network analyst computer guy for 25 years, so I would enjoy doing this. I don't have any ALDL cables or anything yet, so some direction would be helpful. Look forward to hearing from you or anyone else on this thread. Cheers!

[steveo]

nope. you’d need to swap to a 1994-1995 16188051 ecm

[NomakeWan]

That sounds awesome! Especially being able to apply the changes to the bin directly for MAF stuff. VE is already easy as heck, if MAF were that easy...WEW.

[steveo]

here's a new beta. the analyzer ui is getting better. i've matched the ve analyzer to the actual ve table size (a common request) which will make this bin changing thing a lot easier.

http://fbodytech.com/eehack-beta-4-8-4/

implementing the changes directly to the bin is sketchy for sure. still not sure if i'm going to do kur4o's maf thing in this release or not. i'm not sure how much babysitting to do. i'll get a prototype and you guys will have to see how it works out....

[steveo]

i've come to a decision, no more new features in this beta. there are too many important improvements in here to wait for release any longer, such as checksum calcs.

if you guys are okay with it (PLEASE FIND MORE BUGS) i'll make it the new 'official' version while i start the next version.

the next version will have some more serious changes that'll need more testing...

first off i'll add tuning functionality including kur4o's MAF patch along with a user interface and automatic bin tuning (but a bit different than he's been thinking, i think i will only enable it in my alternate 'speed logging' datastream message).

the goal will be to allow someone to log a bunch of driving, click a button, and instantly have their MAF recalibration complete outside of power enrichment range with no playing around (assuming healthy engine and o2 sensors). i think new tuners will really appreciate this one. i'll force a bit of curvature in the result and reject delta TPS events as suggested to ensure accuracy. automatic VE tuning will also be done and it'll be smart enough to know if we're in speed density not to tune the maf (or tune VE if we're using maf metering)

this stuff wont be hard to pull off but i need to spend quite a bit of time testing it thoroughly as one wrong move and i'm writing crap outside the table in question and silently borking the bin. the VE table is split too so i need to figure out the best way to manage that 2000rpm shared border.

even bigger than that is i've been looking at the flash routine and i have some ideas. i can make it much more safe and recover more gracefully with all of the things i've learned since i've written it. i'll add an advanced mode so the user can manually control the procedure, do better tracking of the current ECM state and handle responses from the flash kernel better, and guarantee continued execution of the flash kernel until successful or quit, so unless we drop power from the ECM or the chips wont erase anymore, persistence will eventually succeed. right now in some error states, it goes to reset the ECM which is a really dumb thing for me to have done in hindsight. i'll have to add some controls in eehack to allow jumping into an already executing flash kernel, right now it wont do that and that's a huge limitation.

the other thing i want to do (probably need kur4o's help....) is to write a recovery image that's as small as possible, that allows us to get the flash routine up and nothing else. that way if a flash becomes sketchy and the entire bin can't be written, we have something to write in as few blocks as possible so the ECM isn't bricked and can be repaired once we figure out what's wrong. another alternative idea although not sure how well it'll work would be to write things in a very specific sequence so executable code gets written first, and tables and 'engine running only' code get written last to increase chances of a brick being recoverable if we just bail out.

i will need to rebuild my test bench and find a (maybe socketed) working ECM to develop the flashing functions. actually something with fried injector or fan drivers would be idea since it'll never go into a car. anyone have a loaner i can borrow for a few months? otherwise i'll just buy something on ebay and sell it later.

[Terminal_Crazy]

Evening Stevo

Just downloaded v4.84
On the front page it shows v4.80 (Pre-release)

Also, I guess it's a QT issue, Is it possible to be able to Copy & Paste data from the Analyzer tables as I track & record changes.
or save the Analyzer pages out into a text file, similar to the way notes are saved ?
or saved out with the notes.

Requests for the next version:
Additional Wideband display on the main page as you have left a space for it.
Wideband display AFR / Lamda toggle.

Does the Knock warning button work? I've never seen the screen flash.

Oh yeah, and the secret 100HP boost code button... I need that for Christmas to upset the LS fanboys.

Pretty damned sweet otherwise my friend.

Thanks
Mitch

[steveo]

i can work on copy paste tables for next version

knock warning has been broken for a long time

dual wideband display could happen but low priority

[NomakeWan]

Tested 4.84 on the way to work. Fixed the speedlog bugs from the previous version, both on the dash and in the analyzer! Honestly it looks great. Thank you again.

Can’t wait to test out the new flash routine once you figure it out. I look forward to being able to flash troublemakers like my ‘94. Keep on keepin’ on!

[kur4o]

Nice ideas Steveo.

The best improvement will be to keep the flash routine indefinite in the pcm and continue from there with new aldl cable and PC in case some of these fail midflash.

For a mini bin version you need the last 64 bytes programmed correctly for anything to work. These are the pointers for reset and some of the other interrupts. We can change them all to point to mode 5 loop, but have no idea if it will work. The pcm might need some of the config routines executed at reset.

[steveo]

i really like the idea of a nonvolatile recovery image we write first. i wonder if we can temporarily create a rebootable failsafe loop with an exit by jumping to a 16 bit address ending in FF and the last thing we do is write that ff to the new address...? or is there a better way? test for a byte we set last and loop if its FF ?

[NomakeWan]

Not sure if it's my end or something else, but figure I'll point it out. In 4.84 (and possibly older versions, I haven't tested yet) with the latest patch, if I try to snapshot E-Side I get an error. If I try to stream E-Side the error counts just pile up. No Data is all that gets displayed. This happens whether the car is running or not. Is this expected behavior? I've never bothered with any E-Side stuff, but I poked at it while sitting in my driveway and noticed this, so I figure better to bring it up than not.

[steveo]

if patched it should work with engine not running however the error might be because there's no actual datastream definition for the e-side yet.

[steveo]

alright screw it i'll just release this new version so everyone can roll with it

i'll throw the hammer down on the next version once i reassemble my test bench

i'll call it 4.9 because it' been so damn long since the last release!

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

[steveo]

4.9.1 is now on the download page and fixes a small bug i missed in the new VE analyzer

[NomakeWan]

Found another bug today. If you attempt to run the cylinder balance test while Speedlog is enabled, EEHack crashes completely.

[steveo]

ah thanks, that's weird. i'll fix that in the next version too.

[kur4o]

Hi steveo,

I am trying to log eside while engine is running. I managed to make eside talk with some extra work.
I have some issues with playback of logs.
When I open eehack and haven`t connected yet eside tab says No definitions available. When I try to play a log I got the same message too and no playback is possible. I am trying to use it with 4.7. Is this fixed on the newer version.

[steveo]

did you add any definition for the e-side?... i never had any (so i just put the tab there)

it's never been tested

[kur4o]

I test it with the built in test definition for eside, but have plans to add more. The definition is small one like 17 bytes or so. You provided it with the first version of the definition file. I plan to add a definition for the f-body abs module but suspect it might not work as the eside currently.

[steveo]

that's possible. i never really tested any of that. if i have time soon i'll look through the code and see what the problem is. i'm really close to having my $EE test bench set up again so i can debug it a bit, just waiting on a shipment of serial interfaces from china as I seem to have loaned out or lost my last one.