nope it just reads the byte from memory
if you change the target it should read properly
nope it just reads the byte from memory
if you change the target it should read properly
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.
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.
Last edited by lionelhutz; 05-30-2019 at 07:43 AM.
kur4o, I love you like a brother, but you just made my central nervous system segfault.
This is essentially a true statement. Oxygen sensors tell the ecu when the combustion process is at stoich. Stoich = 0.454v. Agreed?
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).
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.
I would hope at closed loop it is at whatever values are stored in the "stoich afr target" table.
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.
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
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?
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).
Last edited by spfautsch; 05-31-2019 at 01:06 AM.
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
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.Remember some of the settings. Com port, Log folder, Bin folder.
want more details about com port not being remembered
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.
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"".
Stuff i did fix today:
Code:- 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
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.
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.
I’ll definitely download this and give it a shot! I love EEHACK!
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
Bookmarks